SmartThings Community forum

Mariano_Colmenarejo: Yes, that is the method I use to reinstall Zigbee devices Ok. I don’t have any zibgee ir devices. The devices I re-paired (temp sensors and motion sensors) I don’t know if that did a factory reset on the device or just put it re-pair without losing config since I didn’t really have any config on them, and the routines for them were on the hub and remained intact.

Solved! I found the cause of the issue with HTTP Devices V1 – Temperature . The device was receiving the temperature command correctly, but no HTTP request was being sent and the HTTP Response Code remained blank. Using SmartThings CLI logcat , I found this error: attempt to index a nil value (field 'relativeHumidityMeasurement') The solution was very simple: set the Humidity value once (I set it to 20%). After initializing the humidity value, changing the temperature immediately started sending the HTTP POST requests correctly and I now receive HTTP 200 responses. So, if a newly created HTTP Temperature device does not send the request, try setting Humidity to any value once before using Temperature . It seems the driver expects the humidity state to be initialized, even if the HTTP request only uses ${temperature} . Hope this helps anyone experiencing the same issue!

Thanks @Declankn , Yes, that is the method I use to reinstall Zigbee devices when I can’t get them to reconnect on their own by simply removing the battery or rebooting the hub. Usually, they reconnect automatically, though some take quite a while. Since I’m changing the Zigbee channel to try and fix the multiple, sudden, and seemingly random disconnections, I assume I’ll have to reinstall most of them by resetting them; however, before doing that for all of them, I want to test 10 devices to see if they stay online on the new channel. I am very skeptical that changing the channel will solve the issue of massive, sudden disconnections. Resetting certain devices—like IR remotes—means losing stored data for learned command codes; I would have to reprogram each Zigbee IR unit using the original remote controls, which is a tedious process I’d like to avoid. Out of the six IR units, only one has reconnected on its own following the Zigbee channel changes. Regards,

Wow even Tesla gives you a $10 credit each month for personal use of their API… Samsung really thinks people will pay them $5 a month for API access for such bandwidth intensive tasks as “getting a custom notification confirming that the $2,000 washer they bought didn’t fully dry their socks on the first try.”

Is this driver unsuitable for the lumi.plug.maeu01 Aqara smart plug? I want to correct the device from being seen in SmartThings as a light.

Probably not your issue here @Mariano_Colmenarejo , but when I changed the zigbee channel on my hub and rebooted not all devices would come back online, particularly the tuya zigbee ones. I was able to get them back but putting them into pairing mode individually and then doing scan nearby. This found the original device and kept the routines etc. You’ve probably done this already, but just in case you haven’t.

Hi @Jake_Mohl I’ve been having similar issues at one location with a V2 hub since firmware version 61.6. It has 34 Zigbee devices: 29 Tuya units and 5 Heiman smoke detectors. They started disconnecting intermittently—sometimes 12, 20, 2, 25, or 0 devices at a time. They would sometimes take hours to come back online; most routines worked even while the devices were offline, but they couldn’t be controlled via the app. Knowing about the changes to the disconnected-device detection feature, I decided to wait for version 62.7, which had been working well on a V3 hub at a different location during the beta phase. When version 62.7 was installed on the V2 hub (on Tuesday or Wednesday), it was a disappointment; even after getting all devices online, groups of up to 15 devices would go offline again after having been online for hours. Neither restarting nor powering down the hub resulted in stability lasting more than a day. I tried changing the Zigbee channel from 14 to 20, but the devices refused to connect to any channel other than the original 14. I concluded that the V2 hub might be faulty. I had a spare V3 hub—new and updated to 62.7—so I decided to swap the V2 for the V3. Everything went smoothly and quickly, and the V3 set itself up on the same channel (14) as the V2. I had to restart it a couple of times and wait hours; I even had to reinstall some devices, such as the smoke detectors and contact sensors. It seemed to have the same problem as the V2. By the end of Thursday,

In case anyone is still having issues, the procedure is the following, works everytime with multiple blinds of the same reference I have in my house: install the blind and the motor and lower it to the desired “closed” state. Press and hold UP + DOWN for a couple seconds, be patient it sometimes take up to 3-4 seconds until the light starts blinking constantly. Then press up and be prepared, once the blind makes it to the desired min “open” state, click pause or stop. Now everything is configured properly.

In case anyone is still having issues, the procedure is the following, works everytime with multiple blinds of the same reference I have in my house: install the blind and the motor and lower it to the desired “closed” state. Press and hold UP + DOWN for a couple seconds, be patient it sometimes take up to 3-4 seconds until the light starts blinking constantly. Then press up and be prepared, once the blind makes it to the desired min “open” state, click pause or stop. Now everything is configured properly.

All zigbee devices are now offline.

Mariano_Colmenarejo: does rebooting the hub via the awa trigger an update of the interval list managed by the hub, or is there a function that updates this list periodically? Sort of. The hub tracks the list of all device attributes in volatile memory, but only persists the fastest reporting interval in non-volatile memory. So when the hub is rebooted that large list is lost, but the fastest reporting interval is still known, and still used after the reboot. As the hub watches for reported attributes or devices being configured it re-learns the attribute reporting configurations for all attributes, and will update the persisted attribute reporting interval if a faster one is discovered.

I think I have this same issue - everything I imported to ST (rooms and zones) is showing as offline other than the Philips hue hub itself. Routines that call zones/rooms still work, but the zones/room entities in ST show as offline, with the ‘check the device is on’ and ‘check your network connections’ error… None of them show up in offline diagnostics (presumably given the way they are linked) so can’t try bringing them back online in there, rebooting both ST and Hue hubs doesn’t change anything… Looking at the Hue hub within ST, it still shows as linked (have tried relinking also), all the bridged devices show up underneath, but clicking into them shows the same offline error as above… Can’t see where to export logs other than sending them to Samsung, but if you can point me in the right direction I’ll grab them for you if you’re able to help! Thanks for an otherwise very useful driver! Coffee coming your way if you’re able to help work this one out! Cheers Ben