Switches no longer working after Edge migration

I don’t know of a way to batch update them, but just remembered it’s quicker and easier to change drivers via the API Browser than using the ST App.

Devices->“Your Device”->Change Driver
select next device, rinse and repeat

This is much faster, working on this now.

Given that I already received it and started to set it up - is there any problem with having a second hub? I’ve got both of them on the network, but have added nothing to the aeotec yet. My V2 seemed to take a long time doing things (eg. turning off everything seems to take several minutes. so I was wondering if there was a performance benefit to splitting them up. Now, that group is from Alexa, so it may be slow there).

Not something I have any experience with but there are others who do. @JDRoberts : any words of wisdom in running multiple hubs?

Depends what you mean by “problems.” The smartthings architecture has never really been designed for multiple hubs, but over the years has gotten better at it.

The integration isn’t seamless. You can create a routine that includes a device attached to each hub, but when you do, then that routine Has to run in the cloud, which can slow things down.

There’s also the issue of network backbones: they don’t share a Network, they each have their own, so you have to have enough Zigbee and zwave repeaters for each.

Historically people usually ran two hubs in one building because they were having difficulty getting signal between floors, typically in a cement or adobe house. But now we are seeing more people running Zigbee on one hub and Z wave on the other, in part because then they are not duplicating edge drivers on the two hubs so they have more resources on each. :thinking:

There are a few community members who are running multiple hubs: I’m sure they would have something more helpful to say.

Tagging @orangebucket @csstup

2 Likes

No issues with two hubs in a single location. Each has their own set of drivers installed. Routines can run across hubs in a location but always require the cloud, even if the hubs are on the same subnet.

When you pair a new device using the mobile UI, it will ask you which hub you’d like to bind it to.

1 Like

Argh. Spoke too soon. Now it’s much more like the OP’s problem. It worked at first, but when I ran my “Goodnight” automation from Alexa, it didn’t work and everything is no longer working again - had to run around my house turning off all the lights.

Ok, I think I have a better idea of what’s happening. Until I ran that script last night (from Alexa), everything was working well - I could turn lights on and off from Alexa and from the app, and from the web page. After that, the app no longer correctly shows the status of any of the edge switches, shows no history of the edge switches, and those switches are unusable. All the other components (e.g. switches that didn’t get upgraded, buttons, etc) show history, correctly show status and work. But when I run a script that executes a command, the non-edge devices correctly respond, but the edge devices do not.

So it seems like the edge subsystem, in the hub (not the individual systems) has crashed completely - I just rebooted the hub, and the edge devices are not working. However when I update the driver (to the old one, away from the @philh30 one), it works correctly. Somehow rebooting the hub is not resetting the status of the edge subsystem. Interestingly (after updating only one device to the old driver) I ran my goodnight script and it turned successfully turned off the one updated device. The device was then working afterwards.

