This won’t make any difference, but you are right, it shouldn’t be needed if the associations are correctly configured…
@chris Sorry for my rookie-questions.
You are talking about the config in Habmin?
Actually there are two parameters which match to your comment:
Parameter 13 (“Inputs behavior”): Toggle or Follow Switch contact (ON / OFF)
Parameter 14 (“Inputs Button / Switch configuration”): Bi-stable input (Switch) or Mono-stable input.
The second has an impact on the physical switch in the wall (which is a mono-stable button = push button??) behaviour.
As far a s I know openhab does not provide a toggle button (just switch), right?
Hi @TobyWindahl,
thanks, changed that, but it doesn’t change anything.
Would you be willing to provide your node.xml file to me to test?
One more thing:
When I trigger the switch in openhab (from ON to OFF), I can hear a “click”-response from the relay behind the physical switch in the wall, but the state of the light does not change until I trigger the switch in openhab from OFF to ON.
If the switch is switching (ie you can hear it switch when you press the button in OH) then it’s probably working. If it’s not turning on the light, then something in the switch is probably broken.
Have you looking in the logs to make sure that something isn’t being sent twice, or that the correct information is being sent to the switch through zwave?
I am thinking along Chris’s line as well. If you hear it click it sounds as if you have the proper Contact but something else is amiss.
I used this example to configure my switch from ‘Collection of z-wave settings’:
That’s what I meant with not using the refresh_interval.
Try the debug mode if the logs fail to provide any useful information.
Myself, I did not change anything in the Habmin for the switch. The node-file you ask for I know nothing of. I shall look for it and see what it contains.
I do recall it was kind of a pain to manage to pair it though 
The tripple press needs to be very fast on my switch.
/T
I have the same issue, I posted about it a while ago:
https://groups.google.com/forum/#!searchin/openhab/leong/openhab/Yn_SZ7MzjKc/3qlfT6dd4xwJ
And it seemed to be fixed, but now I have the same issue again.
Same symtoms: Bistable switches, hear the relay clicking when I flip the switches, but no event (or message) arrives on the controller. Switching from the Openhab UI or app works fine.
Till now I thought the relay was broken, but since you have the same issue, maybe its something else.
If I understand the problem here (and I’m not 100% sure I do!) the issue is if the UI button is pressed, then the binding is sending a message to the switch, the relay is clicking, but the lights aren’t coming on until the OFF command is sent. I believe it works if the button is physically pressed, so I think this is different?
Thanks @TobyWindahl.
that’s exactly, what I tried as well, but played around with different settings (even without command=switch_binary and with the refresh_interval like in my Wall Plug Switch).
However, the xml would be helpful.
You can find it here:
/var/lib/openhab/zwave/node4.xml (my relay is node4).
Again, thanks for your help.
Hi @l_grave,
I am not sure if this is the same issue:
My physical switches in the wall work as usual.
BUT, when I try to switch the relay from openhab, the light’s status is changed (from ON to OFF of vice versa) only when the OH switch item changed to “ON”.
I other words only every second switch process will change the lights condition.
Clear what I mean?
When I press the physical switches once I get 2 entries in my log:
2016-01-02 20:41:53.937 [WARN ] [.z.internal.ZWaveActiveBinding] - NODE 4: No item bound for event, endpoint = 0, command class = SWITCH_BINARY, value = 0, ignoring.
2016-01-02 20:41:54.258 [WARN ] [.z.internal.ZWaveActiveBinding] - NODE 4: No item bound for event, endpoint = 0, command class = SWITCH_BINARY, value = 255, ignoring.
But the lights condition is changed in each single push.
With the switches on OH I don’t see a log entry, but the light changes on the second trigger only (changing state OFF -> ON)
In my case it IS exactly that way. The only condition change will be achieved when the UI switch changes from OFF to ON. (and the physical switch works as designed).
@chris
I don’t think, that something is broken in the switch, because the behaviour is totally reproducible.
That means the relay (both channels) switch perfectly when triggered by OH (Switch 1 - or 2 respectively).
But the state of the light only changes on every second push of the OH switches (from OFF to ON only).
My conclusion is that it’s a wrong internal parameter.
So, would anybody please share the node.xml of a functional setup of this (or the FGS-221)?
You could always reset the switch then? I guess since others don’t have this issue, resetting to defaults will solve the issue?
Good idea.
Going to try that.
I hope it’s possible without getting it out of the wall… 
Should be possible - I’ve done it with my Fibaros just by clicking the appropriate switch (some of mine are in the ceiling!).
Alright - thanks again.
Will update this thread afterwards…
Hi!
I’m using Openhab 1.6.1 and have exactly the same problem. Using openhab, I can control both relays (defined with endpoint 1 and 2 of my NODE 4) but when I use the physical switch connected to S1, I have the error “No item bound for event, endpoint = 0”.
Do I have to update my openhab / wave binding to solve the problem? The strange thing is that this worked for me in the past and I didn’t change any configuration for this node.
That’s interesting.
So there must have been be some change.
I am using the actual 1.8. zwave binding showing this problem.
I, too, kept and still keep (OH 1.8) seeing that message on a FGS-222.
@chris: seems that on toggling an input switch, the FGS-221/222 have always been sending messages with epid = 0.
How to cope with those? Do you know of any FGS config to map it to the corresponding endpoint ?
Or is there a way for the binding to ‘fish’ these and map them to existing items (which have epids = 1 and 2) ?
I had seen that behavior on FGS-221 for a long time, too, but it seems to have disappeared there recently (since 1.8, maybe earlier). Not sure, though.
Markus