OH2 Z-Wave refactoring and testing... and SECURITY

What are you expecting to happen with these reports? I expect that one of them is tamper, and the other is the motion - so what is being reported when you trigger motion?

In fact I see the manual states this is the case.

Using the 2.3.0 binding, both Alarm and Binary channels triggered when motion was detected. I was suspecting the same with the new binding.

The Neo Coolcam device got no tampering switch, which makes me believe there is no tampering alarm.
The Vision device do have a switch, but I fail to see (in the manual) where is says it´s a tampering switch. I believe this switch is (was) used only for inclusion/exclusion and to wake up the device. (I could be wrong though).
I didn´t notice the Alarm triggering last night, when I pulled off the cover to wake up the device (several times).

Second:
I have a rule running for all my PIR, when ever they´re triggering the Alarm, they´ll return a DateTime value to a virtuel item. Since I updated to the lastest binding last night, both the Vision device and the Neo Coolcam has not been triggering the Alarm channel.

I simply fail to see, where I did something wrong in this update process.

Could this be a cache issue? It shouldn´t since all the things were discovered as new things. But the items names (openHab) are still the same. I only changed the channel names due to the controller beeing discovered as a new Thing as well.

Then this is possibly a bug in the old binding.

Are you sure this is right? The manual states that the alarm report is the tamper - I don’t think you should expect to have the tamper alarm notified every time the motion is detected? Maybe your understanding of the manual is different than mine?

Sorry - which device are we now talking about? Is this a different one than the ZP3102?

So? As per the device manual, at least for the ZP3102, the alarm is connected to the tamper switch. Just because you have configured a rule, does not make it correct :wink: .

Sorry - I’m not sure what you are referring to? Is this still the alarm issue that you are talking about or something else? If it’s the alarm issue, then as I have said above, at least for the ZP3102, this is the tamper alarm. I don’t think there is a problem here.

For the Coolcam device, please advise what the device is and I will take a look. Preferably provide the database reference, or at least your device IDs shown in the properties.

Hmm, then this is pulling the tricks on me :blush:

No, I´m no longer sure, after reading the manual linked from the database page. According to this manual, you´re right. The switch as a tampering switch… Which also conclude the 2.3.0 binding has a bug…
Hmprf!!! :frowning:

Vision :wink:
But my Neo Coolcam device suffer from the same problem… I´ll have to look into this again, to see if the alarm channels is a tampering switch just as well. (not psycical on the device though).
In the end both devices may be working as they should. I simply got confused due to the different behaviour when using the 2.3.0 binding.

I know… The 2.3.0 binding is probably the cause of this, making the alarm channel tringger when moving was detected. So I assumed wrong and used the Alarm channel for my rule.
I will change the rule tonight to be using the binary channel insted. At least the rule works then :slight_smile:

Ignore the cache idea I mentioned… I was just wondering. :thinking:

Regarding the Neo coolcam these are the properties: (from PaperUI).
This device DO have a problem in the database though. It´s discovered including a temperature sensor. But it does not have a temperature sensor. It includes a Lumiance sensor. I mentioned this as well a few months ago. Someone told me to update the database, but I have no idea how…
Anyway…The device could be having a tampering alarm as well. Maybe a “shake” sensor build in.
i cant seem to find the manual rigth now. But as far as I remeber, it was a hell due to different devices (looking the same) and different manuals. Shenzhen is no help either. They´re got it mixed up as wel.

