You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's have a udp.data_transmit action to simply pass arbitrary data to another node (supporting the addresses: field).
An on_data_received trigger (under udp: > providers: > - name to know which provider to expect the data from).
Support the same types as the sensors, eg. binary, float, string (maybe integer? specify type: on both ends maybe like globals are?). Print an error to the log when the data is too big. (adding a warning in the docs)
Eventually configurable, on_data_received should only trigger for data sent by data_transmit from the provider, not the sensors. Moreover, we could support accepting and sending raw messages, to possibly integrate with third party systems communicating via UDP (eg. BrightSign)
Possible use case would be for transmitting actions, not states. For example to relay IR remote signals to a blaster in another room. Or to transmit button presses. Or in conjunction with key_collector transmit the collected keys as string to another node in an encrypted form (say you have an alarm panel in lvgl near the door, but the alarm itself is another node). Also the second use case (covers) from #112 could be less cumbersome if we had this.
The text was updated successfully, but these errors were encountered:
Let's have a
udp.data_transmit
action to simply pass arbitrary data to another node (supporting theaddresses:
field).An
on_data_received
trigger (underudp: > providers: > - name
to know which provider to expect the data from).Support the same types as the sensors, eg. binary, float, string (maybe integer? specify
type:
on both ends maybe like globals are?). Print an error to the log when the data is too big. (adding a warning in the docs)Eventually configurable,
on_data_received
should only trigger for data sent bydata_transmit
from the provider, not the sensors. Moreover, we could support accepting and sending raw messages, to possibly integrate with third party systems communicating via UDP (eg. BrightSign)Possible use case would be for transmitting actions, not states. For example to relay IR remote signals to a blaster in another room. Or to transmit
button
presses. Or in conjunction withkey_collector
transmit the collected keys as string to another node in an encrypted form (say you have an alarm panel inlvgl
near the door, but the alarm itself is another node). Also the second use case (covers) from #112 could be less cumbersome if we had this.The text was updated successfully, but these errors were encountered: