Major issue with device connectivity (ALL TYPES) past few days

also having major problems here(uk) with all ST motion, multi & power devices. just raised ticket

1 Like

Sorry for the very late response but, no I haven’t received ANY type of response from ST.

I have my old t-stat (non zwave/ST) connected until there’s a viable fix. But, to top things off the new boiler has been also acting up. So it’s better for me to leave the old school t-stat on for awhile.

I really hoped that after Samsung bought ST things would be better. Oh well.

Still broken, going on two months now.

I give up, going out tomorrow to buy a Wink.

I am again having issues that make little sense. At times I am unable to control a switch from the app, but Alexa can control it just fine. My CoRE automations have failed to run the past two days. Response from support is to reboot my router, etc…

Here is the problem: I paid $99 for what was marketed as a consumer ready home automation hub. At no point was it marketed as a beta product plagued with bugs and inability to provide reliable service. If I wanted a questionable home hack job, I would have bought a raspberry pi and used it to automate a set of relays.

I’m done playing silly unplug this and unplug that support games. I get paid to solve complex problems at work; I’m not going to troubleshoot Samsung’s crap offspring for free and on my time. Fix your junk, SmartThings. You didn’t sell a prototype beta product. You advertised a plug and play appliance. Make good on it.

1 Like

I’ve been in contact with Mathew almost every day. He is working hard at getting our problems fixed. They are trying to send logs over to engineers during times when the hubs are inactive to see what is going on. I’ve done this a few times so hopefully there is a solution soon. I’ve asked to have my hub software reverted to the previous version when I wasn’t having any of these problems. I know people are working hard to fix this but I’m tired of coming home to a dark house and having an alarm system that is worthless bc the hub goes unresponsive while I’m gone at work and there isn’t anything I can do until I get home and reset the modem.

1 Like

Apparently rolling back my firmware isn’t an option. I am not sure why it isn’t but that’s what I was told. I’m inquiring about compensation now. No way I would have bought a hub if I would have known I was going to be a Beta tester. This has been going on now for almost a month and I honestly see no end in sight. I get a lot of “our engineers are working on it” I am going to be looking at alternatives for my home automation needs soon if this isn’t resolved relatively soon.

A quick question for all on this thread: Does anyone have a Fortrezz moisture sensor in their network? Following up on a possible lead, but just gathering data at this point.

Support was able to finally get some engineering eyes on the problem covered in this thread and they’ve spotted a possible problem with one of my 2 Fortrezz sensors. Feel free to direct/private message me if you like or post on this thread. I’ll post results back here whether it turns out to be a real lead or a red herring…

I’m absolutely ecstatic - we’re working again after 7 weeks, 5 days of being offline. Our Hub and cloud-based commands have been working now for 8+ hours.

The fix? Engineers FINALLY looked into the situation and found a Z-wave device that had identified itself as Zigbee somehow and was causing all that havoc. Specifically, it was a Fortrezz Moisture Sensor. What I don’t know is if the device suddenly had an identity crisis or whether a cloud-based change started choking on the device in the strange state. I suspect latter because the device in question has been in place for many, many months (since the early v1 Hub).

I’ve asked support to let me know how I could identify if a device suddenly decides to have an identity crisis in the future. Support also mentioned that another customer having the same issue had used a custom Device Type Handler that was throwing cloud errors. Perhaps a recent firmware update is less forgiving of errors(?).

Hopefully we’ll get a response soon as to why we had a bunch of customers go offline on about the same day, but am posting this as promised so you can check and see if you happen to have the same issues as me.


That’s wild. Can the hub pair with a device that’s zwave but reports itself as zigbee? If not, it must have been the sensor that changed. Do you know if was actually working (i.e., correctly reporting moisture) before you started having widespread problems?

I’d guess it was a combination of the two. The sensor probably went wonky at some point after install, but the ST update changed the handling and started causing the hub to get borked. That would explain why the root cause appears to have surfaced at the same time for several people.

There’s no way for the physical device to misreport what it is. It’s not even talking to the same part of the hub. The hub is one white plastic box that contains multiple individual devices, one of which is a zigbee coordinator and one of which is a Z wave controller. They don’t talk on the same frequency, they don’t send the same format in their messages. So there just is no way for a Z wave device to misidentify itself and have that work.

On the other hand, database corruption on the cloud Side could make anything happen there. We’ve had a reports in the past, for example, of people who had devices show up in the device list for their account which were not their devices. (One member had screen shots of a dining room sensor when he doesn’t even have a dining room.)

So I’m not sure what happened, or how it happened, and why multiple people would’ve been affected, but I’m 100% sure that the sensor device itself had no way of tricking the hub into thinking it was zigbee when it was actually zwave. That bit had to happen on the cloud side.

1 Like

Yep, completely agree that is the more plausible explanation if the sensor is no longer “malfunctioning”. If it is functioning normally now (can be paired and controlled using zwave), then I think JD is probably correct.

1 Like

Support has contacted me again - they’re going to keep looking into how the device changed. They simply changed from “SmartSense Moisture Sensor” to “SmartSense Moisture” (see image below). One is Zigbee, the other (my device) is Z-wave. Too bad they don’t identify which is which on the device type lists - not that it would have mattered in my case.

I guess it is possible that I changed it, but if so it was completely inadvertent. Matthew said he’d dig until we found out how it changed, so I’ll know if it was me. One thing I’m 100% certain of, is that I did not change it the first week of December. This is our crazy business cycle at work and I haven’t messed with ST for months. Who knows - maybe I butt-changed it. I’ve butt-dialed enough people lately!! LOL.

Here is the response from Matthew in support:

Thanks for patiently waiting.
I’ve just double checked with a different engineer on support rotation this week, but he’s verified what I consider fact: there’s no way for the device to have fingerprinted improperly, and is impossible for it to have worked when the wrong one was selected. Attached is the picture of Types that we changed yesterday, and everything started working afterwards. Most likely it was a person that changed this, but I have yet to get a definitive answer on where/who changed it, we just know what and roughly when so far. I’m thinking you would have remembered changing this, and if you did, that’s totally ok, we’ll at least know. If not, I need to keep hounding different channels to see if we made a cloud change to some device type handlers.

I’ll keep digging, but wanted to give you that update!

1 Like

Is anyone else on this thread (that was offline since early December) back online?

1 Like

I went offline just yesterday (Jan 28). Maybe its unrelated to this thread. I am surprised that no one is reporting a success similar to yours. Are they still offline?

@kilo, it isn’t that the hub goes offline - but that Cloud Processing doesn’t seem to work (routines/commands that only require local processing still work).

I received an email from support that they are working with each person one at a time, but that only 3 of us had committed to “helping”. So far they say that the DTH was somehow messed up, and someone else with similar behavior isn’t responding to emails. I think they already lost him.

It is definitely worth referencing our ticket/problem numbers (earlier in the thread). I’d happily chat with you by PM/DM if you want to talk more about symptoms and whether yours match mine.


PS: Check your batteries if you have a V2 Hub and take them out.

Just downloaded the firmware update. I had to reboot my hub to get the update to initialize. I’m still having the same issue as before where the hub and mobile app report the switch is on when it’s actually off and I’m unable to control the switch with the app. For some odd reason Alexa can control it through the hub.

No improvement that I can see.

Support just sent me an update on my ticket (which they have graciously left open as they continue to troubleshoot).
The symptoms were identical to mine, so I’m sharing what they found:

…we found a sensor using a zigbee device type handler, when it’s network ID was 08. That single bit DNI indicates it’s a z-wave device, so we switched the handler, and rebooted the Hub

So again, somehow a Z-Wave device was using a Zigbee Device Type Handler (DTH). I’ve asked how in the world that could happen automatically, assuming that it shouldn’t, that leaves the possibility of a manual mistake where a Zigbee DTH is chosen inadvertently (or unknowingly since Zigbee/Zwave isn’t indicated in the DTH list that I can tell), or whether there was some other corruption or issue under the surface.

Does anyone know how to use the IDE to check for whether a DTH is Zigbee or Z-Wave? In my case, “SmartSense Moisture” (ZWave) and “SmartSense Moisture Sensor” (Zigbee) are right beside each other. how would I (or any other average or technical, but not developer) user know the difference?

Sorry Tracy, I haven’t checked in in a while. I had the same issue as you but it was with one of my open/close window sensors. First they thought it was the custom device type I had. We switched it to a generic device and the hub worked for 12 hours or so before going dark again. Then after a few days Matthew got an engineer to take a look at it and realized it was one of my sensors. Tracy, I also don’t know if the device changed on it own somehow or what happened. I had the device in place well before the problem occurred and definitely haven’t changed it. My hub is working now.

On a not really related note though I have a bunch of lowes Iris sensors and found out that I had 7 of them that had fallen off the network and I had no idea because they were still reporting temperature but not open/close thus rendering them useless on my alarm. Going to have to look into it some more this weekend.

1 Like

@mikescags Mike, Glad you found it! It really is interesting (not in a good way) that quite a few of us have had a sudden problem related to sensor configurations (stored in the cloud) that have suddenly changed. Matthew has been great for a front-line support advisor and has hung in there and gone to bat for us collectively.

On the Iris sensor issue, I’ve found @krlaframboise Kevin’s Simple Device Viewer to be extremely helpful in seeing when things last checked in, TRUE battery level, etc. Huge kudos to his work on it:

Here’s the community release page: [RELEASE] Simple Device Viewer

Hope you find it helpful too!

1 Like

Thanks, Tracy! I’ll definitely look into that when I get a chance. Would be nice to have all of my stuff working and functioning correctly again. Thanks for all of your help and getting the ball rolling for everyone.

1 Like