2016-11-27 21:57:28.714 [ItemStateChangedEvent ] - Barometer changed from 1027.257 to 1027.266
2016-11-27 21:58:00.080 [ItemCommandEvent ] - Item 'Licht_UG_Fountain' received command OFF
2016-11-27 21:58:28.773 [ItemStateChangedEvent ] - Barometer changed from 1027.266 to 1027.277
2016-11-27 21:59:24.889 [ItemStateChangedEvent ] - FibEye1_Motion_S changed from OFF to ON
Shortly before that I got massive data from node 21:
I’m using this sensor too and got some of problems with it.
While two days ago the sensors worked fine (I’m using 5 of them) now I have the 3rd one which won’t send some or any information.
Maybe first my config which is working:
OH2 1 week old nightly snapshot (don’t know exactly the day and version and don’t know how to check the version)
Z-wave binding: binding-zwave - 2.0.0.SNAPSHOT
here my .items:
/* Auge */
Number Flur_Auge_Lux {channel="zwave:device:5b97d7f6:node6:sensor_luminance"}
Number Flur_Auge_Battery {channel="zwave:device:5b97d7f6:node6:battery-level"}
Number Flur_Auge_Temp {channel="zwave:device:5b97d7f6:node6:sensor_temperature"}
Switch Flur_Auge_Binary {channel="zwave:device:5b97d7f6:node6:sensor_binary"}
Switch Flur_Auge_Alarm {channel="zwave:device:5b97d7f6:node6:alarm_general"}
Number Flur_Auge_Seismic {channel="zwave:device:5b97d7f6:node6:sensor_seismicintensity"}
Switch Flur_Auge_Burglar {channel="zwave:device:5b97d7f6:node6:alarm_burglar"}
Actually I used successfully the lux, battery and temp values,
and for light-on-when-movement I used the burglar alarm.
Here some screenshots of PaperUI and Habmin
As I wrote: all went fine. Besides of that one of the eyes did’t show some values (lux and temp) so I began excluding and re-including.
I did this two times or so because I’ve read that some people just included the eyes with success while doing this several times.
But then: the burglar alarm didn’t work anymore. I testet several times, excluding and reincluding but nothing, burglar alarm seems to be dead. So I guessed it’s a defect and yesterday I wrote to the seller for an refund.
But today I made some more testings with the oder eyes and now - two more lost the burglar alarm.
I have no idea why but the two left which are running well aren’t excluded and included several times, they just working.
Is there any function in OH zu reset all the z-wave settings and configs?
I just deleted the node .xml files but this didn’t any affect (searching for new devices at PaperUI still shows the eye which is already packed for refund without battery…)
During this initialisation it should have updated the channel - eg -:
2016-11-27 21:52:37.730 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 21: Updating channel state zwave:device:1587db82cfc:node21:sensor_binary2 to ON [OnOffType]
So, I don’t know how to solve this. If the device doesn’t send the two different inputs with some way to tell them apart (ie using multi-channel) then I don’t know how we can process it. Maybe there’s a setting, or maybe it requires the multi-channel-association to trigger multi-channel messages (some new devices do this, but I’ve not seen it in any Fibaro devices yet).
and there is still a message in the database which I cannot understand:
Could this be a point where we can make the device work under openHAB2?
Btw, meanwhile I can see (in openHAB2) the switches on the sitemap changing their state according to the input, but still nothing in the event.log.
This simply means that none of the groups have the ‘controller’ box ticked. This means that the binding won’t automatically configure the device to send messages to the controller…
It looks like the missing link might be group 3… Do you want to add it?
Well, that’s strange. I very rarely look at the event log, but if the items are changing state (as seen in the sitemap) then I’ve no idea why the event log wouldn’t log the change. It’s outside of the binding though - the binding just sends channel updates - the framework updates the items…
I’ve just done that manually. Or is it better to upload a “fresh” xml file? Before we started changing the entries for this device it had not been touched for about six month.
Also the device is able to send scene numbers for the scene activation command class which isn’t reflected in the database yet.
Manual is fine - uploading a new XML won’t work - the database ignores XMLs once there’s a certain amount of configuration done to avoid someone loading the wrong file and making a mess ;).
Short story:
The device is working, thanks a lot for your support!!!
I have a warning in the logs
2016-12-10 08:04:08.920 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 23: CommandClass BASIC (0x20) not implemented by endpoint 1, fallback to main node.
2016-12-10 08:04:14.122 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 23: CommandClass BASIC (0x20) not implemented by endpoint 2, fallback to main node.
but actually I don’t care because it’s working without any problems
Newly added scene numbers are also working as expected:
2016-12-07 08:42:52.484 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 21 to 10
2016-12-07 08:42:54.018 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 10 to 11
2016-12-07 08:44:10.132 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 11 to 20
2016-12-07 08:44:10.387 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 20 to 21
Long story:
as I stated earlier I bought a new device because after migrating to openHAB2 I couldn’t get it to work (and because I had accidentally switched the power plus and minus for a few seconds I thought it is broken).
Most of the testing in this thread was done with this new device … and after a couple of days it turned out that the NEW device is not functioning properly (will get a free replacement today).
As soon as I switched back to the old device everything started working … so I cannot tell which of the database changes made the device working.
Thanks again for your neverending support on this binding
Just to be clear, you’re running a recent version and have deleted and re-added the thing since we made the changes to the DB? This was one of the changes I made to the database so I wouldn’t have expected these errors…
If you can provide the debug log showing the frame received it might be useful as I don’t think this warning should be occurring.
Can you also post the XML. I’m guessing it’s probably the same as the previous ones, but since you said you changed to an older version I just want to check. The XMLs above show that the binding has the BASIC class in these endpoints, so I’d expect this to work
Hmmm - thanks. For some reason then, this version of the XML doesn’t show the BASIC class in the endpoints. This explains why there’s an error, but why is it different to the previous versions of the XMLs you posted here ?!?!?
If you don’t mind, can you delete the XML and get a log of this device during startup (ie a complete log of the initialisation).
I’m handling this a bit different in the new version, so this won’t be a problem, but just interested to see what’s happening if you don’t mind. If you’re happy to leave this, then it should go away in future anyway…
openHAB2 is still a beta snapshot, so we should all be willing to test it as much we can (although I must admit I’m using it already as a “daily driver” because it’s pretty stable already)
2nd Edit: and yes, it’s still working after reinit:
2016-12-10 17:56:44.941 [ItemStateChangedEvent ] - FibUniSens1_1 changed from OFF to ON
2016-12-10 17:56:44.963 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 11 to 10
2016-12-10 17:56:46.859 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 10 to 11
2016-12-10 17:56:47.014 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 11 to 10
2016-12-10 17:56:48.499 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 10 to 11
2016-12-10 17:56:48.604 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 11 to 10
2016-12-10 17:56:50.348 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 10 to 11
2016-12-10 17:57:05.359 [ItemStateChangedEvent ] - FibUniSens1_1 changed from ON to OFF
I don’t get it: the warning message disappeared.
Sometimes I’m really lost in the jungle of openHAB debug log files … (not only for zwave).
I’m sure I did delete the device as thing and re-added it with the currently used snapshot. I did not do a re-initialization or deleted the xml file though.
Is that what I should have done after the database update?
If yes, sorry, my mistake …
This shouldn’t be needed (I think!). I think that the XML should be deleted when you remove the thing, although I’m not 100% sure.
Anyway, I don’t think that’s the issue here since the BASIC class was missing from the device endpoints. This probably means that there was some sort of error when the binding interrogated the device. I’ll take a look at your log to see if I can see where this gets defined, but in the upcoming version of the binding, this is done differently anyway as BASIC should always be included, and it’s not mandatory for a device to report that it’s supported.