|zwave_class_basic|BASIC_TYPE_ROUTING_SLAVE|
|---|---|
|zwave_class_generic|GENERIC_TYPE_SENSOR_NOTIFICATION|
|zwave_frequent|false|
|zwave_neighbours||
|zwave_lastwakeup|2018-08-23T10:46:36Z|
|modelId|Motion Sensor|
|zwave_version|3.97|
|zwave_listening|false|
|zwave_plus_devicetype|NODE_TYPE_ZWAVEPLUS_NODE|
|manufacturerId|0258|
|manufacturerRef|0003:0083,0003:008D,0003:1083,0003:108D|
|dbReference|401|
|zwave_deviceid|4227|
|zwave_nodeid|13|
|vendor|Shenzhen Neo Electronics Co., Ltd|
|defaultAssociations|1|
|zwave_routing|true|
|zwave_plus_roletype|ROLE_TYPE_SLAVE_SLEEPING_REPORTING|
|zwave_beaming|true|
|zwave_secure|false|
|zwave_class_specific|SPECIFIC_TYPE_NOTIFICATION_SENSOR|
|zwave_manufacturer|600|
|zwave_devicetype|3|

EDIT:
Here is the list of available channels for the Neo CoolCam. Notice the Temperature channel.


According to the device in the database, there isnt a Temperature channel. (how the heck did it appear then?).
According to Shenzhen there is a device which include a Temperature channel. But also one that include a Lumiance channel.
According to other sites (smarthings forum), some are even mention Neo Coolcams including Lumiance, Temperature and Humidity sensors.
This is a total mess.
The picture in the zwave database is also wrong.,. But thats a miniour problem I guess :slight_smile:

Yes, there is such a channel in the database. I don’t know if it should be there or not, but it definitely is, and this is why it’s displayed in your system.

What exactly is a mess?

Hmm… Isn´t it this device in the database?:
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/401
I dont see any temperature settings.
I did try add the temperature channel when I got it some months ago. It never sends any value update.

Finding this specific Neo coolcam device.
I have seen several manuals. None mentioning Temperaure.
http://manuals-backend.z-wave.info/make.php?lang=en&sku=NEOEMS01Z
https://youcontrol.dk/media/wysiwyg/NEO_motion_sensor_manual.pdf

Yes, that’s correct.

:confused: There is definitely a temperature channel -:

Sometime manufacturers (especially chinese) tend to use the same hardware for multiple devices, so it’s possible the device reports things that aren’t really supported. Maybe the database is also wrong and someone has mixed up devices - I don’t know as I don’t have this device.

Please provide the XML for your device and I’ll have a look.

Nope. Didn’t help. Stopped entire OH, removed both tmp and cache and started again. And after that I stopped the Z-Wave binding and got the exact same error (java.lang.IllegalMonitorStateException) again. Starting to think I maybe should report this as a proper ticket :slight_smile:

edit: Done. Ticket ID 641.

This is the list of command classes I see when entering the device in the database:


So the both belong to Sensor_multilevel??

Where is the XML located?

Yes, all sensors work like this.

In the {userdata}/zwave folder. It will have a name something like network_xxx_node_yyy.

I will take a look at this when I get a chance (in a few days) - it only seems to be a shutdown issue so should not be a significant problem right now (right?).

No, it has no other effect than being irritating in the log :wink: so I put it as priority “Low”…

@chris : here are my DEBUG logs relative to “NODE 0: SetSucNodeID command failed”:
Edit: suppressed

Thanks - can you provide a bit more of the log from just before this please? There should be a request called GetMemoryId and I’d like to see what this is showing. There should then get a call to GetSucNodeId. I’d like to see these two requests - in theory, this should provide your local node, and this local node should then be used to set the SUC ID if the SUC id is not current set.

For the ST814, I can see channels doubled for temperature and humidity:




What is the difference and the usage ?

Yes, this is common for ZWave. There are often multiple ways to get data and the database by default will provide all available channels, and set them to default names.

Ideally, I would have liked to reduce these to only use one set, and also give channels better names, but normally people don’t do this.

Here are the additional log entries:

Edit: suppressed

When connected to my RPI, the Z-Stick is blinking blue orange red blue orange red … Is it normal ?

Thanks - I think I understand what is happening here and have updated the binding. Hopefully it is fixed.

Yes - it’s normal, and, I know, it’s annoying! :unamused: