Normally this is provided in the manual - the group ID is the group number and the manual will normally say something like “Association group 1…” and it normally will say how many nodes it can allow. If not, just set the number to 5.
Yes - this will tell OH to configure the association automatically.
Not normally. Normally there’s one group that is dedicated to the controller, and it gets all notifications. If you check all of them, you will most likely end up with multiple notifications of an event which can cause issues.
Can you have a quick look at the groups I have entered, the manual states that the first group is for the controller only, so I will check it for that. Makes sense.
Looks fine. I don’t think group 2 needs to be linked to the controller - the Lifeline (group 1) should be all that’s needed.
Group 2 would probably be to allow you to control another device (eg to turn on the lights). I seldom use these groups as any automation I have is normally done in OH rather than by having the devices talk to each-other.
Do you think I would have to manually configure associations for the other groups to make it work? Or should the lifeline be enough?
Prior to sorting out this in openhab I had to set an association from the 4th group back to my controller to make this work properly using another config tool (spit spit).
Oh also can you poke in the updated config to the OH 1 build please If you are happy with everything.
I would have assumed that Lifeline ought to be enough - but who knows! The manual isn’t particularly explicit, but my understanding is that the Lifeline group should be all notifications.
I would be tempted to leave it like this and see what happens - if you find you also need another group, then we can update the database.
Any news about the FGK10x with new firmware?
I have upgraded to OH2 Snapshot 26/7-2016 (I guess tha gives me the build from monday?)
From my perspective status is:
It is recognised in the inclusion proces! Though I find it har to configure it, if I use Paper UI a couple of the settings is per default out of bounds, at least from PaperUI. In Habmin I am allowed to save them.
Dows anybody have a working configuration? I just wan’t to use it as a window contact an (maybe) as at temperature sensors (I plan to buy the sensors).
I have managed to configuring one sensor with Habmin. Sofar i am using the “scenes” to report a different number when opening and closing.
Any others that do have a working config?
Is it possible to read the contact part as a bainary sensor (omitting the scene stuff) . When I try that, it seems like nothing at all is reported from the Z-Wave network or the binding.
But scenes works just fine, though there is problems setting some sensible default values for eg. temperature reporting interval. From PaperUI it is only allowed to set this interval to 1 - i guess that is seconds
The device (I assume) should send a binary sensor status - I see that it will do that at least for the external input (according to the manual). Also, looking at parameter 20, it seems to indicate that an alarm notification will be sent.
So, I would grab a debug log and see what is being sent. Load it into the log viewer as it should help display this.
Ideally, it would be good to update the database once we know what all the different notifications do…
Just as a follow up from this I am pleased to say that the device included fine and worked fine first time.
The only slight issue was that I had to create an association between the ‘Control’ group 2 and my controller. But since then the device is working perfectly and now seems to wake up and sleep also which it did not do before.
Hi,
I have found a configuration that seems to make it possible to use the device as the old one. My primary mistake was that I where so focused on the Configuration Parameter section, that I didn’t look carefull enough in the Association Groups. Every now and then during configuration it just forgets the Lifeline Association.
Besides from that there is some problems with the configurationparameters. Not all parameters is allowed, found that the default suggested values for the parameters below isn’t allowed in PaperUI (it also seems to give some problems in Habmin, but not that significant: Parameter 12. Value of ON command frame sent to 2nd association group is 255, but max. allowed i 99 Parameter 51: Temperature reports threshold is 10, but maximum allowed is 1 Parameter 70. Scene activation functionality. Is 0, but minimum allowed is set to 1. Parameter 72. Associations in Z-Wave network Security Mode. Maximum allowed is 8.
I believe the description is fine, in reality I just can’t set the value to a decent value. Hope you can fix this in your database.
If somebody is interested in a working config, I can post it.
And once again, you are doing a wonderfull job Chris. Habmin under OH2 looks very interesting.
I installed the latest binding (which I assume is this) and things look much better now: I have the configuration parameters and Association Group visible in HABmin, and I can also see a reaction to the magnet switch.
FGK has everything on default except association group 1 “Lifeline” is associated to my controller
Openhab item config (got these from examples, I don’t know how to figure these out myself):
Number zbattery "Z-Wave battery [%s %%]" {zwave="5:command=BATTERY"}
I tried the different association options with following results:
Association to “Lifeline”:
zalarm state updates to CLOSED when magnet is introduced or removed
Association to “Control”:
zalarm and zswitch both get updated twice to OPEN/CLOSED according to the magnet position
Association to “Alarm”:
nothing
Association to “Sensor ZW3”:
zswitch get updated twice to OPEN/CLOSED according to the magnet position
Association to “Tamper ZW3”:
nothing
I only tried the switch methodically, but tamper doesn’t seem to do anything with any of them and battery updates occasionally.
I’d appreciate if someone could share a working config.
You have “respond_to_basic” on two items - this will not be good and will definately result in incorrect notifications. That said, it probably doesn’t impact on your problem with the tamper switch not working.
The tamper switch might use the new version of the alarm command class which may not be processed correctly. Can you confirm what is actually seen in the debug log when you press the tamper button?
For the battery, it’s normal that this is only updates periodically (maximum of once per hour, but it can be less).
I removed the “respond_to_basic” from both items and went through the associations again:
Lifeline: no change
Control: nothing
Alarm: no change
Sensor ZW3: no change
Here is a debug with the Lifeline association enabled and the tamper pressed and then released:
That’s what I thought as well. Yet something is wrong because using the Lifeline association, I’m getting “zalarm state updated to CLOSED” whenever the tamper or the switch is either opened or closed.
If you are happy with everything.