OK, will do! I’ll restart logging from scratch, and raise the ticket tomorrow morning!
Cheers
Thanks.
Hi chris,
Does this mean, that the new device database with my devolo humidity sensor will only available in this testing branch? Or is it possible to create an build from the 2.1 branch with the new device?
Regards, Michi
No - the database gets updated into the master branch, and changes are still made to fix bugs in the master branch - this question was simply asking when the new branch will be merged into the master.
I can’t for the life of me get my Schlage be469 included, is there a trick? High power inclusion? Do I add the thing before inclusion is done? The one close success I had it was included but errors out on updating the node neighbors. Should I wait until the system is more stable, the are a lot of unknown nodes for battery devices on my system (I have about 60 devices and fully adding them again will take time after having to delete them all to upgrade.
I have it off the door and within a couple of feet and I exclude it and reset it after each failed attempt.
Maybe the system is too congested, would it maybe be a good idea for the binding to stop heals and initialisations when including?
With my be369 I had to unplug the aeon stick and manually exclude from it. Then re include from habmin watching for the secure inclusion complete tag.
@chris Hoping you can help troubleshoot. Yesterday morning I woke up to 1/2 my nodes not working (physically located on the far 1/2 the house from the controller. Viewing the network in Zwave viewer didn’t show anything off line. I did multiple updates to OH and the Zwave binding (to make sure I had the latest) the last 2 days but now all the nodes I was having issues with yesterday are locked in "Node Initializing: Request_NIF " I’ve tried reboots, clearing the cache and multiple restarts.
Here is a debug of a startup - https://drive.google.com/open?id=0B77VHtwPft8eN3RlRmpwR2I4Mk0
Any ideas on what might be causing this and how to get it to pick up these nodes again?
Thanks.
Edit: I replaced the batteries in my lock that is in that general proximity and things are coming back so maybe the low batteries were impacting the network
@chris, on latest snapshot and your development I have problem with Zipato RGWB bulb.
The color_temperature is not working and I’m stuck at “0” which means cold white.
I can send commands to color_temperature and it seems it accepts it, but nothing happens.
Color and dimming works on other channels.
LOGS and node xml here: https://www.dropbox.com/s/40duv21chebsoek/zipato.rar?dl=0
EDIT:
Items file
// ZIPATO
Color Zipato1RGBWColor "zipRGBW Color" (gZipato1RGBW,All) {channel="zwave:device:e25d115d:node18:color_color", mqtt="<xxxxxxxxx/value:command:default], >[xxxxxxxx/state:state:*:${state}]" }
Dimmer Zipato1RGBWDimmer "zipRGBW dimmer [%d %%]" (gZipato1RGBW,All) {channel="zwave:device:e25d115d:node18:switch_dimmer", mqtt="<[xxxxxxxxxx/value:command:default], >[xxxxxxxx/state:state:*:${state}]" }
Dimmer Zipato1RGBWWhite "zipRGBW white dimmer [%d %%]" (gZipato1RGBW,All) {channel="zwave:device:e25d115d:node18:color_temperature", mqtt="<[xxxxxxxxx/value:command:default], >[xxxxxxxxxxx/state:state:*:${state}]" }
@chris I also have problem with fibaro smokedetectors that I have never got to work with smoke.
Temperature and tamper works fine.
With latest snapshot and your development bidning, logs and xml are here:
Here is items:
Switch Fibaro1SmokeDectSmoke "Corridor Smoke Dect [%s]" (ZWave, gSmokeDetector) {channel="zwave:device:e25d115d:node14:alarm_smoke" }
Switch Fibaro1SmokeDectHeat "Corridor Heat Dect [%s]" (ZWave, gSmokeDetector) {channel="zwave:device:e25d115d:node14:alarm_heat" }
Switch Fibaro1SmokeDectTamper "Corridor Smoke Dect Tamper [%s]" (ZWave, gSmokeDetector) {channel="zwave:device:e25d115d:node14:alarm_tamper" }
Number Fibaro1SmokeDectBattery "Corridor Smoke Dect Battery level [%d %%]" <battery> (ZWave, gSmokeDetector) {channel="zwave:device:e25d115d:node14:battery-level", mqtt=">[xxxxxxxxxxxxxxxx/state:state:*:${state}]" }
Number Fibaro1SmokeDectTemp "Corridor Smoke Dect Temp [%.1f °C]" (ZWave, gSmokeDetector) {channel="zwave:device:e25d115d:node14:sensor_temperature", mqtt=">[xxxxxxxxxxxxxxx/state:state:*:${state}]" }
Edit:
Association groups:
1 Device Status: Openhab Controller
2 smoke Alarm: Openhab Controller
3
4 Fire Alarm: Openhab Controller
5 Tamper Alarm: Openhab Controller
I tried reading on your website for device info and it says in device listing that Group 1 and controller YES while all the others say NO.
I tried only add to group 1, but now it doesn’t even send SENSOR_ALARM_REPORT SMOKE=255
Still temperature/tamper works…
That’s correct. Normally the lifeline will send all required reports.
Normally the lifeline group (group 1) will only allow a single device - so you won’t be able to add to it.
So you mean it used to work, and now it doesn’t? This sounds like the device is not configured rather than it being a binding issue.
Currently I can’t view your files as I don’t have a RAR viewer. In future please just post raw logs, or if you really need to compress them, please use ZIP.
I had a look in the log - I guess node 41 is your lock? It’s reporting low battery in the log. Other than that there’s nothing too obviously wrong. If fixing the lock has resolved things, then this might point to the lock being a bit of a single point bottlekneck in your network though?
@Chris, sorry about RAR file 
Zipato bulb xml:
Zipato bulb Logfile:
Zipato bulb events:
Fibaro smoke detector xml:
Fibaro smoke detector log:
Fibaro smoke detector event:
When I have added the fibaro smoke detector to all association groups, it will send Sensor alarm report smoke =255.
But it will not send a STATE UPDATE for it.
I do not know how it works, but I figure it has to send a state update for OH to understand it is “on”.
You will see it in the logs in the bottom.
Thanks for taking a look!
So there are no smoke notifications listed in this log, I would hazard a guess that there’s a setting you’ve changed to disable this. You need to make sure that events are configured to use notifications and not the sensor alarm.
I think the lock was saturating my network. I had a couple of leftover Vera connected ZWave devices in the same general vicinity and they came back online after I replaced the batteries also.
Something is definitely going on with that lock (it’s Node 49. Node 41 is the door sensor I’ve also been having the fun with earlier on getting it to stay part of the system).
I started experiencing the same issue today. I pulled the batteries out of the lock and everything started responding again. Should I uninstall/reinstall it or is there something else I can do to resolve?
Thanks,
Edit: And it appears to be the lock over broadcasting vs. a bottleneck since it’s taking out one of my Vera connected devices too
@chris: Is there any new version of the development branch ahead? As far as I can see there has been no update since April 23rd. There are several issues like Java exceptions that made me change back to the snapshot branch. Unfortunately both branches have their issues, but as far as I understood the development branch will be the future?
I think there is a large issue with the latest snapshot of the binding @chris. I made the foolish move of just updating the current one with this one, and now have to go dig for backups which will have the previous snapshot version.
It seems right now, this is loading in as a ZigBee binding, not ZWave. I validated by removing the binding from the addons folder, and bundle:list in Karaf, is showing the ZigBee binding (which I never installed) is no longer installed. Not sure what inside this is referenced incorrectly, or if there was a mixup on your site with the binding and it’s associated name.
Ooops - error copying the files - should be sorted now I hope.
Thanks for the quick fix. Sadly I just finished restoring! haha. But I backed up this time and validated, all good now.
how many times did that take?