ID Lock 150 Zwave

[chris (Chris Jackson)]

@vegarroe

In the manual COMMAND_CLASS_NOTIFICATION_V4 is defined with hex code 71

Sure - this is standard - the binding supports this class

I’m not really sure what your point is. Decoding the ALARM command class is not the issue - the issue is you stated that the device doesn’t send notifications if it is commanded by the controller over ZWave. I stated this was normal, and you stated this is strange.

I don’t know what is strange?

Devices typically do not do this to avoid recursive loops - ie one ZWave device sending a command to another, and if that ZWave device sent a command, it could get into a loop.

Please can you clarify the issue as I’m still confused - sorry.

@vegarroe

Will I see all raw data in the logs regardless of the info for the device that is put into the database

Yes - of course. The database doesn’t change what is logged at all. All data received is logged.

[vegarroe (Vegar Røyset)]

@chris

I don’t know what is strange?

See the picture in post 39, the two circles is then for information that newer will be sent. Then for me it is strange to even add it to the document/table.

Of course that is not your fault and I need to contact the supplier (idLock) to get an answer.

@chris

Yes - of course. The database doesn’t change what is logged at all. All data received is logged.

Good knowledge, I have learnt a lot from this post, thanks

[chris (Chris Jackson)]

@vegarroe

Then for me it is strange to even add it to the document/table.

Ok, understood. I see your point, but this is in my experience pretty normal for ZWave. In any case, if the device sends it, then the binding will display the information.

[vegarroe (Vegar Røyset)]

@vegarroe

For the new entry FW min maybe should be 1.6, and FW max for the old 1.5??

I looked at the two manuals at Kundesenter – ID Lock
Z-Wave 150 v1.5: Manual is for FW up to 1.5 and the user manuals rev. is v2.1
Z-Wave 150 v1.6: Manual is for FW from 1.6 and the user manuals rev. is v3.02

I have changed the original database entry to FW max = 1.5 and the new entry to FW min 1.6.

@Bruce_Osborne

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.

Are you @Bruce_Osborne planning to work further on this new FW 1.6 entry in the database?

[Bruce_Osborne]

The xml file was apparently incomplete missing, at a minimum, the firmware version information…
I am not sure how @chris wants to proceed.

[chris (Chris Jackson)]

We’d need to see an initialise debug log to find out why the version is not provided. It looks like probably none of the version information was probably downloaded from the device.

[vegarroe (Vegar Røyset)]

Here is a re-initialise log, will that help? Or do I need to exclude/include?

The file is zip so change the type from log --> zip and then unzip.
ZWave_zip.log (64.7 KB)

After the re-init I now see FW 1.6 under attributes in both Paper UI and Habmin.

[Seaside]

My lock seem to report status very reliably now.

I look at the door condition to determine if the door is opened / closed.
You can’t always look at the door condition to determine if the lock is locked or unlocked, because door condition won’t be changed if you unlock the door from openhab using the lock switch. It will only be updated if you open it using keypad or the unlock button on the lock from inside.

So: DoorCondition to determine if the door is opened / Closed
EntryNotification to determine if the door is locked unlocked.

items:

Group ZwaveIdLock                    "ID Lock"                                         (Zwave)
Number ZwaveIdLockBattery            "ID Lock [%d %%]"      <battery>    (ZwaveIdLock,Battery,gRestore)        { channel="zwave:device:xxxx:node49:battery-level" }
String ZwaveIdLockAlarmRaw           "ID Lock Alarm Raw [%s]"      <alarm>    (ZwaveIdLock,gRestore)        { channel="zwave:device:xxxx:node49:alarm_raw" }
Switch ZwaveIdLockAlarmBurglar       "ID Lock Alarm Burglar [%s]" <alarm> (ZwaveIdLock,gRestore)        { channel="zwave:device:xxxx:node49:alarm_burglar" }
Switch ZwaveIdLockAlarmEmergency     "ID Lock Alarm Emergency [%s]" <fire> (ZwaveIdLock,gRestore)      { channel="zwave:device:xxxx:node49:alarm_emergency" }
Switch ZwaveIdLockEntryNotification  "ID Lock Entry Notification [%s]" <switch> (ZwaveIdLock,gRestore)      { channel="zwave:device:xxxx:node49:alarm_entry" }
Switch ZwaveIdLockDoorLock           "ID Lock Door Lock [%s]"  (ZwaveIdLock,gRestore)      { channel="zwave:device:xxxx:node49:lock_door" }
Number ZwaveIdLockDoorCondition      "ID Lock Door Condition [%d]"  (ZwaveIdLock,gRestore)      { channel="zwave:device:xxxx:node49:sensor_general" }
String FrontDoorLock     "Front Door is [%s]" <lock2>  (ZwaveIdLock, gRestore)
String FrontDoorStatus     "Front Door is [%s]" <door> (ZwaveIdLock, gRestore)

