Closed mhilbush closed 8 years ago
Please make sure you are running the absolute latest OH2 runtime - not just the latest binding, but the latest runtime off Cloudbees. There was a bug in ESH that was fixed a few days ago that caused problems reading the database files - this might be the cause of your problem and I’d like to make sure you’re up to date before I look too much further….
I pulled down the latest using this script from xsnrg (modified for my install locations).
https://github.com/xsnrg/OpenHAB2-tools/blob/master/makeHAB
It pulls from:
https://openhab.ci.cloudbees.com/job/openHAB-Distribution/lastSuccessfulBuild/artifact/distributions/openhab-online/target/openhab-online-2.0.0-SNAPSHOT.zip
and from
https://github.com/cdjackson/HABmin2/raw/master/output/org.openhab.ui.habmin_2.0.0.SNAPSHOT-0.1.4.jar
Is that what you were expecting?
If so, I'm seeing the same behavior.
Yep - thanks.
So… Can you confirm how you are adding the nodes into OH. You put the binding into discovery, the device is found and added to the inbox, and you then manually add it? Or is some of this somehow automatic?
Another question - can you type the following into your browser and send me the result -:
http://192.168.2.1:8080/things/zwave%3Adevice%3A154a5d2a6cc%3Anode9
Obviously change the ip address to the one running OH...
I've done it a couple different ways. BTW, I have this installed on Ubuntu 16.04 LTS.
1) Using HABmin, I put the controller into include mode (using the search glass on the UI), then include the device (triple click on the device's C/F button). After the device shows up in the inbox, I select Add.
2) The Aeon Gen 5 stick also allows you to do the inclusion/exclusion while untethered to the computer. In that scenario, I do the inclusion manually with the stick, then plug the stick back into the USB port. Of course, the port number changes (seems to change between /dev/ttyACM0 and /dev/ttyACM1), so I modify the port using HABmin, after which it picks up the new node.
As for the link you gave me, l get a 404 Not Found. Localized for me, the link is:
http://192.168.10.71:8080/things/zwave%3Adevice%3A154a5d2a6cc%3Anode9
Can you try going to the rest interface then - got to http://192.168.10.71:8080/ http://192.168.10.71:8080/ click on REST API, then go to Things, and click on GET for all and look for this device in the list. I want to see what properties it’s showing as there’s an error in the log that says a property isn’t set, but I can’t see how that’s possible, so just trying to find out what’s set...
REST API does not appear to be starting, and I don't know why. I will need to solve that first...
Well, after spending quite some time trying to find out why the REST API was not working (including doing a from-scratch install on several systems), I realized the URL that I was using (and the one that's used when you select Rest API off the main openhab page) doesn't work (i.e. gives a 404 Not Found).
http://192.168.10.71:8080/things
Then I discovered that this URL is the one that actually works.
http://192.168.10.71:8080/rest/things
At this point, I had a brand new, from-scratch installation of the latest snapshots. When I included the ST814, it included just fine. I have no explanation why it wouldn't include correctly before. Since I can no longer reproduce the problem, I'm going to close this.
Gosh this is really frustrating. It's not like I've never used Z Wave before. I've been using it for years on a different platform (Premise windows app on XP using Leviton VRC0P). The box running Premise died, so I figured this would be a good time for a technology improvement.
My ST814 Temp/Humidity sensor was working well last night. This morning I tried to add an ST812 water sensor to the network. It included, and the node was added, but the identity was never discovered. The node sat in the initializing state for hours. I tried waking up the device manually, restarting OH2, etc.
I also noticed that I was unable to set the wakeup interval and reporting period for the ST814. To more easily test the device, last night using OH1, I had set a very short wakeup interval (5 minutes) and reporting period (1 minute). I tried to change those this morning using OH2, but the changes weren't applied. With such a short wakeup interval, as well as triple clicking the button to wake it up, the config parameter and wakeup interval never were applied, even after many hours.
I shut down OH2, and started up OH1. The ST812 was recognized immediately. Also using OH1, I set a longer wakeup interval and reporting period for the ST814, both of which were set upon receipt of the first WAKEUP command class.
I really don't know what to make of this.
I don't want to reopen this issue, because I really don't know what information to provide to help track down what's going on. It must be something specific to my environment because no one else seems to be having issues like this.
I'm running OH on a relatively old 32-bit industrial (fanless) Atom-based box running Ubuntu 16.04 LTS, while I wait for new hardware. Unless you have any other suggestions. When the new hardware arrives, I'll do a clean install of OH1 and OH2 and then do some more testing.
If you can provide a debug log file I’m happy to take a look.
Did you move your devices close to the Aeon stick? I had similar experiences until I realized that I cannot have them further away than a few meters max. Maybe not at all the same, but might be worth a try.
The devices are within a half meter of the stick during the inclusion process -- for both OH1 and OH2.
And, yes, I certainly can provide a log file. Maybe you will spot something obvious that I'm not picking up on. You will see numerous attempts to include/exclude the node -- node 11, node 12, node 13, node 14. As well as numerous manual wakeups of the device.
Also including the XML for node14. node14.txt
And the JSON for node14 from the rest API. node14-json.txt
Of course, node10 is happily spewing reports every minute filling the log with noise...
The bug is probably this -: https://github.com/openhab/openhab2-addons/issues/819
Currently I'm not sure what this - I'll take a closer look at your log later to see if it helps.
I have the water sensor online, though I have not checked if it is still working in some time... perhaps I should.
If you want to try an older build, they are here but do understand that things have been changing frequently between the binding and the ESH core so I am not sure that an older binding might cause other problems as well.
I just ran my 812 through the paces, turned DEBUG on in the logs, did a wet/dry cycle, and all is well. One comment about this device, I do recall when including it I had to wake it up a lot for it to initialize and write the XML. After that it seems to work just fine. I know you said you waited some hours and tried to wake it up, so try waking it up more? I would first remove the XML (I use this, along with the log file to know the device is initialized properly), do the three presses quick on the button, wait for the light to go out, and repeat that 5-6 times. If that works for the 812, try it on the 814. The log file should have the message that says something like "no more data" when you wake the device up, and the XML file should get re-written. At this point, you should be online.
Additionally, make sure in Habmin2 you have set the association group 1 to the controller if it is not already. See pictures for my config for the 812
Thanks for that feedback and suggestions, @xsnrg.
I did try the manual wakeup multiple times, in addition to the scheduled one. Removing the xml is a good suggestion, and I'll try that along with more manually triggered wakeups.
I will say, however, that in OH1, the detection and configuration happens pretty quickly and consistently.
Once the 814 was configured the other night, it came up with the controller association. I'll make sure to check that if/when the 812 completes the configuration.
Unfortunately, I suspect this won’t help until the bug is fixed since at the moment the thingHandler is crashing...
FYI, I tried adding a new st814, and after three attempts of associating / deleting it worked fine. Seems to be kind of random.
That's pretty much been my experience, @cputoaster After including/excluding mutiple times, it seems to eventually detect properly. But, then, after restarting OH2, sometimes the devices initialize fine to the ONLINE state, other times not.
@cdjackson Any progress on tracking down what's causing ThingHandler to crash?
FYI, I tried adding a new st814, and after three attempts of associating / deleting it worked fine. Seems to be kind of random.
It's unlikely to be "random". Do you have a log? Did you wake up the device or wait for it to wake up?
Any progress on tracking down what's causing ThingHandler to crash?
No - I'm not sure if it's in the zwave binding or in ESH. I can't reproduce it here so it's hard to find unfortunately. Do you still have the issue with a recent build?
Sorry, I got a little side tracked on something else. I'm planning to pull a new build in the next couple days. I'll report back what I learn.
I can attach the whole log since setup of the server, the ST814 is the only sensor I tried adding. openhab.log.zip
I installed the last OH2 and Habmin builds from last night. I added the ST-814 without issue. It took a couple manual wakeups, but it eventually initialized correctly. Then I added the ST-812, also without issue. Again, a couple manual wakeups and all was good. Then I added a SM103 Door/Window sensor. It was on the addition of the SM103 that I got the callback missing exception.
Unfortunately, I was not in debug mode at the time the error occurred. Nonetheless, here's a copy of the log entries. callback-missing-exception.txt
I've also seen a number of these NPEs, unrelated to the issue above. I assume you are aware of this. polling-NPE.txt
@cdjackson
So, I've added several sensors, and things seem pretty stable. :-) So far, I have 4 ST814s, 1 ST812, 1 Hawking HRDS1 (being discovered as an SM103) binary sensor, and one Hawking HRDS1 (being discoverd as an HMS02). I'll be adding some Fibaro sensors and some Leviton switches and dimmers shortly.
I've not seen any more missing callback exceptions other than the one I reported above.
The NPE I mentioned above has not occurred since restarting openhab this morning. It was occurring consistently every 30 minutes.
I do have a few other questions/issues. Would you prefer that I post those as issues on Github, or on the OpenHAB community forum?
BTW, I'm running version 0.1.6 2016-06-05T08:56:54 of Habmin (as reported on the Habmin home page) and a version of openhab pulled on 6/10 (is there an easy way to find the actual openhab build/version number?).
Thanks for all your work on this binding.
I do have a few other questions/issues. Would you prefer that I post those as issues on Github, or on the OpenHAB community forum?
If they are questions, then on the forum, if you’e confident there is a bug, then raise an issue on Github…
BTW, I'm running version 0.1.6 2016-06-05T08:56:54 of Habmin (as reported on the Habmin home page) and a version of openhab pulled on 6/10 (is there an easy way to find the actual openhab build/version number?).
The only way I can think of is to look in the console. I think when you use the list command it lists the version which shows the build date.
I wanted to leave an update on this after several days running with the latest snapshots of OH2 and Habmin.
Aside from one occurrence of the missing callback exception very early on, I have not seen this issue reoccur. I now have running 4 ST814s, 1 ST812, 1 SM103, and 1 HSM02. All were discovered successfully with no more than a few manual wakeups.
Not sure how you want to handle this issue. I know there are others who have commented on this thread. Since I can no longer consistently reproduce the behavior, from my perspective, it could be closed.
I'll close this since it's related to the ST814 and that's working ok. If other problems persist, then we should raise another issue.
Thanks.
It discovers and configures correctly in OH1, but not in OH2, yet there appears to be an entry in the database for it.
Manufacturer, Type, and ID all seem to match up correctly.
DB Entry
Screen snip of entry in OH1
Screen snip of entry in HabMin
XML file from OH2 node9.txt
OH2 log file oh2.txt