NOD ON Module 1 channel cannot be controlled

  • Platform information:
    • Hardware: Openhabian on Raspberry PI 3
    • OS: Openhabian
    • Java Runtime Environment: bundled
    • openHAB version: 2.5

Hi, I am struggling to get my NOD ON module running with Openhab. I already have a 2 channel module up and running and the enocean system works very well. Now I installed a single channel module, but it is only recognised as Pushback Button and I cannot switch off the light using openhab.

When I use the connected wall-switch I receive the following events:

When turning the light off:

2020-01-06 20:49:14.807 [vent.ChannelTriggeredEvent] - enocean:pushButton:FT1I6L57:05141DCC:pushButton triggered PRESSED
2020-01-06 20:49:14.821 [ome.event.ItemCommandEvent] - Item 'Eltern_Licht' received command OFF
2020-01-06 20:49:14.830 [vent.ChannelTriggeredEvent] - enocean:pushButton:FT1I6L57:05141DCC:pushButton triggered RELEASED
2020-01-06 20:49:14.838 [vent.ChannelTriggeredEvent] - enocean:pushButton:FT1I6L57:05141DCC:pushButton triggered PRESSED
2020-01-06 20:49:14.846 [ome.event.ItemCommandEvent] - Item 'Eltern_Licht' received command ON

When turning the light on:

2020-01-06 20:49:21.029 [vent.ChannelTriggeredEvent] - enocean:pushButton:FT1I6L57:05141DCC:pushButton triggered PRESSED
2020-01-06 20:49:21.040 [ome.event.ItemCommandEvent] - Item 'Eltern_Licht' received command OFF
2020-01-06 20:49:21.049 [vent.ChannelTriggeredEvent] - enocean:pushButton:FT1I6L57:05141DCC:pushButton triggered RELEASED
2020-01-06 20:49:21.056 [vent.ChannelTriggeredEvent] - enocean:pushButton:FT1I6L57:05141DCC:pushButton triggered PRESSED
2020-01-06 20:49:21.063 [ome.event.ItemCommandEvent] - Item 'Eltern_Licht' received command ON

My Items:
Switch Eltern_Licht "Eltern Licht" <light> (Eltern_Beleuchtung) [Lichter] {channel="enocean:pushButton:FT1I6L57:05141DCC:pushButton", autoupdate="false"}

My Sitemap:
Default item=Eltern_Licht label="Licht" icon="light"

Any ideas?

Hi Stefan,
where is your actuator item definition ? Did you couple the pushbutton directly to the actuator ? If so, if you want to have the light state visible in OH and control it from OH, you can forget the sensor. You just have to configure you actuator to OH (and if that is bi-directional it will send state-changes to OH so that you can see them).

Only if you want to so something in OH via the switch (eg. run a rule), then you need to define the pushbutton as an Encoean-device to OH

HTH
-Markus

Well, that’s kind of my issue. :wink: Actually, I do not see any actor item for the NOD ON device. I thought it would provide an RockerSwitch like the 2 channel device does, but it does not, at least I do not find any using the auto discovery.

If I configure the Thing manually as RockerSwitch with the following item definition…

Switch Eltern_Licht "Eltern Licht" <light> (Eltern_Beleuchtung) [Lichter] {channel="enocean:rockerSwitch:8d384495:rockerswitchA"}

… then I get the following events fired:

Turn the light ON (physical switch):

2020-01-07 19:48:33.911 [vent.ChannelTriggeredEvent] - enocean:rockerSwitch:8d384495:rockerswitchA triggered DIR1_PRESSED
2020-01-07 19:48:33.922 [ome.event.ItemCommandEvent] - Item 'Eltern_Licht' received command ON
2020-01-07 19:48:33.928 [nt.ItemStatePredictedEvent] - Eltern_Licht predicted to become ON
2020-01-07 19:48:33.956 [vent.ChannelTriggeredEvent] - enocean:rockerSwitch:8d384495:rockerswitchA triggered DIR1_RELEASED
2020-01-07 19:48:33.959 [vent.ChannelTriggeredEvent] - enocean:rockerSwitch:8d384495:rockerswitchB triggered DIR1_RELEASED
2020-01-07 19:48:33.963 [vent.ChannelTriggeredEvent] - enocean:rockerSwitch:8d384495:rockerswitchB triggered DIR2_PRESSED
2020-01-07 19:48:33.967 [vent.ItemStateChangedEvent] - Eltern_Licht changed from OFF to ON

