Agree with your observations, but not sure what to do about it. Keep in mind the command polls happen 5 seconds after a command, so if another command is sent, but not acted upon, the poll will return the current state. You can see that in the first debug. Zero is sent, but the device apparently didn’t get around to changing by the time the poll was sent and the last state was returned at 50:08(50). what doesn’t seem to fit the SET/GET/REPORT are the two state updates at 52:34.855 (50) and 52:37.366(0) Why were those sent? -Is the device still sending unsolicited reports? The 5 second poll for the 75% did not happen until 52:39 (0) and the device still seemed to be at 0 from the 50:03 command. Do you have an unfiltered (all nodes) raw DEBUG covering 21:50 21:53?
unfortunately I did not copy the debuglog at that time, but I deactivated all my rules, so it is unlikely that it is caused by an event or rule.
I was able to recreate the issue again today and the “2 iterations backlog” situation was actually still present in the device. I was not able to reproduce anything that looks like the two state updates at 52:34.855 (50) and 52:37.366(0) that you noticed. After firing numerous commands, the backlog seems to be floating between 3 and 4 commands. I’m unable to witness the drop from 4 to 3. I do not seem to have 2 changes in a row in the log then. I can somewhat work around the problem by sending a value to the device, followed by the command ‘ON’ until I receive a change with a value that ‘matches/is close’ to initial value command
I have 6 identical dimmers active in the house. Probably with identical part numbers. I want to see if I can reproduce the issue on these dimmers, too.
Suggestions on how to proceed or how to test are welcome. This is far from ideal.
Is it too late to return the devices? This does not seem to be OH related. Are the wiring connections sound? The idea to check the others is a good one, there may be just one bad one.
One random testing idea is to set parameter two to zero (eliminate a potential faulty local switch notifications) and set the command poll to zero (to eliminate any polling). Then using OFF and ON (255) only (say in Cron rule - avoid use of the slider), time how long it takes the light to visibly reach each state and how far behind it gets. There should be no event updates, just commands in OH since all reports are theoretically suppressed.
this made me go back to the manual of the device, because I did not fully understand the testcase. I also have the feeling that there is something wrong with the device, but I think we have a binding issue as well.
the thingtype of my thing has been set to: ‘ECO-DIM.06 or ECODIM.07’:
if you have a look at the manual for Ecodim.07 page 25/26 there is a list of available Configuration Command Parameters. This is not the list I see in my Thing. Moreover, the manual does not include a value 2 for parameter 2 (edit: isn’t the SWITCH_MULTILEVEL_REPORT output in the log an indication that this value 2 is not supported on my device?).
but, if you have a look at the manual for the Ecodim.06 page 8, I see two Configuration Command Parameters including a value 2 for parameter 2.
It is possible that this contributes to my problems? To be abundantly clear: I do not own any Ecodim.06 device. Maybe the devices should be separated in the DB?
Yes, looks like “0” is the only option to suppress notifications.
The other parameter that would help is “3” to speed up the dimming speed from 5 seconds to instantly. That is how I have my dimmers set to avoid some of the problems you are seeing.
yes, but the issue is going to be how. Devices have 4 ways to distinguish themselves as unique.
Mfg: 0431 (same for both)
Type: 0202 (same for both)
IDs: 0001 & 0002 (possible to separate on this)
Version (currently all)
Can you pull these from the UI page under the “properties” dropdown?
here are some of the properties from my thing that could be of interest:
| property | value |
|---|---|
| modelId | EcoDim07 |
| zwave_plus_devicetype | NODE_TYPE_ZWAVEPLUS_NODE |
| zwave_version | 1.8 |
| manufacturerId | 431 |
| manufacturerRef | 0202:0001,0202:0002 |
| dbReference | 1114 |
| vendor | EcoBright |
| zwave_devicetype | 514 |
| zwave_manufacturer | 1073 |
Do you have a line with device_id? I’m thinking 0002 is “7” and 0001 is “6”. That would provide a basis for splitting.
zwave_deviceid = 2. I think you are correct. I overlooked it as it has truncated leading zeros just like the node-id
hi @apella12 did you have some time to execute the split in the DB? what should be done on my side? I assume I have to delete my things and do a new discovery, right?
Two things
- I thought you knew the Zwave DB is “community” maintained. There is a blog Blog Posts (opensmarthouse.org) on how to get write access, if you do not have it already (I also thought you had that too.). The blog also discusses splitting/copying devices.
- I still think you can run the test described above. Even with your device parameter 2 can be set to zero and the poll to zero. For a test of “normal” operationn, since parameter 3 is currently missing you could set the poll command to something like 6500 since by default the device is going to take 5 seconds to reach the new state. You do not want to poll before it gets there or you will get an old value.
I just manually edited a partial
ecodim07_0_0.xml (7.5 KB)
with just parameter 3 (hopefully no errors-I think this is the only one relevant to your problem). that you can use following process Update ZWave binding with new/updated device xml - Tutorials & Examples - openHAB Community
I did follow up on that suggestion. I created a script that tested if the device was 0 to turn it into 100 and vice versa. I fired it over and over to all my devices to see what would happen. I toggled both the parameter and the polling to find the optimum, but I couldn’t find a way around the issue. It turned out the the node5 was the only one with the queued command behavior. I ended up removing it from the controller completely, cutting down the circuit braker (which always causes side effects on other appliances, grrr) to give it a full reset and then I included the device again. It is now running fine for a few days without the queued command behavior. It actually also improved the behavior of the slider in mainUI, too, which was actually the most frustrating thing.
I was totally not aware of that yet. I will follow up on that by diving into all the references you added.
Great. Only caution I have is that without parameter 3 the device default is 5 seconds, so don’t trigger changes faster than that and if you use the poll need at least 5 seconds there too. I’d use 6, just to make sure. Again congratulations
yes, that is actually interesting, because I do not experience that on any of my devices. i can send commands within milliseconds and it processes in the correct order very rapidly.
Hi @apella12. I’m only revisiting this topic now as many other things got in the way. I tried to update
ecodim07_0_0.xml (9.4 KB) to the best of my abilities, but there are some points that I do not understand. would you be able to give this a review?
-
I removed the ECODIM.06 reference like so:
property name="manufacturerRef">0202:0002</property>
but I’m not sure if this matches to the allowed use cases to update the zwave-database. Obviously I don’t want to delete the ECODIM.06 device. However, adding this file to the DB means that we create a second reference for the ECODIM.07. -
I listed parameter definitions in line with this source manual. There are some things that I’m uncertain about:
- parameter 4 is missing in the manual. I followed the numbering, so config entry 4 is now missing in the definition too.
- config entries 3 (Switch Dimming Speed), 7 (Switch on Level) and 8 (Turn off Delay) are range values. I was not sure how to model these.
I have seen that the process of creating a new device includes a review process, but I dont feel like uploading something that I’m not confident about. thx
Let me try to sort this out.
- do you have ZW DB write access?
- The xml you are editing is NOT what is uploaded to the ZW DB.
- The XML in the userdata/zwave folder for the node IS what is uploaded. Please post that here so I can have a look.
- There WILL be a problem uploading the XML until the existing ecodim.06 is changed
- Once the .07 is uploaded the parameters and Association groups need to be edited directly in the DB
I see.
ad 1. Yes, I have write access to the ZW DB
ad 3. I found this in var/lib/openhab/zwave:
network_f99e9999__node_xx.xml (11.1 KB)
Ok, a little odd, but should work.
a) change the 202 to 999 to avoid ad 4.
b) create device in DB and paste it in the window.
If it loads okay, fill in the param and assoc group data, docs, etc.
Edit: Last steps: change existing (DIM.06) entry to eliminate the 0202:0002. I also think the references to .07 should be copied over to your new device and taken off the old one. Change the unique ID to ecodim06. (Use ecodim07 for new) I don’t know why it was done that way. They are two separate devices and do not even look the same. MARK for review. Lastly go back to new change from 0999:0002 back to 0202, MARK for review.
I can take a quick look when you are done.
not sure what odd thing you spotted, but I cannot create a new device in the database with that xml file. the DB response is “error”. That is not very specific for this newbie…
It is often hard to tell what the problem is with an upload.
The two things that are odd is the network ID and the lack of a node. Normally a discovered, but unknown device XML will look the same as your other XMLs in that folder and with a node number in the range from 2 to 232. You could try editing them to match, try to exclude and include, or factory reset and reinclude.
So I see you got it added. Just need to fill in the rest of it, so it can be reviewed