ZWave node stuck in "Node initializing: GET_CONFIGURATION"

Tags: #<Tag:0x00007f5c95e82f80>

Hi all,

I have Zipato branded flood sensor (HM-HS1WL-Z Smart Water Leakage Sensor) and have trouble including it to the network. I’ve tried to remove it, re-add etc. but nothing seems to work. With most recent attempt, the device seems to be stuck in “Node initializing: GET_CONFIGURATION”. In addition, habmin shows lifeline configuration change as “pending”:

I do not get any state updates either, I would expect regular updates every x hours, now it’s been almost 24h. Is this a false expectation? These are the channels I have linked

According to description in habmin, the device should wake up with the “networking button” on the sensor. Indeed, by pressing the button, I can see that the led flashing once with red color, and messages are flowing in zwave logs.

I’m having slightly outdated openHAB, I’m running version 2.4.0 – hopefully this has no big impact.

Log attached, starting with device removal, and attaching it again to the network. Node 18 is the problematic one. In the logs you can see how I have waken up the node, receiving some messages.

zwave2.log.zip.pdf (376.6 KB)

Also note that there are quite some traffic coming from other nodes, not sure if this is relevant.

Is there anything suspicious in the logs?
Would openHAB update help here?
Anything else I should try out?

Other than for the initial inclusion, I see no evidence in the logs that the node has been woken up. The node likely won’t complete initialization unless it’s been woken up multiple times.

I see plenty evidence of state updates from node 18. Are you sure you have an item linked to the sensor_binary channel?

BTW, I dunno what’s going on with the date/time timestamp in your log files. The log viewer is having a hard time decoding the date/time.

I see, your log file timestamp is borked up.

Your log file format

Mar 25 19:50:10.915

Standard format

2020-03-26 08:28:32.505

node18-item

This is why you’re not seeing the state updates on sensor_binary. There’s no item linked to that channel.

2 Likes

Yeah…sorry for that… it’s due to the fact I use journald for logging.

No, as you can see from the Paper UI, there is nothing linked to sensor_binary, only to alarm_flood.

As you suggested, I linked item to sensor_binary and I can now see actually see the value! Apparently the battery has updated itself as well. Unlike with the “previous model” of this Zipato flood sensor (PAT02-A), it seems that battery value is not updated even when triggering the button on the sensor.

I made incorrect assumption of linking to alarm_flood – that seemed to be the working with PAT02-A sensor.

Thank you very much, this saved my week after days of struggling!

EDIT: turned out that sensor_binary is not the channel to use: ZWave node stuck in "Node initializing: GET_CONFIGURATION"

1 Like

Well, interestingly enough, the device is sending an alarm report. But the binding is not doing a state update of the alarm_flood channel. It could be that the alarm definition in the database entry for this device might not be correct. Maybe @sihui or @Bruce_Osborne or @chris knows whether the DB should be changed.

And perhaps I should update the openHAB (and thus the DB), could resolve these issues as well?

That appears to be the tamper alarm - not the flood alarm. Or maybe this device is incorrectly reporting the alarm type?

1 Like

I see SENSOR_BINARY set as Basic. Is that correct?

I’m not sure, but it is not relevant here since the command is not a BASIC command.

To be clear - the issue in the log above is that the command is not a flood alarm - it is the tamper alarm which is not in the database.

1 Like

It looks sensor_binary is the wrong after all, it was telling whether tamper alarm has triggered. :frowning:

I attached latest logs. At the end the sensor has been linked to alarm_flood again. I submerged the sensor to water, but the openHAB item does not update.

zwaveMarch26.log.zip.pdf (376.5 KB)

I restarted openHAB in between, now it is REQUST_NIF

Should I just update my system before you guys spend more time on this?

What type of file is this? log? zip? pdf?

1 Like

It’s a zip of the log file, but with a pdf extension so that it can be posted to the forum. :wink:

1 Like

Again - all the notifications are TAMPER alarms.

I suggest to check the following and configure if for notifications - otherwise it seems to me that the binding is correctly using the BINARY_SENSOR channel that you probably have configured? I think these are reported at the same time but the log viewer doesn’t decode times properly as you’re using a non-standard format.

OpenHAB normally logs to /var/log/openhab. Perhaps the standard format logs are there to make the log viewer "happy:

https://www.cd-jackson.com/index.php/openhab/zwave-log-viewer

Sorry not on my machine, it’s configured like this on purpose… Will fix the timestamps for you next time :wink:

1 Like

thanks @chris but I think you are now looking at PAT02-A sensor. That is another sensor I have which is working flawlessly.

The problematic sensor is HM-HS1WL-Z: https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/800 . Rather annoyingly I thought I bought the same model but it looks this is quite different in many ways :angry:

According to DB, HM-HS1WL-Z has no configuration parameters:

Could it be that I broke down the sensor somehow and that is why nothing happens? Thinking point 3 in the WARNINGS

1 Like

Yes, I am. I thought that’s what we were looking at - I did not read all of the messages, but responded to the comment earlier which stated this. Sorry.

2 Likes

I decided to bite the bullet and buy PAT02-A… it looks like the HM-HS1WL-Z is not going to cut the bill with all these issues and lack of configuration…

Thank you all for the help in the any case!