Closed mdave closed 9 years ago
Hey thanks for the PR. I had to manually integrate your changes since I had a pending commit as well. Hope didn't miss anything from your code. I also pushed a new HG version in the zwave-rework branch that is using this latest zwavelib. https://github.com/genielabs/HomeGenie/tree/zwave-rework
No worries! Checked the commit and it looks like everything is in, so I'll go ahead and close this PR.
@mdave I tried to test the CC Version code, but its not working. It was causing errors or getting wrong data. I also moved the querying of cc versions inside the Discovery method, but I commented it because of the errors. Any clue?
Hey @mdave I just pulled so new code. The configuration saving is now automatic, and it will save all persisteable node data. If you still want to check and fix the Version code, this is where to look: https://github.com/genielabs/zwave-lib-dotnet/blob/master/ZWaveLib/ZWaveController.cs#L331 https://github.com/genielabs/zwave-lib-dotnet/blob/master/ZWaveLib/CommandClasses/Version.cs#L48
thanks!
Yeah, something weird definitely going on there because my previously working configuration is now not working :smile: I will have a look and see if I can figure out what's going on.
This PR adds support for the version command class, so that ZWaveLib is capable of processing additional detail from later versions. Versions are stored inside the node configuration file alongside the node information to make them more resilient to restarts (particularly for battery operated devices). Versions are also reported in the
Test.ZWave
utility.As a first go at using this in some of the command classes, I have updated the SensorBinary and Alarm classes to support V2 reports. Note this is only partial, since V2 also allows queries for the device's sensor/alarm capabilities (and thereby their current state), which I have not implemented.
The alarm v2 changes might also need a bit more thinking about. There are standard values (I found a pretty complete list at http://220.135.186.178/zwave/example/ALARM/index.html) but these don't really translate well through the SensorGeneric event parameter. For example, my door sensor reports 0x16 and 0x17 (open and closed) and 0x03 (tamper) which get misinterpreted by HomeGenie. My solution was to map these values to something more sensible (i.e. 0 for closed, 1 for open) and trigger the closest-looking EventParameter. I've added the aforementioned ones that I was able to test, but there are a bunch more that could theoretically be put in.