[SOLVED] Z-Wave DB -> reference

hey @chris

I have 2 PIRs from Kaipule … both have the same enclosure and a sticker IX-32 on them but or discovered as different things as they have different Type / ID.

One is disovered as IX-32 and the other as DP-32
IX-32: http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/667
DP-32: http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/559

I am pretty confident they have the same Parameters and so on.

Is it possible to handle them as the same thing by adding the Type / ID from the DP32 to the IX32?
If so … should the DP32 be deleted then?

thanks!

What a pain :wink: (not you - the manufacturer :slight_smile: ).

Yes, it sounds like you are probably right and I’ve made the changes… (you might want to double check…)

thanks! :slight_smile: looks fine

1 Like

@chris
I am up to clean up more in the DB.
Stumbled over this…
if there are 2 things with the same type:id… how does the binding decide for discover / initalization which is used?

Thanks :slight_smile:

First point - this shouldn’t happen - or shouldn’t be allowed at least… There are checks in the database to try and raise an error if this happens, but I suspect it’s not 100% guaranteed to catch all instances as it’s a little complex.

The binding will use the first set that matches the criterea.

Now - the extended answer…

There are 4 numbers used to match the thing - the manufacturer code, the device type and device ID, and the application firmware version. So, in the case you have above, these two devices are not the same and will not conflict as they have different firmware versions. One device is version 0 to 3, and the other device is version 23.23 to 255.255 (which is the maximum version possible).

with one device my cleaning did not work as expected.

I thought adding a channel with type=GENERAL for SENSOR_ALARM on ENDPOINT 2 should work but it does not

15:26:48.466 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 11 00 04 00 0A 0B 60 0D 02 00 9C 02 0A 00 FF 00 00 EF 
15:26:48.484 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:26:48.495 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 11 00 04 00 0A 0B 60 0D 02 00 9C 02 0A 00 FF 00 00 EF 
15:26:48.505 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 11 00 04 00 0A 0B 60 0D 02 00 9C 02 0A 00 FF 00 00 EF 
15:26:48.521 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0D 00 04 00 0A 07 9C 02 0A 00 FF 00 00 90 
15:26:48.525 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0A 0B 60 0D 02 00 9C 02 0A 00 FF 00 00 
15:26:48.529 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Application Command Request (ALIVE:DONE)
15:26:48.533 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Starting initialisation from DONE
15:26:48.537 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@101a511 already registered
15:26:48.542 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Incoming command class MULTI_INSTANCE
15:26:48.546 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 10: Received MULTI_INSTANCE command V2
15:26:48.550 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 10: Requested Command Class = SENSOR_ALARM (0x9c)
15:26:48.555 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 10: CommandClass SENSOR_ALARM (0x9c) not implemented by endpoint 2, fallback to main node.
15:26:48.559 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 10: Endpoint = 2, calling handleApplicationCommandRequest.
15:26:48.563 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 10: Received SENSOR_ALARM command V1
15:26:48.578 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 10: Alarm Report: Source=10, Type=General(0), Value=255
15:26:48.588 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmSensorValueEvent
15:26:48.596 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got an event from Z-Wave network: ZWaveAlarmSensorValueEvent
15:26:48.604 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got a value event from Z-Wave network, endpoint = 2, command class = SENSOR_ALARM, value = 255
15:26:48.615 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 7: Transaction not completed: node address inconsistent.  lastSent=7, incoming=255
15:26:48.623 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:26:48.634 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0D 00 04 00 0A 07 9C 02 0A 00 FF 00 00 90 
15:26:48.647 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0D 00 04 00 0A 07 9C 02 0A 00 FF 00 00 90 
15:26:48.659 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0A 07 9C 02 0A 00 FF 00 00 
15:26:48.668 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Application Command Request (ALIVE:DONE)
15:26:48.676 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Starting initialisation from DONE
15:26:48.684 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@101a511 already registered
15:26:48.692 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Incoming command class SENSOR_ALARM
15:26:48.700 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 10: Received SENSOR_ALARM command V1
15:26:48.713 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 10: Alarm Report: Source=10, Type=General(0), Value=255
15:26:48.721 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmSensorValueEvent
15:26:48.729 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got an event from Z-Wave network: ZWaveAlarmSensorValueEvent
15:26:48.738 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_ALARM, value = 255
15:26:48.747 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Updating channel state zwave:device:15348538564:node10:alarm_general to ON [OnOffType]
15:26:48.768 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 7: Transaction not completed: node address inconsistent.  lastSent=7, incoming=255

–> Alarm Report: Source=10, Type=General(0), Value=255 must be something different

still throws:
SENSOR_ALARM 0x9c is not implemented for Endpoint 2 in the log

:-/

This means that the binding thinks the device doesn’t support this command class on this endpoint…

There are a few possible reasons -:

  1. The device really doesn’t support this command class on this endpoint!
  2. There was an issue during the device interrogation and the device does support the command class, but the binding thinks it doesn’t.
  3. There was no problem during the interrogation, but the device doesn’t report that it supports the command class, so the binding didn’t add this support.
  • Solution for 1 is obvious - remove the command class from the database. Since the device is sending this command class, this isn’t the reason!
  • Solution for 2 is to delete the XML or reinitialise the device to see if it now reports differently.
  • Solution for 3 is to add an option to the database for force the binding to add this command class.

1 and 2 are out
I added “add” to the command class config and will check if its gone

every other modifcation to the DB work as expected :slight_smile:

Anyways the DB gives me some headache… a lot of channels are e.g. “generalarm” or “alarm_burglar” for tamper etc.
Now somebody changes this to a more fitting channel and by the next nightly I pull channels stop working.
I’m not sure if a local or manual definition of the thing would be more robust.

Why is 1 out? Is this device new for you or something you’ve used in the past?

I’m considering adding a lock to devices that are considered stable to avoid random changes. The idea would be that for locked devices, people need to request further access…

To be fair though, this is also what you are doing :wink: . You’re adding “random” configuration to a device to see what works ;).

This isn’t possible in any case - ESH needs the XML files inside the binding.

i know and I really thought about it because of that :wink: …and stopped remapping other devices to more clear and specific channels like ‚alarm_motionˋ to not destroy working stuff of other people.
I would love to rename these to be very specific and thats the reason I hoped a manual .thing or whatever could allow this some time … seems impossible after your last post.

You didn’t say if this is a new device for you or if this was previously working?

it is sending the alarm. and the alarm i also processed by the corresponding channel.
so I already interpreted your post that it cant be 1 due to that.
for 2 I reinitialized … still the same.
that left me with no. 3

its a fibaro flood … was my first device ever :wink:

all channels in the DB do work as expected. only for ‚tilt‘ and ‚open enclosure‘ this error is in the debug…but works anyways

Yes - of course you’re right (I’m having a brane fade!).

I’m just surprised that this used to work without this addition to the database, but now doesn’t :confused:. The last time the database was updated for this device was March, so we can’t blame people for messing around with the database.