I understand that. This particular device, at least behaviorally, does work that way with Homeseer and Vera. Unfortunately all my existing hard-wired devices that have associations are in my “production” network, and the family approval for this OpenHab experiment will vanish if I pull those out and things stop working.
So I need to dig through my devices and find one I can test with that isn’t battery. The only one I’ve got on the test network that a) has associations and b) is hard wired isn’t communicating anymore since I did the update, and I’ve yet to figure out why. That was one that reliably was working before.
is it just me or looks like with this (Jan2) version the latest device db not used? e.g. Vemmio MT-100 (#760) reports as could not resolve to a thingType!
is working fine in 1230 version.
For both - 1230 and 0102 it’s interesting to see ERROR level for kind of positive COMPLETE message (also in the habmin the green secureinclusioncompleted is shown, seems like no errors) when adding back the Danalock key (sorry I did not have zwave debug switched on - can repeat it tomorrow if it’s crucial and not a known cause) 2018-01-04 00:13:13.866 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 40: Using Scheme0 Network Key for Key Exchange since we are in inclusion mode. 2018-01-04 00:13:14.114 [ERROR] [alization.ZWaveNodeInitStageAdvancer] - NODE 40: SECURITY_INC State=COMPLETE 2018-01-04 00:13:17.976 [INFO ] [ommandclass.ZWaveVersionCommandClass] - NODE 40: Command Class COMMAND_CLASS_BASIC has version 0!
Need to know what you did in order to know if you’re doing it wrong . Is it already securely included? Look in Habmin. If not, double check you have only one binding with the correct verion (from the top of this thread and newer than Jan 2). Then exclude the lock (select controller> Tools> Advanced> Exclude Devices. Then, using Habmin with controller < ~10 ft away from lock (closer is better), start an inclusion, enter programming code into lock and press 0. Then wait a minute or two so for inclusion to complete. Green checkmark on lock will flash and beep. Lock should show up in inbox. If this does not work, exclude again, then reset lock (unplug battery, press and hold Schlage button, then plug in battery), and include again. Your settings will need to be reentered. When I was testing, resetting was not necessary.
Once Habmin shows the lock is securely included (green checkmark under Attributes> Using Security), then put the lock back on the door.
This one took a while, but my Leviton switches and dimmers are now reporting instant status updates again. Long story short… I deleted the Thing and rediscovered. Taking it a step further, I removed the association and the updates stopped. Readding the association brought them back! So, device definition was out of date and somehow broke instant status updates even though they had been working. Updating the definitions fixed it. And another confirmation that adding/removing associations is working (for me).
Is there an easy way to delete all zwave things? If not, I’ll try to script something using the REST API. I guess I could then add default polling and temperature scale…
Sorry if you have already explained this before, but how much effort would it be to have the binding update existing device definitions after a binding update, so that Things would not need to be deleted and rediscovered? Lacking that, maybe a visual cue in Habmin, or a log entry at startup to notify that a device’s definition is out of date. Or maybe a separate channel on each device, so that a rule could be used for notifications?
I think it’s easy - the binding updates the thing type routinely - the only thing I’m not sure about is if I set the same thing type that’s already set, if it will update or not. I have a feeling it might not in which case I might just set it back to the default “unknown” type and let the existing code redetect…
Definition clarification question: the device database holds Thing types, and deleting/rediscovering is updating the Thing type with the version from the binding?
I take it there is no versioning of the Thing type stored in the database, binding, and Thing configuration, so that the version in the binding and Thing configuration could be compared to check if there was an update when the binding starts? Although… setting to “unknown” shouldn’t be too bad if the type/ID can be pulled from the XML or existing Thing.
Correct - in this context it’s in no way related to inclusion etc.
Also correct Maybe I should look to add this…
This is exactly how it works now. The device is always detected as unknown during discovery, then when the thing initialises it does the check and changes the thing type. Setting the type back to unknown will simply repeat this cycle - it doesn’t need to include, or do any discovery at all (assuming that was already completed of course).
Both the FGS221 and FGS222 is working as expected with the setup you describe. Even in my setup.
If I use switch_binary1 instead of switch_binary it doesn’t.
So it is either my expectations, the ZWave Binding or the Fibaro firmware that is the problem. My configuration works fine when using the suggested settings
Well as I see it switch_binary1 doesn’t work as expected. using switch_binary is a workaround, I really loves workarounds, especially those that works :-). But if openHAB should be a intuitive HA solution, workarounds isn’t any good. I am not sure it is a problem in the binding, it could be a lot of other things. There might even be an obvious explanation why it is working that way.
Here’s what I’ve done…
Lock was originally connected to Vera. I unpaired it successfully. (which seems to be rare for me…)
Ive used openhab (docker container) in the past, using vera as my zwave controller. Well, I got the HUSBZB-1 for christmas! Yay, finally time to get rid of the horrible vera
Now onto Openhab…
It’s a new Openhab2 install, using a rpi3.
– Installed Raspbian Stretch Lite
– Installed Java (1.8.0.151)
– Installed Openhab2 from here (https://docs.openhab.org/installation/linux.html#manual-installation)
– updated permissions/groups for the pi and openhab user. Setup samba etc…
Initially added the z-wave binding through paperui. That didn’t work, found your updated bindings. Uninstaled the z-wave binding via paperui, downloaded the org.openhab.binding.zwave-2.2.0-SNAPSHOT.jar from the link above, and placed it my addons folder
Restarted openhab
In paperui, I got to my things, configure z-wave binding and point it to /dev/ttyUSB0 (/dev/ttyUSB1 is zigbee)
paperui (and also habmin) detect all my zwave things, including the Schlage lock.
I added the lock, but it never picks up the secure piece. (this lead to my post last night)
tonight I’ve removed the lock, and followed Schlage process to reset the lock (disconnect batteries, hold outside button, connect batteries) check blinks 3 times.
Using the programing code, I try adding the lock to habmin, but paperui and habmin already see the unsecure lock. I add it anyway, enter the programming code into the lock, after pressing 0, wait about 5 seconds and get the red x. The rpi is about 3 inches away from the lock. (hanging on the door lever).
I don’t see how to force security on the lock, am I doing it wrong?
If the lock was already excluded from the network, just delete the Thing.
Just to be sure, did you also start zwave inclusion/discovery in OH? And did you do this before putting the lock in inclusion mode?
[EDIT} I reread your post a few more times … if you have already included the lock, you will need to do another exclusion. Resetting the lock does not clear the zwave network.
Yeah, I’ve deleted it and readded the lock about a dozen times already, hoping for a different outcome, thinking I’m missing something along the way…
Not sure I’m doing the right thing for the exclusion…
For the exclusion I went to Tools > Show Advanced, then Tools > Remove device from controller.
waited a few minutes
Device was still showing within my things
checked the logs, it’s shoes that the node wasn’t found, but it’s still listed in m things.
2018-01-04 20:57:48.546 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 5: Remove failed node failed as node not found
restarted service, still showing,
deleted it, now it’s gone.
I was assuming Removing Device from controller would remove the device from my things list as well…
As far as adding my devices, as soon as I click the search, the device is seen and added, without me even having time to enter the code on the lock.
Nope. Chris has commented on this, so you should be able to find it in this thread. You will need to manually delete the Thing after an exclude.
OK… this looks to be your issue. After starting exclusion, you need to do the same procedure on the lock that you do for inclusion (program code then 0). You should get a green checkmark. If not, the lock is still included. Your lock is still included. After excluding, delete the Thing.
If you only have the one controller, then it should be set to SUC. Was that the default setting?
