cdjackson
commented
8 years ago You don't actually say what you think the problem is - just that it's not correct?
Closed msmcgillis closed 8 years ago
cdjackson
commented
8 years ago You don't actually say what you think the problem is - just that it's not correct?
msmcgillis
commented
8 years ago Based on the above xml the supported command classes are: 32, 37, 39, 43, 50, 86, 112, 114, 130, 133, and 134.
Where as the dsc24.xml suggests the devices supports the command classes: 0x20=32, 0x25=37, 0x26=38, 0x27=39, 0x32=50, 0x70=112, 0x72=114, 0x82=130, 0x85=133, 0x86=134
Missing 86.
Then it is a little unclear how the various parameters in the dsc24.xml would line up with the supported values from the above. For example dsc24.xml identifies 9 list items the above output only shows one value as a list. Perhaps their is some mapping that makes since between these but I'm not seeing it.
Outside of those sorts of differences I see things like this in the openHAB logs for the above NODE:
openhab.log:2016-01-01 14:51:06.838 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 2: Unsupported command class SWITCH_ALL openhab.log:2016-01-01 14:51:07.230 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 2: Unsupported command class SWITCH_ALL openhab.log:2016-01-01 14:51:07.231 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 2: Unsupported command class SCENE_ACTUATOR_CONF openhab.log:2016-01-01 18:56:32.165 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 2: Unsupported command class SWITCH_ALL openhab.log:2016-01-01 19:45:04.924 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 2: Unsupported command class SWITCH_ALL openhab.log:2016-01-01 19:53:25.050 [WARN ] [.z.internal.ZWaveActiveBinding] - NODE 2: No item bound for event, endpoint = 0, command class = METER, value = 76.315, ignoring. openhab.log:2016-01-01 20:01:49.244 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 2: Unsupported command class SWITCH_ALL openhab.log:2016-01-01 20:21:31.256 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 2: Unsupported command class SWITCH_ALL openhab.log:2016-01-01 20:22:47.499 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 2: Unsupported command class SWITCH_ALL openhab.log:2016-01-01 20:29:07.771 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 2: Unsupported command class SWITCH_ALL openhab.log:2016-01-01 23:44:07.068 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 2: Unsupported command class SWITCH_ALL openhab.log:2016-01-01 23:44:07.091 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 2: Unsupported command class SWITCH_ALL openhab.log:2016-01-01 23:44:07.120 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 2: Unsupported command class SWITCH_ALL
Not really sure what to make of the above errors.
But then my basic question would be from openHAB how do I get any of the actual values identified above like: Energy, Library Version, Switch All, the multiple Previous Interval values ....
cdjackson
commented
8 years ago Based on the above xml the supported command classes are: 32, 37, 39, 43, 50, 86, 112, 114, 130, 133, and 134.
Where as the dsc24.xml suggests the devices supports the command classes: 0x20=32, 0x25=37, 0x26=38, 0x27=39, 0x32=50, 0x70=112, 0x72=114, 0x82=130, 0x85=133, 0x86=134
Missing 86.
This information is not used by the binding so this won’t make any difference.
Then it is a little unclear how the various parameters in the dsc24.xml would line up with the supported values from the above. For example dsc24.xml identifies 9 list items the above output only shows one value as a list. Perhaps their is some mapping that makes since between these but I'm not seeing it.
Please be specific about what you mean? If there’s no list item, then it just means that the user can type in any number - you just need to refer to the user manual.
Not really sure what to make of the above errors.
Firstly, these classes are not normally used, so unless you want to use them, you can ignore the errors. However it also means you are using an old binding as the SWITCH_ALL class has been supported for some time now.
But then my basic question would be from openHAB how do I get any of the actual values identified above like: Energy, Library Version, Switch All, the multiple Previous Interval values ....
Try looking at the wiki, or post a question on the forum.
I suggest that we close this issue as there are no bugs identified. If you ask the question on the forum, someone will likely be able to help you with this device.
msmcgillis
commented
8 years ago I suggest that we close this issue as there are no bugs identified.
Well I'm not going to stop you from closing the bug.
But to me the messages identified don't look good and suggest to me that something is attempting to do something that probably is not appropriate.
The bug to me is that the xml for the aeon dsc24.xml is not right and the parameters identified in that xml as supported are actually not supported by the device.
To me it seems like those things should be fixed in the xml file. But if openHAB wants incorrect information about devices in its data OK.
cdjackson
commented
8 years ago I suggest that we close this issue as there are no bugs identified.
Well I'm not going to stop you from closing the bug.
But to me the messages identified don't look good and suggest to me that something is attempting to do something that probably is not appropriate.
What message are you talking about? Do you mean the command class not supported message? If so, these are fine - as I said, they just warn that these classes aren’t supported, so you can’t use them. It’s not doing anything that is ‘not appropriate’.
The bug to me is that the xml for the aeon dsc24.xml is not right and the parameters identified in that xml as supported are actually not supported by the device.
Ok, then please identify the issues clearly - what parameters aren’t supported. If there are parameters that are incorrect, of course we want to get them fixed - please provide information on what is not correct though, or better still, provide a PR. As I said, the command class information in the XML is not used and is being removed, so don’t worry about that.
Please can you state which parameters aren’t supported - if you can provide this, and the technical manual, then I’ll take a look, but the OZW file is of no use in this area as it is not providing ANY information on the parameters - or do you mean that the DSC24 supports NO configuration? Please just be clear what you are asking for.
Thanks Chris
msmcgillis
commented
8 years ago Please just be clear what you are asking for.
Well this is sort of like me asking openHAB to be clear on what exactly the format and meaning of the dsc24.xml file format is. I have been unable to find any "clear" documentation on what exactly is suppose to be in that file with "clear" details of what all is required .... Please point me to any documentation you feel that "clearly" describes these files that I may have missed.
you say ignore fine I can do that but they are inconsistent and if you don't want to correct it because its ignored thats your call but I believe this would be correct:
<Class><id>0x20</id></Class>
<Class><id>0x25</id></Class>
<Class><id>0x26</id></Class>
<Class><id>0x27</id></Class>
<Class><id>0x32</id></Class>
<Class><id>0x56</id></Class>
<Class><id>0x70</id></Class>
<Class><id>0x72</id></Class>
<Class><id>0x82</id></Class>
<Class><id>0x85</id></Class>
<Class><id>0x86</id></Class>Now this is where I get really lost because I have no idea what openHAB is expecting in this. But from the z-wave DSC24 device perspective in the XML information I provided above the available values that you can get from that device are indicated by the <value> tags.
This is actual output for each of those values through openzwave:
node2: Aeon Labs, product=0018, type=0003
node2: name="", type="Binary Power Switch", location=""
node2: class 32
node2: class 37
node2: Switch=true
node2: class 39
node2: Switch All=-15848
node2: class 50
node2: Energy=76
node2: Previous Reading=76
node2: Interval=493
node2: Power=32
node2: Previous Reading=0
node2: Interval=56832
node2: Voltage=114
node2: Previous Reading=0
node2: Interval=64000
node2: Current=0
node2: Previous Reading=0
node2: Interval=48128
node2: Exporting=false
node2: Reset=undefined
node2: class 134
node2: Library Version=3
node2: Protocol Version=3.67
node2: Application Version=2.15My assumption is the
If my assumption is correct then some sort of translation for each of the <value> tags identified in my xml file must be done in the DSC24.xml parameter section to have this file be correct for this actual device. What that exact translation looks like I wish I knew so I could be clear and simply provide you a correct DSC24.xml file. But, because I don't have clear information on the file format I can't just resolve it.
I consider the above xml information i originally provided to be very clear on what exact values exist for this device I just don't know how to translate that information correctly to an OpenHAB DSC24.xml file because I'm not clear on the OpenHAB DSC24.xml file format and requirements.
cdjackson
commented
8 years ago Please just be clear what you are asking for.
Well this is sort of like me asking openHAB to be clear on what exactly the format and meaning of the dsc24.xml file format is. I have been unable to find any "clear" documentation on what exactly is suppose to be in that file with "clear" details of what all is required .... Please point me to any documentation you feel that "clearly" describes these files that I may have missed.
Not really - if you’re saying it’s wrong, then you should be clear about what’s wrong. If you don’t know, then please say so. If you don’t know where something is, please ask. The documentation is here -: https://github.com/cdjackson/HABmin2/wiki/Z-Wave-Product-Database https://github.com/cdjackson/HABmin2/wiki/Z-Wave-Product-Database
Command Class you say ignore fine I can do that but they are inconsistent and if you don't want to correct it because its ignored thats your call but I believe this would be correct:
If you want to create a PR, then please do, but as I said, the information is not used and is not good source. I agree it’s better to make it correct, so feel free to create a PR.
<Class><id>0x20</id></Class> <Class><id>0x25</id></Class> <Class><id>0x26</id></Class> <Class><id>0x27</id></Class> <Class><id>0x32</id></Class> <Class><id>0x56</id></Class> <Class><id>0x70</id></Class> <Class><id>0x72</id></Class> <Class><id>0x82</id></Class> <Class><id>0x85</id></Class> <Class><id>0x86</id></Class>Configuration Parameters Now this is where I get really lost because I have no idea what openHAB is expecting in this. But from the z-wave DSC24 device perspective in the XML information I provided above the available values that you can get from that device are indicated by the
tags. Ummm - the information you provided from OZW is NOT the configuration parameters - it is the command class dump from the device and is generated automatically in a similar way to what OH does. The issue you are reporting is broken configuration data, and there is NO configuration data in the OZW file.
My assumption is the items in the DSC24.xml file are meant to be identical to the
items in the xml I provided. No - the file you provided is looking at the command classes - NOT the configuration. These are two different things. Look in the OZW file and you will see CONFIGURATION, but there is NO information here because this information doesn’t come from the device.
I can't be sure because I have nothing to compare a correct openHAB xml to a specific device that is correct.
Please look in the information I posted above, or in the database in the source files.
I consider the above xml information i originally provided to be very clear on what exact values exist for this device I just don't know how to translate that information correctly to an OpenHAB DSC24.xml file because I'm not clear on the OpenHAB DSC24.xml file format and requirements
I think what is clear is that you are confused about the configuration class, and the other classes. As above, the OZW file is not reporting the configuration, and yet you keep saying that the OH configuration is wrong. The ONLY place that the configuration information can come from is the manufacturer information (i.e. manuals). All the other information that OZW is reporting is irrelevant to OH.
Again, I’d suggest we close this as there is clearly confusion. I’d suggest that we continue the discussion on the forum until there are bugs identified that need a resolution.
msmcgillis
commented
8 years ago The ONLY place that the configuration information can come from is the manufacturer information (i.e. manuals)
Don't have one but this is the device I have: http://www.pepper1.net/zwavedb/device/774
cdjackson
commented
8 years ago Again, please be clear about what is wrong if you think there’s a problem. If you think the parameters are incorrect, then please let us know which ones - I don’t have time to look through every device in the database (there are over 230!) so you are best positioned to provide any feedback, but we need to have clear information.
I would strongly suggest reading through the OH wiki if you’re unclear (which I guess you haven’t or you would have found the links to the database :) ).
msmcgillis
commented
8 years ago Well from the above it sounds like your happy to take what ever someone throws into your software regardless of its accuracy. Good to understand about the developers.
Don't get me wrong I understand going over every detail takes time that often isn't worth yours.
My point is still accurate you current xml file for this device has a lot of issues and the history I asked for is now clear someone just took some other device and called it this and it was accepted no questions asked.
You have no time to worry about or address the issue also get it. So it will remain wrong and bad but this is a good indication of probably the general openHAB zwave device data.
Got it thanks.
cdjackson
commented
8 years ago Well from the above it sounds like your happy to take what ever someone throws into your software regardless of its accuracy. Good to understand about the developers.
Don't get me wrong I understand going over every detail takes time that often isn't worth yours.
Not at all - I spend a LOT of time on this project, but it is a community effort, and it’s not possible for one person to keep up with every database entry. All I’m doing is asking for your support rather than you telling me there’s a problem and leaving me to work it all out for myself. At the moment, all you’ve done is provide a link to the manual, with a statement that it’s wrong. Please consider supporting the project that you’re using.
My point is still accurate you current xml file for this device has a lot of issues and the history I asked for is now clear someone just took some other device and called it this and it was accepted no questions asked.
You have no time to worry about or address the issue also get it. So it will remain wrong and bad but this is a good indication of probably the general openHAB zwave device data.
Not at all - again, I am happy to support, but all I am doing is asking for you to help by being clear about the issues and clearly identify the incorrect parameters. If you don’t want to help, then you’re right, it may stay that way for a while to come, but please consider supporting the project and not just asking for others to solve problems - this is a community project.
I’ll look forward to an update of the database file from you :)
msmcgillis
commented
8 years ago Maybe I will have to decide if its worth my time as well in community projects everyone gets decide what important to them just like you. I have already contributed by pointing out the issue it is fairly obvious once reviewed.
Pointing things out and clearly identifying them is not enough you want the fix again all good we shall see if this is important enough to me to address, probably not, based on this I'm not sure any of the information in the database actually impacts how the core product functions probably more related to functionality in the admin interface. :)
On my list of things for openHAB that may draw more of my personal attention would be to implement a "buttonitem" itemType and to work out a widgetType "imagemap" that would offer an alternative image navigation/presentation. But, not sure either of those are so important to me to put in the overhead to implement plus at this stage I'm not 100% certain either of those don't actually exist and I have just missed them some place.
cdjackson
commented
8 years ago Just for reference, I checked the OZW database and they don't include this device -:
<Product type="0003" id="0018" name="Smart Switch (2nd Edition)"/>
SkynetHome
commented
8 years ago @cdjackson your patience is astounding!
msmcgillis
commented
8 years ago
I'm looking to understand the history of this file. I don't think it is correct as outlined or at least a couple z-wave devices I have are getting identified as this but do not support the functionality outlined in this.
This is a dump of openzwave output of what it thinks about the devices from scanning it. Which is a fairly different set of items than what exists in the .xml.
Any thoughts or suggestions on where I should go with the descrepancies?