I have a bunch of a light modules installed in my house - all working great. In order to preserve flash memory, they’re all configured to do no state preservation at all. This works fine.
The problem is if my Home Assistant instance is down, then the 15 minute api: reboot timer causes the lights to flicker during the reboot cycle, since during reboot they turn the relay off then on.
I understand the reason they do the reboot is to deal with failures where wifi connectivity doesn’t fully complete but reports success spuriously: my question is if there’s a way to implement this feature without depending on Home Assistant connecting specifically - i.e. instead sending an ICMP ping to my network router, or checking if the HTTP server has been connected to instead?
Basically, can I separate the “network is actually up check” - which I do want - from specifically needing Home Assistant to be up (since in terms of uptime, my router is always going to be up in some way).
What I am saying is - sure, go ahead and do any reboots as needed etc, I thought you were saying that about reboots because of crashes or other issues.
If the issue also is lights toggling when it reboots why do they toggle? If it’s because of the way the logic is written then the logic needs to be improved. There’s no reason at all why any kind of an alteration to home assistant (loss of power or reboot) would cause any light to change unless it causes the system to execute code written to make the lights go off and on. So, improve the way that code is written. Specifically exactly what is making them go off and then back on again?
During a reboot, the logic lines change state momentarily before the physical switch state is re-read, which results in a momentary off/on cycle if the light is on.
This only happens during an ESP reboot: so only during an ESP reflash (which is fine) or, if the timeout triggers. The timeout is a good thing - I could just set api.reboot_timeout=0 and this would prevent it from happening, but then I run the risk of an ESP network stack in a bad state requiring a manual reboot (i.e. I’d have to go toggle the switch to force a reboot).
The goal of my setup is that it should work “normally” if Home Assistant or most other things are down. The need to be able to reset the ESP network stack automatically weakens that requirement a little, but of the “always on” devices on my network, the network router responding to pings has more uptime then my home server.
It looks like I could disable the API timeout and just leave the wifi connect timeout, but since the same option exists for HA and MQTT apis, a positive network check seem like it’s generally desirable. But it looks like possibly this feature needs to be implemented (send ping to target).
I thought there was something like that - that cannot be helped - OMG that sucks… But I think I have the solution you are looking for below -
You can create a command line sensor in your configuration.yaml that would just issue a ping command and then look for a response. In the logic you would put the data into an input_text helper to save the information between HA restarts and so that the sensor value doesn’t change back and forth during reboots possibly causing unintended automation triggering -
(The “| cut -c-255” isn’t required in this case but just as a standard precaution I do that as a command line sensor cannot handle a value of more than 255 characters, and you could use a url if that is preferred over an IP address)
command_line:
- sensor:
name: ping_device_myesphome1name
command: ping ###.###.###.### | cut -c-255
scan_interval: 30
command_timeout: 5
# Then use an input boolean which may be better to use in your automation triggers -
input_boolean.esphome1_is_online = "bytes from" in value
#**** In rereading my post, the above line is actually not allowed as state sensors cannot directly update other objects, you would normally be forced to write an automation that does that. However, there is a new feature which allows you to get around this issue I have learned****
#
# value_template: >
# here the format of this sensor can be massage to be user friendly but not needed in your case
#
unique_id: ping_device_myesphome1name
This would tell you if it is live by updating an input_boolean for indicating same every 30 seconds - and your automation can trigger upon it becoming false. Then once you are finished debugging it, you could just set sensor.ping_device_myesphome1name to be hidden form the default lovelace view.
If you don’t want the input_boolean to be editable by default in the default lovelace view but still have it shown, you could instead make the value template return true or false for that sensor and not use an inpout_booean, or have another state sensor in which just shows the value of the input_sensor and hides the other two, etc.
Thoughts?
Note, where I entered **** in the above incorrect code snippet, I have recently learned that you can in fact cause an action to take place right within a state trigger sensor in the configuration.yaml file. I ghive an example of the syntax where I had done it in the below post:
can you help i recently started with home assistance i have esp32 with Peacefair Pzem-004t module(espHome) for power monitoring recently power outage occur for 10mins after power came the router take at least 2:5 min to boot but esp wont auto connect to ha/wifi. when i press EN button on esp32 it will connect back.