I just downloaded the snapshot from http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar
and placed it in the addons folder, after removing the regular binding.
From my 33 Zwave devices, I got 20 up and running after some time. Remainder not yet, however most are battery operated devices.
However when I check the version in karaf I see:
237 | Active | 80 | 2.1.0.201702082223 | ZWave Binding
@chris Is this the latest snapshot, or is the above link no longer valid?
Other issue is that I cannot get the Network Viewer to display. If I click the link in Habmin it does not show. With previous 2.1.0 binding it did work. Do I need to upgrade more than only the binding ?
I believe this is the right device. This time they didnāt get as far as last time where it actually had the details identified in the attributes section, but the 014F rings a bell, and that is the model of the bulb from my Amazon purchase. If itās helpful I can try to dig thru some logs and see if the old log lines referencing the device when it did recognize the details but still listed as unknown device.
Iāll do a binding update of the test version this evening and then letās take a look - just to make sure that thereās no hang-overs from the ESH update issues over the past day or threeā¦
After that, if problems persist, then a debug log would be good.
The reason I wanted to change to the snapshot is to be able to use the network healing.
I donāt have any security enabled devices.
Is network heal now also included in the standard branch ?
As an added update, here is a snippet of logs from a few days ago with the first download of the new security enabled binding. This discovery was able to fully identify the device (I believe) as seen from the log fully outlining the Thing type and matching to the DB entry provided above. But alas it still sat as an unknown device.
I downloaded the source and compiled my own to do some testing and found it had to do with the version check on the device. I noticed there was no min or max version in the database and that the device had no version. Not sure if it was correct, but I found if I modified ZWaveProduct to set versionMin and versionMax if they were null in the database, then the version checking code was skipped and it was matched. I can provide a patch if you would like. Now I just need to figure out how to make use of the Barrier command class.
I donāt quite understand this. Iāve got tests on this now and I just checked that with null for the version from the database, it should work ok as it sets the min/max to 0 and 255.255. Or, do you meant that this device actually doesnāt return a version, and this is what is causing the failure? That would be a bit strange as I think itās mandatory, but then Iāve found a bunch of things that are meant to be āmandatoryā, but devices are still certified
Sure - I expect itās similar to what I have here with the Yale where itās sending alarms when state changes (I really donāt understand why they chose this strategy). I donāt think it is too hard to process this, but itās not top of my list right now. What Iād suggest is to raise an issue on the issue list with your findings rather than discuss it here as it will likely get lost ;).
I wasnāt sure what was happening either. From looking at it, I agree the code should work. I got the following when I added in a debug line for the checks:
2017-02-10 12:02:33.506 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 26: Device discovery could not resolve to a thingType! 014F:4744:3030::0.0
and
2017-02-10 12:02:30.267 [DEBUG] [.binding.zwave.internal.ZWaveProduct] - Min Version didnāt match: 0.0.0 - 0.0.0
I think there is no version from the device. I donāt see a version an applicationVersion in the XML file for the Version command class for that device.
So, not so sure whatās up really, but it seems it should work ok. Iāll update this security branch later so it would be worth trying again with this.
Thought Iād try out this new version, mainly because Iāve got massive problems with ādeadā nodes (ie nodes that the controller completely refuses to communicate with even though theyāre perfectly functional) and I hope theyāll be happier after some healing. Iāve only got one small question that I havenāt found the answer to in this thread: This renaming of command classes, is it completed or will there be more of it? What I mean is, if I upgrade to the snapshot version now (deleting all my Things), will I be able to upgrade to the stable 2.1 (or 2.2 or whatever) later without needing to delete everything again?
Probably not. The renaming of command classes is complete, but I also want to rename the channel names to be more systematic. This is related to the move toward dynamic channels.
Iām hoping to do all the changes here before merging into the master branch, but if you use this branch now, it will likely need reconfiguration later.
Firstly, thank-you the security command classes work great. I am unable to lock and unlock my Yale lock (secure inclusion was performed on 2.0 stable binding).
However, I observed the following issues and needed to revert to the stable version:
Itās much slower than previous implementations (including 1.7, 1.8 and 2.0)
The initial discovery wasnāt able to resolve some things. I have 6 of the same types of dimmers, some worked and some were still unknown requiring multiple restarts of the binding.
Some things refused to work. In the logs I could see that the command had been received but the thing never changed.
Some things which were the 2.0 binding could not be resolved (Fibaro Motion Sensor).
Thanks again for all your hard work on thisā¦ let me know if you want detailed logs or for me to raise issues in GitHub.
Thanks - these are known issues and discussed above (although I know this is getting to be a long thread now ;). I need to look at the speed issue which is caused by a thread lock I think. The detection of devices should be fixed in the version I loaded last night, although the database for this version might have issues still as it is different than the main OH2 bindingā¦
Hopefully Iāll work through these issues in the coming week or two.
Successfully added my Danalock V2 when I started to use this new binding.
Although because of exploratory testing i needed to do a complete fresh installation
Now Iām not able to include my lock āUsing Securityā.
Network keys are mentioned in this thread, what are those?
I havenāt used any, is that my mistake?
Now to something completely different, can I scan for new things from HABmin?
Thanks in advance
The network key is like your password - all security systems have a key of some sortā¦ Itās configured under the network settings in the controller thing configuration.
It probably doesnāt matter - if I remember correctly the binding will choose a random number if you donāt set one.
Thereās a discovery button. In the Thing configuration menu, thereās two buttons in the top of the menu - one is the discovery button (magnifying glass icon I think).
I removed some of my changes and updated to the dev-switchall-config-type branch (is that the correct dev branch?) and get the same issues. Also get it with the latest jar from the link above. In looking at this though, I now realize that my device was never successfully secure included. Not sure if that explains my above problems, but it explains why I couldnāt get the channel to work. I redid the inclusion with debug logging enabled. Not sure whatās going on with secure inclusion. Iāll try and wrap my head around secure inclusion and see whatās happening. If the log or anything else would be helpful, let me know and I can post it.