Issues with ZW6302 Zwave Motion Sensor

I am able to check the battery %, but I never get anything on the sensor_binary item. I do see it alarm in the logs tho.


Thing zwave:ge_zw6302_00_000:controller:node71 "Node 71: ZW6302 - Motion"
 (zwave:serial_zstick:controller) [ node_id=71 ]


Contact   Front_Door_Motion                   "Front Door Motion [MAP(]"                                    (Motion)                                {channel="zwave:ge_zw6302_00_000:controller:node71:sensor_binary"}
Number    Front_Door_Motion_Battery           "Front Door Motion"                                     <battery>       (Battery)                               {channel="zwave:ge_zw6302_00_000:controller:node71:battery-level"}


18-Jan-2018 15:18:09.532 [TRACE] [nhab.binding.zwave.internal.protocol.SerialMessage] - NODE 71: Message payload = 00 47 03 20 01 FF 
18-Jan-2018 15:18:09.534 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 71: Application Command Request (ALIVE:DONE)
18-Jan-2018 15:18:09.534 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 71: resetResendCount initComplete=true isDead=false
18-Jan-2018 15:18:09.534 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 71: Incoming command class COMMAND_CLASS_BASIC, endpoint 0
18-Jan-2018 15:18:09.534 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 71: SECURITY not supported
18-Jan-2018 15:18:09.534 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 71: Received COMMAND_CLASS_BASIC V1 BASIC_SET
18-Jan-2018 15:18:09.534 [DEBUG] [ernal.protocol.commandclass.ZWaveBasicCommandClass] - NODE 71: Basic report, value = 255
18-Jan-2018 15:18:09.535 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 71: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
18-Jan-2018 15:18:09.535 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 71: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_BASIC, value = 255
18-Jan-2018 15:18:09.535 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 71: Commands processed 1.
18-Jan-2018 15:18:09.535 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 71: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@77c70b58.

@chris do you know how I can set the PIR Timeout Duration in my zwave.things? Since my device is configured manually I can’t set it via habmin.

Sorry, I don’t really have any options. Maybe the Zensys software can do it.

I apologise for this, but it’s a decision that was made in ESH not to support this through the current config mechanism so unfortunately the configuration updates don’t even get passed to the binding when the things are defined in a text file :frowning: .

That sucks, sorta contradicts what @Kai has said about being able to configure openHAB 2 with text files or gui.

Could you elaborate which decision this was? How do you set the PIR timeout of the devices if it is not done textually?

This one -:

It means that it’s not possible to configure things if they are defined in the text files… I know there’s a proposal to allow configuration of devices, but currently there is nothing available.

Err, no. It means that things in text files are configured through text files.
So @sipvoip should be able to define the PIR timeout in the Thing configuration in the things file and the binding should use this setting (and configure the remote device accordingly, if not already done).

Yes, you are right, but the consequences of this would mean that the binding would need to send ALL configuration to ALL devices when it starts in order to fulfil this.

We have discussed this in the past, but to explain this some more -:

Given that many devices have between 10 and 50 configuration parameters and many people have 60 to 100 devices, this would mean thousands of additional transactions which would really slow down the initialisation.

For this reason I don’t think it is a good idea to implement a system that reconfigures all parameters on startup.

Additionally some parameters are there to reset the device or make major changes and these must only be sent when really required.

@kai I was wondering if you had any further thoughts on handling this? I don’t think it’s possible for the binding to know if a config value is configured manually or not so I can’t see any easy way around this other than to send all configuration values on startup, and as above I think this is a really bad thing to do.

I’m open to thoughts on how to resolve this if you have any…

Well, I think this is pretty much related to this issue. We are talking here about a device configuration and I agree that it does not make much sense to send those out to the devices on every startup.
I would actually also claim that if someone configures his system statically/textually, the startup should not mess with the surrounding devices, but rather consider them to be pre-setup already.

Maybe we could think of some “configure device on startup” feature in issue #3484, but for now I would agree that those parameters are better not at all used in a textual configuration.

@sipvoip Could you live with that? Or what would be your current expectation of how the binding should behave if you have values set in your things file?

The only “path in the middle” that I would say is to have the binding check whether some value is out of sync and only set it, if it sees that the local config contains a different value than the device. Whether this is feasible (not sure if and how often you might get those values from the devices?) is probably something @chris can answer best.

Yep, I agree :wink: .

Technically, this is possible, but it will result in every parameter being reset to defaults if it was previously configured…

The config description will be reset to the default values when a thing is added - the binding can then read the configuration of the device, and it could check if it’s different, and then configure it. But it means that any previous configuration would be reset to default values, so if someone is using other software to configure devices (such as the Zensys tool that is used by some) then it will be reconfigured.

Also, if the database is configured incorrectly (always a possibility) and then we end up with the device configuration in a bit of a mess.

So, I don’t really think this is a good thing to do.

I’m still not really sure why we shouldn’t allow the configuration to be updated in a thing, even if it’s not a managed thing? I know you said that the fact that the configuration is not persisted will confuse people, but I think if people are manually configuring their things, then they could be considered “advanced users” and therefore smart enough to work this out :wink: . I think this is a useful feature (forgetting device configuration completely) as it allows users using text configuration to adjust their system in the UI, find the right configuration for them, and then update their text files.

Also, I think currently there is no way for a user to update configuration without reinitialising the thing since I believe the thing will be reinitialised when the text files are updated (right?).

Yes, I could live with that!

@kai, @chris, any update on this? I also have some ct100plus stats where I need to set the Temperature Reporting Threshold in my zwave.things file.

The new features to allow device configuration are being worked on, but it’s not ready yet.

Thanks for the quick reply! When they are ready for testing please let me know.

Will do - I don’t know that I would expect it super soon, but maybe in a month or so by the time the ESH changes are added, then the binding is updated.

Keep an eye on the issue that Kai referenced above.

Its been a few months, any update on this?

No - unfortunately not. There have been some discussions about adding the new features to ESH, but it’s not available at the moment.