Sorry for the slow responses - the hotels the past couple of nights have had limited internet (next to none!)
You shouldn’t need to delete the xml - I’m not sure of the best way to ensure this is included - it should ignore the 255 responses but I’ve not added any logging or anything. Unfortunately I can’t check that cloudbees built correctly after the change at the moment. If you can grab a log I’ll take a look - I’m not sure it will be tonight though unless I can get my Mac onto the internet at this hotel…
I updated again yesterday (there was a new binding version available). Also I deleted xml and thing and re-added it. After three manual wakeups, the devices were initialized and the xml were created.
And good news: There wasn’t any alarm triggered during the regular wakeup.
During all this, I made a DEBUG log. Don’t know if you want to have a look at it anyway.
I monitored this closely the last two days. No further alarm was triggered. So my theory at the moment is (I have no better one… ): After each restart of the binding (reboot, update, etc.), only the first wakeup of the device triggers an alarm.
@chris: Do you think this is possible? Do you have another theory? Or even better: A solution?
I think I’m having the same issue as you. I purchased three Fibaro smoke detectors a few weeks ago.
I set them up and everything seemed okay. Then after an upgrade they started to show alarms in the openhab gui. Heat alrm, smoke alarm etc. But no effects in the real life such as sound or other indication.
I’ll try to confirm your theory about the first wakeup being the one that falsely triggers the alarms. I’ll try to get a debug log also.
My nodes are due to wake up in 1 to 2 hours.
I have restarted my system now and set karaf in DEBUG mode. Will see what comes out in the morning.
I’ll try and look at this more over the coming days - I’m flying back to the UK from India in an hour or so so will be in a better position to support ;).
Sorry for you, but good to hear that someone else has similar problems. I’ve only linked the smoke and heat alarm channel, so I don’t know if the other alarm channels also trigger an alarm. But it is most likely I think…
Yes, this clearly doesn’t come from the devices.
After the false alarms, I manually set the items back to no alarm state (through PaperUI or Karaf console, doesn’t matter). And then no further alarm is triggered. Until I restart or upgrade openhab.
After the night’s past I’ve gone into the logs and looked. I’m not sure my smoke detectors give off on the first wake up but instead on the second.
Before the restart last night of my openhab I took a note of the last wake up times of each of my three smoke detectors. Then I did an estimate of coming wake up times and put it in a little spreadsheet.
And now after reviewing the result it looks like my alarms go off on the second wakeup. This is after looking in the events file and seeing the trigger times there.
Regarding first/second wakeup. This could easily be also the same for me. Until now I only assumed that it’s the first wake-up, as the second indeed has made even less sense for me. I didn’t do a research like you but my feelings do tell me: You could be right…
@ErikAhl can you email me the logs zipped up (chris -at- cd-jackson.com). I don’t seem to be able to download them properly - maybe it’s very large or something and Github seems to be falling over with downloading it as text in the browser.
@chris thanks. I emailed the logs now. Yes they take up some space don’t they.
Whish there was an easy way to perhaps filter out stuff that’s not interesting. Like in this case the data for all other nodes might not be needed.
I spent a bit of time tonight looking at the logs from @ErikAhl. I think it’s likely that I don’t understand exactly how the responses work and I’ll clarify this with Sigma. I’ll provide an updated binding (just a database update) tonight if I can get the database processed - I think it will solve the smoke alarm issue as it should filter out some alarms linked to testing that are currently being detected as smoke alarm.
However, I’m a little bit confused how to get this update. Maybe you can help. Since the release of OH 2.0, we now have three different versions (stable, unstable, testing). What does this mean for the zwave binding? Do you also maintain three binding versions now? If so, what happens when you update your binding? Do you have to decide for which version you do the update?
I have switched (as probably many others) from snapshot to 2.0 stable recently and I am not sure that I get all the latest changes of the zwave binding simply with an apt-get update/upgrade.
At the moment, I’m updating the snapshot version - basically, by default everything is merged into the master branch and this is used to create snapshots.
There is a 2.0.x branch which Kai added to address my concerns about this sort of thing - I’m not sure if it’s only built periodically, or if I merge commits into that branch if they will be available in the release version. However, I wouldn’t be merging lots of commits into this branch for fear of breaking the release version. The release should be a fixed version so it doesn’t benefit from continual updates like the snapshot. Critical bugs, and database updates would generally be the only thing I’d look to merge across.
Otherwise, to run the snapshot version of the binding with the release version of the runtime, you’d need to install the zwave binding manually.
Yeah, probably. But easier said than done. With PaperUI, this can’t be achieved. Even on the Karaf console I only get the two standard versions of the binding offered:
): After each restart of the binding (reboot, update, etc.), only the first wakeup of the device triggers an alarm.
I’ve only linked the smoke and heat alarm channel, so I don’t know if the other alarm channels also trigger an alarm. But it is most likely I think…