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