Ultimately, it’s the name on the front that matters, not the smallprint on the back . By this I mean that even if we say that FIRE_ALARM is really DOOR_BROKEN alarm - or anything you want - the definition of the alarms in the database is effectively just telling the binding what number to look at. What people see is the label and the options etc - and we can call this whatever we want (ish!)…
The label is completely free-form within the database. The options are linked to the channel - this is currently hard coded in an XML file in the binding - we can add new channels with new options very easily, or I can do what I’ve done for thermostats where the options are also defined into the database and we make the whole thing configurable.
Does that make sense? I think it does what you want, but if not I’m sure we can find a way…
Those both sound like good approaches although I have to admit I don’t fully follow. I suppose I should look at the thermostat code and xml in OH1 to get a feel for that. Haven’t played with OH2 yet so I need to brush up on those concepts, especially channels since I think that is new. Sounds like either one would give us what we need so that’s good.
I’m not too sure looking at the thermostat classes will help too much - they are similar to the alarm except they are handled differently in the database…
The point is though that if I say a “Lock Alarm” has a value of 1, or a value of ALARM, or a value of FLOOD_ALARM, it doesn’t matter if all the user sees is “Lock Alarm” - everything else is irrelevant (to the user at least).
FYI - I’ve received the Yale lock I mentioned last week (without the Z-Wave module so far though…)
I’m not sure if it’s interesting to anyone or not, but I have two Kwikset 910 locks working using openhab 1.8.0 using the zwave binding from e96fdee7c1812d71f7d7df2513c83430c523d939 in https://github.com/dbadia/openhab.
@daemonalec Thanks for testing. My 2 kwikset locks have been working well for about a week now. Still have some stuff on my todo list but overall things are working well.
@mganapa@Nicholas_Waterton I think this is a good time for you to retest on your networks to see if things are still flaky with your other devices.
@gottsman
There’s been progress on the barrier class, see this thread
@chris My branch has fallen far behind 1.8 master and I’d like to bring it up to date. I submitted PR4073 which has some minor whitespace changes. Once that’s in I can get my branch up to date. Just want to avoid mixing whitespace and logical changes in the same commit.
Hi Dave
As I said - I don’t think this is needed. Isn’t it the label the user sees that matters? I don’t think the enum name makes any difference - so long as the channel is set with the right name, what goes on under the hood doesn’t matter. Given the binding can’t easily have two sets of numbers for the same command class, we can only do this I think?
Also I’m going to try and copy your secure stuff over to the OH2 binding in the coming days. This is going to be a bit ‘fun’ when it comes to maintenance as we’ll have two versions and we’ll need to try and keep any changes updated in both .
I’ll take a look at the PR again - I’m not a fan of the large commits as it can be difficult to trace stuff, but given the IDE is formatting and there’s no control, we probably need to do it…
If you wait a little longer for the OH2 merge then I might be able to submit a PR for it. I have re-merge my OH1 changes anyway because of the massive amount of whitespace changes so I’m going to create a new branch and try to squash the commits down to one.
Hi Dave
I can do if your planning changes, but this is all going to have to be manually copied over - we won’t be able to manage a PR for the OH2 stuff. If your planning significant changes then I can hold off though?
Ok not sure why this isn’t sinking in for me So if we use the channel to “override” the default alarm types for a particular door lock model, would those overridden values also appear in the events log?
Well, what appears in the events log now is not related to the command class. The event log logs the item that changes, and the value that it changes to - the value however is not the enum that is used in the command class - it’s normally either 0 or 255. So, the same is true in the OH2 binding.
From the 0/255, an item would normally use a translation/mapping to change this to read correctly for the respective alarm (open/closed, alarm/ok…). This is handled by selecting the correct channel - see here for the current list of channels that zwave supports. This list can easily be updated, and then we can set any alarm type to be associated with a particular channel…
Does that make sense? Or maybe I completely misunderstand what you’re trying to do in which case it might pay to reiterate this in case I’ve lost the plot . I think though that you just want to show the correct alarm label, and conditions for an alarm, even if it’s not what is set in the command class, and if so, this can easily be done without changing the code (and in fact it can’t be fixed by changing the command class).
I finally got the courage to try compiling the security testing branch and pairing my Danalock Circle, and I’m happy to report that everything initially worked as expected. I have automatic relocking enabled and although it doesn’t seem to send a message immediately when it relocks, openHAB picks up on it after 10-20 seconds. Further testing seems like some unlock/lock commands from openHAB are ignored though, not sure why. I will keep playing with it! It looks like the lock and openHAB isn’t always agreeing on the nonce. When this happens, the lock will send an update saying it is still locked and openHAB will flip the switch back instead of trying to unlock again.
Unlocking and locking is near instant when it works, it takes around 1 second from clicking the button to the lock reacting.
The rest of my z-wave network seems to behave as normal. Figuring out the initial state of all the devices felt a little slower than with the regular z-wave binding but I don’t know if that’s just because of all the extra debug logging.
Have these changes been merged to openhab addons master on github? I’ve checked the 1.9.0 build on cloudbees and I can’t tell from the commits whether they have all been put in. I’m looking to add my Schlage Camelot Deadbolt but don’t have the motivation to set up an entire IDE to build the one binding.
Or am I wrong and it’s more than just the zwave binding that needs updating?
@dbadia - I finally received the Z-Wave module for my lock, so ran some first tests today - gotta say there’s a lot of great work in here . I’ve managed to get it running in OH2 (kind-of!) and the porting wasn’t too bad. Currently it bombs out while doing the security handshake and I wouldn’t be surprised if I’ve missed something in the copy process from your OH1 branch, but it’s getting there…
Anyway, if you wanted to take a look, it’s in this branch. I’ve got a few other jobs to do before my partner gets home but will continue with this in a day or so…
@chris That’s great! If you post your log file somewhere I can look at the error to see where the problem might be. I have a tool that will format the handshake process so it’s easier to see what’s going on.
Also, I have finished my “clean” diff of the security changes OH1, you can see them here.
It might be easier to see what’s changed with that as a reference.
Dave
. By this I mean that even if we say that FIRE_ALARM is really DOOR_BROKEN alarm - or anything you want - the definition of the alarms in the database is effectively just telling the binding what number to look at. What people see is the label and the options etc - and we can call this whatever we want (ish!)…
(without the Z-Wave module so far though…)
.
So if we use the channel to “override” the default alarm types for a particular door lock model, would those overridden values also appear in the events log?
. I think though that you just want to show the correct alarm label, and conditions for an alarm, even if it’s not what is set in the command class, and if so, this can easily be done without changing the code (and in fact it can’t be fixed by changing the command class).
. I’ve managed to get it running in OH2 (kind-of!) and the porting wasn’t too bad. Currently it bombs out while doing the security handshake and I wouldn’t be surprised if I’ve missed something in the copy process from your OH1 branch, but it’s getting there…