I have four of the devices all bought at the same time, same supplier and running Openhabian 2.5.0 on a Raspberry Pi 2 .
Since updating from 2.3.0 to 2.4.0 and recently to 2.5.0 one device of the four is not being identified correctly
Should be
Thing Type Label : ZWS12 Chain Actuator.
Actually shows as ARZ Z-Wave Roller Shutter
Attributes still show correctly as
Manufacturer 0085 “Fakro”
Type/ID 0003:0001
Status does not update correctly (has been the case since 2.4.0 but ignored as not high priority):
2020-01-01 23:03:42.756 [ome.event.ItemCommandEvent] - Item 'MtrWinBed' received command 30
2020-01-01 23:03:42.762 [nt.ItemStatePredictedEvent] - MtrWinBed predicted to become 30
2020-01-01 23:03:42.800 [vent.ItemStateChangedEvent] - MtrWinBed changed from 0 to 30
2020-01-01 23:03:44.607 [vent.ItemStateChangedEvent] - MtrWinBed changed from 30 to 2
and then
2020-01-01 23:22:32.007 [ome.event.ItemCommandEvent] - Item 'MtrWinBed' received command 0
2020-01-01 23:22:32.012 [nt.ItemStatePredictedEvent] - MtrWinBed predicted to become 0
2020-01-01 23:22:32.045 [vent.ItemStateChangedEvent] - MtrWinBed changed from 2 to 0
2020-01-01 23:22:33.741 [vent.ItemStateChangedEvent] - MtrWinBed changed from 0 to 28
The item has no Association Groups section in Habmin as its identical brothers have. Nothing changes with a device Heal or Re-initialisation.
Initially the system would not allow me to create a linked item giving this error: Could not update element with key MtrWinBed -> zwave:device:dbe4518c:node9:blinds_control in ManagedItemChannelLinkProvider, because it does not exists.
After a reboot the link was able to be created.
But still no Association Group and still does not update status correctly.
Do I just remove the device and re-include?
I also notice on 2.5.0 that my light switches do not update if toggled at the wall plate.
These are
Manufacturer 015t “McoHome Technology Co., Ltd”
Type/ID 5121:5103
Is the status not updating on these various devices a bug or config problem?
Yes, that manufacruter has used the same device type and id numbers for various devices. That combination, along with the manufacturer id is the only way of identifying Z-Wave devices
We have no way of properly supporting these devices.
I seem to recall a way some people modified their local configuration to support their specific situations. A search of this forum may be beneficial…
All four devices show the attributes as above but only one gives an incorrect device description and lacks the Association Group section. Quite strange.
I have tried deleting a few times but always re-discovers the same with incorrect description and no Association Group section. I have also tried subsequent clean-cache with no effect.
It’s interesting that the others are mis-reporting position as well - I use them less often so had not noticed
2020-01-02 12:54:32.771 [ome.event.ItemCommandEvent] - Item 'MtrWinStudy' received command 40
2020-01-02 12:54:32.778 [nt.ItemStatePredictedEvent] - MtrWinStudy predicted to become 40
2020-01-02 12:54:32.811 [vent.ItemStateChangedEvent] - MtrWinStudy changed from 20 to 40
2020-01-02 12:54:34.470 [vent.ItemStateChangedEvent] - MtrWinStudy changed from 40 to 22
They drive to the correct position but the reported position does this dance around settling on a false number.
As I mentioned earlier this is all happening on a mature system that behaved well on 2.3.0.
The position reporting issue appears to me to be a zwave bug in 2.4.0 and 2.5.0 but the mis-identification of device is weird. I would prefer not to exclude and re-include it as that would mess up the number sequence of devices - I know not a big deal to some. Maybe I could copy a node xml file from the other device and edit some id details?
The most recent log shows a bit more info with the position finally getting updated
some 22 minutes later:
2020-01-02 12:44:48.937 [ome.event.ItemCommandEvent] - Item 'MtrWinBed' received command 30
2020-01-02 12:44:48.945 [nt.ItemStatePredictedEvent] - MtrWinBed predicted to become 30
2020-01-02 12:44:48.982 [vent.ItemStateChangedEvent] - MtrWinBed changed from 0 to 30
2020-01-02 12:44:50.889 [vent.ItemStateChangedEvent] - MtrWinBed changed from 30 to 2
2020-01-02 12:52:09.664 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key MtrWinBed -> zwave:device:dbe4518c:node9:blinds_control in ManagedItemChannelLinkProvider, because it does not exists.
2020-01-02 12:53:06.515 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key MtrWinBed -> zwave:device:dbe4518c:node9:blinds_control in ManagedItemChannelLinkProvider, because it does not exists.
2020-01-02 13:06:32.431 [vent.ItemStateChangedEvent] - MtrWinBed changed from 2 to 30
I would need to see a debug logfile to understand what is happening. The event info is really of no use to understand what is happening.
My guess is that this might be related to the command repoll period where the binding polls the state shortly after the command is sent, but the device is still moving. If you increase this does the problem stop?
Thanks Chris.
The device probably takes about 15 seconds to get to 40% so I have set the repoll period to 30000 (milliseconds right?) and it seems to be giving sensible results
Log attached. zwaveLog.txt (33.1 KB)
The second problem though is the incorrect identification as per the title of this post. Any thoughts with this?
According to our database this could happen, depending on firmware version. It the vendor has reused device type/id pairs there is not really anything we can do.
So then it’s as Bruce said - it seems that there’s an overlap in the device type/id and the version. We could limit the version in the ARZ for (say) 3.255, so that should make your device work again and we can see if there are people with overlapping versions then…
@Bruce_Osborne - any objections? Are you aware of anyone with this ARZ device with a high version number? I note that in the database it states that this is the 2013 version, so hopefully there’s not a wide range of versions!
I am ignorant of Fibaro devices Sorry. I assume that would require a new database entry for the newer firmware ZWS12?` We should try to get the latest manual & XML file to have the most accurate entry.
It’s not Fibaro - it’s Fakro. I suspect the same is still true though?
I also know nothing about them, but just wanted to make sure that you weren’t aware of any other discussion about this? (@sihui - same question)
If not, I’d suggest to change the version on the ARZ, then create a new version of the ZWS12 starting at (say) 4 and copy over the configuration. Maybe @robb01 can spend a few minutes to help copy over all the overview type information in the general device info?
