Idlock themselves recommend all customers to upgrade. They have on their facebook page urged people to upgrade.
With that being said it seems the most reasonable is to provide support for the latest firmware only. If it’s possible to do that without breaking previous versions, great, otherwise, people will have to upgrade.
Regards, S
So you recommend we stop supporting peoples devices? I don’t really think that’s a good idea.
If we stop supporting previous versions they would stop working 
I’m not really sure how we can force, or even recommend that people upgrade other than to post a message on the forum here.
I agree seems a bit harsh. So what is the alternative? Multiple versions (one per firmware increment?)
How have this been handled historically with other z-wave devices which comes with different firmware versions and capabilities?
Regards S
Yes, exactly - that is how the binding works. It can differentiate different firmware versions and choose the appropriate configuration for the firmware that is in each device.
So about door condition. In the current code it is not working.
The Door condition for the previous firmwares (https://idlock.no/wp-content/uploads/2018/08/IDLock150_ZWave_UserManual_v2.1.pdf) has been a 0, 1, 2, 3 option (not like it is today implemented as an OnOffType).
Which means that changing the the converter java class would probably benefit users using the old firmware as well.
I’ll be happy to test out any changes in the code. Like I said previously I got the door condition to work reliably using the sensor_general and displaying it as a number. Json might be a bit of overkill? (Considering you have only 4 different possible values).
Regards S
Sure - we can add that to the old definition as well - no problem.
Possibly, but this is my preference as there is a lot of data to add and this is more consistent with other channels such as alarms.
Fair enough, consistency is important. 
I’m also not completely sure what version of the command class this device uses so I want to ensure that the new channel covers any future changes 
@chris or @sihui
help??
Original device is 887. I started tryng to make a new one, 1106.
Even though I set firmware versions, the system is complaining about duplicate entry.
That helps, thanks.
I have some further questions.
I get the following message when locking/unlocking manually from the inside and with keypad from the outside with corresponding data for notification, event and status. When commanding via zwave I don’t get this in my log file.
Is the reason that this information was not in the earlier FW version? I assumed I would see the raw data (first of the three lines in my attachment) even if the binding couldn’t decode it.
The FW min should be 1.5 (I have already edited it in the database). This makes the former version up to and including FW 1.4 and the new one from and including FW 1.5.
I thought the link in this thread said version 1.4.9
I am still learning adding / cloning devices. I cannot seem to get the xml to load for the new one. It just updated the old.
I hesitate to create the endpoint manually.
The lock has FW 1.4.9, the ZWave module has FW 1.6. From the change log attached to the new entry in the database you can see that ZWave FW is first mentioned for the latest FW that came 23/8-19, so what it was before I don’t know. My lock came with the latest version 5 days ago.
In Habmin the FW is shown as 0.0.
For the new entry FW min maybe should be 1.6, and FW max for the old 1.5??
Typically, when commanding by ZWave, devices will not send reports about their status - this is a requirement from ZWA. Some devices may do this, but some companies have been told off for doing so.
Then it is strange that the manual describes such notification under command_class_notification_v4.
Why is that strange? Doesn’t the device send that notification? Maybe I’ve misunderstood something - sorry.
In the manual COMMAND_CLASS_NOTIFICATION_V4 is defined with hex code 71
The details is in the following table and it states ´RF Unlock Operation´ with ID = 0 for ZWave and ID of the RFID-chip for RFID.
When testing the lock sends notification when using RFID but not when using ZWave. If the lock doesn’t sent notification when command is sent from ZWave I find it strange that it is mentioned in the table with ID = 0.
So back to my original question in post 33:
To be more clear: Will I see all raw data in the logs regardless of the info for the device that is put into the database
