Sensative Strips 11 01 021 in OH3

Lukas_1st · August 31, 2021, 6:09pm

I tried to add to the OpenHAB v3 a new device - the Sensative strips model 11 01 021. I noticed that the log contains full communication with the device and I got full information but system did not recongise it. At the same time I have not found the same model in the z-wave database. I know about all problems with strips and I had to waking up this device a lot of time too but finally in my log I see that when I “open the wnidow” I will get proper message Notification Report.

Do you have the same problem with this model? I think this is a problem with the z-wave database.

chris · August 31, 2021, 8:29pm

Maybe the device is not in the database if it’s a new device? You say above that you didn’t find it in the database, so I don’t think it’s a problem with the database, but if it’s not there, then it will surely need to be added.

Lukas_1st · August 31, 2021, 9:41pm

Maybe I didn’t write it clearly, but I thought that this specific model is not present in the z-wave database. I even tried to create a ticket in OpenSmartHouse but I got errors (finally tickets were created, more than one).
Of course, I also have an XML file that the OH created and I understand that it will be possible to add an entry to the z-wave database based on it.

Lukas_1st · September 28, 2021, 10:44am

@chris
I have added the device to my network and I can see that alarm_system and alarm_access channels are not supported. By default, this is how the channels are created based on the XML file from the OH. I think I have to modify configuration of this device to what we have in other sensors, i.e. instead of alarm_access I will use sensor_door, and instead of alarm_burgler I will use alarm_tamper. Can I have to make a new ticket?

The question is, do we have something in place of alarm_system?

Lukas_1st · October 7, 2021, 5:43pm

@chris, you must be very busy. Maybe I’ll just make few modifications to these two channels (alarm_access and alarm_burgler), and alarm_system channel I will leave as it is.

chris · October 7, 2021, 7:18pm

Sorry - I missed your last message. If there are channels missing, then please update them in the database. You will need to create a ticket if you don’t have access and I’ll update your access.

stefan.hoehn · October 30, 2021, 8:50pm

Hi

This strip seem to be not processed right. It seems the old strips behave differently than the new ones

NODE 95 is the old one that is working. Here are the channels you see in OH

NODE 102 isn’t receiving the open closed state (=NULL). Here the channels in OH