Turn the light OFF (physical switch):

2020-01-07 19:48:46.765 [vent.ChannelTriggeredEvent] - enocean:rockerSwitch:8d384495:rockerswitchA triggered DIR2_PRESSED
2020-01-07 19:48:46.779 [ome.event.ItemCommandEvent] - Item 'Eltern_Licht' received command OFF
2020-01-07 19:48:46.786 [nt.ItemStatePredictedEvent] - Eltern_Licht predicted to become OFF
2020-01-07 19:48:46.792 [vent.ChannelTriggeredEvent] - enocean:rockerSwitch:8d384495:rockerswitchA triggered DIR2_RELEASED
2020-01-07 19:48:46.796 [vent.ChannelTriggeredEvent] - enocean:rockerSwitch:8d384495:rockerswitchB triggered DIR2_RELEASED
2020-01-07 19:48:46.817 [vent.ChannelTriggeredEvent] - enocean:rockerSwitch:8d384495:rockerswitchB triggered DIR1_PRESSED
2020-01-07 19:48:46.823 [vent.ItemStateChangedEvent] - Eltern_Licht changed from ON to OFF

So it seems the device acts like a two channel device while I have to send the correct combination for the two channels to control the lights, like in the log files.

Is that right, or is there a better way to do it?

Thanks.

Can you post a list of the Enocean-stuff that you use ? (make and model)
To what physical device (actuator) is your light connected ? A NodOn SIN-2-* ?

You need an actual actuator (eg the mentioned Nodon) that does the actual switching and (ideally) an pushbutton/rocker that drives the actuator (outside of OH) via Encocean-radio.

If you have that working, define your actuator in OH and control it via OH commands.

Lastly define your pushbutton to OH if you want other things to happen from OH but initiated from your pushbutton/rocker. If that step works as well, you could unpair your pushbutton from your actuator and instead have OH send a command to it when OH receives a pushbutton press/release

HTH
-Markus

