Idea: Monitoring HASS restarts

[terba]

I have an idea of a light solution for the HASS restart problem: hass-tracker could periodically query an Uptime Sensor (ideally counting in minutes), and if the actual value is less than the last one got, then hass-tracker could do a synchronization.

This can be an optional thing in /etc/config/hass-tracker like:

        option uptime_sensor 'sensor.uptime'
        option uptime_check_interval '00:05'

[SaturnusDJ]

Would be nice. 👌

Alternatives:

1. Use the HA SSH component to login on the router and force a sync. (Not tested.)
2. Idea like Monitor, MQTT maybe #31 MQTT rebuild of this project.

[quthla]

The issue should be fixed in HA itself because that's what's causing it.

1. Use the HA SSH component to login on the router and force a sync. (Not tested.)

I did that before I fixed the issue. It does work

2. Idea like Monitor, MQTT maybe #31 MQTT rebuild of this project.

That might bloat the size of the module up too much especially for devices with little space

[terba]

The issue should be fixed in HA itself because that's what's causing it.

You are right, HA should at least persist the states of device trackers between restarts. But it doesn't do that.

1. Use the HA SSH component to login on the router and force a sync. (Not tested.)

It has to work. But I think it isn't a secure approach to let HA log into the heart of the network.

2. Idea like Monitor, MQTT maybe #31 MQTT rebuild of this project.

For me this would be the best solution with retained publishes to the queue. But it is much more work. That's why I suggested this simple solution, nearly everything is already there to do it (token, URL etc).

[quthla]

The issue should be fixed in HA itself because that's what's causing it.

You are right, HA should at least persist the states of device trackers between restarts. But it doesn't do that.

Because it's broken and must be fixed and then no workarounds are needed.

[SaturnusDJ]

Related to home-assistant/architecture#230?

HA has some flaws at the core that they seem kind of unwilling to change.

[quthla]

Related to home-assistant/architecture#230?

HA has some flaws at the core that they seem kind of unwilling to change.

Not related but that also annoys me. There's an issue specific to device trackers in the HA repo. I also posted my code to fix it there.

[2sheds]

1. Use the HA SSH component to login on the router and force a sync. (Not tested.)

It has to work. But I think it isn't a secure approach to let HA log into the heart of the network.

Except it can be made sufficiently secure. SSH itself provides robust restrictions mechanism which will grant the key only the necessary permissions. This got me thinking so I implemented a simple AppDaemon script that runs sync_state via SSH on every HASS restart: https://gist.github.com/2sheds/4b6e738c57e731d68e294ff728e35536

[quthla]

1. Use the HA SSH component to login on the router and force a sync. (Not tested.)

It has to work. But I think it isn't a secure approach to let HA log into the heart of the network.

Except it can be made sufficiently secure. SSH itself provides robust restrictions mechanism which will grant the key only the necessary permissions. This got me thinking so I implemented a simple AppDaemon script that runs sync_state via SSH on every HASS restart: https://gist.github.com/2sheds/4b6e738c57e731d68e294ff728e35536

Looks pretty neat but I guess it was more work than to just fix the root cause in HA itself.

[2sheds]

Looks pretty neat but I guess it was more work than to just fix the root cause in HA itself.

Well, the "root cause" may be worth fixing but I'm not exactly in favor of my router polling HA server every 5 minutes to check its uptime. Looks like a lot of overhead when a targeted listener event can be attached with AD (as demonstrated above) or by an automation triggered on HA start. Happy to provide a PR if deemed useful.