I am just starting up with OH2 and trying to bind it to a couple of Fibaro relay switches (FGS222) and a dimmer (FGD212). However, I cannot get the dimmer to work properly.
I managed to get it to bind in OH2 (after lots of trial and error thanks to Fibaro’s unintuitive controls and non-existing feedback). The device is discovered and all the items are showing up. However, I cannot interact with the actual device (control brightness, change settings, read power readings).
The dimmer works with the Z-way server, even if this status appears, which makes me suspect that the z-way server works around the issue somehow. In the log file, I see a lot of warnings like
2016-08-13 18:33:24.185 [ERROR] [curityCommandClassWithInitialization] - NODE 4: SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting
2016-08-13 18:33:24.242 [ERROR] [curityCommandClassWithInitialization] - NODE 4: SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting
2016-08-13 18:33:24.302 [ERROR] [curityCommandClassWithInitialization] - NODE 4: SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting
2016-08-13 18:33:24.333 [ERROR] [curityCommandClassWithInitialization] - NODE 4: SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting
2016-08-13 18:33:24.380 [ERROR] [curityCommandClassWithInitialization] - NODE 4: SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting
2016-08-13 18:33:24.410 [ERROR] [alization.ZWaveNodeInitStageAdvancer] - NODE 4: Node advancer: Retries exceeded at STATIC_VALUES
2016-08-13 18:45:59.709 [ERROR] [col.security.ZWaveSecureNonceTracker] - NODE 4: SECURITY_ERROR Device message contained nonce that is unknown to us, id=5.
2016-08-13 18:45:59.807 [ERROR] [mmandclass.ZWaveSecurityCommandClass] - NODE 4: SECURITY_ERROR MAC Authentication of packet failed. Dropping.
2016-08-13 18:45:59.810 [ERROR] [ssage.ApplicationCommandMessageClass] - NODE 4: Failed to decrypt message out of Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 04 1E 98 81 F0 E6 67 91 65 ED 01 2F 2F 28 BC 3D 9D 9A 5E 4F 0D B8 DD 05 4E 0E 50 23 11 D2 79 AC .
(Node #4 is the dimmer)
I also noticed that there are files node?.xml in /var/lib/openhab2/zwave except for Node #4.
The relay switches seem to work perfectly. They were included from z-way though, in contrast with the dimmer which I included from OH2. I am not sure if that makes a difference e.g. in the way encryption was set up.
Is there a known compatibility issue with the FGD212? Should I create an issue with the zwave addon on Github?
Good tip, thanks. I see the option, I’ll try it (for the record, I use the apt channel which seems to point to the CI server, which I presume means I’m living on the edge ). Now I just have to go in there and reinclude the device, at the slight risk of electrocution. I never got inclusion to work except by pressing the “B” button hidden deep inside the device , and it has to be operated with live voltage on the device. I suppose Fibaro could use a good interaction designer.
Unfortunately, it did not help. I still see the same problem in the log file, Initialising Thing Node... then SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting repeatedly.
Z-way is also reporting the device as only partially interviewed, with the same services failing all the time (basically, the same as the poster on z-wave.me). Fibaro is apparently unwilling to fix the issue and instead blame z-way for the issue.
From that thread I read it that some devices (not just the Fibaro) will just never complete a full interview. Would that cause a problem for OH? i.e. is there a logic like
if (!interviewComplete) {
fail();
} else { ... }
somewhere in the code? Because it seems that Z-way is still able to work with the dimmer, even though its “expert UI” reports the device as under interview indefinitely.
Edit: I just had a look at the source code, and maybe the problem is not that the interview is incomplete, but that the dimmer implements the “Security” command class (and maybe does so incorrectly)? I compare with the Fibaro relay switch and that does not have a Security command class. It seems to correlate with the command failures in the log file. I’ll dig some more.
Got it working now. It turns out that the dimmer was still bound “half-securely”.
After enabling trace logging and comparing the packets sent by z-way and the OH z-wave addon, I could see that the z-way stack sent “Security” (0x98) commands first in response to a value change, where OH sent “Switch multilevel” (0x26) requests. I suppose that since the Fibaro firmware is not behaving properly, the two implementations are treating the broken security state differently (broken as in the interview times out).
I had to re-include the device from z-way, making sure that the “force insecure” checkbox was set (I was never able to this from OH2, and I am not sure why, possibly user error from my side). To verify that security is disabled, it is easiest to check for the nonexistence of the “Security” command class from the z-way UI (or by enabling debug logging in OH2 and verifying that there is no line Application update is adding command class SECURITY in the log. (I did not find a UI for viewing command classes in OH2/z-wave.)
The dimmer firmware version is 3.4, and AFAIK this is the latest version.
). Now I just have to go in there and reinclude the device, at the slight risk of electrocution. I never got inclusion to work except by pressing the “B” button hidden deep inside the device 
, and it has to be operated with live voltage on the device. I suppose Fibaro could use a good interaction designer.