Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FR: udp sensor from multiple providers #112

Open
nagyrobi opened this issue Jun 14, 2024 · 0 comments
Open

FR: udp sensor from multiple providers #112

nagyrobi opened this issue Jun 14, 2024 · 0 comments

Comments

@nagyrobi
Copy link

nagyrobi commented Jun 14, 2024

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! ):
kép

  • 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:
kép

  • 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.
  - 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant