ESPHome commands are not guaranteed - what workarounds?

ESPHome
21

what I am going to do is rewrite this test/demo thing as a push button - the esp32 will have a button that then toggles D2 this is more like how my irrigation system runs - I’ll also change it to distinct button push instead of all in an area
I push a button the esp32 then turns on the solenoid for 5 mintues and turns it off, If I push the button twice it on the lacelot interface the esp32 does it for 10 minutes, it also will only turn one solenoid on at a time - and queues up all the times
the issue is when I eventually try and automate the actual watering based on weather. - one of the watering areas is a nursery of seedlings, missing one day will kill them, if I trigger and it does not happen , I dont get an alert - so now I have to code to cope with that

I’ve already had a esp32 crash in the middle of a download I was also silly enough to have the solenoid powered on - so I have plans to put my power supply on a zwave controlled switch
My house has a pump for water (pressure switch controlled) - so I’ve got a CT transformer on it to tell me if the water runs for too long/unexpectedly

22

if the nursery is critical you should add a moisture sensor or some other monitor to check soil or whatever condition is useful.

23

could this be helpful?
API Action Responses

24

Thanks for all the responses - as a summary for the answer to my original question which was
“So it appears commands don’t always get actioned I cant see any error messages Is this expected, accepted as normal and is there any simple way to cope with it ?”
The general consensus is ESPHome communication are not reliable , it is accepted as normal for commands to not be actioned and for there to be no notification to the user of a failed ESPHome command. The workaround is to accept intermittent failures and if such failures are not acceptable , use additional hardware , multiple retrys (Again with no feedback on failures) or program in the send /ack response to confirm command actions

25

I’ve changed the include file to

logger:
    level: debug
api:
    encryption:
        key: !secret api_encryptionkey

esp32:
  board: esp32dev 
  framework:
    type: esp-idf
    advanced:
      minimum_chip_revision: "3.1"
ota:
  - platform: esphome
    password: !secret ota_password

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "RJWESP_${mac_suffix}"
    password: !secret wifi_password
captive_portal:

time:
  platform: homeassistant
  id: homeassistant_time
  on_time_sync:
          then:
            - logger.log: 
                format: "Time Sync"
                level: INFO
            
            
switch:
  - platform: gpio
    pin: GPIO02
    name: "On board D2"
    id: d2
    
binary_sensor:
  - platform: gpio
    pin: GPIO0
    name: "On board Boot"
    id: boot
    
button:
  - platform: template
    name: "Toggle D2"
    id: esp32oom_toggle_d2_button
    on_press:
    - script.execute: esp32oom_toggle_d2_script

script:
  - id: esp32oom_toggle_d2_script
    mode: single 
    then:
        - switch.toggle : d2

and the automnation to

alias: Every five seconds push buttons
description: ""
triggers:
  - trigger: time_pattern
    seconds: /5
    minutes: "*"
    hours: "*"
conditions: []
actions:
  - action: button.press
    metadata: {}
    target:
      area_id: espdevelop
    data: {}
mode: single

Once I see thay they are all reprogrammed ill then change to

alias: Every 5 seconds  press individual buttons
description: ""
triggers:
  - trigger: time_pattern
    seconds: /5
    minutes: "*"
    hours: "*"
conditions: []
actions:
  - action: button.press
    metadata: {}
    data: {}
    target:
      entity_id:
        - button.temp_2e8994_toggle_d2
        - button.orchard5_toggle_d2
mode: single

This then matches my watering code being
HA: If need watering ESPButton.Press

The consensus is that the ESP may not receive the pusbutton command - but I will report back

26

I don’t believe that was the consensus

27

my question was “does Comms to the ESP fail?” the the responses are all you must program to cope with failure

28

I still think, you are barking up the wrong tree. Esphome device can’t do anything if it doesn’t receive the command in the first place. Of course you can program some heartbeat function if you want.

But best approach is to build all automations on esphome and only adjust them from HA (or other instances).
For example my irrigation has schedule to water twice a day at certain times hardcoded to esp. I can interact from outside, I can postpone, cancel or extend one shoot. So if my rain sensor or weather automation sends a message to esp >> “skip next watering”, esp skips it. If it doesn’t receive anything, it goes with hardcoded program.
I can call for “manual” watering as well, but only with duration parameter included. So any connection issue never leaves watering unintentionally on or off.
Esp needs only wifi once in a while to keep time in synch with sntp, for the rest it’s autonomous. Neither time synch is essential.

29

I still think your test results are very weird and that in my experience communication with WiFi devices, including esphome, is very reliable in general.

However, for critical use, such as discussed here, it’s always better to have some extra safety net.

1 Like
30

I can confirm that the button.push commands also fail with no notification

