I'm already added (a whle ago) - I think this is a matter of adding any needed keywords to my packagemanifest.json so the repository can be found -- not sure what to do there. Also, I was unsure if I need to do anything when I update a version -- do I need to run any command so that HPM knows there is an update?
nope just update the apps version number.
def setVersion() {
state.name = "Auto Lock"
state.version = "1.1.37"
}
in the app manifest update the version also:
"version": "1.1.37",
1 Like
Hi @jvm33. I've been following your posts regarding this supervision stuff. While I can't say I understand it all, I had a question.
We're you planning on extending your work to zwave locks? I'd be very interested if a custom driver of this fashion would help clear up some of the issues posted about with schlage zwave locks.
I've been trying to, but locks are very tricky (particularly in the handling and configuration of the user codes), and all my locks are older Schlage locks that don't support Supervision. In general, if a device supports S2 it will support Supervision. Many of the problems I've seen posted deal with older Schlage locks, so Supervision won't be applicable.
1 Like
Fair enough. Thank you for your time.
Thank you for this driver. I have also tested it with a EATON RF9640 and it is allowing me to configure it properly... Except... when turning OFF the switch with this driver, it does not turn it OFF completely (still some residual lights going through...) even though it register OFF on Hubitat.
Turning OFF the switch by pressing the physical button is turning OFF completely (no residual light)...
Thanks for the hard work...
Sorry, no idea why you are having this problem.
However, I'm in the process of rewriting my drivers based on some new features in 2.2.8. Its possible I'll identify / fix some issue during the rewrite. This will happen slowly though (I'm swamped at my "real" job) so it will be at least a month
Thank you for your answer...
FYI : the only (incomplete) driver that I found can turn the RF9640 switch fully OFF (BUT unfortunately does not support the Z-Wave+ status reporting) can be found here : ( Link to the driver ).
It seems to be a simple driver (not as elegant and complete as your solution as it does not support the setting of parameters and the reporting of the status when the switch is physically pressed... which defeat the purchase of Z-Wave+ components)...
Anyway, I think the OFF command is on line 225 of that driver. It seems to combine 2 z-wave commands with a delay :
delayBetween ([zwave.basicV1.basicSet(value: 0x00).format(), zwave.switchMultilevelV1.switchMultilevelGet().format()], 3000)`
Your code is quite complex and I made several trials and error to understand where and what to change... Looking at the code above, I was able to make my switch work and turn OFF completely by changing line 1102 of your code :
else sendSupervised(zwave.switchMultilevelV1.switchMultilevelSet(value: newValue), params.ep)
with :
else sendSupervised(zwave.basicV1.basicSet(value: newValue ), params.ep)
In addition to this code change, I had also to set the switch parameter 7 : Dimmer Ramp Time to a number greater to 0 (I set it to 1 second). (Great that your driver allows this easy set-up!)
Anyway, I am not entirely sure why... but ONLY the combination of the 2 above made the difference and made the switch work for perfectly the first time!...
Thanks again for this driver and your contribution to this community!
First, be sure to install the most recent version here: https://github.com/jvmahon/HubitatCustom
The driver you want is "Almost Any Z-Wave Plus dimmer Driver.groovy"
When installed on Hubitat, it will have the name "Any Z-Wave Dimmer Driver v1.1.8".
Also, you are right - the code I have is quite complex to handle almost any device. I am converting this to the new "Libraries" code model which will simplify the logic, but that will take time.
Have you tried the built-in Hubitat driver? It doesn't support the setting of all the parameters as my driver does, but once you have them set, you should be able to use that. I can confirm the name of that driver when I get home from work.
Thanks for your follow-up.
Yes, the modification I first made @ line 1102 was on your driver "Any Z-Wave Dimmer Driver v1.1.8". Replacing the "zwave.switchMultilevelV1.switchMultilevelSet(value: newValue)" by "zwave.basicV1.basicSet(value: newValue)" was fixing the issue with my switch... But this was yesterday...
Today, I realized something else... When I force the duration for the ramp down to OFF to anything different from 0 (zero), it works! so I replace the code on line 1102 from the original :
else sendSupervised(zwave.switchMultilevelV1.switchMultilevelSet(value: newValue), params.ep)
to
else sendSupervised(zwave.switchMultilevelV4.switchMultilevelSet(value: newValue, dimmingDuration:1), params.ep)
I prefer this as it is closer to your original code... And it works perfectly... No residual current is going through the switch... But don' t ask me why! 
Hello,
Driver had been working great for me on a single switch (HS wd200). I only needed the multi-tap capability. I just upgraded to the latest version 1.1.8 using package manager and it quit working. Getting errors in my log:
java.lang.NullPointerException: Cannot invoke method get() on null object on line 1092 (method off)
I tried manually updating the driver code and error still exists. Any ideas?
I've completely rewritten the code and it isn't in Package Manager at the moment.
Its now been re-written as a series of libraries which are here (in library form): https://github.com/jvmahon/HubitatDriverTools
The drivers, with all the components pulled together into one file, are here:
I suggest you try out the new drivers.
As a bonus, the new drivers allow you to add multiple child devices so that one physical switch can appear as multiple "child" devices. This is useful if, for example, you use one of the homekit or Google Home apps and you want the same device to appear in multiple "rooms" in HomeKit or Google Home.
They remain a work-in-progress.
There's also a work-in-progress wiki on how to use my libraries. That is here: https://github.com/jvmahon/HubitatDriverTools/wiki
So far, I"ve only documented the send/receive library.
THANKS! i'll do that.
@jvm33, I just came across your driver and I find it very useful -- thank you for all the time you have invested into this!
As an example of what I found very helpful: On the ZEN25 it exposes the ability to set parameter 18, which previous required the use of the basic z-wave driver tool.
I have a couple of questions:
- At this time, do you recommend sticking with "jvmahon/HubitatCustom", or should I be using the "jvmahon/HubitatDriverTools" version?
- Do any of these drivers work with the ZEN17 relay? The current ZEN17 relay driver only exposes a tiny subset of parameters, requiring a lot of tweaking with the basic zwave driver, which is a painful way of adjusting things.
Thanks!
Marc
I need to update the posting at HubitatDriverTools. The version there is a substantial rewrite -- correcting a number of bugs. It also adopts a different driver "philosophy" in that there is one parent driver that contains all of the "main" code for dimmers, switches, sensors, etc. etc., and you add "Generic Component Drivers" onto that which customize it for your particular device.
I hope to have that update by the end of the coming weekend.
Yes. The way the driver works is there is a database of devices (which, just so happens, to exactly match what I own) which includes the parameters for each device. If you happen to be using a device not in that database, then the first time the driver is initialized, it will query this database OpenSmartHouse Z-Wave Device Database where it can then learn all the parameters supported by the device (it then stores those in the devices "state" for re-use). That's why I was referring to this as an "Every Device" driver - i.e., it can learn what it needs to know about the parameters.
Zen17 is in the opensmarthouse database so it will be supported: OpenSmartHouse Z-Wave Device Database
In the version you are using, you still had to expose Capabilities / Attributes in the driver itself. In the new version, the only capabilities exposed in the parent are those that deal with Central Scene. The actual devices are then enabled through Generic Component drivers. It gives a simple way of having one parent driver that does not need to be changed. Under this model, event a single endpoint device has at least one child device. Right now, it supports switches, dimmers, and non-sleeping sensors (like the Ring G2 Motion Sensor). Eventually, I'll add sleep / wake support. It also supports endpoints and various notifications for the sensors.
If I understand correctly, using the new driver will result in a new device (the generic endpoint). This means that all existing rules and apps that reference the old device will need to be updated. Is that right, or is migration going to be simpler than that?
Just want an understanding of how much time I’ll need to update to the new driver when it’s ready for production.
It would mean migrating.
BUT, the driver is flexible enough that if you were to include the capabilities in the "parent" it would work just like the old driver.
Try this for the Zen17: https://raw.githubusercontent.com/jvmahon/HubitatDriverTools/main/FullDrivers/user_driver_jvm_Any_Z_Wave_Universal_Parent_Driver_v1_6_517.groovy
That's the "full" driver with all of the libraries included.
Its also available as a library "bundle": https://github.com/jvmahon/HubitatDriverTools/tree/main/Bundled
As mentioned, the driver works by representing everthing as "child" components. For example, for a basic switch, you would get something like:
Usually, I lave the "Parent" in its most basic form - handling only Central Scene. But if you want the parent to behave as a driver, you can uncomment the Actuator / Switch / SwitchLevel capabilities.
Is this ready to be called a beta version, or more of an alpha release for those that really need the new driver model (e.g., for the Zen17 mentioned above)?
I'm happy to give it a whirl on my HS-WD100 & HS-WS200 if you are looking for testers.
