I’m feeling like that is the only option for me as well.
I just ordered the Aeotec Hub 2 (V4). It supposedly has twice the memory and twice the CPU of the V3. I’m going to do a hub replace from my Zigbee V3 hub to the new one and see if this fixes the problem for me. If this works, then I’m going to buy a new Aeotec V3 and replace my older V3 for all of my Z-Wave devices, just so I have all new hardware.
The two V3s I have now are going on nine years old, and I’m worried about them dying and losing all of my Z-Wave devices. I like ST a lot, but if this doesn’t work, then I will have to move to HA or Hubitat and start from scratch.
The Station I got a few years back is basically worthless to me now that I know it has less power than the V3 hubs.
I do not have a lot of devices in my house and this was all working like CLOCKWORK before they updated the firmware, this isn’t a hardware problem it’s a software issue.
The same thing happened with my nanit baby camera. They pushed through an update that broke wifi and/or made it intermittent. They kept telling me it was hardware, reset, uninstall/reinstall blah blah blah and then wanted me to buy a new camera and were going to offer me a discount. I bought another camera used/3rd party, same issue. So then i found/installed an older app before the update and guess what? Like magic it worked again. I emailed their support and they were so thankful that I FOUND THE PROBLEM they upgraded my sleep insights for a year for free.
The reality is they have a new hub coming out and they are going to push people to new hardware and ultimately never fix this imo. To be honest, this sounds ripe for one of those massive class action lawsuits where we end up with like $30 at the end of the day LOL. I think i’m going to start contacting attorneys and see if they are interested.
I purchased the Aeotec Hub 2 (V4) and performed a hub replace, moving all of my Zigbee devices from my V3 hub to the new V4. Everything is working perfectly again—no devices offline and no more “A network or server error occurred. Try again later.” messages.
I can control everything now, and the devices respond more quickly. I tested all of my routines, and they are working faster as well.
I will keep you updated on how it goes. Hopefully, there are no more bad firmware updates!
Hi, @mlchelp
Thank you for letting us know the steps you took regarding the hub. Just to shed some light on what happened before. The engineering team analyzed the hub logs you sent and in the context of the device called “Sunroom North Sengled Light”, they saw the following:
- The device routes through “Front Living Rm 1st Iris Smart Plug” along with “Basement Big bed Iris Multipurpose Sensor”
- The problem seems to (at least partially) be that “Front Living Rm” is switching its parent pretty frequently, from the Hub directly to “Sun Room Iris Smart Plug”, “Air Purifier Iris Plug”, and “Family Living Rm Coal Blower Iris Smart Plug” at various times throughout the logs.
- They also noticed you have some incredibly chatty 14 thermostats. We see that you use some custom drivers. Are you using them to change the reporting frequency?
- In general, they observed that the main culprit is that the incredibly active network leads to unstable topography as busy nodes get selected/deselected as routing parents depending on what they happen to be handling when asked to refresh the mesh.
If the issue comes back with the V4 hub, the team can perform a change in the Hub so the network routing table is updated less frequently than the default of every 5 minutes.
Thank you. I haven’t had any issues with the V4 so far. I turned the power off in my house for five minutes at the breaker to reset all of the plugs. The Front Living Room 1st Iris smart plug is about 20 feet from the hub, so it shouldn’t be jumping around.
The custom driver on the thermostats is Mariano’s Zigbee Thermostat MC. None of the thermostats worked after the move to Edge, and he made them work with his driver. Most of my devices are using his drivers, as it was the only option when everything was moved to Edge. This may be part of my problem, since he is no longer around to maintain them.
I removed a lot of old virtual devices that I’m no longer using to clean things up. I’m going to try migrating all of the devices to the stock ST drivers and see if they work now. With the IKEA Matter over Thread devices being so inexpensive, I’m considering migrating everything over and getting rid of most, if not all, of my Zigbee devices. The Thermostats are line voltage units and there isn’t many alternatives yet.
@Mariano_Colmenarejo is still active in the background. If you look at his drivers you will see that most of them were updated in Dec. 2025.
I use many of his drivers and they are not causing me any problems, but our setups are very different.
Thanks for letting me know. I head read a few posts throughout the forums mentioning that he was not active anymore.
You can see if you accidentally changed this configurations for your thermostats.
This can cause them to report changes very frequently, making them very “chatty”.
Thank you, I will check.
Hi @nayelyz, I really didn’t want to write in the forum, but I saw the engineering department’s analysis, and it seems so simplistic (They don’t say what attribute the talkative one is.) and lacking in depth regarding the defects they found and their possible solutions. Out of respect for this affected user, I’m going to do it.
You can tell them the following:
-
The custom Zigbee Thermostat Mc driver uses the same attribute reporting configuration values as the stock Zigbee Thermostat driver (local temperature attribute: max interval 60 sec, reportable change 0.5°C). The problem is that SmartThings didn’t consider that someone might have 14 thermostats connected to the driver (60 sec / 14 thermostat= 4 sec average per message).
-
This device configuration is in the stelpro-ki subdriver.
-
My stelpro-ki subdriver is a copy of the stock one and had an error in setting heating_set_point; it doesn’t support decimal values. I corrected this error for this user and others in January 2023.
-
In th issue report in 2023, the user clearly stated the thermostat model with the problem (Stelpro KI), but the stock driver only fixed issue for devices using the main
init.luafile and leviton subdriver, with PR 1049.
it does not fixed for the stelpro-ki subdriver. To this day, the issue remains unresolved for stelpro ki, making it impossible to use the stock driver.
@mlchelp The maximum local temperature report interval has already been increased in the zigbee Thermostat MC driver. The problem to keep in mind is that in SmartThings, for these changes to take effect on already installed devices, the user has to reinstall the devices so they can be reconfigured.
During the development of Edge, SmartThings changed the configuration intervals several times, including temperature, humidity, power, and energy. There are thousands of Zigbee devices that were migrated from Groovy or installed several years ago and are configured with outdated values. No one told them they had to reinstall the devices when the configuration changes were made.
Community-developed drivers add value to this platform, even if some people find them annoying. For many users, they are their only solution.
Regards
8 Likes
Hi, @Mariano_Colmenarejo
The hub logs don’t contain the same information as the driver logs, they are more focused on transmission details.
For this reason we collect both when analyzing issues with device status not updating as expected.
In this case, they can only see many messages incoming from the devices, not their details.
And, since I’ve seen some custom drivers allow you to change the reporting interval, I mentioned it as a possibility and see if he might decrease the frequency to help in the situation.
About the stelpro-ki subdriver, I’ll create a report to follow up on the changes.
Also, about this statement, I don’t know if anything in my comment made you think that, but I don’t think the Community drivers are annoying.
We know they add a lot of value, and I appreciate that you wanted to help in this thread.
6 Likes
Hi @nayelyz
Sorry, I wasn’t referring to you!! 
You’re the person who has helped us all the most during these years of Edge development, and I’ll always be grateful.
As soon as the team saw that there was a custom driver, they assumed that was the reason the thermostats were talking so much.
The SmartThings app constantly reminds us, on every device, that if you use a community driver, the device may malfunction, and you can change to other driver.
Maybe,They could say: Thanks for using SmartThings, even though we didn’t create an official driver for your device. We hope you have a good experience with us. 
Regards and thanks a lot
7 Likes
Mariano, I added each thermostat again as you instructed and they are all working. Thank you. Much appreciated.
3 Likes
Following up on this comment, the engineering team created this PR: CHAD-17711 Adds missing fix from BUG2-532 for Stelpro Ki Zigbee therm… by greens · Pull Request #2821 · SmartThingsCommunity/SmartThingsEdgeDrivers · GitHub
Thank you for bringing this to our attention.
We invite everyone to let us know (aside opening issues in the repository) if they find something wrong or that can be improved in the official drivers. We can provide more awareness about it by opening an official report.
Thanks again! 
2 Likes
Hi, @nayelyz
Perhaps they should increase the maximum reporting interval for the localtemperature attribute, currently at 60 seconds, to 300 seconds, for example.
With 14 thermostats installed, there are many messages in the network