[OBSOLETE] ZWN-SC7 Enerwave 7 Button Scene Controller

Devices & Integrations Community Created Device Types
, ,
1

See post #4 for custom Device Type and SmartApp for this device.

While I’m still working out a few bugs with my Enerwave Dual Load ZWN-RSM2 I’m hoping someone can get me started with getting the ZWN-SC7 to control devices on/off state.

Specifically, I’m hoping to control 3 of the ZWN-RSM2 modules with this device and will be adding even more in the future.

In short my rooms almost all have ceiling fans/light combo’s but only one hot wire. So I’m putting the ZWN-RSM2 in the fan canopy and using the ST App and ZWN-SC7 to control them.

ST doesn’t support secondary controllers from what I understand, but from the little digging I’ve done. My guess would be that with a custom device type and maybe app, I should be able to accomplish that. ST does recognize and install the device, so I guess thats good.

Anyone have any input help me get started?

I know there are remotes and controllers that people have got working. I have one of the HA07’s although I can’t even get ST to recognize it period. I’ll get to that later.

1 Like
2

Here is the reference document I received from Enerwave

Hopefully someone can help me create a custom device type or something…

3

Here is a quick view of this device:


http://ecx.images-amazon.com/images/I/31aJBLkSyBL.AA160.jpg

4 Likes
4

Thanks to the power of the community @bdahlem @dmazzoni @bravenel this device now works with SmartThings with a custom device type and smart app.

[Edit 12/24/2014 Device type 1.01 published to github]
[Edit 12/27/2014 Add 5b to use a different SmartApp by @tgauchat for more button functions]
[Edit 1/11/2015 Added fingerprint on device type. Swapping step 2 & 3 of instructions because step 2, now 3 you shouldn’t need to assign the device type]
[Edit 3/5/2015 Fix in SmartApp from @mattjfrank @mattjfrank @mkowalchuk]
[Edit 10/5/2015] Updated SmartApp using suggested changes from @erocm1231 in post #473
[Edit 10/14/2015] Updated SmartApp using changes from @erocm1231 in post #507
[Edit 10/22/2015] Edit instructions for device type step #4

I’m very new to groovy and SmartThings coding, struggling to learn what it all does and how it works. Feel free to provide feedback. I wanted to get this code posted so the kinks can all get worked out. I know it’s messy, your help is appreciated.