My irritation with this issue is
HA determines watering is needed HA sends a push button command to the ESPHome device, The pushbutton runs a script on the ESP,This script turns on the solenoid, check the water flow , waits the appropriate time, turns off the solenoid, again check the flow and raise alerts as needed , so safe enough , it also counts how long the solenoid is on for and ensures only one solenoid is ever on but will honor all pushbutton triggers as soon as possible

But the bold step may not occur - and I need to check if it happens - but I cant do that in the ESP , where most of the safety checking is - it must be done in HA

This is trivially easy to do in the actual send/send ack of TCP communications that should be being used - a message or retry loop could then be added (I still need to check what you posted)
But for me to do it - makes my code needlessly complex.
Roughly - I have to wait due to comms , I have to do something in the ESP to set a flag that HA will read and let the HA Trigger script see that the command worked
A whole lot of extra steps - in HA and ESPHome

I’ve got code in HA now counting how many of the LEDs have toggled - I have to wait a second after I send all the Pushbuttons , I’ve got two out of sync in an hour (Every 5 seconds , 9 devices) not very often but it happens - If I count straight after the send pushbutton script - some of the states have not reported back , so I need to wait

Now that I’ve confirmed pushbutton can fail - I’ll look at the error handling you have pasted

31

Based on this I would say this is code(yaml), network or device issue. If there is one thing that is reliable with esphome it is binary sensors, buttons and switches.

These are WiFi correct? RTT / Ping. How is that?

What PC you using?
Lots of addons /integrations?
What about connected cameras or AI.

How is water needed determines?

Add a step. Two butttons

HA turns on button to start process
Esp turns on button to confirm received (if this doesn’t occur trigger already…done)
Esp turn off button upon completion (alert if not done)

You can alert and retry at same time or other steps.

1 Like
32

I can fix it - I am not looking for advice on how to code this what I am saying is
it should not be necessary
Commands between one processing platform and another processing platform should be “reliable” - by which I mean if it does not happen I get told
I don;t mean it “always works fine except when things are a bit noisy and then you need to fix your network”
! mean it ALWAYS works fine - and failures due to bad networks disconnection are alerted

The ESP runs the code asynchronously - it may water an hour after the request is sent It is not relevant to this discussion how the HA determines if watering is needed

This screen shot shows how often it fails it should be 9 or zero - so all the short points are where it is failed

image
image729×255 24.7 KB

The 9 devices are very close together in a room with a metal roof and the Access point
There would be a lot of reflections, it fails a lot more when I sit down in from of the devices
The code is making it worse as it is guaranteed all 9 commands are sent one after the other
It may be that out in the garden with unsynchronized commands this happens much less often
To me in the context of I send a command - it should happen if not I get an alert I can see that no one agrees

33

I agree with you. However, that appears to NOT be how esphome works. I was going to suggest that you use MQTT, but it has the same issue (maybe more).

Every component/system makes some level of “promise”. If that is good enough for your use case, you don’t need to do anything special. If not, you need to find some way of making a stronger/better promise.

I have an esp8266 based device reading my water meter. I see it disconnecting from MQTT occasionally and I see it not sending updates when it should quite regularly. I have another one nearby that appears more reliable. I have many Tasmota based ones. A couple dozen of them are incredibly reliable and only disconnect on power failure, but two of them are more problematic.

None of the devices are doing things where the occasional dropout is a real problem, but they still concern me.

esphome is designed for ease of use, so it’s not clear what it could do that would be easy enough to use when there is a failure to communicate. It does reboot if it loses communication for a long time.

MQTT does offer the option of a stronger promise, but that also requires additional logic/code at the higher level of what to do if it still doesn’t work. esphome doesn’t appear to have any logic for dealing with failure at the user controlled level (other that just rebooting).

It seems if you care this strongly, esphome is not a good fit. Tasmota likely isn’t either. You might be better off creating your own project that does exactly what you need. I am pretty sure the lower level libraries make a promise that would be acceptable to you. You will, of course, need to also provide all the middleware logic/code in addition to your user problem specific logic/code. I didn’t want to do that, so I use esphome. I have not been impressed with esphome reliability. It generally works but I find Tasmota much more reliable. However, I find developing custom code for the esp32 much easier with esphome (than with Tasmota).

34

I will ask this again, since maybe you didn’t see it. You mentioned that you are using Unifi APs, so:

35

General comment: I suspect you are ignoring Arthur Clarke’s third law, expecting far too much from your toys you are playing with.
Watering systems on timers and moisture sensors do not need home automation as an essential service to make them function.
Your network equipment features in a lot of reported problems.
Your code and integrations in HomeAssistant seem to be following a steep learning curve.
Maybe ESPHome constantly changing parameters is not for you yet?

You have too many unknowns in your scenario to be able to lock in a reliable solution. Too many points of potential failure.

Maybe break it into smaller chunks, get each working reliably, and then string them together?

1 Like