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
Allow provider: item in the udp sensor/binary sensor configuration to also accept a list of providers. Reason is to accept data from multiple source nodes into the same sensor (from provider sensors using the same id).
Some use cases:
Retrieve BLE sensor values through multiple "proxies" (for redundancy + enlarge coverage)( notbluetooth_proxy! ):
multiple BLE sensors placed around the house (~10)
catching signals with multiple ESP32 nodes (wired, wifi), as internal sensors pass data forward via UDP
get the UDP messages on an ESP32 node which implements thermostats to control the various heating zones around the house. Only at this point present the sensors data to HA, along with the climate components.
Another use case is control of various RF motorized covers from multiple locations:
have a LVGL/Nextion/pushbutton based wall controller, in each room, with UP, STOP and DOWN touch buttons for each cover. Some of the covers can be controlled from multiple such controllers.
have a central ESP32 node running an rf_bridge or remote_transmitter to transmit the signals, implementing Time Based covers towards HA
for each cover's button/function use a number. Eg. for cover1 use 1001 for UP, 1002 for STOP and 1003. For cover2 use 1011, 1012, 1013 etc. A text_sensor could proabably make life easier with strings.
each button press will update a template sensor on the display's node with the corresponding number. The sensor's value is provided via UDP to the RF transmitter node, where with on_value it's gonna know what's the desired action to perform.
Would be handy in the UDP receiver / RF transmitter node to be able to pipe in values from the different provider wall controllers into the same udp sensor:
Allow
provider:
item in theudp
sensor/binary sensor configuration to also accept a list of providers. Reason is to accept data from multiple source nodes into the same sensor (from provider sensors using the sameid
).Some use cases:
Retrieve BLE sensor values through multiple "proxies" (for redundancy + enlarge coverage)( not
bluetooth_proxy
! ):internal
sensors pass data forward via UDPCurrently this works using:
Would be very handy if we could just simply have:
Another use case is control of various RF motorized covers from multiple locations:
rf_bridge
orremote_transmitter
to transmit the signals, implementing Time Based covers towards HAon_value
it's gonna know what's the desired action to perform.Would be handy in the UDP receiver / RF transmitter node to be able to pipe in values from the different provider wall controllers into the same
udp
sensor:Of course this has
update_interval: never
set on the providers side to avoid repetition of commands.Both cases focus on increasing reliability by keeping the system operational even when the HA instance is offline for any reason.
The text was updated successfully, but these errors were encountered: