Mikrotik does not restore states

[tjorim]

The problem

When rebooting Home Assistant Core, I end up with a lot of unavailable entities. In HA 0.104 and older (with legacy device_tracker) this wasn't an issue and old states were restored. Now I have a bunch of entities with the following message:

This entity is currently unavailable and is an orphan to a removed, changed or dysfunctional integration or device. If the entity is no longer in use, you can clean it up by removing it.

Entities stay that way until the device connects back to the network (state = home) and leave after that (state = away).

Environment

• Home Assistant release with the issue: 0.105.3
• Last working Home Assistant release (if known): 0.104.x
• Operating environment (Hass.io/Docker/Windows/etc.): Home Assistant (Hass.io) on generic Linux
• Integration causing this issue: mikrotik
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/mikrotik/

Problem-relevant configuration.yaml

Set up using config flow.

Traceback/Error logs

NA

[probot-home-assistant]

Hey there @engrbm87, mind taking a look at this issue as its been labeled with a integration (mikrotik) you are listed as a codeowner for? Thanks!

[engrbm87]

Hello @tjorim ,
Restoring the state of a device_tracker while the integration is unavailable will not provide the current state of that device (it might be currently away while the last state was home). If the entity state is unavailable this means either the integration is unavailable (disconnected for some reason) or the integration is not updating the state of this entity in which case you may need to check the reason for that.

[tjorim]

There are no errors in the log. Devices that are still connected show up as home fine. However, devices that are unavailable should be marked as away instead, because they are not available on the network, because they are disconnected.

[engrbm87]

If these devices were created from the previous integration and have not been discovered by the new mikrotik integration (which doesn't use known_device.yaml and uses the entity registry) then they will show as unavailable and should be removed. New devices will show as away if they are disconnected from the network.

[tjorim]

I started clean, removing old integrations and known devices. Yet devices show as unavailable instead of away after a restart. Once a device has connected again, marked as home and disconnects, it is marked as away instead of unavailable (until the next HA restart).

[vampywiz17]

Same problem, possible to solve it? It make harder to automate a lot of things.... (in need to handle unknown state every time...)

[tjorim]

Issue should originate here: https://github.com/home-assistant/core/blob/dev/homeassistant/components/mikrotik/device_tracker.py#L28. Looks similar to unifi yet it doesn't work: https://github.com/home-assistant/core/blob/dev/homeassistant/components/unifi/device_tracker.py#L54

[engrbm87]

For the mikrotik integration the all_devices list is maintained from the DHCP server leases. If the devices showing unavailable on startup are not in the router DHCP server Leases then you can simply make the lease as static so that it doesn't get removed.

[bigboban]

Same issue for me. My observation is device-tracker entitites from Mikrotik integration are NOT in know-devices file. Before restart all works great - presence home/not home works fine. But after restart if device is away entity goes to Unavailable state.

Unusable device-tracker integration for me. 👎

[damousys]

I have also this issue
I use the Wi-FI only option because there is no DHCP on my Router / Acces Point
HA Release 114

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.