search

openhab / org.openhab.ui.habmin

HABmin - a graphical user interface for openHAB 2
231 stars 92 forks source link

Request to add Leviton VRS05-1LX to database #182

Closed mhilbush closed 8 years ago

mhilbush commented 8 years ago

I've included 2 separate VRS05-1LX devices, neither of which have resulted in the creation of a nodeNN.xml file. I'm attaching the debug log showing the discovery process. What do I need to do to make it create the nodeNN.xml file?

node11-lev-VRS05-1L-log.txt

Edit: I see in the log that it is finding the Manufacturer, Product Type, and Product ID; however, the Habmin UI is showing all blanks for these fields. Not sure if that is normal, or not.

cdjackson commented 8 years ago

Loading this log into the log viewer (http://www.cd-jackson.com/index.php/openhab/zwave-log-viewer http://www.cd-jackson.com/index.php/openhab/zwave-log-viewer) shows that the device isn’t responding to version requests for the SCENE_ACTUATOR_CONF class.

This is a class that the device supports (reported in the NIF) so it should respond. I’ll have to have a think about how to stop it requesting this.

cdjackson commented 8 years ago

I’ve made a change to allow us to force the command class version which should prevent this issue… I’ll merge today (probably) so please try tonights snapshot and provide another log if it doesn’t work.

mhilbush commented 8 years ago

Yes, I saw that in the PR. Excellent. I'll let you know how it works out.

mhilbush commented 8 years ago

Here's an update on this issue after trying the latest OH version containing the PR mentioned above.

The device now gets farther through discovery, but it still doesn't create an XML file. Here's the thing definition. node11-thing

I'm attaching a debug log. Node 11 is the device in question. Note that the VERSION_COMMAND_CLASS_GET requests are still occurring. node11-debug.txt

As an aside, you also will see in the log that those requests are occurring for a variety of Leviton devices, including VRS05 (nodes 10, 11, 15), VRI06 (node 14), VRP03 (node 16), and RZP03 (node 18). This appears to be a more widespread occurrence than just the VRS05. I noticed in the Open Zwave config for Leviton that they explicitly disable the VERSION_COMMAND_CLASS_GET for several Leviton devices.

Is there anything else I can provide that would be helpful?

cdjackson commented 8 years ago

The change that I made was specifically to try and stop VERSION_GET requests for this device for the scene config class, but it’s now also not responding to the scene activation class! I’ll update with this class as well - I guess there might be another one next - I’ve not got an easy way to totally disable this class at the moment since the version requests is performed quite early.

mhilbush commented 8 years ago

I guess there might be another one next

Right you are! :-(

This time it's the BASIC class, which is occurring on the VRS05 (nodes 11 & 15), as well as the VRI06 (node 14), VRP03 (node 16), and RZP03 (node 18). It appears this whole family of devices has a problem with VERSION_GET.

Here's the latest log. openhab-2016-06-15.txt

cdjackson commented 8 years ago

Ok - I’ll update with the classes I’ve found for this device. If we’re lucky, I’ll get most of them, and if not, we’ll be 10 days closer! :)

Let’s see if we can get this one going, then I’ll replicate for the rest of the (expletive deleted!) devices :)

On 15 Jun 2016, at 21:57, Mark Hilbush notifications@github.com wrote:

I guess there might be another one next

Right you are! :-(

This time it's the BASIC class, which is occurring on the VRS05 (nodes 11 & 15), as well as the VRI06 (node 14), VRP03 (node 16), and RZP03 (node 18). It appears this whole family of devices has a problem with VERSION_GET.

Here's the latest log. openhab-2016-06-15.txt https://github.com/cdjackson/HABmin2/files/317201/openhab-2016-06-15.txt — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cdjackson/HABmin2/issues/182#issuecomment-226317824, or mute the thread https://github.com/notifications/unsubscribe/AA_kQ63v3LiiSazo-nY9oqh-Tj2vkEuPks5qMGdGgaJpZM4IzkM_.

mhilbush commented 8 years ago

Looking at the PR. I see you're going for the shotgun approach... Nice! LOL

I'll test it early tomorrow AM.

cdjackson commented 8 years ago

Yep - I checked out a manual I found on the ZWave site and added most of the classes the device is meant to support… Let’s see :)

On 15 Jun 2016, at 23:27, Mark Hilbush notifications@github.com wrote:

Looking at the PR. I see you're going for the shotgun approach... Nice! LOL

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cdjackson/HABmin2/issues/182#issuecomment-226338632, or mute the thread https://github.com/notifications/unsubscribe/AA_kQ58O90iDx4TIxO2EtnR6K81CcMheks5qMHw4gaJpZM4IzkM_.

mhilbush commented 8 years ago

It looks to me that the PR didn't make it into last night's build, but I'm not 100% sure about that. Can you confirm one way or the other?

cdjackson commented 8 years ago

Damn - yes I forgot to merge it last night. It will be tonight - sorry.

On 16 Jun 2016, at 12:46, Mark Hilbush notifications@github.com wrote:

It looks to me that the PR didn't make it into last night's build, but I'm not 100% sure about that. Can you confirm one way or the other?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cdjackson/HABmin2/issues/182#issuecomment-226462384, or mute the thread https://github.com/notifications/unsubscribe/AA_kQ6b7cUEII97o-rnsPiflrokwwWUKks5qMTeigaJpZM4IzkM_.

mhilbush commented 8 years ago

No worries.