So to summarize, everything starts out working fine, I then run a Routine from Alexa (goodnight) that turns off most of the switches in the house. That routine does not complete (it may turn off some , and following that, all edge devices are inaccessible. I see two possibilities - either that script runs and hits an individual device that somehow kills the edge subsystem (so aggressively that it can’t be restarted with a reboot), or the script somehow overloads the queue (since it’s running ~140 commands from Alexa, rather than using the Smartthings own automation), and that queue keeps anything in it that is using the driver that was in place at the time of the script being run.

Coincidentally, every time I try to do anything on the app, I get a network delay as it’s trying to find a path to the server. This happens regardless of whether I’m on the local wifi or no wifi at all.

Are you using the reboot button in the old IDE? I’ve usually found it takes power cycling the hub to recover when it’s truly hosed.

Your V2 is beefier than the V3, but the specs still fall short of a Raspberry Pi. You’re probably overloading it with that routine. I’d suggest running logcat on all drivers when you kick off that routine to get a better idea of what’s happening to the hub.

Agree with @philh30 that you’re probably overloading your network or hub if you’re blasting that many commands with no pauses.

My Alexa “lights out” routine has an Alexa “wait” for 5 seconds about every dozen devices. For what it’s worth, I’m mostly triggering scenes from Alexa with each scene setting the lights in one room off. Then wait 5 seconds before triggering the next scene. Repeat until the whole house is done.

No - power cycling it.

What are your opinions on Hubitat?

I actually have a “room” in Alexa with all the devices and the script just turns that off.

I am going to try putting scenes in Smartthings and trigger those as you suggested.

Curious why this would overload the new system, but has worked for years before now.

I had all sorts of issues when I tried to turn off more that 15 or 20 devices at once. Delays on some and some devices didn’t turn off. In fact, my Alexa routine repeats each scene because of those issues.

As best as I can tell my problems were from having too many Z-wave devices in one physical room. We’ve got a great room that incorporates kitchen, dining, wet bar, entry, and living room. Aside from lights in the room there are controls for two hallways and all the exterior lighting on two sides of the house. All told there were something like 30 Z-wave switches and dimmers around the perimeter of this one room. I ended up replacing about a third of them with ZigBee and my Z-wave mesh issues went away.

For what it’s worth it seems like you’re having mesh issues. I don’t recall if you’ve mentioned doing a Z-wave repair recently. Or if you’ve checked for “ghost” devices.

Unless I’m mistaken, he’s running the routine from Alexa. So it would be Amazon processing the routine. I know the ST hub has to handle the 140 device calls but I’m doubting he has 140 devices that need to be triggered.
It sounds to me like he has at least two issues going on here.
I use Alexa to trigger ST scenes instead running Alexa routines.
I have a goodnight scene that turns off all lights, locks doors, shuts the garage, and sets STHM to armed stay. It has worked flawless since I created it way back with an original Echo.
Where I have any delay or issues with lights not going off is during Christmas when I add 15 or so devices that I let Alexa control. Those devices are added to an Alexa routine along with triggering my ST goodnight scene. However, this year I put those devices into a ST scene “Christmas lights off” and trigger both scenes from Alexa. It has worked flawless and triggers every device within a second or two.

So am I. I’ve had issues with far fewer devices in the past as detailed in my last post.

If we had better diagnostics we might be able to do some real root cause analysis. With what we’ve got we have to grasp at straws based on anecdotes.

2 Likes

yes, Alexa is handling the routine. Regarding devices, I did overstate that slightly - I just counted. Of the 146 devices in the API Browser+, ~26 of them are not GE switches, so I have 120 GE ZWave switches. I don’t know how quickly Alexa sends the commands, but it is sending the 120 commands to the ST hub.

I never removed my Christmas devices from the Alexa goodnight routine, although they were not plugged in previously, and until the edge update, it worked. Since it’s only the edge ZWave devices that fail (not the Alexa wifi ones, or the non-edge ST ones), I don’t think the issue is in Alexa.

I am going to try to create some scenes. The more I try things, the more I think it’s one bad switch, which will be quite hard to find from 120!

1 Like

Yeah, I’ve tried running a repair many times. Tried again last night. Coincidentally, is there a way to run a repair from the API+ or CLI? I used to do this from the old UI. Unless I keep the app open and my screen on, the logs don’t show on the phone, so I can’t tell what happened with the repair. I have not yet done a logcat (just learned about that) so I’m going to try that next and see if the repair finds anything interesting. there are always a few devices that have problems, but the edge ones, from what I’ve seen, do not show any updates.

Yes! this is exactly my feeling!

1 Like

If the Alexa routine is to turn off all of those devices, then the Edge driver is still processing all 120 off commands. The driver is then adding a z-wave command to the radio’s queue for each. I definitely think that’s the kind of spike that can overload the hub.

2 Likes

I’ve never really looked at Hubitat. I never really liked writing code in Groovy (though that was probably because of the ST cloud being involved) so I haven’t explored it. I think their hubs have better specs than the current ST hubs though. My biggest issue with ST right now is that the hub they’re selling wasn’t designed to handle local processing, so it’s collapsing under the weight of all of the drivers we’re installing on it. My V3 starts crashing if I install more than 11 drivers. I started experimenting with HA over the holidays and that’s probably where most of my heavy lifting is going to move since I can choose how powerful of a system I run it on.

2 Likes

That is good to know. I’ve never had a reason to run a log on my scenes or routines so I wasn’t sure how they fired.

I would have assumed if ST got a command to turn something off that is already off, it would ignore that command. I definitely assumed with the new Edge Drivers that this is how it would work. Given their locally run and supposed to be more efficient.

1 Like