Installation Instructions
1- If you have already added your ZWN-SC7 put your hub in exclusion mode and press and hold the bottom big button on the ZWN-SC7 for a couple seconds, the lights will all turn off. Now press and release the top right button, then the second row right button, now the 3rd row right button, the lights will flash and the device should be reset. (You may have to repeat this step a couple times if you aren’t able to get the device added.

2- Install the Custom Device Type at https://github.com/mattjfrank/ZWN-SC7-Enerwave-7-Button-Scene-Controller Once installed save and publish to self. This should automatically assign the device type you created to the device when including the device below.

3- Put your hub in inclusion mode, press and hold the bottom big button on the ZWN-SC7 for a couple seconds. When the lights go out, press and release the top left button, the second right light will come on, now press and release the second row left button, the third row light will come on, press and release the third row left button the lights will all flash and the device should show up in the SmartThings App as ZWN-SC7 Enerwave 7 Button Scene Controller, name it and add it. If it shows up as a Z-Wave Controller change it to your custom device type of ZWN-SC7 Enerwave 7 Button Scene Controller (If it doesn’t detect the first time you may need to repeat this step a couple of times.)

4- Open Live Logging, Open the device in the SmartThings App and press configure. The live logging should response with 7 buttons stored. If not then you’ll need to repeat step 3 until it does.

5a - Create the SmartApp at https://github.com/mattjfrank/ZWN-SC7-Enerwave-7-Button-Scene-Controller
Once you’ve created the SmartApp you need to install it for your Z-Wave Controller as you install it you will select which device to control with each button.

or

5b - Create the SmartApp at https://github.com/CosmicPuppy/SmartThings-ButtonsAsPIN/ to setup numerous combinations to control devices/modes/phrases

Current Issues
1- Button 1 doesn’t seem to respond or work. I am guessing it’s because I created this based off @bdahlem device type and smartapp for a VRCS4 and that device has a relay for button 1. I thought I removed all that stuff but I’m sure I’m missing something. [Edit Resolved 12/24/2014 with device type version 1.01]

2- You will notice in Live Logging that when you press a button to turn a device on or off the log shows the opposite. I think this may be related to why the light indicators on the device don’t show the proper status. [Edit 12/24/2014 the light indicators on the device seem to light up for the last button press, I’m not sure yet how to get them to light up to indicate something is on or off]

15 Likes
5

Great work!! I will order one of these now. No doubt the handful of wrinkles in the Device Type will get worked out.

Thanks!!

1 Like
6

Thank You, I looked at this device type before and gave up pretty quickly. Knowing that others were interested in it kept me up late last night seeing if I could get it going.

7

I’m wondering if anybody watching this thread has this 7-Button Controller and could test it with my “Security-PIN” SmartApp (beta)??

Info on the SmartApp is at this Topic:

Thanks!
…CP (Terry).

8

I gave it a try and it does not work. But I’m guessing it’s the way my initial use of the existing device type that I modified to make the ZWN-SC7 work.

10

I turned on debug in your app it appears to be functioning and recognizing it just doesn’t turn the switch on/off Sometimes it does recognize duplicate button presses but again I think this is device type related. It looks like this device type is based off the Aeon Key Fob, I’m going to try to rewrite it based off the minimote.

2:06:56 PM: debug "Use Buttons As PIN Input".("Use Buttons As PIN Input"): buttonEvent Device: [Z-Wave Controller], Name: [button], Value: [button 4], Data: [{"buttonNumber":4}], ButtonNumber: [4]
2:06:51 PM: debug "Use Buttons As PIN Input".("Use Buttons As PIN Input"): buttonEvent Device: [Z-Wave Controller], Name: [button], Value: [button 3], Data: [{"buttonNumber":3}], ButtonNumber: [3]
2:06:47 PM: debug "Use Buttons As PIN Input".("Use Buttons As PIN Input"): buttonEvent Device: [Z-Wave Controller], Name: [button], Value: [button 2], Data: [{"buttonNumber":2}], ButtonNumber: [2]
 2:06:02 PM: debug "Use Buttons As PIN Input".("Use Buttons As PIN Input"): Initialized - state: [inputDigitsList:[], pinLength:3, pinSeqList:[2, 3, 4]]
 2:06:02 PM: trace button from Z-Wave Controller was provided with buttonEvent...creating subscription
 2:06:02 PM: trace Use Buttons As PIN Input is attempting to unsubscribe from all events
 2:06:02 PM: debug "Use Buttons As PIN Input".("Use Buttons As PIN Input"): Updated; settings: [comb_2:3, comb_1:2, switches:[Office Light], comb_4:4, buttonDevice:Z-Wave Controller, pinLength:3, comb_3:4]
 2:06:02 PM: trace "Use Buttons As PIN Input".("Use Buttons As PIN Input"): Updated; Version: v0.1.0-beta+005
1 Like
11

EDITED

The Minimote handler provides values “pushed” or “held” with the events. My App explicitly requires “pushed” events:

    if(value == "pushed") {
    	state.inputDigitsList << buttonNumber.toString()

I think there is a questionable design issue in the Minimote Device Handler, frankly. The “held” buttons should simply be numbered 5 through 8, since they essentially are exactly like 4 additional normal buttons. It’s like saying that the # sign is Shift-3; consumers of shift or unshifted keyboard characters don’t care how a particular symbol is created, just that it is. This is different from keypresses that are not mappable to characters, such as ALT+key.

In other words, all buttons are momentary… There is no “held” capability, as this would only be useful if the duration of the hold was reported (it is not… And it isn’t even a concept in the device).

Only devices which have true duration and/or locking down after push… Well… The former is “held duration” and the latter is “on / off” or at worst “up / down”.

So why does this inconsistency exist? --> Insufficient documentation. (NB: @Jim)

The page https://graph.api.smartthings.com/ide/doc/capabilities lists detailed Attributes (states) for many Capabilities, but it is unclear on capability.actuator, capability.momentary, capability.sensor (the attributes column is blank), and for capability.button, the attribute is only “button”, but not “button number”, or "button state (up/down/pushed/held).

Per the Device Class Summary documentation page ( https://graph.api.smartthings.com/ide/doc/device ), device.State is reported with method current/latestState(attributeName); thus, it is essential that the “attributes” be defined for EVERY official implemented Capability. And devices also have the latestValue(attributeName) method; which means that the capability table really needs to specify what are the value-types provided by each attribute. Should value be button number, or up/down? The former is a configuration identifier, the latter is a state; very confusing.

So where does that leave us?
If the Device Handlers for two similar devices (that provide the same official Capability) are inconsistent, then, either and/or:

  1. The Device Handlers should be rewritten to be consistent (but this is difficult without official solid documentation of the applicable Capabilities (i.e., attributes, states, values).

  2. SmartApps that use these Devices need to accommodate all known variations in the possible attributes, values, states that come from state or event getter methods.

So @mattjfrank: You can try to write your Device Handler to be more similar / consistent with the Aeon Minimote device type (which I am ambivalent about, given that I don’t think the current Minimote device handler is “proper”); and/or I can modify the PIN SmartApp to accommodate the variation on the button capabilities that you implemented.

CP / Terry.

12

It may not be “proper”, but it works reliably. You know what they say about fixing something that works… :smile:

13

@bravenel wasn’t knocking your code at all. I do almost have it working 100% with the ZWN-SC7 just need to do some more pounding away to get it to work consistently. I think my big hurdle is the ZWN-SC7 does not have a load, and button 1 almost seems to require the the ability for the device to a have a load even if I tell it in your SmartApp it doesn’t have one.

@tgauchat I was able 1 time out of 20 or so to get your app to trigger my switch. But now I’ve broke my device handler so until I get back to a working version I can’t test further. I’ve got a lot on my plate right now and someone just told me Christmas is this week. Self Employment never seems to account for weekends and holidays! Anyway, I’m going to say with a better working device handler your app should work with the device.

Also you should both know. I am by no means a groovy developer. This is all new to me and I’m learning it just like I learned php, Other peoples code, Trial and Error and Google Searches.

14

I know. So glad you’re doing the heavy lifting for all of us!!

1 Like
15

I just received a ZWN-SC7 in the pre-Xmas delivery rush. I’ll poke around with your device type. I don’t think button 1 is a lost cause yet. The Leviton VRCS4 comes in two flavors, one with a load and one without. @bdahlem’s device driver was designed to work with both. I have succeeded in getting it to work with the version that does not have a load. So I’m pretty optimistic that you or the collective will get ZWN-SC7 to work with all 7 buttons.

Perhaps someone can figure out how to do pushed and held with the ZWN-SC7, wouldn’t that be a hoot! Just kidding…

16

It appears that the Minimote actually throws different z-wave strings for pushed vs held. My impression from using one is that if you push and release, it sends one payload, and if you push and hold, it sends a different payload. The device itself actually blinks when the held condition has occurred, providing visual feedback and suggesting that the device knows the difference. I agree with you completely that the design is a bit contorted. I was under the impression that ST got this to work taking advantage of a unique feature of the Minimote in a clever way.

I’ve found very few uses for Held with a Minimote. It certainly flunks WAF, because how are you supposed to remember 4 buttons and pushed vs held for each. People aren’t like that. I did come up with a 1 button ceiling fan control. Each push bumps up the fan speed, or back down after it’s gotten to high. A held button turns the fan off.

2 Likes
17

Yes – that is quite correct; but…

The two different Z-Wave payloads are just “different” button numbers. “Pushed” 1,2,3,4 are Z-Wave messages 0x01,29,51,79 respectively., “Held” 1,2,3,4 are Z-Wave messages 0x15,3D,65,8D respectively, which should, IMHO, be called buttons 5,6,7,8 by the Device Handler.

This is because the Aeotec Minimote is really an “8-button multi device”.

Another manufacturer may not issue different messages for held buttons; but another manufacturer might have a keypad with 8 distinct buttons. These two devices ARE equivalent!!!

So I would assert that it doesn’t work properly…

A fundamental concept in SmartThings is the abstraction of Device capabilities from their manufacturer, brand or model. This is so that you can swap out physical devices with the same capabilities (i.e., light bulbs from assorted manufacturers: GE, Philips, Lifx; thermostats: Next, Honeywell, HP; button pads: Aeotec, Enerwave) and ALL the SmartApps that are properly configured to the standard capability definitions (ahem … when fully documented), will still work.

To restate: If the Aeotec Minimote Device Handler is properly written to report Buttons # 1…8 as momentary pushes, then it will be interchangeable with “any” set of 8 Buttons (whether they be on a similar looking remote, a rubber keypad, a software keypad, an Arduino project, a wall panel, or a set of 8 panic buttons…).

I hope I’m making sense,
…CP/Terry.

18

You get empathy from me in that regard…

Over the past 1.5 weeks I have learned Groovy AND git / GitHub (by the same methods… other’s code and Google Search)! Take that! :smile:

I have a 1991 Bachelor’s of Math & Computer Science for University of Waterloo; but that was mostly C language, with a little C++; just enough C++, actually, that I was lucky to learn Object Oriented concepts before graduating. Recent college classes in PHP, Ruby, and Java … where I found that the Java was the easiest. Groovy is a lazy hybrid of Ruby and Java (in my view); and I think lazy languages make programming harder, not easier (i.e., I prefer strict datatypes, etc.). Most of my real-world programming experience is in Transact SQL, Korn Shell and Windows VBScript … but I seriously modularized and data typed all my script language code to make it very much like C or PHP.

I did a built a pretty complex real-time Arduino multi-sensor and coded it entirely in C++, using Atmel Studio (a free clone of MS Visual Studio), and SubVersion.

==> While I’m no expert, if anyone has Groovy, git, or SmartThings questions or challenges for a particular SmartApp or Device, I’m ready to give advice or pitch-in.

…CP.

1 Like
20

I certainly understand that idea, and agree that it’s desirable for the reasons you state. It shouldn’t be very hard to write a new Device Type that does just that with a Minimote. Then you could just add a Minimote and then change its device type to this new one that gives it 8 buttons.

I like the current device type and corresponding apps because they reflect the reality of the Minimote.

21

Yup … I understand, but remain ambivalent.

I think SmartThings will be steadily beefing up their “enforced” standards & guidelines as a side-effect of (a) extremely improved and extended documentation (@Jim), and (b) their analysis of SmartApps and Device Handlers that are “Officially Submitted for Publication” from external developers, and © their growing internal development staff needing to get and stay aligned as more and more concurrent projects start rolling.

22

I certainly hope so…and I hope to see a ramp-up in January of new things, smart apps, and approvals!!! At the moment, it feels like the community is adding all the new device support, @wackware especially!!!

1 Like