Flag for Packet Transport to only send once all values are updated

[ss89]

Component name

packet_transport

Link to component documentation on our website

https://esphome.io/components/packet_transport/

Describe the enhancement

I would like to have a flag for the packet_transport component, so that its update function will only execute once all mentioned sensors in the providers part were updated.
Currently the packet_transport provider component always sends all data.
A bool flag with a nice name (this is the hardest part i guess) could allow the ESPHome user to let the packet_transport component either send updates on each and every component or only on a final set of data.

Use cases

I am currently building a small ESPHome device with no connections to the outside world but a LoRa Module.

Current the device is using the packet_transport component to send the data to a receiving station to finally ingest the data into my HA.

It seems that the packets are often sent twice, because of me trying to make the battery last as long as possible (future improvements still coming).

Instead of wasting time waiting on the rather slow transport (and to reduce airtime in general) I'd prefer to let it only send data once all sensors in the provider section has been updated once.

Here's a demo config yaml:

esphome:
  name: lora-bme280
  friendly_name: LoRa-bme280
  on_boot:
    - priority: -100
      then:
        - sx126x.run_image_cal
        - sx126x.set_mode_tx
        - component.update: battery_voltage
        - component.update: bme280
        - delay: 1s
        - deep_sleep.enter: main_sleep
  on_shutdown: 
    - priority: 800
      then:
        - sx126x.set_mode_sleep

esp32:
  board: seeed_xiao_esp32c6
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_BT_ENABLED: n
      CONFIG_BLUEDROID_ENABLED: n
      CONFIG_ESP_ZB_ENABLED: n
      CONFIG_OPENTHREAD_ENABLED: n
      # CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ: "20"
      CONFIG_LOG_DEFAULT_LEVEL_NONE: y
      CONFIG_ESP_LOG_DEFAULT_LEVEL: "0"
      CONFIG_LOG_COLORS: n
      CONFIG_LOG_TIMESTAMP_SOURCE_RTOS: n
      CONFIG_LOG_BOOTLOADER_LEVEL_NONE: y

logger:

spi:
  clk_pin: GPIO19
  mosi_pin: GPIO18
  miso_pin: GPIO20

sx126x:
  dio1_pin: GPIO7
  busy_pin: GPIO9
  rst_pin: GPIO8
  cs_pin: GPIO3
  pa_power: 3
  bandwidth: 500_0kHz
  crc_enable: true
  frequency: 434000000
  modulation: LORA
  hw_version: llcc68
  rf_switch: false
  sync_value: [0x14, 0x24]
  preamble_size: 8
  spreading_factor: 9 
  coding_rate: CR_4_5
  tcxo_voltage: NONE
  tcxo_delay: 5ms

packet_transport:
  platform: sx126x
  encryption: "xyz"
  rolling_code_enable: true
  sensors:
    - battery_voltage
    - battery_percentage
    - temperature
    - pressure
    - humidity

i2c:
  scl: GPIO14
  sda: GPIO15

sensor:
  - platform: adc
    id: battery_voltage
    pin: GPIO1
    samples: 10
    attenuation: 12db
    accuracy_decimals: 2
    unit_of_measurement: V
  - platform: copy
    source_id: battery_voltage
    id: battery_percentage
    accuracy_decimals: 2
    unit_of_measurement: '%'
    state_class: total
    device_class: battery
    filters: 
      - calibrate_linear: 
          datapoints:
            - 2.8 -> 0.0
            - 3.3 -> 100.0
      - clamp:
          min_value: 0.0
          max_value: 100.0
  - platform: bme280_i2c
    id: bme280
    address: 0x76
    temperature:
      id: temperature
      name: "BME280 Temperature"
    pressure:
      id: pressure
      name: "BME280 Pressure"
    humidity:
      id: humidity
      name: "BME280 Humidity"

deep_sleep:
  sleep_duration: 59s
  id: main_sleep
  wakeup_pin_mode: IGNORE

Anything else?

Let me know what you think, challenge my approach. Maybe i'm just not getting it how to do it "the right way".

[github-actions[bot]]

🏷️ I've automatically added the component: packet_transport label to help categorize this feature request.

[ss89]

Or alternatively implement batch_delay as we have it for the api component

[nagyrobi]

I use update_interval: never on the packet transport instance so it doesn't send any packets by itself.

This way it only sends the packets when the corresponding sensors update.

packet_transport:
  - id: temp_sender
    platform: ...
    update_interval: never
    sensors:
      - temp_a
      - temp_b
      - temp_c

[nagyrobi]

Not sure why you do that...

[clydebarrow]

Well, if you ask it send twice then having a flag won't help :-) I can see some possibilities, but for now why not remove the second send? You will always have to trade off reliability of transmission over an unreliable channel against battery drain.

One thing I am already looking into is an acknowledgement mechanism to turn packet_transport into a reliable channel. That itself will cost you battery though, as you have to stay awake and turn the receiver on, so there's no magic bullet.

[ss89]

Well, if you ask it send twice...

I don't, that's my point.
I ask both the adc and bme280 component to get fresh values off their sensors.
I would love to query the sensors simoultaneously, but it seems that's not possible.
Why not have a delay possible like in the api component?

but for now why not remove the second send?

can you explain to me where you see me proactively asking it to send data? I only see me asking for updated sensor values.

[ss89]

Not sure why you do that...

do what? Component.update? That I do so that the adc and bme280 has fetched sensor values

[nagyrobi]

I first thought you're speaking about repeated send of the same sensor data.
If it's two sensors, it's two sends, with two different data. Regardless if you query them simultaenously or not.

As a quick workaround you could probably combine the two sensors into one with some math template, and then on the receiver side decode them back to separate sensors.

For example with

• batt percentage 0-100
• temp -40 to +70C

I would multiply temp by 0.01, so it goes decimal entirely:

• temp -0.40 to +0.70C

Then I would add up the values of batt with the small temp. For example 80% batt and 25.7C you'd get 80.257, that's the only value to send.
On the receiver side you do the reverse: to get the batt round it to low, to get the temp substract the rounded temp from the received value and multiply back with 100. And keep the negative sign only for the temp.

[clydebarrow]

oh, I also misunderstood, sorry. Will think about the best way to approach it, but your initial idea sounds reasonable.