Here is the information from IDE. If you could tell me how to take live logs, I’d be happy to do it. I have an additional one of the same switch to test on.
The supported button values are showing in the IDE, so the handler is working to add those, and you can control it in webcore. It is odd that the app won’t update with the new values. My guess is this is likely related to some sort of device caching issue with the new app, which many people have been having trouble with. Basically, that is where the app and Smartthings cloud has the wrong device presentation “stuck” somewhere. Sometimes, this flushes out on its own in a couple days. Other times, the only way is to exclude and re-add the device. Did you try assigning it to stock, then going back to the custom handler? Some also have cleared the app cache on their phone.
I could be missing something, especially since it is a slightly different Honeywell switch, but I would be pretty sure it is a presentation issue in the app itself. To look at live logs, you can go into the IDE and click “live logging”. Then go to your switch and click it up, down, double tap up, and double tap down. Then you can paste the logs here. Also, if you can click “list events”, after doing the presses, and list that here, I can double check if it is possibly some other issue.
I’m having the same issue. I had to roll back the code to the previous version because I couldn’t see the new buttons in Automations and my existing double-tap actions (button 1, button 2) in Smart Lighting stopped working.
Yeah I’m not sure why that’s happening. I have the switches and they show up in mine. Are you getting the supportButtonValues all showing? Maybe its a different hub or switch? I’m on a V3 hub and there are so many versions of this switch its hard to figure out where this is going wrong.
Yes that would be the case for anyone upgrading. The button values all changed with this update. Before there was “button 1” and “button 2”, but the new app only recognizes “button 1” and nothing else. Then it assigns different “supportedbuttonvalues” to that button one. So I had to redo the handler to move everything to button one and use supported button values of “up_2x” “down_2x” etc. Therefore, any smartlighting automation would need to be deleted and redone. That was the only way I could get it to work with the new app’s automation screen. Also, many regions do not support smart lighting and for those people, after the new app upgrade, they couldn’t use the old handler at all unless they used webcore. I added this warning to the code:
* Button Mappings NOTE - THIS IS A BREAKING CHANGE from prior versions and uses a single button.
* ALL prior automations will need to be re-programmed or updated when updating this DTH from old versions:
*
* ACTION BUTTON# BUTTON ACTION
* Double-Tap Up 1 up_2x
* Double-Tap Down 1 down_2x
* Double-Tap Up Hold 1 up_3x
* Double-Tap Down Hold 1 down_3x
* Double-Tap Release 1 down_4x
If you have smartlighting and all was working fine, it is best you just stick with the prior version if you don’t want to have to redo everything. I know this isn’t ideal, but I’m just working with what Smartthings is giving me with the new app.
1 Like
Just discovered the DH this weekend so this weekend I was able to switch over to this DH but not without issues. Currently I have two GE/Jasco 14292 switches with one switche is using a 12728 addon switch. I purchased both switches back in 2019 and found that my fingerprint ID was different that what was in the code. No biggie, I just added it in.
fingerprint mfr:“0063”, prod:“4952”, model: “3037”, ver: “5.22”, deviceJoinName: “GE Z-Wave Plus Toggle Switch”
First switch had no issues when I switched the new DH. The double toggle function worked just fine. The issue was with the second switch. This switch uses the addon switch. For whatever reason it would not register a double toggle. I tried deleting the device from Smarththings. Resetting the switch but still would not work. As a last ditch effort I powered off the switch at the breaker and turned it back on. Ha! It would would work. Not sure why or what was going on but something to try if others are having issues.
So now the only thing that isn’t working is my addon switch. I know the addon switch is just that. The switch just registers on or off regardless of how many toggles you do. Does anyone use the GE/Jasco Switch with an addon? Does it register a double toggle or is it simple on/off?
I have an add-on that does work with my zwave plus dimmer, but from reading older posts on here, the add-on is hit and miss whether it triggers double tap or not. It seems to be more of an issue with this on/off switch then the dimmers even. If you search this thread for “add-on”, There are several that report the main switch supports double tap, while the add on works for some and not others.
Unfortunately it’s going to be in the device firmware whether it works or not, and there’s no setting or code change that will get it working if it doesnt. I have not seen Jasco ever release firmware updates, and firmware updates with zwave devices, even if the manufacturer releases them, are not currently supported by Smartthings. Smartthings is currently beta testing zwave firmware updates, but Jasco is not on the list.
I can confirm I have the newer 46201 on/off switch with an add/on, and the add/on for that newer on/off switch does support double, and even triple tap, both at the main switch and add on. That switch uses central scene control for that which is an upgrade over older switches. I released an updated handler for that switch, more info here - [RELEASE] GE/Jasco 46201 On/Off Switch
But unfortunately, unless someone knows something i don’t, the only way to get double tap working with the add-on for the on/off switch will be upgrading to the 46201 switch. Your existing add-on would still work fine so only the one switch would need to be replaced.
1 Like
GE add ons don’t really have firmware. They don’t have radios and they aren’t smart devices. It’s the master switch that does all the thinking. unless you were referring to the firmware in the master switch.
Here’s a teardown of the add-on.
https://www.reddit.com/r/homeautomation/comments/5ihlao/inside_of_the_ge_smart_switch_addon/
1 Like
Sorry I meant the firmware of the primary switch will dictate if the add-on can control double tap. The add-on just sends a low voltage signal back to the main switch. All the processing still happens at the main switch.
I had a non plus Jasco with no double tap, and then replaced with the new switch with double tap. Same add on as before now triggers double/triple tap without replacement of the add on.
2 Likes
That’s a bummer. It would be nice if the firmware was ungradable on these things. We really shouldn’t have to replace them if we want new features. Not sure I want to buy another one just to get this feature. I’m currently looking into other alternatives like smart replays. I have an Enerwave replay on the way. Curious to see how that works.
Just found this DH (and am fairly new to them in general). I was using another DH (by rym002) for the dimmer switch, and I noticed you can disable the hardware switch within the ST app. I’m not seeing that feature in this handler (haven’t checked your Dimmer DH yet). Is that something you’d mind adding. EDIT: I’m a dummy… Looks like the other DH doesn’t have it either, it’s on the Zooz handlers. Do you know if this switch supports it?
Or, since I’m a programmer, maybe you could point me in the direction of how to add it myself? It seems to be in the preferences portion of metadata.
Also, this is a REALLY dumb question, but what does the Force Settings Update do? I’ve seen something similar on the Zooz DHs, and I have no clue what it is. Thanks for helping a n00b
I’ve never seen a Jasco switch with that functionality. Smart bulb mode is a feature that’s usually prominently advertised, so if you need that in a switch make sure you see it on the product description before buying. Zooz and Inovelli are two of the manufacturers that I’m aware of that are including that option on their devices.
We’re in the middle of a transition away from DTHs written in Groovy. The replacement, Edge drivers written in Lua, is in developer beta. There’s a topic with an overview of the transition so I won’t go into further detail here. If you’re starting to play around with DTHs as a programmer, I’d recommend you look at Edge instead. For the GE/Jasco devices that work with this DTH, I have an Edge driver that you can find here.
That’s not a standard function, so it does whatever it was designed to do by the person who wrote the DTH.
2 Likes
Jeez, thanks for the dive down the rabbit hole of Edge, Matter, Thread. Looks like I’ve got a whole new list of things to figure out after “getting my Pi back up and working” gets done. I just found the Virtual Switches in Labs a couple weeks ago and was loving them.
Is it even worth learning any of the current smartthings stuff at this point? I’m seeing “device association IDs” which piques my interest, but if it’s just going to get scrapped… sorry if this is too close to LMGTFY territory, but is there a general wiki somewhere that I can get lost in? Thanks for the suggestions.
I will say, and this isn’t relevant to this thread, having ALL devices switch to an edge device driver is a big no Bueno. I’m hoping they address that. I like testing one device before going all in, and thats one of the things I like about the IDE…
Probably best to move to a more appropriate topic to continue this conversation. Feel free to tag me if you post elsewhere or create a new topic.
Just to hit a few of your points though:
- I wouldn’t spend time learning anything based in Groovy (which includes the very popular webCoRE rules engine) as the Groovy cloud will go away, it’s just a question of when.
- Not everything is changing (device association is a z-wave thing, and works just fine in the new architecture).
- All devices will eventually need to move to the new architecture. The answer for hub-connected devices (z-wave, zigbee, LAN) is Edge, and there are other solutions for devices that connect through the cloud.
If you’re just starting now and have devices connecting locally to your hub, then Edge is definitely worth diving into. Great time to learn as we’re all learning.
And apologies for sending you down the rabbit hole. You mentioned you were a programmer just starting with ST so I didn’t want you to waste effort in Groovy if you were going to start playing. For consumers using normal off-the-shelf devices, ST should be handling the transition to the new architecture seamlessly. It’s the custom DTHs and home-built devices that are a different story.
2 Likes
- To answer your second question first, there’s a community-created wiki that’s been around for a few years, but there’s hardly anything in it yet about edge and the new architecture. However, it is a good place to find the list of community written edge drivers that are available for public trial.
There’s quite a bit of official documentation, but all of it is still in development and some of it is contradictory. So you can definitely get lost in it, but I’m not sure that’s a good thing. 
Phil and others have spent a lot of time in that labyrinth and might have some additional thoughts, but, as he note, that’s for a different thread.
- as far as this question:
Is it even worth learning any of the current smartthings stuff at this point?
It’s really hard to define what “current“ since Samsung missed their own announced timeline for cutting over from the old architecture to the new architecture, and there’s no new timeline specifics announced, so who knows what will be working when? Some things are only available in the old architecture, but a lot of the new architecture is still in beta and there are glitches and frequent changes.
I don’t think it makes a lot of sense to spend time working on groovy, whether it’s for smart apps or DTHs, unless there’s a specific device that you really need to get working in the next few weeks and it’s not supported in the edge beta yet.
There are a number of community members who have begun developing edge drivers (written in Lua instead of Groovy), but again, everything is beta and there are glitches. So it’s interesting, some of it can be used right away, but you will be spending time on something which is changing frequently. That would be worth it to some people, but not others.
The following thread might help:
FAQ: I have no idea what Edge is. Is that a new developer tool? (2022)
- Zwave direct association is part of the independent third-party specifications for Zwave. It’s useful for some situations and feels kind of out of date for others. It’s been around a long time. The biggest issue with it is that you can’t make the triggers conditional like you can with scenes or routines. So if you set it up with a direct association so that this motion sensor turns on that light, then activating that motion sensor will always turn on that light, regardless of time of day or who is home or any other conditions.
Personally, I think Zwave direct associations are most useful for auxiliary switches in a three-way set up, because I personally can’t think of a situation when you wouldn’t want the auxiliary to turn on the Master. ( and I’m really good at thinking about use cases. 
)
Zwave direct associations will work even if the hub itself is broken, again, good for three-way light switches. But they are just a very primitive form of automation.
They are also popular for multi button wallmount or handheld switches, again, because if you want a double press on that switch to turn on a specific light, you want to do it every time: you’re not going to wrap a conditional around it.
But Z wave direct association can only be used between 2 zwave devices and only if they are at the same security level.
Most of the other automation methods available to you on the SmartThings platform will let you work with any devices of any protocol that are exposed to your smartthings account. They don’t have to both be z wave.
So… Z wave association is part of the protocol and some manufacturers do rely on it, particularly for multi button remotes. It’s good to know about it and you may want to use it for some specific devices. But it’s not something you’re going to use most of the time, it’s just too inflexible.
Regrettably, from my point of view, from the very beginning smartthings made the decision that they were going to make anything which was specific to one protocol pretty much invisible to the end user In the official features. They thought this would be less confusing, I think it’s just frustrating. It means that the official UI doesn’t offer an easy way to create associations or set up zwave central scenes, or identify Zigbee groups, or really anything which is protocol-specific.
right now, for example, the official response from smartthings have been that they don’t even know whether you will be able to set associations with an edge driver, which to me is bizarre for a hub which is a certified Z wave controller. However, as @philh30 noted, it can be done. But I doubt if you’ll find official documentation on it yet.
Anyway, you just happen to hit one of my own hot button issues, which is that multiprotocol platforms should provide more options, not fewer, but that’s just my own philosophy.
———-
If you want to talk more about the issue of what is worth researching right now, that’s getting pretty far off topic for this particular thread, so you can either start your own thread or join one of the existing conversations about development for the new architecture.
2 Likes
The device would need to support this at the hardware/firmware level, and the jasco switch doesn’t. Most if not all the Inovelli switches support the option to disable local control at the switch, but they are mainly on back order at the moment.
https://inovelli.com/products/switches/
Something I’ve done as a workaround with this jasco switch is create an “override” automation that keeps turning the light back on if it’s manually turned off. Ie if a kid plays with the light and keeps turning it off, but I want it on, I can enable a virtual switch I made called “child override” that when on will trigger an automation that will cause the light to immediately turn back on if it is turned off.
I added this option to the handler to mimic the “refresh” tile that was in the old Smartthings classic app. It’s an empty setting that doesn’t actually change anything specific, but it forces the updated() method of the device handler to run. Occasionally, zwave settings, parameters, and associations may go “out of sync” with the settings stored in Smartthings. This could result from trying to change a setting while the device is offline, or is at the edge of communication in the zwave network and the device failed to update the parameter change. What the toggle does is force the settings you enter to get resent and resynced to the device.
So, it’s meant to be used as a way to force a refresh if you notice something you set isn’t sticking, without having to change other settings.
I mentioned elsewhere I’m not planning to publish updates to any of the groovy handlers I’ve posted since I no longer use Smartthings, but anyone is welcome to use them to develop their own. Also nice to see @philh30 has posted an edge version, and thanks for sharing the link for others.
3 Likes