Description
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)( not bluetooth_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.
Currently this works using:
- platform: udp
id: kamra_through_proxy_1
provider: provider-proxy-1
remote_id: temp_kamra
on_value:
- lambda: |-
id(temp_kamra).publish_state(x);
- platform: udp
id: kamra_through_proxy_2
provider: provider-proxy-2
remote_id: temp_kamra
on_value:
- lambda: |-
id(temp_kamra).publish_state(x);
- platform: template
id: temp_kamra
name: "Kamra temperature"
state_class: measurement
unit_of_measurement: "°C"
device_class: temperature
accuracy_decimals: 2
Would be very handy if we could just simply have:
- platform: udp
id: temp_kamra
provider:
- provider-proxy-1
- provider-proxy-2
name: "Kamra temperature"
state_class: measurement
unit_of_measurement: "°C"
device_class: temperature
accuracy_decimals: 2
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
orremote_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.
- platform: udp
id: room_cov_command
provider: lcd-panel-room
remote_id: cov_command
on_value:
- lambda: |-
id(cov_command).publish_state(x);
- platform: udp
id: hallway_cov_command
provider: lcd-panel-hallway
remote_id: cov_command
on_value:
- lambda: |-
id(cov_command).publish_state(x);
- platform: udp
id: kitchen_cov_command
provider: lcd-panel-kitchen
remote_id: cov_command
on_value:
- lambda: |-
id(cov_command).publish_state(x);
- platform: template
id: cov_command
on_value:
- lambda: |-
switch (int(x)) {
case 1001:
id(cover_room).make_call().set_command_open().perform();
break;
case 1002:
id(cover_room).make_call().set_command_stop().perform();
break;
case 1003:
id(cover_room).make_call().set_command_close().perform();
break;
case 1011:
id(cover_hallway).make_call().set_command_open().perform();
break;
case 1012:
id(cover_hallway).make_call().set_command_stop().perform();
break;
case 1013:
id(cover_hallway).make_call().set_command_close().perform();
break;
//...........
}
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:
- platform: udp
provider:
- lcd-panel-room
- lcd-panel-hallway
- lcd-panel-kitchen
id: cov_command
on_value:
- lambda: |-
switch (int(x)) {
case 1001:
...............
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.