2021-10-30 22:25:39.201 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=102, callback=0, payload=00 66 09 71 05 00 00 00 FF 06 17 00 C9 00 
2021-10-30 22:25:39.202 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2021-10-30 22:25:39.202 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 102: Application Command Request (ALIVE:DELETE_SUC_ROUTES)
2021-10-30 22:25:39.203 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 102: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2021-10-30 22:25:39.204 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 102: SECURITY not supported
2021-10-30 22:25:39.204 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 102: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2021-10-30 22:25:39.205 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 102: NOTIFICATION report - 0 = 0, event=23, status=255, plen=0
2021-10-30 22:25:39.206 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 102: Alarm Type = ACCESS_CONTROL (0)
2021-10-30 22:25:39.206 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 102: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2021-10-30 22:25:39.207 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 102: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
2021-10-30 22:25:39.208 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 102: Alarm converter processing NOTIFICATION
2021-10-30 22:25:39.209 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 102: Alarm converter NOTIFICATION event is 23, type OnOffType
2021-10-30 22:25:39.209 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 102: Alarm converter processing NOTIFICATION
2021-10-30 22:25:39.210 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 102: Alarm converter NOTIFICATION event is 23, type OnOffType
2021-10-30 22:25:39.211 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 102: Alarm converter NOTIFICATION event is 23, channel alarm_system is not implemented.
2021-10-30 22:25:39.212 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 102: Alarm converter processing NOTIFICATION
2021-10-30 22:25:39.213 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 102: Alarm converter NOTIFICATION event is 23, type OnOffType
2021-10-30 22:25:39.214 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 102: Alarm converter NOTIFICATION event is 23, channel alarm_access is not implemented.
2021-10-30 22:25:39.214 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 102: Commands processed 1.
2021-10-30 22:25:39.215 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 102: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1a5f55b.
2021-10-30 22:25:39.216 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2021-10-30 22:25:39.216 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2021-10-30 22:25:39.218 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2021-10-30 22:25:39.218 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2021-10-30 22:26:15.396 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 12 00 04 00 5F 0A 71 05 00 00 00 FF 06 16 00 00 D5 00 F2 
2021-10-30 22:26:15.399 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=95, callback=0, payload=00 5F 0A 71 05 00 00 00 FF 06 16 00 00 D5 00 
2021-10-30 22:26:15.401 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=95, callback=0, payload=00 5F 0A 71 05 00 00 00 FF 06 16 00 00 D5 00 
2021-10-30 22:26:15.401 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2021-10-30 22:26:15.402 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 95: Application Command Request (ALIVE:UPDATE_NEIGHBORS)
2021-10-30 22:26:15.403 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 95: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2021-10-30 22:26:15.403 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 95: SECURITY not supported
2021-10-30 22:26:15.404 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 95: Received COMMAND_CLASS_ALARM V4 NOTIFICATION_REPORT
2021-10-30 22:26:15.404 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 95: NOTIFICATION report - 0 = 0, event=22, status=255, plen=0
2021-10-30 22:26:15.405 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 95: Alarm Type = ACCESS_CONTROL (0)
2021-10-30 22:26:15.406 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 95: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2021-10-30 22:26:15.406 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 95: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
2021-10-30 22:26:15.407 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 95: Alarm converter processing NOTIFICATION
2021-10-30 22:26:15.408 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 95: Alarm converter NOTIFICATION event is 22, type OpenClosedType
2021-10-30 22:26:15.408 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 95: Updating channel state zwave:device:7175b6a970:node95:sensor_door to OPEN [OpenClosedType]
2021-10-30 22:26:15.409 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 95: Alarm converter processing NOTIFICATION
2021-10-30 22:26:15.410 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 95: Alarm converter NOTIFICATION event is 22, type OnOffType
2021-10-30 22:26:15.415 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 95: Commands processed 1.
2021-10-30 22:26:15.416 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 95: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@f041d6.
2021-10-30 22:26:15.417 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2021-10-30 22:26:15.420 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2021-10-30 22:26:15.422 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2021-10-30 22:26:15.423 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2021-10-30 22:26:19.451 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 12 00 04 00 5F 0A 71 05 00 00 00 FF 06 17 00 00 CD 00 EB 
2021-10-30 22:26:19.453 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=95, callback=0, payload=00 5F 0A 71 05 00 00 00 FF 06 17 00 00 CD 00 
2021-10-30 22:26:19.455 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=95, callback=0, payload=00 5F 0A 71 05 00 00 00 FF 06 17 00 00 CD 00 
2021-10-30 22:26:19.455 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2021-10-30 22:26:19.456 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 95: Application Command Request (ALIVE:UPDATE_NEIGHBORS)
2021-10-30 22:26:19.457 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 95: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2021-10-30 22:26:19.457 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 95: SECURITY not supported
2021-10-30 22:26:19.458 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 95: Received COMMAND_CLASS_ALARM V4 NOTIFICATION_REPORT
2021-10-30 22:26:19.459 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 95: NOTIFICATION report - 0 = 0, event=23, status=255, plen=0
2021-10-30 22:26:19.459 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 95: Alarm Type = ACCESS_CONTROL (0)
2021-10-30 22:26:19.460 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 95: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2021-10-30 22:26:19.461 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 95: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
2021-10-30 22:26:19.461 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 95: Alarm converter processing NOTIFICATION
2021-10-30 22:26:19.462 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 95: Alarm converter NOTIFICATION event is 23, type OpenClosedType
2021-10-30 22:26:19.463 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 95: Updating channel state zwave:device:7175b6a970:node95:sensor_door to CLOSED [OpenClosedType]
2021-10-30 22:26:19.464 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 95: Alarm converter processing NOTIFICATION
2021-10-30 22:26:19.464 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 95: Alarm converter NOTIFICATION event is 23, type OnOffType
2021-10-30 22:26:19.465 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 95: Commands processed 1.
2021-10-30 22:26:19.466 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 95: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1502d90.
2021-10-30 22:26:19.467 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2021-10-30 22:26:19.468 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2021-10-30 22:26:19.468 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2021-10-30 22:26:19.469 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2021-10-30 22:26:30.492 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Polling...
2021-10-30 22:26:30.494 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 65: Polling deferred until initialisation complete

if uploaded to the zwave viewer this info isn’t even shown

look at the logs above saying “channel alarm_system is not implemented.”

2021-10-30 22:25:39.210 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 102: Alarm converter NOTIFICATION event is 23, type OnOffType
2021-10-30 22:25:39.211 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 102: Alarm converter NOTIFICATION event is 23, channel alarm_system is not implemented.

Here is the documentation of the device: Strips Guard 700 - Sensative

Our database entry for the device at OpenSmartHouse Z-Wave Device Database has the the following command classes which includes the notification, so I think we are good here, aren’t we?

