[ST Edge] Driver for GE/Jasco Z-Wave Motion Switches and Dimmers - 24770, 26931, 26932, 26933

This is an Edge driver for GE/Jasco Z-Wave motion switches and dimmers, including models 24770, 26931, 26932 and 26933. This driver provides all of the functionality that is included in my main driver for GE/Jasco/Honeywell z-wave switches, while also adding several configuration parameters to the detail view and exposing them to automations:

The list of fingerprints currently included can be found here. If you have a model that’s not included, let me know and I’ll look into adding it.

Please note that, as of December 2021, Edge is in beta and therefore this driver should also be treated as such.

To install:

Use the following link to enroll in the channel and install the driver on your hub: Channel Invitation

If your device is already using an Edge driver, you can use the driver utility in the app to switch drivers.

If your device is currently using a Groovy DTH, you will need to exclude and then add it back to SmartThings to pick up this driver. If you have any custom Groovy DTHs installed that have the device’s fingerprint, either delete the DTH or comment out the fingerprint before attempting to re-join the device.

As this driver uses several custom capabilities, you may need to reboot your hub and/or restart the app for everything to work properly.

Code:

8 Likes

Well done Phil!

1 Like

Hey @philh30,

I will echo @nathancu and say well done. Regarding your comment about …

Does thiis mean the occupancy mode is exposed as well (i.e. can this be changed in a routine or ST automation). And it is a long shot, but does it expose the occupancy to WebCore as well?

Great work and Happy New Year!

1 Like

All of the capabilities shown in the screenshot are available to ST scenes/routines - current state on the If side and commands on the Then side. I probably haven’t tested everything in automations, but I hit enough last night to be pretty sure they’re all working as intended.

I’m completely off of webCoRE now, and honestly never got too deep into it since I just wrote my own smartapps for anything complex. Looking at it now, I don’t see the custom capabilities pulling in. However, I had the same thing happen initially with the custom capabilities in my alarm panel integration, and they eventually populated. I suspect that webCoRE does some sort of periodic refresh of custom capabilities, so it could just be that these capabilities are less than 12 hours old and will be picked up in the next few days.

1 Like

Interesting…Can you let me know if it DOES show up in WebCore. This is the only functionality that is ‘non-stock’ that I need to replicate before ST moves away from Groovy…

Great work on this!

1 Like

Can these switches differentiate between a command to turn ON/OFF and using the physical switch to turn ON/OFF? If so, what has to be done to take advantage of that. I see in WebCoRE that it is potentially possible to differentiate.

Here is a Use case:
Use the motion sensor to turn on/off the light. However, in certain cases, maybe automation is not needed, and the physical switch can be turned on to keep the light on all the time, or turned off to keep the light off all the time (maybe change the operation mode to manual, then back to occupancy as needed.

Can this be done, and if so, how?

No.

SmartThings used to support physical v. Programmatic access (and the remnants are still in WebCoRE…)

The problem is manufacturers dont support it similarly if at all. So to prevent confusion on itnworks here but not there (sometimes between different models of the same device) SmartThings dropped support for that feature.

I agree it would be helpful and have had MANY occasions over time where it would be useful, but sorry its just not there.

2 Likes

Did you happen to see the occupancy pieces show up in WebCore? This will be interesting if it does work.

No, and I’m beginning to think that it won’t happen unless/until webCoRE drops the Groovy connection and switches to using the API. A little testing just now:

  • My older (LAN device) Edge drivers continue to have full functionality in webCoRE
  • The custom capabilities for my more recently developed (z-wave) Edge drivers don’t populate in webCoRE
  • A virtual device using a Groovy DTH that includes all of the same custom capabilities as this device immediately populated in webCoRE

That leads me to believe that there is no issue with these custom capabilities, and the difference in what’s passed to webCoRE is either between new/old custom capabilities or between LAN/z-wave drivers. That’s all the testing I’m going to do on this, because it seems like it’s a symptom of the Groovy end of life (there’s a statement from one of the ST staff that drivers won’t work with Groovy apps, and while that was a blanket statement this is the first indication that I’ve had that it’s true). I would assume that if action is taken to keep the ST/webCoRE integration alive by switching it to the API, then everything would function properly.

If you’re intent on getting this device into webCoRE for however long that integration continues to work, my suggested workaround would be to create a virtual device and use ST routines/rules to link it to the real switch. You can even use the same custom capabilities in the virtual device as the real device uses (in the linked GitHub, look in the profile files for the capabilities in the platinummassive43262 namespace).

Final caveat: I don’t webCoRE, and seeing the current state of the integration I’m going to go ahead and delete it from my account. It’s possible that someone else who actually uses it will have better luck.

Edit to add… Another option is to keep using your current Groovy DTH, but edit it to use the custom capabilities and vid from this driver. You lose the local processing of the driver, but your DTH should regain functionality within the ST app while still interfacing with webCoRE since you’ll still be on Groovy. If you then also install this driver, your device would presumably map to it when ST pulls the trigger on the transition, and if somehow webCoRE has been saved then your pistons may continue to work since they’ll be using the same capabilities as the driver.

2 Likes

Thanks Phil,

I have backup plans for this in case I keep it on ST (this is the only DTH in my setup now) and I will continue to use it until it doesn’t work. I like have a hub that Home Assistant can control (instead of mass migrating my devices). Worst case is that I add a ZWave hub to my Home Assistant and just pair those devices as switching also brings LESS Alexa connectivity (and I have thought of the virtual switch idea).

Thanks for looking into this for me!

2 Likes

Bringing the conversation from here over to this thread.

I am working on getting logcat working. I currently have issues with timeouts with my hub when trying to connect for logging.

After reading through your thorough note in the thread above, @philh30 , and doing some additional troubleshooting, I am really starting to think this may be an association group issue. The devices have very sporadic motion/no motion events like there will be no events for most of a day until I refresh the device. This seems like what you described as the device is only sending the event when requested. Is there any way to see this association group? It really seems like all of my GE motion dimmers (edge or old DTH) are experiencing this exact same problem. Strangely my motion SWITCH is working just fine and is the farthest from my hub.

It seems really weird that you’d have all of them lose the lifeline association setting at once unless you were already messing around with the association settings. But probably worth ruling out. For the ones in the old DTH, you can swap to Tweaker (the version that was updated to mostly work with the new app) to check. I’ll PM regarding the ones in Edge. The only thing that needs to be set is node 1 in association group 1.

In the past I have used Webcore to set parameters in the ge dimmer/motion switches/dimmers depending on time of day. This has allowed me to keep the switch locally turnign things on and off based on motion and light (gives instantaneous response) and have adjustable time outs and dimming based on time of day so that for example in the middle of the night the bathroom is lit dimly and during the day it is brighter etc.

I can see the functions of the switch in core and appear to have the ability to change them – that is I can see SetTimeoutDuration but I don’t seem to be able to set it. I have tried passing an integer, and argument and a number. But there is no change in the device.

Can anyone help?

Or in this new edge world is there another way to accomplish this? That is set device parameters as part of some sort of automation or routine?

Thanks for the help.

@MichaelS The custom capabilities are working in webCoRE now. No idea what changed - I’m back to thinking it’s a periodic refresh.

@wgrichmond2710 The values below are the options that you can pass from webCoRE as string parameters for each of the functions. Parameters need to be lowercase as shown below.

  • setLightSensing()
    • on
    • off
  • setMotionSensitivity()
    • high
    • medium
    • low
  • setOperationMode()
    • manual
    • occupancy
    • vacancy
  • setTimeoutDuration()
    • 5s
    • 1m
    • 5m
    • 15m
    • 30m

All of those commands are available in the native ST routines that you set up in the app, and should also be available in the native ST rules if you feel like wading into those. The advantage to those options is that, so long as you don’t introduce anything that requires cloud processing, the routine or rule should run locally on your hub. Neither of those options has as much flexibility as webCoRE though, so they may not be an option if you have complex automations. One thing that you should begin to pay attention to if you continue to use webCoRE is whether the work is being done to ensure that it survives the shutdown of the Groovy cloud.

The driver at present does not expose the default dim level in the same way that the other parameters are exposed. You can’t change it by automations at the moment - only through the settings menu. Someone else had requested that it be added, so it’s on my to-do list. I’ll post instructions for updating to a new version of the driver when that happens.

Interesting. Ironically, I just moved all of my GE switches to Home Assistant so I can’t be happier with them now. Good work on the edge driver, nevertheless…this will help those that have started to see the age in my DTH and are have compatibility issues in the interface. You also rightly pointed out, however, that this may be temporary if they deprecate WebCore.

Nicely done!

I will probably update the DTH documentation to retire the code and to point users to your edge driver.

1 Like

Looks good! It’s so refreshing to have something work properly for a change. Most of the Groovy DTH are on their last legs and crumbling. Only pain is removing and re-adding which results in broken automations.

1 Like

Phil –

I can see them in the setting part of Smartthings but I want to change them dynamically as part of an automation.

Maybe what I am missing is the smart things rules engine. I have the smart lighting but really can’t figure out how to get the broader rules engine which is what I would really like.

Can you point me to where I can get this installed and working?

Does the detail view for your device show Operation Mode, Motion Sensitivity, etc like the screenshot in the first post? There are two drivers in my GE/Jasco channel that will support these devices. This one should display them in detail view and make them available for automations, while the other one is a more general purpose driver for all GE/Jasco switches and will only shown those options in the settings menu.

Smart Lighting is a Groovy app, so its fate is tied in with the shutdown of the Groovy cloud. Since Smart Lighting is an official ST product, there’s a chance there will be some sort of official migration off of it, but I would recommend skipping it for new automations.

The native ST automations that are part of the new architecture are Routines and Rules. Routines are set up in the app (Automations tab, hit the plus sign, choose “Add Routine”). There currently isn’t an easy interface to set up Rules - they have to be submitted through the API. Neither option allows for the extremely complex logic that the term “rules engine” implies, but ST does seem to be continuing to work to add more functionality to both.

1 Like

The thing that Smart Lighting offers that is not currently available in Routines is the mixing of specific times with relative times. For example, I can’t have a routine that’s active from 10:00pm to Dawn from Dusk to 12:00am.

I also haven’t figured out a way to get the mirror function of Smart Lighting to work either. I use it to turn on/off lights that are on multiple switches in a room.

1 Like

You can setup automations to do this. I have a light that comes on at sunset, goes off at 2am. I also have a turn off at 10am as i use it in the morning before it’s light out. Below is a a screenshot