llrp_manager_example: Enhancement request: New LLRP Manager Commands about rdmnet

[peternewman]

@vanvught in the short term, my WIP OLA PR will allow you to send this commands to a manager (and indeed ANY PID OLA knows about, whether it should be allowed or not). It's still very rough around the edges, but might get you going for now. OpenLightingProject/ola#1612

I'd suggest more broadly the manager should let you send ANY valid PIDs, I hacked the above set stuff in because someone wanted to test setting an IP address which currently isn't exposed via this either, the list will be endless as long as the supported list of PIDs (plus possibly wanting to test RDMNet support ones which shouldn't be allowed via LLRP.

[vanvught]

@peternewman Hi Peter, I will for sure give the WIP OLA PR a try.

send this commands to a manager

I suppose it will sends commands to a RDMNet LLRP device. No broker needed. Correct?

because someone wanted to test setting an IP address

The latest DMX Workshop from Artistic Licence can configure the IP address. One big disadvantage; it does not run on MacOS.

I am not interested in the full RDMNet implementation; it is a heavy-weight implementation with its (own) broker and it implies that there is a tcp/ip stack available. I do not have a tcp/ip stack and I have no plans writing a tcp/ip stack.

I really do like the llrp_manager_example; it is an easy to use, stand-alone, command-line utility, with a MacOS installer. It is perfect for testing and debugging my RDMNet LLRP only device enabled firmware.

cc: @samkearney

[peternewman]

@peternewman Hi Peter, I will for sure give the WIP OLA PR a try.

send this commands to a manager

I suppose it will sends commands to a RDMNet LLRP device. No broker needed. Correct?

Correct, as per the LLRP spec it doesn't require a broker.

because someone wanted to test setting an IP address

The latest DMX Workshop from Artistic Licence can configure the IP address. One big disadvantage; it does not run on MacOS.

Yep, I think it was that, or something similar, I can't remember exactly.

I am not interested in the full RDMNet implementation; it is a heavy-weight implementation with its (own) broker and it implies that there is a tcp/ip stack available. I do not have a tcp/ip stack and I have no plans writing a tcp/ip stack.

The responder doesn't need to run the broker, and it can just be built into the manager. Obviously the TCP stack would be needed.

I really do like the llrp_manager_example; it is an easy to use, stand-alone, command-line utility, with a MacOS installer. It is perfect for testing and debugging my RDMNet LLRP only device enabled firmware.

Yeah it was certainly invaluable during my initial testing.

I'd probably suggest any further discussion on the OLA option should happen on the PR and/or OLA issues.

[samkearney]

LLRP is meant as a bootstrapping method that allows the full RDMnet stack to be more "zero-conf". Typically it should not be used standalone. From ANSI E1.33 sect. 1.2.1:

LLRP does not provide a complete RDM-over-IP solution. It is not scalable or routable. It is not to be used for RDM messages beyond the minimum message set required to facilitate configuring a Component for connection and operation within an E1.33 network.

This is why the set of allowed messages over LLRP is limited to those in E1.33 Table 5-5. The two commands you have requested are in this table and therefore allowed, so we will merge your PR.

I am not interested in the full RDMNet implementation; it is a heavy-weight implementation with its (own) broker and it implies that there is a tcp/ip stack available. I do not have a tcp/ip stack and I have no plans writing a tcp/ip stack.

I'm assuming you mean you have a UDP/IP implementation but no TCP implementation, since LLRP requires UDP and IP. In this case it's understandable that you want to only implement LLRP, and I'm sure you have other valid reasons as well. Just keep in mind that the standard discourages this.

[vanvught]

Hi Sam,

In my firmware I have strictly defined the allowed PID's as shown E1.33 Table 5-5.

LLRP is meant as a bootstrapping method that allows the full RDMnet stack to be more "zero-conf". Typically it should not be used standalone.

I provide the RDMNet LLRP device only on my initial SDCard image for bootstrapping the visibility of the node in the network and then TFTP-ing the final firmware to use. I have also added the LLRP device only to the 'E1.31 sACN -> Art-Net bridge' firmware. Only at user request I will add LLRP to sACN E1.31 and Art-Net 4 node's.

I'm assuming you mean you have a UDP/IP implementation but no TCP implementation, since LLRP requires UDP and IP. In this case it's understandable that you want to only implement LLRP, and I'm sure you have other valid reasons as well. Just keep in mind that the standard discourages this.

With my open source in general, I am not using any third-party libraries at all. This includes not using the standard C/C++ libraries as well. Writing a TCP/IP stack is pretty time consuming. And for now, there are really no requirements for having TCP/IP. For example, the remote configuration of the node's is done by means of human readable UDP messages; hence you can easily script this on MacOS/Linux and mostly important: you do not have to loggin into each node individually (web browser).

Arjan

[samkearney]

Yes, I would strongly advise you against writing your own TCP implementation 😄

I'm glad llrp_manager_example has been useful for you. We will have a versioned build with your additions out shortly.

[samkearney]

The new binary packages are now available, version 0.3.0.9