[SOLVED] Don't get all values (channels) from my NEO Zwave PIR - only luminance

Hi,

I have a problem with a zwave Shenzen Neo PIR sensor.
It worked fine under 2.5 M1. During an unfortunate (stupid) chain of events, I decided to remove the Thing and it’s Items. The start was that I noticed that the category for the Binary Sensor was a Door, when I thought it should be a Motion. Said and done, I changed this and then it wouldn’t detect any movement.
Couldn’t get it to work so I decided the simplest approach was to remove the Thing and create new Items. Said and done.
Existing Thing was removed from controller, and then added. Leading to new NodeID.
But… the other thing that happened was that I didn’t see the same channels anymore.
Gone was the Binary Sensor and it was now replaced with a Motion Alarm.

The device now can report Luminance, but I get nothing for the Battery Levels or the Motion Alarm.

I checked the db and noticed that the picture was the newer version (or at least not the same as I have)

So, what can I do about this? Why does my sensor report Luminance but nothing else?
Is there a way to re-use the old Thing connected to the old Node ID my somehow changing this to the new Node ID?

br

1 Like

There is a lot to read about this device:



Please check your device type, device id and firmware version and post it here.

Hi @sihui,

Wow, wasn’t aware… will read up.

Device type/ID: 0003:1083
FW: 3.80

(It has same values for both the old and the new Thing.NodeID)

You picked the wrong database entry, the correct one is:
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/401

The available channel is alarm_motion with a Switch itemtype. For the other channels please see:
https://www.openhab.org/addons/bindings/zwave/thing.html?manufacturer=shenzhen&file=motionsensor_0_0.html

Make sure you are using the correct channels and wake the device manually to get fully initialized.

Yes, seem like I did. Anyway, this picture is the new one, the one I have is older and without magnetic holder. Might be same internals though.

Yes, but that’s the strange thing. The old thing (when working) didn’t have a Motion Alarm, it had a Binary Sensor.

Not sure what you mean exactly, the channels I use are the ones displayed in the PaperUI and the only that seem to work is the Luminance. None of the other seem to get any values. When trying to provoke motion - dancing in front of the sensor :slight_smile: It looks like it triggers (led flashing) but nothing ends up in the logs.

Waking the sensor up, yes, tried that but that changes nothing. It also seem to register correctly/completely when including.

My question is maybe, are you sure that the profile I get from the db is the correct for this old hardware? Seem strange that it was Binary Sensor and now it’s Motion Alarm?

Also; I get a channel for Temperature, which the device actually doesn’t have. But that was true for the old Thing too.

Is there any way to re-use the existing old Thing (NodeId 40) instead of the new Thing, I mean, could I somehow change the nodeid of the old Thing to the new nodeid, or ist that a bad idea?

br J

The database changes frequently so the channels may change.

Good, that’s the right thing to do.

Make sure you have set the association group (usually Lifeline or Group 1) to your controller.

Battery operated devices sometimes need to be woken up several times.

Not sure what you are talking about: the node id is provided from your controller, you can’t have the same device on two different node id’s

Yes, done.

Might be totally bonkers, don’t know exactly how OpenHab talks to the ZWave controller, but my thinking goes something like this; the nodeid is the controllers way to know that signal comes from a specific hw (like the PIR). It then sends this information on to (or OH reads) to OH, wich translates this into variables (items)
So, I was thinking, since the old Thing and corresponding Items used to work, and since the controller now has given a new nodeid (due to removal and re-inclusion) to the PIR, maybe I could change the old Things nodeid to the new nodeid. Just a thought.

One thing, since the lumincance values get reported every time the change, I suppose that the rest of the channels should be initiated and expect that the Items for these to work too? none the less, I’ve waken the device a (great) number of times, but nothing really changes.

br J

Then you need to switch the zwave binding to debug mode, reinitialize the device, feed the log through the zwave log viewer (tomorrow as the server is down at the moment) and see where your problem is.

Ok, Will be away for a few days, but will pick this up as soon as I’m back. Thanks for all the input, appreciated!

1 Like

So, I’ve created a log file and uploaded to logview, not sure what to look for exactly.
Did however notice something interesting when setting the life line;

     2019-06-20 14:14:29.903 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored binding_pollperiod to 86400 (BigDecimal)

2019-06-20 14:14:29.907 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored group_3 to null (null)

2019-06-20 14:14:29.911 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update set group_2 to [controller] (ArrayList)

2019-06-20 14:14:29.915 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Unknown association group 2

2019-06-20 14:14:29.917 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored action_heal to false (Boolean)

2019-06-20 14:14:29.920 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored config_1_1 to 12 (BigDecimal)

2019-06-20 14:14:29.922 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update set wakeup_node to null (null)

2019-06-20 14:14:29.925 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Error converting wakeup value null

2019-06-20 14:14:29.928 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored config_7_2 to 180 (BigDecimal)

2019-06-20 14:14:29.931 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored config_8_1 to 1 (BigDecimal)

2019-06-20 14:14:29.933 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored config_9_2 to 100 (BigDecimal)

2019-06-20 14:14:29.936 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored config_2_2 to 30 (BigDecimal)

2019-06-20 14:14:29.939 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored config_3_1 to 255 (BigDecimal)

2019-06-20 14:14:29.942 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored config_4_1 to 255 (BigDecimal)

2019-06-20 14:14:29.945 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored node_id to 43 (BigDecimal)

2019-06-20 14:14:29.948 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored config_5_2 to 100 (BigDecimal)

