I hope you do not have any older GE switches.
Me too! Those old GE Switches are aweful!
At the moment, for hub connected devices, the only thing an organization member developer can do that a community developer can’t is submit a DTH for publication.
The documentation for the new mobile app and hub connected devices isn’t available to members of organizations either…
I love my switches. I have about 50 installed and have no problem with then on ST.
I understood exactly what you were alluding to… which is why I added the
If you want some more of those old GE Z-Wave Switches/Dimmers/Auxiliaries, I have some that I removed when I installed Lutron switches, dimmers, fan controllers, and pico remotes. Just let me know - seriously…
Nah, I’m good. I’ve got about 20 of them in reserve. I bought mine when GE discontinued the blister packaging for the boxes. Mine all require a neutral. I bought a ton of them in case any went bad. I guess it’s been about 4 years now, maybe 3 and I haven’t replaced a single one of them. As a matter of fact, the only devices I’ve been forced to replace were 4 of the Philips Bulbs.
My switches cost me an average of about $8.30 each.
I’m not willing to dump a ton of money on new switches just to go to a new hub. I’ll move to openHab first. They are a learning curve and slow to make changes, but they are definitely a contender.
Have you taken a look at HASS.IO? Basically, a streamlined version of Home Assistant? Seems like Home Assistant is much more popular than OpenHAB these days - but I really have no data to back up that claim… I loaded HASS.IO on a Raspberry PI using a complete SD Card Image and had it communicating to a Z-Wave switch and Zigbee motion sensor in short order (using a spare Zigbee/Z-Wave combo USB stick.) Something to consider should either of our preferred platforms take a turn for the worse. I haven’t looked at OpenHAB for many years…maybe it has come a long way in that time?
I’ve actually never looked at HASS.IO or Home Assistant.
I have used openHab a bit here and there. I was looking at it last week and their newest release is pretty good. They have really stepped up the rule engine and voice control. They are compatible with almost everything out there.
I have it running on a little quad core TV box that I converted over for it. I’ve also had it running on a desktop and it runs great on both.
Stange behavior of the Automation part: it only lists my “offline” devices…
The app device list work fine otherwise and the devices all show up in the Smartthings Home Monitor…
Seems we are missing to trigger an automation upon mode change.
I had this automation in classic: if some doors opened and not in (“away” or “babysitter in the house” modes), then change mode to “about to leave”.
In the new app,I cannot have a condition (IF) on the modes. I see the SHM security modes (armed away, armed home, disarmed) are proposed but that is not equivalent at all.
Need to add the modes as IF conditions
Also the number of xiaomi devices bing used we need to ensure these work smoothly in the transition. I know custom handlers are bing addressed but it will stop a lot of custom users migrating.
On a side not the home screen really needs overhauling. It’s terrible.
This seems to work for me. I have the option to select location in my if statement.
It has been mentioned above, I think @JDRoberts said it. You cannot have modes in both IF and THEN. For that matter, you cannot have the same “thing” in both (the same device or modes). This is what prevents me from converting my Classic Routines.
I have the same issue… check the status of a light that gets triggered by motion on the Ring doorbell. If the time is between sunset and sunrise, and the light is off, turn it on for 10 minutes at 100%. If the light is on, do nothing.
Am I the only one having issues in the new app with devices randomly showing offline but they still work? The issue is I am trying to put them in a scene or automation and it won’t let me because they are offline.
I am usually able to correct this by rebooting the hub from the IDE.
@oldcomputerwiz that worked thanks. Never had this issue in the old app, just saying.
It’s been an issue with the new app for a long time now. If you don’t need the devices to create some kind of automation they will USUALLY eventually come back on their own.
Yup, most of us as well. Did you have the health check enabled in the Classic app? If so, that was a very early attempt to do what the new app is now doing; but it never really took off and most folks never enabled it. If you did enable that feature in Classic, the device would show up with a red dot next to it and it wouldn’t function either - until you turned off health check.
What I’ve found with the new app compared to Classic with regards to this is that if a device in the IDE show up as HUB_DISCONNECTED, it will work in apps/automations and in Classic, but show as offline in the new app.
That status can be from a recent hub offline/online condition and devices haven’t updated their status properly. Rebooting the hub has always resolved that for me, like @oldcomputerwiz has just stated.
I find HUB_DISCONNECTED seems to happen regardless of whether my hub has been offline.
This does lead onto a broader issue though.
Just as we seem to crave info about making Groovy apps more ‘new’ app friendly, we have never had any useful information about Device Health since it was introduced.
The IDE shows what in Groovy terms is device.getStatus() with ONLINE, OFFLINE, ACTIVE, INACTIVE and HUB_DISCONNECTED as values (this is $status in webCoRE). The new app seems to work with a binary online/offline concept, similar to the healthStatus and DeviceWatch-DeviceStatus attributes that seem to be related to Device Health.
Personally I don’t particularly care how the status is derived, but I would really like there to only be one definitive source. Ideally I’d like it to be a compulsory device health capability for all devices.