mhilbush commented 8 years ago

So I was looking through the debug log and comparing it to the xml definition.

Are the characters in the Manuf Ref field transposed, or am I reading this wrong?

capture

capture2

mhilbush commented 8 years ago

So I tweaked the leviton_vrs05_0_0.xml in my copy of the jar file to change this: <property name="manufacturerRef">010F:0209</property>

to this: <property name="manufacturerRef">0F01:0209</property>

I also added this because it was getting stuck trying to get the VERSION: <property name="commandClass:MANUFACTURER_SPECIFIC">setVersion=1</property>

Discovery completed successfully and I got node.xml files for the VRS05. Yeah!

I'll make a few database updates today.

Edit:

openhab_2016-06-17_03.txt

cdjackson commented 8 years ago

I didn't check what you did, but I've posted the updates you made into tonights binding, so let's see how it goes...

I'll take a look at the log shortly...

cdjackson commented 8 years ago

For node naming, it seems this device continues it's liberal interpretation of the ZWave standards. It's not providing byte which according to the standards it should - the binding expects this, so it causes an exception...

So, can I ask you to try and set the node name if you can? I'll update the binding to prevent this, but I'd like to see what the device returns once you set the data, and then again once the name is removed...

If you can do that and provide a log it would be good...

Thanks.

mhilbush commented 8 years ago

Liberal interpretation of the standard is an understatement. Some of these devices are fairly old...

I'll set the node name and provide a log. I saw similar errors in the log for the node location, so I'll also set the node location (in a separate transaction so as to keep things clear) and provide a log. I'll do this tonight.

As for the database changes, thanks for pulling those updates. I took a look at the PR, and it doesn't look like it reflects all my database changes. Then again, I'm not sure I fully understand how the "setversion=1" is handled. For example, I made a number of changes to the VRI06 device, and I didn't see any of those changes reflected in the PR. Also, I added a new device (RZP03), but the PR shows some odd deltas with a reitz blind control...

Tomorrow morning I'll take a look at the build and see how it compares with what I did.

mhilbush commented 8 years ago

Here's a log file, along with a summary of what I did. I used node 15 for the experiment.

19:48 Saved node name in HABmin; update shows pending. Node name entered was "Front Porch Light"

19:53 Save node location in HABmin; update shows pending. Node location entered was "Front Porch"

20:02 Delete node 15 and rediscover. Nothing of interest.

20:07 Stop OH

20:08 Start OH

20:11 HABmin shows node name of "FrontPorchLigh" and node location of "FrontPorch". Here's a screen snip of HABmin. Note that spaces have been stripped. Not sure where this is occurring, but the spaces appear to be in the node name and node location set requests and responses in the log file. capture

Here's a screen snip of the thing. capture2

Node name was truncated in the node name request and response. Standard must impose a limit?

Seems like the errors occur when the node name and node location are uninitialized in the device.

Here's the log file. openhab_2016-06-17_05.txt

Hope you find this useful.

cdjackson commented 8 years ago

I noticed that some of the changes you made didn’t result in any change to the XML. I suspect you have added setVersion=1 to the database? If so, this is wrong. Instead, you should use FORCEVERSION in the database. This then generates the correct information in the XML using the command class version that is specified in the database. I’ve improved the ‘diff’ viewer now so it should be easier to see what changes have been made if they don’t result in an XML change.

Truncation of the name is correct - well, it should truncate to 16 characters and it looks like it might be a little less (14 I think), but “close" seems like a good result for these devices :) I’ll take a look at the log - I want to see how it’s handling the character set information now since this wasn’t sent at all earlier. I’ll generate a fix for this issue.

mhilbush commented 8 years ago

Correct. I did setVersion=1. I must've missed the FORCEVERSION when I looked at the VRS05 in the DB. :-( I'll make my changes today using FORCEVERSION.

Thanks for the feedback, and thanks for the above fix.

I'll hold off installing a new build until tomorrow when all the changed are included.

mhilbush commented 8 years ago

One last question...

Making database updates... On the RZP03 I mistakenly entered command class of SWITCH_BINARY instead of SWITCH_MULTILEVEL. I see no way to edit this. How do I fix it?

cdjackson commented 8 years ago

I’ve deleted it. I’ve not given delete rights - just in case someone accidentally does something ‘bad’ ;)

On 18 Jun 2016, at 13:25, Mark Hilbush notifications@github.com wrote:

One last question...

Making database updates... On the RZP03 I mistakenly entered command class of SWITCH_BINARY instead of SWITCH_MULTILEVEL. I see no way to edit this. How do I fix it?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cdjackson/HABmin2/issues/182#issuecomment-226938767, or mute the thread https://github.com/notifications/unsubscribe/AA_kQz4o7paqGu1MZ6z2HzOfRb-UXaMOks5qM-O2gaJpZM4IzkM_.

mhilbush commented 8 years ago

Totally understand on the delete rights. Thanks for taking care of that.

All my DB changes are in.

mhilbush commented 8 years ago

The log is looking much cleaner now. Not sure what's going on with node 14, but that might be an issue with the device.

Here's the log. openhab_2016-06-19_00.txt

I did see some of those handler callback missing exceptions after the initial install of last night's build. So, I cleaned out cache and tmp, reinstalled the build again, and restarted. I haven't seen it since. (Note that I zapped the log file, so those exceptions are not in the attached file). I'll open a separate issue if I see those again.

I'm going to close this issue. Thanks for everything.