Some openzwave devices may be missing because the instance are the same but not the index #803
Comments
sbouchex
changed the title
sbouchex
changed the title
sbouchex
changed the title
|
Yep, struggling with this myself actually this morning... but not something easy that can be changed without all users having new sensors, and old sensors not working anymore, or other sensor data being put in another (old) sensor Basically we should use both instance and index values Mayor problem, every manufacturers implement it 'their' way, for instance look at this: (There is actually only 1 Luminance sensor on the device) or this (which looks better): |
|
Or this one: |
|
Even if you find a way to move from the "old" ids to the "new" ids, the database contains data for device which is probably not the right one from the beginning. You way migrate automatically ids when it's possible (because there is no conflict between devices) and for the others, you migrate by using the first found and the other will be discovered and added afterwards. |
|
Not sure what you mean with this, but for instance i have years of logging that is correct. |
|
Your data are correct because you don't have devices having the same instance but different indexes and that's fine. Example:
If we migrate ids during the first ZWave devices discovery, Device "A" device ids will be based on instance 1 + index 1 and the device will not be touched and all data will be kept. Sounds feasable ? |
|
With device, you mean sensor on a Node? First and last will return 4 |
|
Sorry for the misunderstanding, I did not mean "adding" both value but composing the id with both: In ZWaveBase::SendDevice2Domoticz, the szID is composed of: [0][nodeID (8 upper bits][nodeID (8 lower bits)][instanceID], we can move to [nodeID (8 upper bits][nodeID (8 lower bits)][instanceID][indexID] The same think must be done in ZWaveBase::GenerateDeviceStringID (and other places) Most difficult part: At startup, Domoticz will migrate the id to the new one by adding the index and update the database and all internal structure. |
|
Most sensors (if not all) also have a unit (next to the deviceID), so we could have as device id the (NodeID<<8) | Index, and as unit the instance |
|
Yes but this unit may not go to this unique identifier as long as the nodeId, instance and index identifies it. Once this device ID is defined, of course all code relying on these id must be modified. |
|
Yep, so , first the internal device string should be extended with both index/instance, then all generated sensors should have nodeid+index+instance |
|
That's right ! |
|
What are we doing for this subject ? Some devices like the Qubino Smart Meter is not working, do you expect a patch from me ? Need to specify more ? You do it ? |
|
If you would like to do this, perfect. |
|
ok, I will try to work on a patch but tests will be required since most ids will be changed |
|
What is also on the 'wish list', is that we extend the zwave node table For instance, you have a zwave stick with 30 nodes, you excluded some during setup, so they wont be incrementally numbered Now, you stick broke down... or you switch to a zwave+ stick you need to include all your nodes again..... It would be great if we could 'map' the new nodes to the old nodes (or visa versa) |
|
Yes, make sense but I wouldput it into a separate issue |
|
Just one point of advice: always separate ids with some extra character when you combine them to form a new one: without the separator you would still end up with duplicate ids (111). |
|
the ids must be a numeric value |
|
AABBCCDD aa = node_id something like this should be fine |
|
unfortunately internally a temp sensor has only a 16bit ID... yep.... |
|
could be done when #1412 is done |
|
@gizmocuz sure ! as long as the id is correctly built |
|
I am running version: 3.8153 (on RPi with Razberry). |
|
Hello!
However, I don't get always responses from poll.xml. I have traced calls from the OZWCP pages in domoticz, and found that maybe a previous call to /json.htm?type=openzwavenodes could help, but I'm not sure if this is the way. So my question is: could you, please, confirm if this workaround is valid, or give me some directions to develop a good script? In particular I'm interested in correct URLs. Thank you, |
|
Why don't try to update to the beta version? |
|
Does the latest beta correct this issue? My main concern is the Qubino Smart Meter. |
|
If the latest beta solves this, wil I have to exclude/include the device again so domoticz assigns correct new IDs? |
I'm using a qubino ZMNHTD smart meter zwave device (with openzwave) and the CommandClass looks like this:
All entries have the same instance id but different indexes.
Once loaded into Domoticz, this device only reports a single sensor : the first one !!!
Analysis: In ZWaveBase::GenerateDeviceStringID, COpenZWave::UpdateValue and other functions, the DeviceStringID does not include the index, the unicity is not complete.
In ZWaveBase::SendDevice2Domoticz, same problem : ID is built by only using the instance, not by including the index as well.
Note : The issue may appear also with Razberry
The text was updated successfully, but these errors were encountered: