[BUG] z2ma says 'This device is UNRESPONSIVE' even though the device is fine

[backcountrymountains]

Describe the bug

z2ma shows some devices as 'This device is UNRESPONSIVE'--sometimes for 10 weeks, since the device was added--but the devices are all currently working fine. Network map works fine. Where does the 'last_seen' information come from? How do I get more detailed logs?

Overall, I really like having this add-on. The yellow 'unresponsive' tag is just really getting to me.

To Reproduce

Steps to reproduce the behavior: Just open the web-ui

Expected behavior Show correct information about device connectivity.

Steps I took to try resolve the problem

I've restarted z2ma, but the unresponsive times remain the same. I've clicked the 'Reset Local State' button, but everything continues to show 'unresponsive'.

Installation

Version of Zigbee2MqttAssistant (this software): 0.3.147 (0.3.147+Branch.master.Sha.92d831d1df50a48c4a2fd38c201e9465dc7e88dd) Release Version of Zigbee2Mqtt: 1.11.0 Coordinator version: 20190608 Coordinator Zigbee Id:

Running Hassio on Vbox with z2ma add-on

Pertinent logs

Not sure what to put here. The mqtt disconnect happens a while after the add-on is started. I don't see timestamps, but it connects successfully and can do the network map and everything.

Only have add-on logs: Starting Zigbee2MqttAssistant v0.3.147+Branch.master.Sha.92d831d1df50a48c4a2fd38c201e9465dc7e88dd... Hosting environment: Production Content root path: /app Now listening on: http://[::]:80 Application started. Press Ctrl+C to shut down. warn: Zigbee2MqttAssistant.Services.MqttConnectionService[0] Disconnected from MQTT server 192.168.1.135. System.Threading.Tasks.TaskCanceledException: A task was canceled. at MQTTnet.Client.MqttClient.TrySendKeepAliveMessagesAsync(CancellationToken cancellationToken)

[backcountrymountains]

So I just started going through my z2m logs. I found the 'lastSeen' time for a couple of devices, and its all wrong. This is probably a z2m bug, not a z2ma bug. Oops.

[backcountrymountains]

Okay, so what I'm finding is that the 'lastSeen' in the zigbee2mqtt/bridge/config/devices topic seems to sometimes be the date the device was added to z2m. I've changed the configuration.yaml of z2m to have 'last_seen: epoch' under the advanced options. However, the 'last_seen' only appears in the topic for each individual device, and doesn't change the 'lastSeen' that is in the zigbee2mqtt/bridge/config/devices json.

How can I get z2ma to use 'last_seen' from the individual device topic instead of the zigbee2mqtt/bridge/config/devices topic?

Do I need to change the format of 'last_seen' to something other than epoch? Options for 'last_seen' are at https://www.zigbee2mqtt.io/information/configuration.html

Is there a way to update the zigbee2mqtt/bridge/config/devices in z2m?

Side question: why the heck does z2m have conflicting 'lastSeen' and 'last_seen'? What the heck, that is so confusing!

[backcountrymountains]

Now I'm just spamming. I hope this helps someone else.

I individually turned on and off each light from HA and z2ma changed the devices from 'unresponsive' to the accurate time it was last seen.

However, I use zigbee groups to control groups of lights all at once and if I turn a group on or off, the corresponding lights don't update their 'last_seen' information. Bummer. Seems like a z2m bug though.

Also, can we change 'AutosetLastSeen' to default to true since I'm an idiot and didn't RTFM? Or to put up a little notification that says z2ma is using 'lastSeen' from the devices topic and not the individual light's topic, and thus might not be accurate?

Thanks.

[magpern]

@backcountrymountains I must say - very good bug report. This is a school book example of how one should do. My system is finally back online again after a 4 day hardware problem. I will put this on my queue to analyse - I have seen similar things with LastSeen