The notification events are as follows

should that map to parameters in our database?

So how do we have to map the following items in our database?

Cheers
Stefan

chris · October 30, 2021, 9:30pm

It looks like it’s processing ok - you just need to change the database to sensor_door.

Yes, this is fine - it is clearly being processed as you show in the image.

You can ignore this - or we can remove the alarm_system channel as it’s not implemented - it doesn’t change anything though (other than to make the debug message go away)

As shown in the log, it is already processed just fine - no need to map anything .

stefan.hoehn · October 30, 2021, 9:38pm

like it is done in the “old” sensor?

taken frim endpoints of OpenSmartHouse Z-Wave Device Database

instead of

(but keep it with V8?!)

chris · October 30, 2021, 9:41pm

Yes, that looks fine. I will remove the system channel as you won’t be able to delete something, but you should be able to change the existing channels.

Yes, these are old definitions from V2 (IIRC). The version here really doesn’t matter anyway - it’s the channels that matter.

stefan.hoehn · October 30, 2021, 10:03pm

That was quick

I changed the channels and set it ready to review.

You mentioned lately the build would run basically overnight. I am not familiar with the new marketplace concept in M3. Is it possible with that to provide a new bundle quicker by just uploading it there? (not that I am expecting you to do that with every build, just asking).

Lukas_1st · October 30, 2021, 10:08pm

Sorry, I’ve had a lot of work on my projects lately and haven’t made the changes I mentioned earlier, it means replacing the alarm_access channel with the sensor_door channel and alarm_burgler channel with the alarm_tamper channel.

chris · October 30, 2021, 10:08pm

I am not 100% sure when bindings might become available. It will be built once the update is done from the database which I’ll do shortly. Then it needs to build, and you could take the output of that build and drop it directly in your addons folder (removing the current binding of course).

I think adding it to the marketplace is more of a pain, and I’m not sure if that is a live update either as I’ve not looked at how that is managed. Manually dropping the JAR in your addons folder is the quickest - just keep an eye on the zwave repo on Github, when you see the database update you should be able to click on the CI link (once it’s built) and from there (ie on Jenkins) you should be able to get to the JAR.

stefan.hoehn · October 30, 2021, 10:25pm

Yep, that was why I was asking. I am not really sure yet where the advantage of the marketplace could be. Maybe to provide some version that a developer want to provide outside of a release cycle or even addons that are not part of the official OH repo at all (I include yours, though)

chris · October 30, 2021, 10:31pm

I don’t think it has a lot of advantage for “official” bindings like this that are already available though the normal route in the UI. Where it comes into its own (IMHO) is to allow others to publish “unofficial” bindings - ie ones that aren’t offically included in the OH addons. Getting bindings into the addons requires the maintainers to review and approve, and this can take months and I know there are a number of bindings out there that are not available due to this.

So, for sure there’s an advantage of the marketplace, but just not for your current use case (IMHO) .

So as a quick “how to”. The export of the database has just finished and is on GitHub -:

You see the build status and can then click on the Details button next to the Jenkins line, and it will take you to Jenkins. This has the links to download the JAR. Since I started writing this the build has now completed, so the link to the last build is there.

Enjoy

stefan.hoehn · October 30, 2021, 10:45pm

I feel the same, actually.

Thanks, overall the turnaround is more than quick here anyway and adding it the addons is not so much of a topic. By the way, when you add a bundle to the addons folder, do you actually delete the official one in OH first? I have seen situations in karaf that otherwise both, the old and the new one, are active.

I will try out tomorrow, btw, and let you know if it worked as expecred (almost 1am here )

chris · October 30, 2021, 10:52pm

Yes, you should uninstall the official one first if it’s installed via the UI - otherwise you will end up with multiple copies. The only “gotcha” here is that you also need to manage dependencies (eg the serial driver) if they aren’t installed another way.

You can also use the command line, and list all the installed bindings, find the zwave binding, and uninstall <bindingid> to remove it.

Nearly midday here

stefan.hoehn · October 31, 2021, 4:44pm

I seem to be totally blind or haunted by halloween but for ten minutes already I am looking everywhere to find a link to the build or anything where I could download it but I don’t see anything. Please help

apella12 · October 31, 2021, 6:21pm

It doesn’t look like it was merged to me. The Jenkins site also still shows the last .jar as five days ago.

Bob

chris · October 31, 2021, 6:55pm

It shouldn’t matter - CI does the build and they are available for testing as part of that PR build. It was there yesterday when I wrote the comment above, but possibly the CI settings remove builds a lot quicker now