Downloading the latest manual in that page the latest version shows parameter differences.
compared to the old devices:
Parameter changed from 10 to 11
New Function at Parameter 10
New Parameter 12
I have created a new device for firmware 3.80+ for the ID 0003:108D . And as Advised I also submitted a modification for the old device (403) with max Firmware 3.79.
Although who-ever has the pd02Z device seems to be always on this firmware. I think it is a good separation to begin with (the Firmware).
I just ran into the same issue. I’ve noticed you’re already in the process of updating the ZWave database, can you maybe post back here once everything is updated?
I’m just looking at the changes that were now merged, but I’m not 100% sure the changes are correct:
If I look at this correctly, the device database now contains:
‘Old’ detectors: Firmware up to 3.79 and references 0003:0083,0003:008D,0003:1083,0003:108D
‘New’ detectors: Firmware from 3.80, but only for references 0003:108D
This seems to imply that firmware 3.80 and up do not exist for non-108D devices, right? However, I have an old detector (with ID 0003:1083) that has firmware version 3.97. With the current device database this would not work anymore, right? Since now firmwares from 3.80 and beyond are only supported for ID 0003:108D.
My First Suggestion was to separate the 0003:108D from the stack as it is the new hardware with Temperature sensor PD03Z.
I was advised not to do so.
The questions:
1.Is your 0003:1083 with or without temperature support?
2. what parameters does your device accept? is the Led Blinking modifiable by the param10?
Normally, this is the best method as we don’t know how devices are defined by manufacturers. We do not know if this new device is defined by a new set of IDs, and removing IDs from an existing device is just as likely to break someones device.
Normally, when firmware is updated, it is better to leave the IDs along, and create a new version. At the time, you only reported that the parameters had changed, so this was the best course of action. We often see new versions of a device, with new parameters, and we don’t want to use the IDs to differentiate these -:
Now what I’m reading here is that this is a different device completely? In that case, maybe it is better to separate out the IDs if we can work out what they are for each device - that will require some discussion which I’ll leave you to do, and we can conclude afterwards .
Chris No offence! I am not native in English and my language might be harsher than I intend to.
The new device has temperature sensor which the older do not.
We found this only on *D models (at europe at least) and this was the first though
Per your advice which, I found also normal way to do the first changes!
Roy helped us to understand what happens.
The new device is coded PD03Z where the old are PD01 and PD02 (design change but same function).
Factory delivers the OLD manual with PD03Z and firmware 3.80 which fits the attached pdf!
This device is so confusing!
@chris
Maybe we can move the *108D under PD03Z and remove it completely from the old device? as it has an extra temperature sensor.
The craziest thing:
Box is the same, Included manual the same (only 10 params), Looks same (PD02 and pd03), Hardware different!
When I first received the device, I contacted the shop I bought them their reply:
The 1083 is without temperature support. I’ve tried hooking up that channel, but nothing is coming in.
LED blinking is indeed controlled by param10.
I ordered both the 1083 and (six months later) the 108D device from the same reseller on AliExpress. Both are being sold as PD01Z, but I don’t think that is accurate. The manual provided with both devices is identical though, with the manual for the 108D (erroneously?) stating that LED blinking is controlled by param10.
What led me to this topic though is that the 108D doesn’t seem to be sending any updates at all. But that is maybe related to configuration parameter “Motion Event Report One Time Enable” which by default only sends events when the previous event was acknowledged?
Well, these devices report that they use the ALARM command class (AKA NOTIFICATION). This command class is the preferred (ie more modern) command class, and should be used if supported. The database says that the lifeline sends the notification - maybe this can be disabled? If so, it should be enabled.
If the device really doesn’t support this, then we can change the database to use the SENSOR_BINARY, but it’s not the best option if NOTIFICATIONs are really supported as the device states.
I can’t get the new device to send anything, even though I see it responding due to its LED flashing when I trigger the alarm. Again, I assume this is because of the missing “One Time Motion Alert” configuration parameter, but I’m not sure
Additionally, I’ve found that the old device’s trigger shows up as a switch whereas the new device shows up as a motion alarm.
This ought to be processed fine by the binding (2.4) - but note that the channel type MUST be correctly set to alarm_motion or it will not be looking for motion alarms. The database looks ok in this respect.
.