rules

val String LOG = "IdLock"

rule "UpdateDoorStatus"
when
    Item ZwaveIdLockDoorCondition changed
then
    val doorStatus = transform("MAP", "idlock_door.map", ZwaveIdLockDoorCondition.state.toString)
    FrontDoorStatus.postUpdate(doorStatus)
    val lockStatus = transform("MAP", "idlock_lock.map", ZwaveIdLockEntryNotification.state.toString)
    FrontDoorLock.postUpdate(lockStatus)
    logInfo(LOG, "[IDLock] The door is " + doorStatus +  " and " + lockStatus)
end

rule "UpdateLockStatus"
when
    Item ZwaveIdLockEntryNotification changed to ON or
    Item ZwaveIdLockEntryNotification changed to OFF
then
    val lockStatus = transform("MAP", "idlock_lock.map", ZwaveIdLockEntryNotification.state.toString)
    FrontDoorLock.postUpdate(lockStatus)
    logInfo(LOG, "[IDLock] EntryNotification, the door is " + lockStatus)
end

Transform idlock_door.map

0=Opened
1=Closed
2=Opened
3=Closed
-=Unknown
NULL=Unknown

idlock_lock.map

0=Locked
1=Locked
2=Unlocked
3=Unlocked
ON=Locked
OFF=Unlocked
-=Unknown
NULL=Unknown

Note that since I have manually edited the zwave database and binding, this is probably not how it will work. I expect the door condition to be a json string in the future.

[sihui]

@vegarroe

After the re-init I now see FW 1.6 under attributes in both Paper UI and Habmin.

Could you please provide the newly generated xml so we can finish the database entry?

[vegarroe (Vegar Røyset)]

@sihui

Could you please provide the newly generated xml so we can finish the database entry?

network_c6d21033__node_23.xml (9.2 KB)

[Bruce_Osborne]

@sihui Are you completing this one?
If not, I can work on it.

[sihui]

@Bruce_Osborne

If not, I can work on it.

If you want to start, feel free.
I will be available again later this day.

[Bruce_Osborne]

Updated & review requested.

[vegarroe (Vegar Røyset)]

I have done review down to endpoints and corrected an error with hinge position according to the manual and also by confirmation on correct understanding on my device.

Further the endpoints has to be reviewed further.

[Bruce_Osborne]

The hinge position text was copied from the older firmware version. I thought it looked backwards.
For many people here, and many vendors, English is apparently not their native language. I have given up fixing many thnigs and just copy from the manual.

[sihui]

@Bruce_Osborne

Updated & review requested.

Approved. Thx

[vegarroe (Vegar Røyset)]

@sihui

Approved. Thx

I don’t think the entry in the database is complete. Missing some end points and some command classes that should be secure is not marked as secure.

My experience of adding devices is limited, some of the info is logic and clear how to implement and other not. I have just recently looked into the database details and need more time to be able to do more changes.

Is there any guide in addition to the one at cd-jackson.com. The best had been a used case with examples of the initial xml and a good user manual.

[sihui]

@vegarroe

I don’t think the entry in the database is complete.

It’s coming from your xml and in 99% of all devices this was sufficient to get a working device.

[vegarroe (Vegar Røyset)]

Ok, it might be that I don’t understand the concept completely.

Using the former version in the database I have these in my items file but even more channels are available:
{ channel=“zwave:device:1:node23:alarm_entry” }
{ channel=“zwave:device:1:node23:alarm_raw” }
{ channel=“zwave:device:1:node23:lock_door” }

Then don’t they need to be defined in the database?
Now only lock_door and alarm_access is defined (It is as difference between the database entry for FW<1.5 and FW>1.6.

And what about the Sec and UnSec columns, do they need to be corrected to make it work as a secure device. I see in the xml that a lot of the command classes are secure, dump from the xml below saying secureCommandClasses:

[chris (Chris Jackson)]

@vegarroe

Missing some end points

Are you sure? Looking at the XML file that was uploaded earlier, it only shows one endpoint.

@vegarroe

some command classes that should be secure is not marked as secure.

This does not really matter. Of course correcting it is good as it will look better on the web, but it will not impact the binding t all.

@vegarroe

Then don’t they need to be defined in the database?

Yes, these were probably added manually, so they will need to be added.

@vegarroe

And what about the Sec and UnSec columns, do they need to be corrected to make it work as a secure device.

No - it will not matter at all. However, as mentioned earlier, it would be good to correct it so that the database correctly reflects the device so it’s a useful reference.