Alternative to api: reboot_timeout for network availability detection?

ESPHome
6

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: