No — it’s not hardware based, just my thoughts for a ‘standard’ way of adding more buttons. I’m fairly certain this can be sorted with a smart app/device type, but I’m going to leave it to folks who are knee deep in this one already as I’m working on a few other devices that are of higher priority to me.
My thought is that the app or device type would check to see if the ‘7’ key was pressed within the last three seconds?
Yup… There are a few ways to do this. If similar to my “PIN App”, this could be implemented in the Controller SmartApp (frankly, Aeon and Enerwave can actually use the same SmartApp if the concept of “held” is handled better…); by just trapping all key events and setting state.shifted = true and the shifted state would last until the next button press (or shift again to cancel). This method would require no time limit since the shift is pressed.
Works well, thanks @mattjfrank and @bdhalem, my plans are realized: I can control different delayed bathroom fan turn-off times, coordinated with the light, all from buttons of the ZWN-SC7 (just added delay minutes input for the “Turn on” in the smartapp).
[Why I care (and nobody else should): I forget to turn the fan off, and having timers turns it off saving energy. I use to have a plain wall timer, but, wanted to sync this fan with a crawlspace fan that can’t be accomplished with a plain wall timer. I’m in an old pier and beam house with some funk in the crawlspace that gets sucked in when the bathroom fan runs unless there is a crawlspace fan pulling the other way. All complicated by a single gang box feeding the fan and light. Installing those Aeon micro switches required great patience. A new house might have been easier than this, but I am content…]
Updated the deice type code with the device fingerprint so that when adding the device if you’ve already created the custom device type code and published it to yourself you shouldn’t need to edit the device and select it.
Tried the setup steps multiple times, never automatically recognized the device as documented, says may take several times, did well over 5, no joy. Couldn’t get anything to work till I changed the type manually on ide.
The toggle feature seems great to get more items active vs one button on and another off, unfortunately, not very effective. While watching the log, it seems when you press a button, it may show up as if you pressed it 2-3 times, thus the toggle action becomes confused and seems not work. Seems like a delay is needed so single press are received as single toggles. It is actually very hard to tap a switch and only get one scan in the log.
Am I missing an update? Seems like the thumbprint update should have fixed my 1st issue. Any updates done beyond this thread?
Hello @jimmay3 I’m glad you got it working, yes the work around for #1 would be exactly what you did. I will have to retest this part. I just verified the fingerprint is correct.
As for your second issue. The buttons are very very touchy. You’ll notice in the device type code there is some code to detect these and ignore them. I’m currently using mine with the app I published with the device type and 1 button for each toggle.
When I get some time I will be playing with this some more. I also have a couple GE Quirky Tapt switches I got working but they should have more functionality that I need to figure out. Work load as of late is taking priority over ST, not to mention I’m learning as I go with ST code.
I should note I use this device numerous times a day and except for a couple days of ST glitches, it’s worked exactly as I expected.
Seems better when I assign one button for off and one for on for each device vs. one button in toggle mode. Watching the log, it fails toggle every time the log shows more than one press of the button. If I really try and press button very fast, then it seems to get one key scan and work ok, but a normal key press usually renders 2-3 button scans in the log, thus it just seems to lock up and not change state at all.
On/Off works better, but again still not 100%, maybe about 80% vs. the toggle which is about 30%.
I’ve programmed a lot of languages in the past, but haven’t really looked at the setup with ST, all new to this system, nice to have an open architecture to support users to go out on their own, but you would think the mfg’s of the hardware would really want their products to function 100%, thus more sales. Seems like a possible huge market for a fully functional wall mounted and regular remote. Tried a few and this is the closest to working, still very frustrating for the normal user, almost enough to drive them off to another platform.
Seems if you we’re going to make a hub, you’d offer some type of affordable multi-switch wall mounted and remote controllers (or at least put some effort into getting one of each type to function on their system), the idea that everyone just wants to use a smart phone is nuts. Other platforms offer controllers right from the hub mfg, some even a package deal. Seems nuts that you would walk around with your phone, or tuff when you have guest over or young children…
I ought to do a close comparison of the ZWN-SC7 Device Handler vs the Aeon Minimote, since I’m only familiar with the latter…
But, my comment is that the Aeon Minimote has clearly special behavior when the same button is pressed multiple times quickly, vs. if you press different buttons in the same amount of time. In the first situation, the multiple button presses are filtered out … only one button press event is reported by the Handler.
There is / was some code that looks backwards in the event log for additional button presses, but the results made no sense to me.
Overall, this behavior and the supporting code does make sense to me, because it seems reasonable to read multiple button presses, of the same button, in a short period of time, as filterable error … a debounce, sort of.
Do you think there is a similar between these two scene controllers?
The code for the ZWN-SC7 is basically the minimote code if I remember correctly.
I have a V1 of the minimote and I dislike it very much.
What do you dislike about it?
I find it tolerably bothersome that you need to wait for a 1+ seconds duration round-trip of some sort to receive the confirmation red LED flash before pressing the same button more than once in a row, but that’s not too common a requirement.
The long-press (“held”) option for buttons 5-8 takes a bit too long too, but is at least confirmed with a blue led flash…
(But otherwise … at sub-$30 … I 
them!!!)
I’m not a big fan of remotes, because they are never where you leave them. But when these V1 dropped so low in price it was the perfect fit for bedside to control a few actions. However, it’s very unreliable. It fails to actually work probably 50% of the time.
It’s not a distance issue, it’s about 15 feet from the hub.
Hmmm… I currently have 3 of them deployed and I’m getting at least 80% success.
80% is not good enough, but it is a rough guess … maybe I should keep a log.
Still: This presents a debugging challenge. Where or what about the system is causing the high failure rate? Z-Wave interference? Dropped messages? Dropped ST Events? Slow SmartApp execution? …
I these enough to want them to succeed (and I’ve 3M velcro taped them into place so as not to lose them; and I wrote that ButtonsAsPIN SmartApp…). So I have incentive to debug!
I’m pretty sure it’s not on the z-wave side (interference), the logs are showing the button presses, but like noted above, we need to filter out the multiple ironious scans, seems to definitely confuse the toggle option. Only hitting about 80% with the ZWN-SC7 on simple single on/off assignments to each button, log shows 2-3 button presses each time I press a button, but sometimes nothing happens. Hub is about 12’ away. This seems to be the only half way functioning wall mounted remote and the v1’s sound very ruff too; so if the code is similar, we may need to dig into it. Last time I looked at the device type, they didn’t appear similar, we’ll have to check again…
The implementation of “toggle()” has always concerned me, though it may not be the root problem. The toggle method needs to reliably know the current state of the light … or one of a group of lights. And we know that device state reports can be flaky.
Personally, I’d like to see “toggle()” added as a standard command in capability.switch or a new capability.toggle alternatively … because the Device knows what last command (on or off) was sent to it … well, if it was sent through ST.
Toggle seems to work great, except when I press the ZWN-SC7 button, if I get two presses in the activity, then the device turns on and off real fast, thus the end result is the same. If I really focus and try and press it real fast and get a single scan, then toggle seems ok, it’s actually pretty nice, always swaps the mode good. But holding the button too long and getting more than one button press leads to issues. Need the device type or app to see if the prior button press was was less than a second and if it was the same button, then ignore.
That’s the opposite behavior of the Aeon Minimote. Two presses of the same button are ignored, unless you wait until the confirmation led flashes.
If I had one of these ZWN-SC7, I would compare and reconcile the behavior.
The buttonEvent(evt) handler in the SmartApp should be handling that “debouncing” with the recentEvents checking. That would be the place to start debugging.
The code looks the same so maybe the timing is different somehow with this device and the minimote?
If I recall correctly, with the Minimote, recent events returned really inconsistent results. It would only return more than one event if there were multiple button presses close together, but not the same button, or maybe it was the other way around.
I will set up a test / log.debug version and show the behavior… But someone else will need to run the same against the Enerwave.
@mattjfrank I cant get this to work for me for the life of me… I have a feeling the controller isn’t adding on to the system correctly. It never shows up as a ZWN-SC7 it always just comes on as a Zwave controller then I need to go and manually to my devices and change it…
Any help would be much appreciated.
I am trying to do what you have it set for to control the enerwave dual load controller for fan and light
here is likely something wrong with the fingerprint.
You can do exactly what you said, add the device and change it from z-wave controller to my device type. It should work once you change the device type and install the smartapp.