I deleted it from the Things section, added it again.
I tried to reinitialize, no xml file is created.
I excluded it, did a hardware reset, included it again. Nothing
I bought a new device (!), tried to include it … no xml file created.
openHAB2 Snapshot Build #594 from today, zwave binding 20161118
Device was already on the stick, included in openHAB1.
Please provide an unfiltered log. If you filter it to just this node, then we loose all the receive data messages which don’t have the node number listed as we don’t know this until much later…
From what I see though, the device probably doesn’t support the ALARM_SUPPORTED_GET message, so we can easily update the database to solve this if it’s the case.
Unfortunately not.
I grabbed the latest openHAB2 snapshot #603 from this morning, zwave binding is now 2.0.0.201611201812
FGBS001 Fibaro Universal Sensor node number is now 21.
Excluded the device from the controller, hard resetted it, included it again:
Still no xml file is created.
In Habmin under “Things” the screen shows a green node with “Node initialising: STATIC_VALUES” and there it stops.
I grabbed the latest zwave snapshot binding and the xml file was created instantly:
BUT: I still don’t get any commands from the device.
I linked items to all four channels (sensor_binary and sensor_alarm) and I can see they get added in the events.log, but if I physically trigger the input there is no command change.
Could it have something to do with those three messages in the device database?:
There are 2 association groups but none are linked to the controller. Is this correct?
Endpoint 1 has no command class linked to the basic class.
Endpoint 2 has no command class linked to the basic class.
Sorry - it was a very long week at work (unfortunately week of the same another next week ) and when I get home I’ve been trying to finish off the security classes…
Anyway, I’ve just updated the database so I’ll merge this tonight. Let’s see if it helps.
Sorry to hear, hopefully that earns a lot of money in your pocket
Thanks a lot for updating the device, will try as soon as it makes it into the binding.
Maybe I just make a dumb mistake because I assume I’m not the only one who is using the FGBS001 with openHAB2.
I know you have a busy week so I will patiently wait until you get into this.
What I did:
installed new zwave binding version: 2.0.0.201611270958
reinitialized the device
deleted device from things
added it again
added links to all four channels (sensor_binary, alarm_general)
→ did not work
added controller to association groups 1 and 2
→ did not work
changed config para 5 (Type of transmitted control frame for association group 1) to basic set and config para 6 (same for association group 2) to alarm generic
→ did not work
All was done with debug enabled, log can be found here (node21):
The alarms don’t seem to be encapsulated in multi-channel, and as there’s no channels in the root, they won’t do anything -:
I don’t know if this should be sending these alarms in multi-channel encap?
What do you think it’s meant to send? eg if you press a button (or whatever is linked to the input) what do you think should happen? Should alarms be sent to the endpoint, or the root device. I’m not sure if you’ve looked at the log yourself in the viewer, but a lot of stuff is sent to the root…
In the “old days” of openHAB1 that sensor worked as a contact for sensor_binary EP1 and EP2 Contact FibUniSens1_1 "Contact [%s]" { zwave="5:1:command=SENSOR_BINARY,respond_to_basic=TRUE" }
My assumption was that in openHAB2 it should work as a switch for sensor_binary EP1 and EP2.
So I defined it as:
Ok - so these two channels still look like they are being sent. sensor_binary channel is however defined as a switch (as you correctly assumed ).
Strange - the binding says it is sending the state to ON / OFF for these channels . HABmin seems to think the channels are linked to items - are you sure the items are switches (sorry - I’m sure you are, but just double checking as everything seems to be working with these channels - except for the ‘small’ point that they don’t seem to actually work!)