I have a NodOn SIN-2-1-0-1 (see https://www.reichelt.de/unterputz-modul-1-x-2-3kw-enocean-nodon-sin2101-p243488.html)

I connected it with the physical switch (s1 & s2) that controlled my lamp. Now, the device sends the commands via enocean to openhab (I can see the incoming events), but I am not able the switch the device from openhab (that’s the missing part).

I am not sure, how to send a command via openhab / enocean bridge to the actor (nodon device). :frowning:

I can control a NodOn SIN-2-2-01 from OH without any problems. This actuator uses EEP D2-01-12, whereas yours is using D2-01-0F.

Here is my things-definition:

Thing measurementSwitch xxxxxxxx "Lichter Anrichte/Spüle" @ "Küche" [ enoceanId="xxxxxxxx", senderIdOffset=10, sendingEEPId="D2_01_12_NODON", broadcastMessages=false, receivingEEPId="D2_01_12_NODON", suppressRepeating=false, pollingInterval=300]

So you’d probably need to use “D2_01_0F_NODON”.

Once your thing is online, you should see a “generalSwitch” channel in PaperUI. For testing, just link it to an switch-item and toggle it. See if the Nodon reacts.
Next test would be toggling the Nodon from the physical switch and see, if OH pics up the state-change, that the Nodon sends, properly.

(I currently in fact have issues with that with my dual-channel nodon where it indicates always both channels at the same state. Need to debug this. )

HTH
-Markus

1 Like

Forgot: note the senderID; either use text-based config and pick one AND pair the nodon, or use PaperUI for the definition and let it pick a free senderID while doing the teach-in

Great, with the measurementSwitch configuration I can see the Thing and a can connect to the Switch and get the status updates from the physical switch immediately in OpenHab.

Still, when I change the Switch in OpenHab, the device does not change from ON/OFF or vice versa.

I use the protocol as you mentioned “D2_01_0F (NodOn)” for both, sending and receiving.

Good to hear, that is progress :slightly_smiling_face:

From the symptoms you describe it looks like your OH is not correctly paired with the NodOn switch. Receiving from the NodOn works without pairing.

So within the Openocean-binding initiate a discovery and then press the pairing-button on the Nodon. I hope the pairing works if you already have defined the thing, but it should be ok.

That that still does not work, perhaps @fruggy83 can help.

-Markus

1 Like

Well, running a discovery brings up the thing, but it finds and configures it again as a Push Button as follows:

I copied over the EnOceanId to the other Thing, but that still does not work. I am short before throwing the thing away and using a 2 channel NodOn device instead, which works great for me at two other installations. :frowning:

Are you sure you put the Nodon successfully into pairing mode ? (Led should light red). I had to press the button really quick 3 times; If you are too slow, it toggles the switch - and spits out the rocker-EEP messages that the switch was pressed …

1 Like

Or try to reverse the process: first put the NodOn to pairing mode then initiate the discovery

OK, shame on me, that was my fault. Setting the device into pairing by pressing the button real fast brought up the enocean:measurementSwitch in discovery mode. :slight_smile: thanks for this hint. I was not fast enough.

Now the thing is paired correctly and I receive updates and can change the light. As long as I do not change the hardware switch it works like charm.

Still, using the hardware switch kind of deactivates the switch in OH. I have to toggle the switch three times to see an effect but sometimes it just does nothing until I use the hardware switch again.

Looks like it has troubles when the hardware switch changes the state. Did you experience same issues?

Glad it now works.

I have no hardware switches at all connected, just radio-rockers. I think the binding somehow struggles now with the status-messages of the Nodon.
Have you tried adding the “F6_00_00” additionally as the receiving EEP ? (That is necessary for some Eltako-devices, not sure if needed or even possible with your version of the Nodon).

I guess Daniel (@fruggy83) as the binding developer can help with the status-message.

1 Like

To add: even with my Nodons just switched via radio-rockers, I do get the status-change immediately (and it should not matter if a physical switch is used).

HI Stefan @bechte,

as Markus (@mdillman) said, maybe the NodOn sends telegrams of another type when a hardware switch is used. Could you enable the debug log of the binding and watch/post your log when you hit your hardware switch. If we see RPS messages, I have to add the F6_00_00 EEP to the receiving EEPs, it is currently not in the supported list.

Best regards
Daniel

Hi Daniel @fruggy83,

sure. Switching the lights OFF gives the following logs:

2020-01-15 21:14:38.740 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 05141DCC payload F61005141DCC3001FFFFFFFF5200 received
2020-01-15 21:14:38.842 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 05141DCC payload F60005141DCC2001FFFFFFFF5000 received
2020-01-15 21:14:38.848 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 05141DCC payload F67005141DCC3001FFFFFFFF5200 received
2020-01-15 21:14:39.250 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 05141DCC payload D204608005141DCC0001FFFFFFFF5200 received
2020-01-15 21:14:39.252 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D204608005141DCC00 for 05141DCC received

Switching it back ON, leads to the following logs:

2020-01-15 21:14:44.192 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 05141DCC payload F63005141DCC3001FFFFFFFF5500 received
2020-01-15 21:14:44.198 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 05141DCC payload F60005141DCC2001FFFFFFFF5500 received
2020-01-15 21:14:44.207 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 05141DCC payload F65005141DCC3001FFFFFFFF5500 received
2020-01-15 21:14:44.879 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 05141DCC payload D20460E405141DCC0001FFFFFFFF5300 received
2020-01-15 21:14:44.883 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460E405141DCC00 for 05141DCC received

while 05141DCC is the EnOcean ID of my NodOn Thing, but I guess this is already obvious to you guys. :slight_smile:

After switching the state in OpenHab the logs look different.

Switching the device ON produces:

2020-01-15 21:19:34.874 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 05141DCC payload F61005141DCC3001FFFFFFFF5200 received
2020-01-15 21:19:34.889 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 05141DCC payload F60005141DCC2001FFFFFFFF5300 received
2020-01-15 21:19:34.896 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 05141DCC payload F67005141DCC3001FFFFFFFF5300 received
2020-01-15 21:19:35.386 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 05141DCC payload D20460E405141DCC0001FFFFFFFF5300 received
2020-01-15 21:19:35.390 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460E405141DCC00 for 05141DCC received

And back OFF produces:

2020-01-15 21:19:40.486 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 05141DCC payload F63005141DCC3001FFFFFFFF5600 received
2020-01-15 21:19:40.499 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 05141DCC payload F60005141DCC2001FFFFFFFF5600 received
2020-01-15 21:19:40.508 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 05141DCC payload F65005141DCC3001FFFFFFFF5500 received
2020-01-15 21:19:41.177 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 05141DCC payload D204608005141DCC0001FFFFFFFF5300 received
2020-01-15 21:19:41.179 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D204608005141DCC00 for 05141DCC received

Just to chime in here: I just installed my first NodOn SIN-2-1-0x (IN WALL MODULE - 1 CHANNEL) and while the OpenHAB-to-NodOn ON/OFF switching is working as expected, I can’t seem to get any of the NonOn-to-OpenHAB hardware switches communication going on.
The User Manual clearly states that this device can and does send the signals of it’s hardware switch(es) connected to terminals S1 and S2. Furthermore, the device is hardwired in such a way that S1 switch input can both control the relay inside and send the telegrams, while S2 does not control the relay inside but only sends the telegrams. So, not only that they envisioned such a function, they even built a separate terminal just for that.
However, in my OpenHAB 2.5.0, the device was recognized as Energy Measurement Switch and among the channels offered, this hardware switch is nowhere to be found. The channels I got are: LastReceived, Switch, RepeatCount, RSSI and Repeater Mode. That’s all of them. Hence, I feel like there is one channel missing: hardware switch from the device. Now, to be precise, there are total of 3 hardware switches on this device: 1) a built in local switch on the device itself, 2) input terminal S1, and 3) input terminal S2. But, I guess the device would be sending only one telegram for all three. Or maybe three different telegrams for three switches? But I doubt it.
Anyway @fruggy83, thank you for your great work on EnOcean binding and let me know if I can be of any help. Thanks. Cheers!

