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

Tags: #<Tag:0x00007fc8f9bf8690> #<Tag:0x00007fc8f9bf85a0>

If you restart the system, you also need to refresh HABmin otherwise HABmin looses the connection for SSE events. Maybe this could explain it?

Yes - on startup the system should try to initialise the correct features, so this is correct.

I’ve updated this morning to the new version and indeed the problem, that the value “1” is stored in meter_kwh is gone :+1:!

But it seems that there might be some kind of timing issues, because openHAB don’t get with every wake up of the node the “METER_REPORT ELECTRIC_KWH” but the “BATTERY_REPORT” is always updated.

So when it is ok it looks like this:

and when only the BATTERY_REPORT gets updated:

So “METER_GET” request is send out from the controller. But there are fewer “ACCEPTED BY CONTROLLER” messages. With the version from openHAB 2.0.0 I got stable feedback of my node regarding the ELECTRIC_KWH report.

For testing purposes I’ve set the minimum poll period to 60s and the wake up time to 300s.

EDIT:

After removing “batter-level” from my items the pull for only ELECTRIC_KWH is working very stable:

Following this thread with interest. I don’t currently have any items that run secured mode. But I am thinking of getting a zwave door lock.

Can I ask what operating system you run on your Pine64? I’m running a Rpi3 today with Raspbian on a MicroSD card as harddrive. Thinking of future options of expantion. :slight_smile:

I updated to this test version yesterday and everything seemed to work nice. Then it seems suddenly tonight my Aeon multisensor stopped sending any values at all, I have it configured to send values for luminance, humidity and temperature every fifth minute to group one in which I’ve got the controller. It’s still ONLINE according to habmin and there’s no errors in the log. I’ve got the following log posts around the time tonight that it stopped sending, don’t know if they tell anyone anything?

2017-02-26 02:32:57.751 [BindingEvent              ] - org.openhab.binding.zwave.event.BindingEvent@8855c0
2017-02-26 02:32:57.754 [BindingEvent              ] - org.openhab.binding.zwave.event.BindingEvent@4fb1e1
2017-02-26 02:32:57.757 [BindingEvent              ] - org.openhab.binding.zwave.event.BindingEvent@703eb0

I don’t really know what to test or do?

So I digged a little bit deeper and I compared the FGWP102 entry on @chris zwave database to the FGWP101 entry. The entry for the FGWP101 on http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/130 shows some warning - the entry FGWP102 doesn’t. Maybe it is just an invalid database entry?

Regards,

André

That are only parameter description errors because the wording is too long to fit in there, nothing to worry about.

Fixed by database update.

2 Likes

I’m using the openHAB-specific Ubuntu that is offered in the pine64 downloads. But not the install that came with it at the time. I’m now using it more like a standard Ubuntu install.

1 Like

http://docs.openhab.org/installation/openhabian.html#pine-a64

1 Like

I’d just like to note that after a full restart of openhab (for other reasons) this seems to work again, the sensor now sends readings. Guess that means this was a problem somewhere within openhab or the binding (and not simply the sensor not sending values anymore). Don’t know really what though…

By the way, I get quite much of the following in the log now (for all nodes). Is it any problem or just safe to ignore?

08:04:07.493 [ERROR] [age.AssignSucReturnRouteMessageClass] - NODE 7: AssignSucReturnRoute command failed.

I have the same issues with my HEM. I’ve been trying to figure out the issue but haven’t found anything as of yet.

Yes - I’ve covered this a few times (I know this thread is getting long)… There’s an issue with the test binding that after some time, or some event in some systems, it stops receiving data (or to be more specific, it stops processing received data). This is why it works when it restarts, and this also causes the timeouts which causes the slow speed issue.

I don’t have this issue in my configuration and as time has been a little short over the past couple of weeks I’ve not yet managed to nail this problem.

Ahh. I must have missed that in the thread. I see it happen fairly often with my HEM. I know how life can be busy, thanks for all your work on this!

Doh. My bad. Should’ve read more carefully before testing. Well, I can see now (turned on debug for the binding) that there actually is data coming in from the sensor. Do you have any use of debug output?

Oh, and the only workaround now is full openhab restart? Tried only restarting the binding (bundle:restart), doesn’t seem to make any difference…

Yes - the data comes in, but there’s no messages showing it being processed (right?)? If so, this is what I’ve seen before - I think it’s probably caused by a thread synchronisation/locking issue,

I’ve got some logs from someone else which I need to look over - if you want to email me logs then please feel free (I can always delete them if I don’t end up using them :wink: ).

That’s interesting - maybe it’s because the binding isn’t closing down properly due to the thread not allowing the binding to actually close.

Ok, this is weird. Now even a full openhab restart didn’t help :confounded:

Anyway, I sent you a mail with debug log. Hope it tells you more than it tells me :slight_smile:

Network view is working for me for the record.

This made me do some looking at the code. I did some debugging and may have found some of the issue.

I then put a try/catch block in ZWaveReceiveThread in the ZWaveTransactionManager class. This showed some NPEs that caused the thread to exit. I’ve made a few changes and now my HEM has been updating all day since then.

How would you like me to send you what I’ve found?

1 Like

I have an Aeotec DSB45 Water Sensor that I just included to my network. I noticed an odd behavior with it that I’m not sure is the fault of the test binding or not.

The device has a wake button on it. When I press it, the LED on the device goes on for 10 minutes. The manual claims that this wakes the device. When I look in my logs, I see log entries flying by saying that the node is not awake, which is not expected.

The reason why I am not sure this is a problem with the binding is because the database data on this device includes this warning:

To wake up the sensor, don't push the wake up button, as it does nothing. Instead, tap the zwave button once. Use the wake up button to put back to sleep immediately.

I find this confusing and not sure if I should trust it, because the LED definitely goes on and seems to be indicating that the device is awake.

When I press the zwave button while in this supposed LED on awake state, I notice many messages start flying by in the log which make it seem like the device has been woken up. I see a queue of 4 messages that gradually dwindles to none. The manual does not define what’s supposed to happen when the zwave button is pressed while in supposed LED on awake mode, but the log messages looked correct to me. Still, the pending device configuration changes that I had queued up before this action remained pending despite the device appearing to wake.

This supposed engineering document about the device (that I found in this addons repo, issue #3001) claims that the Z-Wave button will do a few things including “Wake Up Notification command will be sent”, while the Wake Up Button does not say a command will be sent, but instead “Wake up device for 8 seconds.”

So, in conclusion, who knows what the heck is going on.

In case this is of interest to Chris, I’ll send him an email with my debug log.

For me network view is now also working, after I upgraded to the test version of last weekend.