Are you saying you’re having Zigbee problems with a Connect or Smartthings WiFi hub? A friend of mine was having Zigbee trouble with a Connect system, and he tried to fix it “once and for all” by starting over with a new Aeotec hub. He did this without access to the new hub-replace feature, so he had to start over completely. Unfortunately, he says he’s still having Zigbee issues… Ugh.
I’m using a single Smartthings WiFi hub, but just for the Zigbee and Z-Wave networks (I’m not using the mesh Wi-Fi) and, fortunately, everything’s actually working quite well.
But, I’m anxious for a firmware update that will, hopefully, enable the hub-replace feature. On the one hand I don’t want to mess with a system that’s working, but on the other I’m nervous about having to start over from scratch in the event that my hub dies.
Maybe I’m worrying too much? That’s is, if my system is stable, should I just leave well enough alone? How vulnerable to failure is a six-year-old hub?
I just checked, but I only have 1 location in the app and that is the correct one. I have now re-paired 100 ZigBee devices with the hub and they now seem to stay online. It cost me 6 hours of my life Now I just have to find a way to explain to my wife why we really need a smart home
An error occurs randomly in the driver that causes the driver to restart.
Until now that the code of the 51X libraries has been published, I was not able to see the details of the error since in the latest 49.x libraries published, those lines of code indicated by the error do not exist.
Now I see that the code of the files cosock.lua, st/thread.lua, st/driver.lua has changed in this firmware version 51.x
I have made a dump hub log at approximately 22:10 UTC
Also activate access to my account
Could this have something to do with the Hub’s memory management and the error occurs that restarts the driver?
I have had the same drivers and devices installed for a long time, with sofLimit in both memory fields of the Hub and this error had never happened to me with previous firmware
2023-12-10T21:39:11.857194617+00:00 TRACE Zigbee Light Multifunction Mc Found CapabilityCommandDispatcher handler in zigbee_light_multifunctions
2023-12-10T21:39:11.868926284+00:00 PRINT Zigbee Light Multifunction Mc <<< color_Changing_handler: Inactive
2023-12-10T21:39:11.882791951+00:00 PRINT Zigbee Light Multifunction Mc device:get_field(colorChanging) Active
2023-12-10T21:39:11.890481951+00:00 INFO Zigbee Light Multifunction Mc <ZigbeeChildDevice: 09c67265-e042-41dd-a907-59e5d55321f0 [0f922249-3c54-40fa-a217-ebe9eec40e53][main] (Mirror Group
Control-Lámpara Sofás)> emitting event: {"attribute_id":"colorChanging","capability_id":"legendabsolute60149.colorChanging","component_id":"main","state":{"value":"Inactive"}}
2023-12-10T21:39:11.912416284+00:00 INFO Zigbee Light Multifunction Mc <ZigbeeChildDevice: 09c67265-e042-41dd-a907-59e5d55321f0 [0f922249-3c54-40fa-a217-ebe9eec40e53][main] (Mirror Group
Control-Lámpara Sofás)> emitting event: {"attribute_id":"progOn","capability_id":"legendabsolute60149.progressiveOn1","component_id":"main","state":{"value":"Inactive"}}
2023-12-10T21:39:11.928755617+00:00 INFO Zigbee Light Multifunction Mc <ZigbeeChildDevice: 09c67265-e042-41dd-a907-59e5d55321f0 [0f922249-3c54-40fa-a217-ebe9eec40e53][main] (Mirror Group
Control-Lámpara Sofás)> emitting event: {"attribute_id":"progOff","capability_id":"legendabsolute60149.progressiveOff1","component_id":"main","state":{"value":"Inactive"}}
2023-12-10T21:39:11.951865951+00:00 INFO Zigbee Light Multifunction Mc <ZigbeeChildDevice: 09c67265-e042-41dd-a907-59e5d55321f0 [0f922249-3c54-40fa-a217-ebe9eec40e53][main] (Mirror Group
Control-Lámpara Sofás)> emitting event: {"attribute_id":"randomOnOff","capability_id":"legendabsolute60149.randomOnOff1","component_id":"main","state":{"value":"Inactive"}}
2023-12-10T21:39:11.955428284+00:00 FATAL Zigbee Light Multifunction Mc runtime error: [string "cosock.lua"]:313: [string "st/thread.lua"]:124: select returned unwatched socket
stack traceback:
[C]: in function 'assert'
[string "st/thread.lua"]:124: in function <[string "st/thread.lua"]:55>
stack traceback:
[C]: in function 'error'
[string "cosock.lua"]:313: in field 'run'
[string "st/driver.lua"]:847: in method 'run'
[string "init.lua"]:608: in main chunk
2023-12-10T21:39:11.973594951+00:00 INFO Zigbee Light Multifunction Mc <ZigbeeChildDevice: 09c67265-e042-41dd-a907-59e5d55321f0 [0f922249-3c54-40fa-a217-ebe9eec40e53][main] (Mirror Group
Control-Lámpara Sofás)> emitting event: {"attribute_id":"circadian","capability_id":"legendabsolute60149.circadian","component_id":"main","state":{"value":"Inactive"}}
2023-12-10T21:39:20.412010385+00:00 TRACE Zigbee Light Multifunction Mc Setup driver zigbee_light_multifunctions with lifecycle handlers:
DeviceLifecycleDispatcher: zigbee_light_multifunctions
default_handlers:
added:
infoChanged:
removed:
init:
doConfigure:
driverSwitched:
child_dispatchers:
DeviceLifecycleDispatcher: zigbee_light_multifunctions -> XY Color Bulb
default_handlers:
added:
child_dispatchers:
51.02 and still zigbee devices offline. I’ve tried 30 minute power off, with no improvement. I guess tomorrow I will try a longer power off but I have little faith that will solve anything. I was hoping to find a solution here.
Although I’m not (yet) getting those device offline issues I am getting several of the other frequently reported and not responded and fixed issues that are making using ST a chore rather than the reliable and useful thing we had before migration.
rapid battery drain on devices such as the motion sensor
scheduled device switch-offs randomly not done - both with auto turn-off in switch-on routines and specific switch-off routines
presence detection by phone stopping working requiring the ‘get location from’ setting to be toggled off and back on
Similar to the majority of the thread, most, not all, of my Zigbee devices are reporting offline. No automations working with the offline zigbee devices. I’ve tried resetting a couple devices and they are not found when attempting to add them back. I unplugged my hub for two hours this evening, hoping zigbee would rebuild the network, but no success yet.
This started after the firmware update (000.051.00002 - V2_HUB). If was at first 4 zigbee devices offline and has grown to 20 devices offline. At the moment I only have 2 zigbee devices online.
I am in the Netherlands also ( offtopic: near The Hague)
I got the Smarttings UK support address. They helped me perfectly. and my problem was really complicated. support@smartthings.co.uk
I give them a ten!. My data was more or less corrupt on 4 different remote locations.
Are others finding this as well? I have a few Zigbee devices for which battery drain has become more rapid. As two examples, new batteries only last about a month now in a Smartthings button and a Smarrthings multi-purpose sensor (used to detect tilt of garage door). I tried a different driver for the multi-purpose sensor, and set it to report temperature at a low frequency, but it still seems as though battery life is poor. I cannot be sure, though, that I didn’t get a batch of shoddy batteries (I bought a ten pack, or similar, from Amazon…).
P.S. I finally learned how to quote a snippet from another post!
A thread about battery Zigbee Extreme Battery Drain - I think temp noticeably influences reported battery %ge - for instance below around 15C or so it’ll likely be below 33%
In the thread @jwsg linked to Mariano explains that ST has changed the drivers to improve battery life but you would need to exclude and repair the devices to ST for it to take effect.
I have not had the time to exclude and repair all my battery operated Zigbee devices, but I plan to do it over the holidays.
Reading that thread I havent spotted the mention of ST changing drivers or details about an excluding and repair process - just mention of an alternate “Zigbee Contac Mc” driver for the contact sensor (I’m using a motion sensor) with settings to adjust update rates.
I already tried a device remove reset re-join but still using the ST driver and there was a small improvement for a few days - in the past a new battery would last months before an alert.
" I don’t know what driver you are using.
You can see with the CLI if devices are sending messages very frequently.
Maybe you should pair them again so they are set to the most recent reporting intervals. Smartthings changes them in their drivers to improve, but forgets that users who already have the devices in use configure them when they pair them again.*
I’m not seeing a fix there. Ive tried a device remove reset re-join and there was a small improvement for a few days but it soon dropped back below the alert level. Devices are using the 21/11 driver. Ambient temp is a factor.
I gave up on using the ‘coin’ batteries in my SmartThings motion and multipurpose sensors over a year ago due to the coin batteries needing to be replaced every 1-2 months (what a pain) using the old SmartThings pre-Edge DTH driver. I converted my sensors from the 3v coin battery over to using dual AAA battery packs which are 3v thanks to @jlv. I now rarely have to change batteries in my sensors since the dual AAA batteries last almost a year or so now.
Interesting. I’ve got one SmartThings motion detector that’s been in place for close to 5 years. It’s above the door from the house to the garage and is probably triggered 10 to 20 times per day. The garage is inside the house insulation envelope so is mostly climate-controlled.
Now I just have to find a way to explain to my wife why we really need a smart home