- Please remember the “preformatted text” hint and edit your post above.
- I would paste the complete log to pastebin or https://gist.github.com/ or whatever you prefer and reference it here.
Then we need to wait for Chris to take a look at this, I have no idea whats wrong …
These are the logs that I recorded in debug mode from karaf.
They are devided up per type of action I was doing as the log entries went outside of the karaf window after a while, I noticed this in a first attempt so I copied all the logs after each step I did.
-
Deleting the node (device)
https://gist.github.com/anonymous/49bd87e540de7b05c7f6c512cb77b317 -
Inclusion of the device back into the openhab zwave network
https://gist.github.com/anonymous/bfaca03145a8293922df8c8969df54d4 -
Pressing the add button in habmin after inclusion was finished
https://gist.github.com/anonymous/0a554a989ee9350ba6e89d8f172b103c -
Manually opening the door sensor to see what would happen after doing multiple awakenings
https://gist.github.com/anonymous/95b8422e972b81109c9c70bde68524aa -
Added two items, binary switch and door contact
https://gist.github.com/anonymous/31ec5b6a480a255f29ff5eff930219b2 -
Manually opening the door to test results
https://gist.github.com/anonymous/315502397e1d4607f8e0d894fda6b07f
Great, should be a good starting point for chris whenever he is available again.
1 Like
@chris I’m flagging you in this post as well. I guess since you might be making an update to the zwave binding due to the issue with the smoke sensors maybe this can be put in at the same time. 
Now I am facing the same problem.
Did anyone solve his problems in the meantime? Can someone give me some advice?
Like you can see above in post 3 I have a FGK101 which works well and shows status open/closed.
2017-02-15 20:03:19.685 [ItemStateChangedEvent ] - N04FibaroDoorSensorFGK101Garage_DoorSensor changed from OPEN to CLOSED
Now I bought new FGK101 and to me it looks like all off them are included well.
They show battery level and other items.
But they don’t change status from closed to open.
I guess I got the latest binding but I get this error messages:
2017-02-15 20:04:44.724 [ERROR] [class.ZWaveMultiInstanceCommandClass] - NODE 12: Endpoint 0 not found. Cannot set command classes.
2017-02-15 20:05:12.886 [ERROR] [class.ZWaveMultiInstanceCommandClass] - NODE 13: Endpoint 0 not found. Cannot set command classes.
2017-02-15 20:08:19.559 [ERROR] [class.ZWaveMultiInstanceCommandClass] - NODE 14: Endpoint 0 not found. Cannot set command classes.
In HABmin device configuration I can’t see any difference between the good and bad FGK101 devices and they all have the same firmware 3.2.
Screenshot of bad device
I’m on openHAB2
I would do the following:
– Set the zwave traces to DEBUG and check if there is communication between the sensor and then main controller when you wake up the device
– Try opening / closing door to see if there are any messages sent back and forth
– Delete the channel association and recreate it
– Delete the sensor from openhab via habadmin. It will not remove the sensor from the zwave network but only from openhab. You can add it back in and normally it will keep all the channel configuration
– Try resetting the sensor. From the fibaro manual
Resetting the Door/Window Sensor
Reset procedure deletes EEPROM’s memory, including all information
on the Z-Wave network and the main controller.
1. Open the cover.
2. Remove the battery.
3. Install the battery while holding both TMP buttons.
4. Release the TMP button within 5 seconds.
5. Visual indicator will blink 3 times to confirm launching of reset
procedure.
6. Wait around 30s for the resetting process to end, do not remove
the battery.
7. Visual LED indicator will blink 6 times to confirm the reset.
I was troubleshooting a fibaro motion sensor who had been constantly ON for some reason and did all the above. The reset had finally fixed the issue. The side effect was that when I added it back it got a higher node ID in the zwave network while it kept also the old ID (ghost ID). Good news is that I removed the ghost device by using zensys tools and this post
Hope this helps
Christos
2 Likes
Hi Christos,
I just have seen your answer. Thanks for your advice.
I will try that later, when I’m back home.
Edit: I did as you recommended, but I can’t get FGK101 work, neverless it shows batterylevel and status closed.
The sensor don’t change items, when opening or closing the door.
Yes, there is communication when waking up the device. (NODE 12)
13:46:23.663 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 1D 00 49 84 0C 17 04 07 01 5E 85 59 22 20 80 70 56 5A 7A 72 8E 71 73 98 2B 9C 30 86 84 D3
13:46:23.689 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
13:46:23.697 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 1D 00 49 84 0C 17 04 07 01 5E 85 59 22 20 80 70 56 5A 7A 72 8E 71 73 98 2B 9C 30 86 84 D3
13:46:23.704 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 1D 00 49 84 0C 17 04 07 01 5E 85 59 22 20 80 70 56 5A 7A 72 8E 71 73 98 2B 9C 30 86 84 D3
13:46:23.711 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 0C 17 04 07 01 5E 85 59 22 20 80 70 56 5A 7A 72 8E 71 73 98 2B 9C 30 86 84
13:46:23.712 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 12: Application update request. Node information received.
13:46:23.713 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 12: Starting initialisation from DONE
13:46:23.714 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@d87106 already registered
13:46:23.715 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 12: Is awake with 0 messages in the wake-up queue.
13:46:23.716 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveWakeUpEvent
13:46:23.716 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Got an event from Z-Wave network: ZWaveWakeUpEvent
13:46:23.720 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=12, callback=182, payload=0C 02 84 08
13:46:23.726 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 0C 17 04 07 01 5E 85 59 22 20 80 70 56 5A 7A 72 8E 71 73 98 2B 9C 30 86 84
13:46:23.728 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationUpdate, callback id=182, expected=SendData, cancelled=false MISMATCH
13:46:24.719 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 12: No more messages, go back to sleep
13:46:24.720 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 12: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
13:46:24.722 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
13:46:24.722 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
13:46:24.725 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 0C 02 84 08 25 B7 F5
13:46:24.727 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 12: Sending REQUEST Message = 01 09 00 13 0C 02 84 08 25 B7 F5
13:46:24.738 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
13:46:24.769 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
13:46:24.784 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
13:46:24.786 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
13:46:24.786 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 B7 00 00 02 5E
13:46:24.788 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
13:46:24.789 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 12: Sent Data successfully placed on stack.
13:46:24.809 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
13:46:24.812 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 B7 00 00 02 00 00 50
13:46:24.814 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 B7 00 00 02 00 00 50
13:46:24.816 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=B7 00 00 02
13:46:24.817 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 12: SendData Request. CallBack ID = 183, Status = Transmission complete and ACK received(0)
13:46:24.818 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 12: Starting initialisation from DONE
13:46:24.819 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@d87106 already registered
13:46:24.821 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=12, callback=183, payload=0C 02 84 08
13:46:24.823 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=B7 00 00 02
13:46:24.825 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=183, expected=SendData, cancelled=false transaction complete!
13:46:24.825 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
13:46:24.827 [DEBUG] [curityCommandClassWithInitialization] - NODE 12: updating lastSentMessageTimestamp
13:46:24.827 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 12: Went to sleep
13:46:24.828 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 12: Is sleeping
13:46:24.830 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
13:46:24.831 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 12: Response processed after 82ms/3902ms.
And also when open/close the door (see ERROR: NODE 12: Endpoint 0 not found. Cannot set command classes.)
13:50:31.016 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 13 00 04 00 0C 0D 60 0D 00 00 71 05 00 00 00 FF 06 16 00 1F
13:50:31.039 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
13:50:31.042 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 13 00 04 00 0C 0D 60 0D 00 00 71 05 00 00 00 FF 06 16 00 1F
13:50:31.044 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 13 00 04 00 0C 0D 60 0D 00 00 71 05 00 00 00 FF 06 16 00 1F
13:50:31.046 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0C 0D 60 0D 00 00 71 05 00 00 00 FF 06 16 00
13:50:31.047 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 12: Application Command Request (ALIVE:DONE)
13:50:31.048 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 12: Starting initialisation from DONE
13:50:31.049 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@d87106 already registered
13:50:31.050 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 12: Incoming command class MULTI_INSTANCE
13:50:31.050 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 12: Received MULTI_INSTANCE command V0
13:50:31.051 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 12: Requested Command Class = ALARM (0x71)
13:50:31.052 [ERROR] [class.ZWaveMultiInstanceCommandClass] - NODE 12: Endpoint 0 not found. Cannot set command classes.
13:50:31.053 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=12, callback=186, payload=0C 02 84 08
13:50:31.056 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0C 0D 60 0D 00 00 71 05 00 00 00 FF 06 16 00
13:50:31.056 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=186, expected=SendData, cancelled=false MISMATCH
Deleting channel associations, and also deleting the sensor from openHAB didn’t change anything.
Also, I reset the sensor. I’ve done it as described on the Fibaro website http://manuals.fibaro.com/door-window-sensor/ which is different to your description.
What’s confusing me is, like I told in post #3 I have an older FGK101 that works.
But all four new, which I bought later, are showing the same behavior.
@chris Could you please have a look at my logs, and tell me what’s your opinion? From my point of view, the 4 new sensors are broken and I have to send them back to my vendor.
I would suggest to ensure that you’re using the latest version of the binding - ie the snapshot version and not the release version. I think that the error about not finding the command class is fixed in the recent version.
Thx for your answer!
At the moment I’m on the latest version of openhabian which I updated yesterday.
Am I right? With this actual openhabian version I do not have the latest zwave snapshot version?
I searched the forum and found this: How to install a SNAPSHOT version of a binding in a OH2b4 installation
I will follow this description, but I’m not sure, if the version used in this command is the latest/right. And I don’t know, where I can have a look, which is the latest version.
So could you please confirm, if I really need to update, and if the command below is ok?
sudo wget https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/lastSuccessfulBuild/artifact/bindings/org.openhab.binding.zwave/target/org.openhab.binding.zwave-2.0.0-SNAPSHOT.jar
Correct - this looks like the release build, not the snapshot build, so it is from January.
Yes - you really need to update.
If you just download the snapshot binding, then it may be difficult to install as you may also need to manage the dependancies… Others on the forum should be able to help with this if needed.
Switch openHABian to the snapshot release:
http://docs.openhab.org/installation/openhabian.html#switch-openhab-branch
1 Like
Thx,
If the description, I linked above, is the best/only way to do this, I’ll try.
Edit: Just saw the message from sihui. Thank you, I’ll have al look to this.
I will try to install a new zwave version, rather than switch the whole openhab2-installation to unstable.
How can I determine if zwave-2.0.0-SNAPSHOT.jar is the right version to install?
Not the right version, zwave-2.1.0-SNAPSHOT.jar is the newest version, should be somewhere in here but cannot find the individual binding jar at the moment …
And maybe you have to perform this in addition to that:
(I guess it is easier to switch openHABian)
Sounds like a lot to do, not knowing where I will end up. No matter which way I go. 
But I’m still wondering, why the sensor don’t work?
I ordered a FGK101-DoorSensor in Jan/2017, just to test if it works, and it did.
And because he did, I ordered 4 more Sensors, and they don’t.
And I compared ConfigurationParameters, AssociationGroups, DeviceConfiguration, WakeupConfiguration, Channels and so on, and I couldn’t find any difference. But they don’t work.
I had a flat battery in mine (after one year of operation, not too bad) and could not get it to work with the freshly installed battery.
I ended up excluding and including it again and after about the tenth try it worked …
So it looks like those devices are a bit tricky …
Ok, I’ve slept on it and this morning switched openHABian to the snapshot release, like you suggested.
I didn’t knew exactly, what I was doing, but followed the Link you provided and uups - now my doorsensors are working as expected. 
Thx.
(If someone is interested I could offer a step by step list, of what I’ve done.)
1 Like
In theory it would be:
sudo wget https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/lastSuccessfulBuild/org.openhab.binding$org.openhab.binding.zwave/artifact/org.openhab.binding/org.openhab.binding.zwave/2.1.0-SNAPSHOT/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar
However, as others replied already, there is a risk of not having all dependencies or interface incompatibilities. So adding a binding in a different snapshot version might not always work.
1 Like
Ahh, thx, that was the link I could not find anymore 
For future reference here is the link to all bindings:
https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/lastSuccessfulBuild/