2019-06-20 14:14:29.950 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored config_6_1 to 8 (BigDecimal)

2019-06-20 14:14:29.952 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update ignored config_99_2 to 1000 (BigDecimal)

2019-06-20 14:16:12.086 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update received

2019-06-20 14:16:12.093 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update set group_1 to controller (String)

2019-06-20 14:16:12.095 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Unknown association group 1

Note the “unknow association group 1” at the end? It seem the lifeline won’t stick.

Did you do the config changes via PaperUI?

There seem to be problems when changing configs through PaperUI, for Zwave it is recommended to use HABmin as it is designed for that.
Also make sure after using the newer binding to delete the Thing and readd it (don’t exclude/reinclude!)

Yes, and by newer binding I assume you mean the 2.5 M1? Yes, that’s the one I’m using.
Delete was done by admin interface - waste basket icon. Add was done in Admin.

Yes, normally, so I tried doing them through Admin, but still resulted in the same errors:

2019-06-21 12:34:26.951 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update received
2019-06-21 12:34:26.964 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update set group_4 to [node_23] (ArrayList)
2019-06-21 12:34:26.966 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Unknown association group 4
2019-06-21 12:34:26.969 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update set group_1 to controller (String)
2019-06-21 12:34:26.972 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Unknown association group 1
2019-06-21 12:34:26.974 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update set group_3 to [node_32] (ArrayList)
2019-06-21 12:34:26.977 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Unknown association group 3
2019-06-21 12:34:26.979 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update set group_2 to [node_15] (ArrayList)
2019-06-21 12:34:26.984 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Unknown association group 2
2019-06-21 12:34:48.814 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 43: Application Command Request (ALIVE:VERSION)
2019-06-21 12:34:48.818 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 43: Incoming command class COMMAND_CLASS_SENSOR_MULTILEVEL, endpoint 0
2019-06-21 12:34:48.821 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 43: SECURITY not supported
2019-06-21 12:34:48.824 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 43: Received COMMAND_CLASS_SENSOR_MULTILEVEL V0 SENSOR_MULTILEVEL_REPORT
2019-06-21 12:34:48.828 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 43: Sensor Type = Luminance(3), Scale = 1
2019-06-21 12:34:48.832 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 43: Sensor Value = 275
2019-06-21 12:34:48.836 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Got an event from Z-Wave network: ZWaveMultiLevelSensorValueEvent
2019-06-21 12:34:48.840 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SENSOR_MULTILEVEL, value = 275
2019-06-21 12:34:48.845 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Updating channel state zwave:device:25c838a3:node43:sensor_luminance to 275 % [QuantityType]
2019-06-21 12:34:48.851 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 43: Commands processed 1.
2019-06-21 12:34:48.860 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 43: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1474d34.

Tried to set the other association groups too, but as you can see, same problem there.

however, changing wakeup seem to work

2019-06-21 12:39:42.460 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update received
2019-06-21 12:39:42.466 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Configuration update set wakeup_interval to 1500 (BigDecimal)
2019-06-21 12:39:42.469 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Set wakeup interval to '1500'
2019-06-21 12:39:42.484 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Wakeup node not specified, using 1
2019-06-21 12:39:42.487 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 43: Creating new message for command WAKE_UP_INTERVAL_SET to 1500s, node 1
2019-06-21 12:39:42.490 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 43: SECURITY not supported
2019-06-21 12:39:42.494 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 43: Command Class COMMAND_CLASS_WAKE_UP is NOT required to be secured
2019-06-21 12:39:42.496 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 43: Bump transaction 213 priority from Config to Immediate
2019-06-21 12:39:42.499 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 43: Adding to device queue
2019-06-21 12:39:42.502 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 43: Added 213 to queue - size 11

UPDATE1: @sihui Problem solved! Will try to describe what I did/had to do tomorrow. Big thank you for pointing me in the right direction! Part of it seem to be Admin/Paper UI.

UPDATE2:
I think there were at least two different problems involved here.

  1. I hadn’t included my device using admin ui (I had seen posts about not using paper ui for zwave but I also remember seeing posts that it was supposed to work fine)
  2. There seem to be something weird in the things/items db (internal one, not CJs)

so, I as I said before, I had a working system with a Neo Zwave PIR device. For some reason I decided to fiddle about and change the item connected to the motion channel, to a different category. From Door to Motion. For some reason this made the device not register (or at least not in the eyes of OH) Luminance however worked. The thing had an original ID of 40.

So after much fiddling about I came to the conclusion that the easiest would be to exclude/re-include. At this point I used the paper ui to include. The new ID was 42.
It still didn’t register motion but luminance was working.

This is when I reached out to the community and @sihui helped me.

So I excluded/re-include the device again, using the admin ui. The thing now got a ID of 43. No motion, still luminance.
And now it gets weirder. I deleted the device and rediscovered it, but now OH found the previous Thing, as undiscovered but with the ID 42, meaning the previous ID, not the current. (To me this indicates that the internal db for some reason was in a bad/incorrect state)
At this point I was ready to through the device in the trash and buy a new one - but alas - I gave it one more shot.
This time I excluded the device, cleared the OH cache and restarted the RPI.

  • I reincluded the device using the admin ui (I noticed in the logs that the channels this time were detected which I think was a first) The Thing had the correct ID of 43
  • I kept waking the device up until it had FULLY initialized (many times…) and then
  • added the item for the motion channel, in the admin ui.
    Now it worked!!

The conclusion I draw is this, always use the admin ui for zwave. If something seem really weird, clear cache and restart.

1 Like