It isn’t now anymore because you don’t have any endpoint 0 channels available 
According to your debug log you don’t get state updates for your FGS211:
I would double check the association group for the controller: for the FGS211 it is group 3, not group 1 like usual.
It seems correct… I do have what seems to be a general issue where the UI normally looks like it’s unset (it shows “Search”) although in this case it did show as “Controller” when I went to the edit page.
My last idea: set the correct controller group again via HABmin, not PaperUI.
Experiencing exactly this issue, did you get it resolved @evans_jon ?
Might there be a bug to report if not ?
This is really not a helpful description of your problem - please provide more information about your system, logs, problem, etc.
Sorry. Thought it made sense from threadmaker and my link. Here we go.
Hardware:
MacMini model A1347
Aeotech Z-Stick GEN 5 model: ZW090-C (868,42MHz)
Fibaro Relay switch FGS211 v2-1
20+ other z-wave devices including one batterypowered FGMS.
RFXtrx433E - via USB
Software:
Ubuntu 18.04.2 LTS
Openhab2 2.4.0
Z-Wave binding 2.4
One of my FGS211 is wired like this: Analouge (?) dusk-to-dawn sensor wired via an electric relay to S1 on FGS211 Node 24 and a lightbulb connected to output of this node 24.
When dusk sensor triggers the S1 closes on Node 24 and the lightbulb lits. The FGS211 Node 24 is not updating its state to openhab. It only does this:
These are my settings as far as associations matter:
And my mesh lookes like this:
DEBUG log when S1 closes as seen above in z-wave log viewer (either by dusk sensor or manually with physical switch):
2019-09-24 17:14:47.860 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-09-24 17:14:47.861 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: Application Command Request (ALIVE:DONE)
2019-09-24 17:14:47.861 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 3: resetResendCount initComplete=true isDead=false
2019-09-24 17:14:47.861 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 3: Incoming command class COMMAND_CLASS_SWITCH_BINARY, endpoint 0
2019-09-24 17:14:47.862 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 3: SECURITY not supported
2019-09-24 17:14:47.862 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 3: Received COMMAND_CLASS_SWITCH_BINARY V1 SWITCH_BINARY_REPORT
2019-09-24 17:14:47.862 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 3: Switch Binary report, value = 255
2019-09-24 17:14:47.863 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2019-09-24 17:14:47.863 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SWITCH_BINARY, value = 255
2019-09-24 17:14:47.863 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: Commands processed 1.
2019-09-24 17:14:47.864 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@5d13aaa6.
2019-09-24 17:14:47.864 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-09-24 17:14:47.864 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-09-24 17:14:47.865 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-09-24 17:14:47.865 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
Steps performed:
- Restart and reboot several times
- Exclusion and inclusion of z-wave devices
- Set and re-set Controller as lifeline in group 3 of the FGS211 associations
- Heal individual nodes
- Heal whole network
- Moved around Controller in house for range issues
- Debug with logs
Lately in my investigation I’ve discovered that all of my 4 or 5 FGS211 behaves the same. Not reporting its status to controller.
It does though update the Items state when performing poll. My item looks like this (where X is my controller ID:
Switch SW_GARAGE_SKYMNING_1 "Switch1 Skymning" <garage_detached> (Switches) { channel="zwave:device:XXXXXXX:node3:switch_binary1" }
My strong suggestion is to update to a newer binding. 2.4 is now pretty old, and it doesn’t handle some incorrectly formatted commands that can come from the UI. This can lead to associations getting removed and nodes not reporting state to the controller. If the devices aren’t reporting state, it is almost certainly because the associations are not correctly set.
However I’m also a bit confused about what you are trying to do. It looks from the log image that node 24 is sending an event - I’m not sure how this relates to node 3 that you have then shown further down?
Sorry for that, Node 24 was Node 3 before exclusion/inclusion so the textual log is “older” than my image.
I will go about updating the binding. Thankyou!
Ok, understood.
The device is not sending the multi-instance command so the binding isn’t picking up on this. Again, the newer binding may resolve this so let’s see if things improve when you update, and if not we can look at it again then.
You might need to exclude and re-include the device to get it reconfigured completely - otherwise it may not configure for the multi-instance configuration.
Ok, now running:
OpenHAB 2.5.0-SNAPSHOT (#1700)
binding-zwave - 2.5.0.SNAPSHOT
Followed all your steps here ZWave binding updates
Removed all things except controller and then re-added all things from inbox. Found out that these FGS211 behaved like before. Excluded one of them and re-included. Healed it but still reports like noted before without updating state to Openhab.
Have scheduled a network heal for about 45 min from now. Let’s see if that helps, otherwise I think I have followed the steps you wanted me to ?
Now the network has healed and is all green. Looks like it has the same behaviour though.
Not updating state (this is when physically pressing the switch):
2019-09-26 21:53:53.945 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 19 03 25 03 00 CE
2019-09-26 21:53:53.946 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=25, callback=0, payload=00 19 03 25 03 00
2019-09-26 21:53:53.947 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=25, callback=0, payload=00 19 03 25 03 00
2019-09-26 21:53:53.947 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-09-26 21:53:53.948 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Application Command Request (ALIVE:DONE)
2019-09-26 21:53:53.948 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 25: resetResendCount initComplete=true isDead=false
2019-09-26 21:53:53.948 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 25: Incoming command class COMMAND_CLASS_SWITCH_BINARY, endpoint 0
2019-09-26 21:53:53.949 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 25: SECURITY not supported
2019-09-26 21:53:53.949 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 25: Received COMMAND_CLASS_SWITCH_BINARY V1 SWITCH_BINARY_REPORT
2019-09-26 21:53:53.949 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 25: Switch Binary report, value = 0
2019-09-26 21:53:53.950 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2019-09-26 21:53:53.950 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SWITCH_BINARY, value=0
2019-09-26 21:53:53.950 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Commands processed 1.
2019-09-26 21:53:53.951 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 25: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@219b09fe.
2019-09-26 21:53:53.951 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-09-26 21:53:53.951 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-09-26 21:53:53.951 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-09-26 21:53:53.952 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
Is this now a classic switch or still your dusk/dawn sensor?
I’m not sure why thi device isn’t sending the encapsulated commands - it will never work if it doesn’t do this. Unfortunately this is a VERY messy area of ZWave as there are something like 7 significantly different versions of command classes relating to associations, and due to the fluidity in the specifications over the past couple of years, there are many devices that also do things differently to these.
Can you please provide a log of the initialisation of this device so I can see what the binding is doing, and what versions of command classes are being used.
We can disregard the dusk sensor now since I discovered that this behaviour applies to all my FGS211. Also the ones connected to classical switches.
I see why it’s not working. The binding is not using multi-channel associations to set this configuration since the device is only reporting it supports 2 association groups in multi-channel mode. The binding therefore uses the older command class to set the association for group 3, and probably that means the device doesn’t send multi-channel encap reports.
I could try and force the binding to use the MC mode, but if the device reports it’s unsupported, then this will fail. In older Fibaro devices they always sent MC encapsulated commands. With the changes to the way associations work, I guess that this is now configured by using the MC association command as per the standard, but they are supporting V1 of this class so my guess is it could be buggy as there were a lot of changes happening around this time.
Thankyou for your reply and time! I’m not at that level to understand all of your post. I can tell you that my log was created by runnint “re-initialize” the node if that changes anything ?
If you have some solution it would of course be greatly appreciated and I’ll be happy to test it. A note is that when using Domoticz before I can not recall having this issue if it helps you.
After a whole lot of trouble updating, switching between versions, stable/testing/snapshot and probably messing something up along the way I wiped the Openhab2 installation tonight and reinstalled using 2.5.0.M5 and ZWave binding 2.5.0.M5.
The FGS211 is now updating its status to the controller instantly on channel switch_binary
Association group 3, “Controller update” is set to “Controller” as it should be.
On switch_binary1 and switch_binary2 it is not updating though.
I’m happy!
1 Like