Not just those, but ive had a few motion and contact sensors do the same.
1 Like
Hello Everyone.
Today, we will be updating the existing Customer Beta V2/V3 hubs to 54.12. Here are the release notes from that update.
54.12 Release Notes
- Fix bug causing driver crashes when opening multiple sockets and receiving unexpected closures
- Fix bug that could cause connection instability after initial connection loss to the cloud
Thank You.
4 Likes
TCP sockets?
Does 53.19 have these bugs as well?
It seems that the change in the order of execution of the init and doConfigure lifecycles, which I reported in this post, has not been reverted.
Does this mean that it will stay like this forever?
Should the code written in the init lifecycle be changed to doConfigure function, so that the custom configuration is applied to the devices that need it. Including all the smartthings stock drivers that have it like this too?
I have tried putting configuration values of 600 sec in the init lifecycle and when installing a device it is configured with the defaults, 300 sec, instead of the custom ones, 600 Sec, then something must be done or not?
4 Likes
It seems that the change in the order of execution of the init and doConfigure lifecycles, which I reported in this post, has not been reverted.
I am going to look further into this but we have not explicitly changed the order of lifecycle events (last potential change I can see was in August of 2023). If you are enterprising, you can find where this event is generated by opening the lua_libs_api_v*.tar.gz file from the Releases Page of the Edge Drivers. In that archive you’ll find a file named st/driver.lua and the event is triggered in local function lifecycle_result_handler only when a device wasn’t already known. I’ll provide the version I have locally here.
local function lifecycle_result_handler(driver, pcall_status, err_or_event_ret, ...)
local lifecycle_dispatcher, driver, device, event, event_args = select(1, ...)
if not pcall_status then
return
end
if driver ~= nil and device ~= nil then
local device_already_existed = (event_args and event_args.device_already_existed)
if event == "added" then
if not device_already_existed then
device.thread:queue_event(lifecycle_dispatcher.dispatch, lifecycle_dispatcher, driver, device, "init")
end
elseif event == "doConfigure" then
device.log.debug_with({ hub_logs = true },
'doConfigure callback did not fail, transitioning device to \"PROVISIONED\"'
)
device.thread:queue_event(
device.try_update_metadata, device, { provisioning_state = "PROVISIONED" }
)
end
end
end
Since this is the result_handler this means we will only trigger the init event either for know devices at driver startup or when a device is added to the driver for the first time. Feel free to walk back through the release assets to find where the ordering was changed but I feel confident in saying it hasn’t changed for over 1 year.
One of the big problems here is that device events can end up yielding control of the device’s coroutine to allow for other events to be processed. This can cause confusion into how the order of events is determined but since drivers run completely asynchronously we can’t make any promises about what event will be executed when.
I did a handful of tests with the zigbee switch driver on a v2 and saw that added typically happens before init and in some cases doConfigure is delivered before added can finish meaning the init event would only be triggered after doConfigure had happened.
2 Likes
Yes, I’ve already reached that point in the lua libraries and I haven’t found where the init lifecycle is explicitly called except in that function.
The truth is that with firmware 53.19 the order is: init, added,
doConfigure, added too and infoChange. See cli logs in the above post.
And with 54.10 is: added, doConfigure, added too, init, infoChange
The init life cycle is always called when driver is initialized by a driver update or hub reboot, but i do not know where is the code in lua libraries.
Driver functions in Init lifecycle are needed run before of doConfgure lifecycle, to add configure and monitored attributes in devices with custom configurations and now this not works fine, in stock drivers too.
In Lan drivers others problems can exit, depend of the code in the init lifecycle functions, but i do known that.
Thanks
What you mean is, that init resets or overwrites any custom configuration now, right?
No, what happens is that instead of sending the custom configuration to the device, it sends the default configuration of the attributes.
For example, in the zigbee humidity sensor driver:
In the init lifecycle the driver should add this custom configuration for the sonoff sensors, by executing the functions: device:add_configured_attribute(attribute) and device:add_monitored_attribute(attribute)
local function device_init(driver, device)
local configuration = configurationMap.get_device_configuration(device)
if configuration ~= nil then
for _, attribute in ipairs(configuration) do
device:add_configured_attribute(attribute)
device:add_monitored_attribute(attribute)
end
end
end
configuration.lua module
EWELINK_HUMIDITY_TEMP_SENSOR = {
FINGERPRINTS = {
{ mfr = "eWeLink", model = "TH01" },
{ mfr = "eWeLink", model = "SNZB-02P" }
},
CONFIGURATION = {
{
cluster = TemperatureMeasurement.ID,
attribute = TemperatureMeasurement.attributes.MeasuredValue.ID,
minimum_interval = 10,
maximum_interval = 7200,
data_type = TemperatureMeasurement.attributes.MeasuredValue.base_type,
reportable_change = 50
},
{
cluster = PowerConfiguration.ID,
attribute = PowerConfiguration.attributes.BatteryPercentageRemaining.ID,
minimum_interval = 3600,
maximum_interval = 7200,
data_type = PowerConfiguration.attributes.BatteryPercentageRemaining.base_type,
reportable_change = 16
},
{
cluster = RelativeHumidity.ID,
attribute = RelativeHumidity.attributes.MeasuredValue.ID,
minimum_interval = 10,
maximum_interval = 7200,
data_type = RelativeHumidity.attributes.MeasuredValue.base_type,
reportable_change = 300
}
}
},
This code will write the custom configuration values in the attributes configuration tables, which will be sent to the device when the doConfigure lifecycle is called.
But since doConfigure is running before init, then what is found in the tables are the default values instead of the custom ones and the device will not work as it should.
2 Likes
It may appear this way but the code that determines any kind of ordering here hasn’t changed since August of 2023 and very explicitly is triggering init only after added has completed. I believe what you are interpreting as the order is either 1. coroutine scheduling making it appear different or 2. log ordering, we make a best effort to provide logs but the order is not always guaranteed to be exact. I suspect that in 53.19 the actual order of events was added → init though the logs made it appear as though something else was happening. Because the coroutines in any callback handler are provided by the driver developer, we can’t actually make any guarantees about the order that things will happen unless you explicitly synchronize events by using something like a cosock.channel.
Ok, but the real problem is that doConfigure is executed before init, regardless of the fact that the order shown in the log may not match the real one, what I have verified is that:
- Running
device:add_configured_attribute(attribute)in the init lifecycle, I set a maximum reporting interval of 600sec in the onOff attribute: - With firmware 54.10: max interval 300 sec are sent, the default value instead of 600 sec that should have been sent.
This proves that the doConfigure lifecycle code was actually executed before the code called in the init lifecycle.
This renders any custom device configuration inoperative in the stock drivers that have it, which are many.
2024-10-02T15:54:49.372726020Z TRACE Zigbee Switch Mc Received event with handler device_lifecycle
2024-10-02T15:54:49.441367395Z TRACE Zigbee Switch Mc Zigbee Device: 48220c53-66d0-429d-b370-4089d2e0e79c
Manufacturer: _TZ3000_kdi2o9m6 Model: TS011F
[242]: server | client: 0x0021 [11]: server: Basic, Identify, Groups, Scenes, OnOff | client: OTAUpgrade, Time
2024-10-02T15:54:49.443928729Z INFO Zigbee Switch Mc <ZigbeeDevice: 48220c53-66d0-429d-b370-4089d2e0e79c [0x47F2] (Lidl Plug)> received lifecycle event: added
2024-10-02T15:54:49.469218437Z TRACE Zigbee Switch Mc Received event with handler device_lifecycle
2024-10-02T15:54:49.470202062Z INFO Zigbee Switch Mc <ZigbeeDevice: 48220c53-66d0-429d-b370-4089d2e0e79c [0x47F2] (Lidl Plug)> received lifecycle event: doConfigure
2024-10-02T15:54:49.471660437Z TRACE Zigbee Switch Mc <ZigbeeDevice: 48220c53-66d0-429d-b370-4089d2e0e79c [0x47F2] (Lidl Plug)> received unhandled lifecycle event: added
2024-10-02T15:54:49.472604312Z DEBUG Zigbee Switch Mc Lidl Plug device thread event handled
2024-10-02T15:54:49.511217270Z TRACE Zigbee Switch Mc Found DeviceLifecycleDispatcher handler in Zigbee_Switch_Mc
2024-10-02T15:54:49.512253354Z PRINT Zigbee Switch Mc << do Configure function >>
2024-10-02T15:54:49.534857104Z INFO Zigbee Switch Mc <ZigbeeDevice: 48220c53-66d0-429d-b370-4089d2e0e79c [0x47F2] (Lidl Plug)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x47F2, dest_endpoint: 0x0B, profile: 0x0000, cluster: 0x0021 >, < ZDOMessageBody || < ZDOHeader || seqno: 0x00 >, < BindRequest || src_address: EC1BBDFFFEA88018, src_endpoint: 0x0B, cluster: OnOff, dest_addr_mode: 0x03, dest_address: 286D97000204B680, dest_endpoint: 0x01 > > >
2024-10-02T15:54:49.566965145Z INFO Zigbee Switch Mc <ZigbeeDevice: 48220c53-66d0-429d-b370-4089d2e0e79c [0x47F2] (Lidl Plug)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x47F2, dest_endpoint: 0x0B, profile: 0x0104, cluster: OnOff >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x00, seqno: 0x00, ZCLCommandId: 0x06 >, < ConfigureReporting || < AttributeReportingConfiguration || direction: 0x00, attr_id: 0x0000, DataType: Boolean, minimum_reporting_interval: 0x0000, maximum_reporting_interval: 0x012C > > > >
2024-10-02T15:54:49.584427437Z DEBUG Zigbee Switch Mc Lidl Plug device thread event handled
2024-10-02T15:54:49.586731062Z DEBUG Zigbee Switch Mc <ZigbeeDevice: 48220c53-66d0-429d-b370-4089d2e0e79c [0x47F2] (Lidl Plug)> doConfigure callback did not fail, transitioning device to
“PROVISIONED”
2024-10-02T15:54:49.610806229Z TRACE Zigbee Switch Mc Found DeviceLifecycleDispatcher handler in Zigbee_Switch_Mc
2024-10-02T15:54:49.619226270Z PRINT Zigbee Switch Mc <<< Device do_init >>>
2024-10-02T15:54:49.652141604Z INFO Zigbee Switch Mc <ZigbeeDevice: 48220c53-66d0-429d-b370-4089d2e0e79c [0x47F2] (Lidl Plug)> emitting event: {“attribute_id”:“energy”,“capability_id”:“energyMeter”,“component_id”:“main”,“state”:{“unit”:“kWh”,“value”:0.0}}
2024-10-02T15:54:49.685104395Z INFO Zigbee Switch Mc <ZigbeeDevice: 48220c53-66d0-429d-b370-4089d2e0e79c [0x47F2] (Lidl Plug)> emitting event: {“attribute_id”:“energyReset”,“capability_id”:“legendabsolute60149.energyReset1”,“component_id”:“main”,“state”:{“value”:“Last: 0.000 kWh (10/02/2024)”}}
2024-10-02T15:54:49.713581604Z INFO Zigbee Switch Mc <ZigbeeDevice: 48220c53-66d0-429d-b370-4089d2e0e79c [0x47F2] (Lidl Plug)> emitting event: {“attribute_id”:“randomOnOff”,“capability_id”:“legendabsolute60149.randomOnOff2”,“component_id”:“main”,“state”:{“value”:“Inactive”}}
2024-10-02T15:54:49.728002062Z INFO Zigbee Switch Mc <ZigbeeDevice: 48220c53-66d0-429d-b370-4089d2e0e79c [0x47F2] (Lidl Plug)> emitting event: {“attribute_id”:“randomNext”,“capability_id”:“legendabsolute60149.randomNextStep2”,“component_id”:“main”,“state”:{“value”:“Inactive”}}
2024-10-02T15:54:49.751836187Z PRINT Zigbee Switch Mc << Custom max interval in init: 600
2024-10-02T15:54:49.757707937Z DEBUG Zigbee Switch Mc Lidl Plug device thread event handled
2024-10-02T15:54:49.892400270Z DEBUG Zigbee Switch Mc Lidl Plug device thread event handled
2024-10-02T15:54:50.124049979Z TRACE Zigbee Switch Mc Received event with handler zigbee
2024-10-02T15:54:50.126707812Z INFO Zigbee Switch Mc <ZigbeeDevice: 48220c53-66d0-429d-b370-4089d2e0e79c [0x47F2] (Lidl Plug)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, <
AddressHeader || src_addr: 0x47F2, src_endpoint: 0x00, dest_addr: 0x0000, dest_endpoint: 0x00, profile: 0x0000, cluster: 0x8021 >, lqi: 0xC8, rssi: -64, body_length: 0x0002, < ZDOMessageBody || < ZDOHeader || seqno: 0x02 >, < BindRequestResponse || status: 0x00 > > >
2024-10-02T15:54:50.134906354Z DEBUG Zigbee Switch Mc Lidl Plug device thread event handled
2024-10-02T15:54:50.338961437Z TRACE Zigbee Switch Mc Received event with handler zigbee
2024-10-02T15:54:50.345268145Z INFO Zigbee Switch Mc <ZigbeeDevice: 48220c53-66d0-429d-b370-4089d2e0e79c [0x47F2] (Lidl Plug)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, <
AddressHeader || src_addr: 0x47F2, src_endpoint: 0x0B, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: OnOff >, lqi: 0xC6, rssi: -63, body_length: 0x0004, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x22, ZCLCommandId: 0x07 >, < ConfigureReportingResponse || ZclStatus: SUCCESS > > >
- With firmware 53.19: max custom interval 600 sec are sent. Ok
2024-10-02T16:20:33.410805542Z TRACE Zigbee Switch Mc Zigbee Device: a390224a-49d0-4fbe-b311-1710bfedf6b3
Manufacturer: _TZ3000_kdi2o9m6 Model: TS011F
[242]: server | client: 0x0021 [11]: server: Basic, Identify, Groups, Scenes, OnOff | client: OTAUpgrade, Time
2024-10-02T16:20:33.422020042Z DEBUG Zigbee Switch Mc driver device thread event handled
2024-10-02T16:20:33.431077084Z TRACE Zigbee Switch Mc Received event with handler driver_lifecycle
2024-10-02T16:20:33.440730167Z INFO Zigbee Switch Mc received driver startupState: {“hub_zigbee_id”:“0FKoo2ekAAE=”,“hub_node_id”:1,“hub_ipv4”:“192.168.1.46”}
2024-10-02T16:20:33.450058625Z TRACE Zigbee Switch Mc Found DeviceLifecycleDispatcher handler in Zigbee_Switch_Mc
2024-10-02T16:20:33.462392917Z PRINT Zigbee Switch Mc <<< Device do_init >>>
2024-10-02T16:20:33.472806625Z INFO Zigbee Switch Mc <ZigbeeDevice: a390224a-49d0-4fbe-b311-1710bfedf6b3 [0x283E] (Lidl Plug)> emitting event: {“attribute_id”:“energy”,“capability_id”:“energyMeter”,“component_id”:“main”,“state”:{“unit”:“kWh”,“value”:0.0}}
2024-10-02T16:20:33.528128834Z INFO Zigbee Switch Mc <ZigbeeDevice: a390224a-49d0-4fbe-b311-1710bfedf6b3 [0x283E] (Lidl Plug)> emitting event: {“attribute_id”:“energyReset”,“capability_id”:“legendabsolute60149.energyReset1”,“component_id”:“main”,“state”:{“value”:“Last: 0.000 kWh (10/02/2024)”}}
2024-10-02T16:20:33.648772292Z INFO Zigbee Switch Mc <ZigbeeDevice: a390224a-49d0-4fbe-b311-1710bfedf6b3 [0x283E] (Lidl Plug)> emitting event: {“attribute_id”:“randomOnOff”,“capability_id”:“legendabsolute60149.randomOnOff2”,“component_id”:“main”,“state”:{“value”:“Inactive”}}
2024-10-02T16:20:33.696617042Z INFO Zigbee Switch Mc <ZigbeeDevice: a390224a-49d0-4fbe-b311-1710bfedf6b3 [0x283E] (Lidl Plug)> emitting event: {“attribute_id”:“randomNext”,“capability_id”:“legendabsolute60149.randomNextStep2”,“component_id”:“main”,“state”:{“value”:“Inactive”}}
2024-10-02T16:20:33.736936709Z PRINT Zigbee Switch Mc << Custom max interval in init: 600
2024-10-02T16:20:33.773348625Z DEBUG Zigbee Switch Mc Lidl Plug device thread event handled
2024-10-02T16:20:33.812087084Z TRACE Zigbee Switch Mc Received event with handler device_lifecycle
2024-10-02T16:20:33.967286292Z INFO Zigbee Switch Mc <ZigbeeDevice: a390224a-49d0-4fbe-b311-1710bfedf6b3 [0x283E] (Lidl Plug)> received lifecycle event: added
2024-10-02T16:20:34.162243001Z TRACE Zigbee Switch Mc <ZigbeeDevice: a390224a-49d0-4fbe-b311-1710bfedf6b3 [0x283E] (Lidl Plug)> received unhandled lifecycle event: added
2024-10-02T16:20:34.301896542Z DEBUG Zigbee Switch Mc Lidl Plug device thread event handled
2024-10-02T16:20:34.349838542Z TRACE Zigbee Switch Mc Received event with handler device_lifecycle
2024-10-02T16:20:34.367784584Z INFO Zigbee Switch Mc <ZigbeeDevice: a390224a-49d0-4fbe-b311-1710bfedf6b3 [0x283E] (Lidl Plug)> received lifecycle event: doConfigure
2024-10-02T16:20:34.389666376Z TRACE Zigbee Switch Mc Found DeviceLifecycleDispatcher handler in Zigbee_Switch_Mc
2024-10-02T16:20:34.392697584Z PRINT Zigbee Switch Mc << do Configure function >>
2024-10-02T16:20:34.409916709Z INFO Zigbee Switch Mc <ZigbeeDevice: a390224a-49d0-4fbe-b311-1710bfedf6b3 [0x283E] (Lidl Plug)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x283E, dest_endpoint: 0x0B, profile: 0x0000, cluster: 0x0021 >, < ZDOMessageBody || < ZDOHeader || seqno: 0x00 >, < BindRequest || src_address: EC1BBDFFFEA88018, src_endpoint: 0x0B, cluster: OnOff, dest_addr_mode: 0x03, dest_address: D052A8A367A40001, dest_endpoint: 0x01 > > >
2024-10-02T16:20:34.443003334Z INFO Zigbee Switch Mc <ZigbeeDevice: a390224a-49d0-4fbe-b311-1710bfedf6b3 [0x283E] (Lidl Plug)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x283E, dest_endpoint: 0x0B, profile: 0x0104, cluster: OnOff >, < ZCLMessageBody || < ZCLHeader || frame_ctrl:
0x00, seqno: 0x00, ZCLCommandId: 0x06 >, < ConfigureReporting || < AttributeReportingConfiguration || direction: 0x00, attr_id: 0x0000, DataType: Boolean, minimum_reporting_interval: 0x0000, maximum_reporting_interval: 0x0258 > > > >
2024-10-02T16:20:34.476609251Z DEBUG Zigbee Switch Mc Lidl Plug device thread event handled
2024-10-02T16:20:34.513386126Z DEBUG Zigbee Switch Mc <ZigbeeDevice: a390224a-49d0-4fbe-b311-1710bfedf6b3 [0x283E] (Lidl Plug)> doConfigure callback did not fail, transitioning device to “PROVISIONED”
2024-10-02T16:20:34.546743542Z DEBUG Zigbee Switch Mc Lidl Plug device thread event handled
2024-10-02T16:20:34.579739792Z TRACE Zigbee Switch Mc Received event with handler zigbee
2024-10-02T16:20:34.617589292Z INFO Zigbee Switch Mc <ZigbeeDevice: a390224a-49d0-4fbe-b311-1710bfedf6b3 [0x283E] (Lidl Plug)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x283E, src_endpoint: 0x00, dest_addr: 0x0000, dest_endpoint: 0x00, profile: 0x0000, cluster: 0x8021 >, lqi: 0xFF, rssi: -41, body_length: 0x0002, < ZDOMessageBody || < ZDOHeader || seqno: 0x1F >, < BindRequestResponse || status: 0x00 > > >
2024-10-02T16:20:34.650868126Z DEBUG Zigbee Switch Mc Lidl Plug device thread event handled
2024-10-02T16:20:34.683994626Z TRACE Zigbee Switch Mc Received event with handler zigbee
2024-10-02T16:20:34.720555584Z INFO Zigbee Switch Mc <ZigbeeDevice: a390224a-49d0-4fbe-b311-1710bfedf6b3 [0x283E] (Lidl Plug)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x283E, src_endpoint: 0x0B, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: OnOff >, lqi: 0xFF, rssi: -41, body_length: 0x0004, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x0A, ZCLCommandId: 0x07 >, < ConfigureReportingResponse || ZclStatus: SUCCESS > > >
2 Likes
It is in st/driver.lua lines 983-993.
That isn’t what I see in my driver for VIRTUAL devices, it would appear that I get added before init these days.
This would seem to be the big problem area, especially when it comes to configured and monitored attributes which the Edge reference suggests would typically be handled in the init lifecycle, and which is indeed where stock drivers are handling them. I understand their purpose but not the detail - do these need configuring every time the driver restarts?
1 Like
Sorry for not wait to @robert.masen response,
It is not necessary to configure them, but it is necessary to update the attribute monitoring values tables since they are saved with a device:set_field(persist = false) and if the driver is restarted, the custom maximum interval attribute monitoring values are lost and would no longer coincide with the intervals configured in the device, resulting in the heal_check function not being executed correctly when needed.
This is do in the same function in init lifecycle
In my drivers I have already done this a long time ago, I have duplicate functions device:add_configured_attribute(attribute) and device:add_monitored_attribute(attribute) in the doConfigure lifecycle and in init.
I think this is not the first time this has happened.
Thanks,
I looked for it a lot of times and I didn’t see it. 
Just to be clear then, you have no issue with added coming before init? It is instead that a doConfigure event is arriving now before init?
Yes, this is correct
But, I don’t have the problem, we all have a problem, I think
3 Likes
Yes, this is correct
Thanks for that I am sorry I was under the impression your primary issue was the ordering of added and init. What I suspect is that in this release we have significantly improved the latency of how your hub communicates with the driver leading to the doConfigure event arriving more quickly than it had previously.
init being entirely synthetic will always be queued immediately after added has completed but other events can be queued before added has finished leading to this scenario. I’ll connect with the team and see if we can’t figure out how to fix this.
Thank you for your persistence and thorough-ness through this!
9 Likes
Since you insist that nothing has changed in this firmware, I have done more tests and you are right, it was already wrong in version 53.19.
What is happening?
When a device is paired with a driver that does not have any paired devices everything works fine:
-
How the driver is initialized then the init lifecycle is called in the
Drive:run function, as @orangebucketst/driver.lua lines 983-993said. the init arrives before the doConfigure. -
When another device is added, the driver no longer has to be initialized and then the doConfigure is called before the Init and this second device is configured with the defaults instead of the custom ones.
I hope this helps.
4 Likes
You should get a trophy for finding this bug.
6 Likes
Wait a minute…
Maybe a lot of Zigbee devices that have an abnormal battery drain are just misconfigured (reporting interval, for example)? And that’s really difficult to debug if the first device behaves as expected.
Referencing my other post, that bug seems to be not solved yet, or you have some other issues with your cloud…
If I can guess that would be the second one, because some other users reported similar with 54.10, but who knows. And as it is weekend, I guess nobody cares about it either…
So all in all, the app keeps popping up notifications of a disconnected Hub. Not even notification of re-connection, but rather just disconnection. Sporadically a connected notification comes in as well, but the ratio if about 5:1 for the disconnect messages. Otherwise everything else is working as expected at home, just the Hub does this limbo. I have limited amount of devices connected to the Hub and not really controlling those, but monitoring them with it, so cannot really comment on the real disconnection fact, or just the Hub thinks it that way.
1 Like