Few minutes of shutdown fixed my problem. I just need to keep it slow and low with the virtual devices.
Or… If you have a repeatable way of triggering this issue then it might be worthwhile to do it again with logs running.
MAybe I should log Edge drivers that I’m using at that moment too?
My hub was back at it tonight. It coincided with a driver update from another dev being installed (automatically, not through CLI), so I’m pretty certain that was the cause.
2022-06-16T21:47:05 - Timestamp on the new version of the driver
2022-06-16T22:03:20 - Hub event - disconnected (begins cycling offline/online)
2022-06-16T22:10:19 - Hub event - HubUpdated (presumably indicating the driver install)
2022-06-16T23:24:49 - Hub stops cycling and remains online. Querying installed drivers shows the driver in question has the new timestamp. Logcat connects, and logs are going absolutely crazy, processing the backlog from the past hour. The commands below are usually generated by the device several (I think about 5) seconds apart:
2022-06-16T23:28:12.191489442+00:00 TRACE Honeywell-Ademco Envisalink RX < %00,02,1C08,08,00,****DISARMED**** Ready to Arm $
2022-06-16T23:28:12.231722215+00:00 TRACE Honeywell-Ademco Envisalink RX < %00,01,1C08,08,00,****DISARMED**** Ready to Arm $
2022-06-16T23:28:12.286172427+00:00 TRACE Honeywell-Ademco Envisalink RX < %00,02,1C08,08,00,****DISARMED**** Ready to Arm $
2022-06-16T23:28:12.327514421+00:00 TRACE Honeywell-Ademco Envisalink RX < %00,01,1C08,08,00,****DISARMED**** Ready to Arm $
2022-06-16T23:35:03 - Hub event - disconnected (begins cycling offline/online). Logcat remains connected, but processing slows to a crawl. Same device for comparison, now showing at 15s intervals:
2022-06-16T23:59:30.385576465+00:00 TRACE Honeywell-Ademco Envisalink RX < %00,02,1C08,08,00,****DISARMED**** Ready to Arm $
2022-06-16T23:59:44.024288471+00:00 TRACE Honeywell-Ademco Envisalink RX < %00,01,1C08,08,00,****DISARMED**** Ready to Arm $
2022-06-17T00:00:05.042289481+00:00 TRACE Honeywell-Ademco Envisalink RX < %00,02,1C08,08,00,****DISARMED**** Ready to Arm $
@nayelyz Was there any resolution to this issue which seems related?
Thanks for the info, @philh30.
I’m checking the status with the team and I already shared the new information you provided. This behavior certainly is strange so it needs further analysis. I’ll let you know in case we need more info.
1 Like
Linking this here in case it’s related. Looks similar to what I saw with the the rapid processing of a backlog (though just one driver instead of everything).
This is similar what I’ve experienced. And every time it has been either virtual devices or LAN devices that has caused it.
Mine just started doing this last night. Very odd.
@nayelyz Any updates on this?
I’ve gotten some improvements in stability by eliminating most drivers where I can’t control the timing of updates (including the ST stock drivers) but this continues to happen a couple times per week.
I opened a support ticket as you recommended, but that’s been a complete waste of my time.
Sorry, not yet, I already pinged the team again. I’ll let you know in case we need more info.
Support has now recommended a factory reset of the hub, with the only other troubleshooting advice over two weeks of emails being to reboot the hub. I honestly question whether the support rep has bothered to read my emails before sending back canned responses. This has been a disappointing exposure to the ST customer support framework.
@nayelyz Considering this issue appears to have been introduced with the 43.x firmware and appears related to the Edge beta, I’m hoping you have some sort of update or can at least confirm that someone is still investigating this.
The report I created about this is still open, and I already shared your comments there. I haven’t received feedback yet but we haven’t forgotten about it.
I found your ticket with customer support, so, I’ll leave them a note there, we might be able to check the issue together.
Same issues here. Support is useless and their suggestion to me was to uninstall/reinstall the app.
@nayelyz ticket number 1372720
Yet again this happened. I tried to turn off some of my Wiz lights, which are cloud based, and they send my hub to reboot itself and now many of my LAN based devices are offline.
Mine hub too.
5 hours ago it disconnected 3 times every 5 minutes and stopped by itself.
45 minutes ago it started to disconnect again and the 5th time I turned hub off for a few minutes and it is working fine for about 20 minutes.
No driver installation, driver update, driver change, or anything other than normal operation was being performed when hub start to disconnect and connect.
I’m having some issues with my hub as well.
Half an hour ago I received a couple notifications from Alexa, indicating devices already connected were connected again, but they aren’t working.
Other devices are simply showing connected, the Edge driver info is missing.
Hub (beta) firmware hasn’t updated yet.
Edit: checking the event logs, I have 8 “HubUpdated” events from around 4:30 this afternoon.
That’s what I see too. This time only a reboot fixed this. All but LAN devices seem to work properply. Usually I’ve had to power cycle the hub to fix this.
(Oops, wrong thread with that post but we are also looking into this issue as well)
Thanks for the insight. It’s good to see something is happening behind the scenes related to this problem. 
Hub went inactive/active loop once again this morning. And every time this happens I need to power cycle my hub. That causes some of the LAN devices going offline and they are useless after that. I need to delete them and create new ones. It won’t affect all devices but usually they are the same type, LAN presence sensor and LAN trigger. Do you @TAustin have any idea what might cause this?