@bechte, I believe the source of your confusion to be this text that you posted, but if you read it again with an accent on the highlighted word, you will see that the meaning is actually something different:
I doubt that the internal states of the S1 and S2 are exposed by the module. Because it would strongly rely on the connected switch. Furthermore, if they are exposed, they would be only Contact sensors because one cannot (or at least should not) change their states from remote…
And, yes, I agree, they could only be Contact Sensors, that’s the whole point.
The more I read about it (and believe me, this is the 10th time I’m reading the User Manual ) the more I am certain that OpenHAB binding for this device is missing S2 receiver end. True, S1 should reflect on the switch itself automatically and according to your findings, indeed it does, but S2 should be just a decoupled info point that users should receive in OpenHAB.
Hi,
I don’t agree to your opinion that S2 is separately controllable and is supposed to just send a telegram.
In the wiring diagram there is a single icon for switch (possibly two channels for up/down or on/off). If the input were indeed separate, NodOn would depict two.
In my experience with other NodOns S1/S2 drive the internal relay and a change of state of that relay triggers a telegram which could be used by openHab or other Enocean devices.
I suggest you contact NodOn support to verify that S2 is indeed independent just sending telegrams.
That is exactly what I was trying to say: S1/S2 only drive the internal relay but are NOT propagated externally. Therefore, neither S1 nor S2 is externally readable, but only the state of the internal relay, and this is propagated through the external switch.
This is not a change request to the openhab binding but to the nodon hardware itself.
Ah yes, that makes sense alright. Thank you @bechte and @mdillman for your patience in explaining this. These S1 and S2 are just inputs for one and the same relay, but it is not the inputs’ state that gets sent via a telegram, it is relay’s state that gets sent via a telegram. That is confirmed in the manual by this text:
That is like a dual-interconnected-rocker configuration sometimes used on stairways to enable user to turn on or off lights from downstairs even though they are upstairs and vice versa. So, what the manual calls ‘synchronized’ here is actually both-NodOns-working-in-unison, while what they call ‘desynchronized’ is a tug-of-war configuration where one NodOn goes ON while the other one goes OFF and vice versa.
Now I get it. It took me reading the manual “only” 15 times, plus all that advice from you to realize this.
sorry for my late answer, I must have missed your answer.
Thanks for sharing the log. I am not sure if I understand your switching procedure correctly. I guess the first two logs are received when you switch your Nodon by your physical switch, then by openhab to OFF (without a log) and afterwards again physically?
The messages indeed look strange. Whenever you change the state of the internal relais, Nodon sends four messages. The first two message simulate a rocker switch (pressed and released), the third one is a RPS status response message (useful for older devices which do not understand VLD messages) and the last one is the VLD status response message. Despite of the different rocker switch messages, you even get different RPS status response messages.
F607 means ON, F605 means OFF. The last two logs are ok but the first two logs are inverted However the VLD status response messages are always correct. D20460E4 means ON, D2046080 means OFF. So the VLD response does not match the RPS response in the first two logs.
So I recommend not to add the F6_00_00 EEP to your receivingEEPIds. If I may guess the Nodon seems to have troubles if you switch it physically and by openhab. It seems that the Nodon tries to keep track of physical rocker switch and gets into trouble when you directly switch it by an EnOcean message, as the relais state gets out of sync with the physical rocker switch state in this case. Maybe you should configure it to use a pushbutton (Taster)
thanks a lot for your words. Always good to know that this binding is usefull for others too.
Sorry for my late answer. However I hope that all your problems are solved already with the help of the other two. Just let me know if its not the case.
) the more I am certain that OpenHAB binding for this device is missing S2 receiver end. True, S1 should reflect on the switch itself automatically and according to your findings, indeed it does, but S2 should be just a decoupled info point that users should receive in OpenHAB.
However the VLD status response messages are always correct. D20460E4 means ON, D2046080 means OFF. So the VLD response does not match the RPS response in the first two logs.