Hi @AtmanActive ,

I am a bit confused from your description. The NodOn SIN-2-1-0x has only one channel.

You can use the module with both a rockerswitch (German: Wippe) or a pushbutton (German: Taster) to control the device. This is used to have the physical switch still in use while adding the remote control ability. The NodOn module will automatically determine the type of switch when you switch it the first time(s).

If you connect a rockerswitch, then you have to connect both S1 and S2 to the both output channels of your physical rockerswitch. This way the NodOn will receive a signal representing the state of the rockerswitch (e.g. S1 open, S2 closed). If you connect a pushbutton (typically via S1), then it will switch the internal relais whenever a signal is sent.

You (explicitly) CANNOT connect two different switches via S1 and S2, which is also stated in the user manual:

AUTO-DETECTION OF SWITCH CONFIGURATION
When you turn ON the supply voltage after set up the In-wall Module, please do a single push
on the wired wall switch. An auto-detection will be made to know whether you’re using monostable or bi-stable wall switch.
Note: The same configuration is applied for both Switch 1 and Switch 2. It is not possible to have 2 different types
of wall switch wired to a single in-wall module.
To perform a new auto-detection, the product must be manually reset.

Having said this, I would say you cannot determine whether or not a signal is received via the plugs S1 and S2, but you will receive an update on the modification of the internal relais when it is switched. This is sent via the “Switch” channel you have mentioned and it works like charm for me.

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…

Does that makes sense? Or did I misunderstand you?

Best bechte.

Hi @bechte,

It is a one channel switch in a sense that it has only one relay, meaning, only one mains line. But, according to my understanding of the manual, it does have 2 distinct hardware input switches and I don’t agree that a rocker switch has to be connected to both. I would say that’s a misconception on your side. Let’s all take a deep look at this picture, from the manual:

Now, please note that the S2 input is connected to… NOTHING! It clearly shows a radio icon explaining that this switch is just sent via radio, nothing more. This configuration can be useful if you have a double rocker switch at the physical point where your SIN-2-1-00 is, but, somewhere down the line you will still have two lights, hence, your NodOn can send that signal to your next NodOn which can then switch it’s relay channel by this command. They made it so you can connect a double rocker switch to one NodOn but still control two NodOns. Furthermore, if you talk to any electrician, everyone will tell you that rocker switches do not require two inputs. One input is enough: OFF/ON, like in old pre-home-automation times.

There is this part of manual that according to my understanding confirms what I’m talking about:

So, yes, it is a one channel relay, but, a smart EnOcean relay that can send it’s hardware switch input information in a linked or unlinked fashion, depending on whether you want to use S1 or S2 inputs.

Thanks.

Cheers!