No - while the initialisation can only occur very quickly after inclusion (ie 20 seconds or so), once the key exchange has happened, and the device is securely included, then this won’t be done again. When the device is reinitialised, or the binding is started without the XML files, the binding tries to send a few secure commands to see if it gets a response - if it does, then it will try and download all the secure data it need (this isn’t key exchange though). If it doesn’t get the response it expects, then it continues without security.
Unsure if related to the new test binding here or something else.
-
Twice now when I have added in a new Zwave device recently enabling the search/inclusion for new devices, Habmin did not initially show the found device although it was included by the controller. I was able to check the controller itself and see the device was added. And then after a stop and restart of OH2 and then a second search/inclusion, Habmin found and included the device.
-
After updating to the latest Snapshot today, I always stop OH2, update/upgrade, and restart. And on the OH2 restart, the binding ‘failed’ because it was missing the transport-serial binding. So I guess possibly an update of OH2 uninstalls the serial binding? I think I needed to do this the last time I updated as well.
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 
!
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. 
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.
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
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 
).
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 
Anyway, I sent you a mail with debug log. Hope it tells you more than it tells me 
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