manually send a udp command to node-lifx to turn on a light

[mariusrumpf]

manually send a udp command to node-lifx to turn on a light

[ristomatti]

It seems superfluous to add a udp listener myself ontop of the already instantiated existing udp listener in node-lifx...

Could you describe in more detail what are you trying to achieve? The library does not have a network API that would listen for external commands commands. It binds to a UDP port for sending commands to lights and receiving status request responses.

To achieve what you describe, you would need to create some proxy/wrapper around the library. I cannot speak for @MariusRumpf but I doubt there are any plans of adding this type of functionality. I think it would be better suited for a separate module and would likely be a marginal use case.

[MariusRumpf]

I am with you there @ristomatti this is nothing we support, or which I see make sense for a broader audience. Besides this if needed one might write a wrapper library which does this.

[koraysels]

But in the cli.js example there is a listener already setup? And if i create another udp listener i have to chose another port which is not supported by my home Automation System. This library uses the node udp4 package So it has a listener. If i send commando to it it does somthing with it.. like in cli.js i just was wonderkind what it does and hoe it expects the udp call to be formatted. The rest i will weird myself. This is more a request for help than a feature request. Because i think it is already there....

[MariusRumpf]

The Client class opens the udp4 socket, right. It keeps it itself as reference in the socket variable found here. You can get that socket from there in your wrapper library.
This library adds his own message queue to support rate limits for sending and message listeners in order to keep track of bulb states. This might be a problem for you when using the same socket. Another problem when using the same port would be that you send your udp message to the lifx lights too, since the processing capacity of the lights is limited and you "spam" the traffic with unneeded packages besides the unknown effects to the message content. I would not go for an approach like this where you use the same port.