EnOcean and Nodon?

knebb · June 26, 2020, 7:41am

Hi,

I am running latest OH2 and Raspbian.
I have already a Nodon “IN WALL MODULE - 2 CHANNELS” up and running fine.

Now I purchased additional ones and having issues adding them to my OH2 instance.

I added it through PaperUI as thing and configured the channels as items and added them to my sitemap. Just as I did for the first Nodon module.

Now I can push the button on the module to switch the attached device on and off. And I can see this event in the log (enabled debug mode for Enocean):

2020-06-26 09:38:15.110 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 058487F0 payload D2046180058487F00101FFFFFFFF5B00 received
2020-06-26 09:38:15.115 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D2046180058487F001 for 058487F0 received
2020-06-26 09:38:15.158 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 058487F0 payload D2046080058487F00101FFFFFFFF5C00 received
2020-06-26 09:38:15.163 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D2046080058487F001 for 058487F0 received

Same when switching on:

2020-06-26 09:39:26.498 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 058487F0 payload D20460E4058487F00101FFFFFFFF5C00 received
2020-06-26 09:39:26.502 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460E4058487F001 for 058487F0 received
2020-06-26 09:39:26.562 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 058487F0 payload D20461E4058487F00101FFFFFFFF5C00 received
2020-06-26 09:39:26.566 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20461E4058487F001 for 058487F0 received

Unfortunately this does not work when using BasicUI (nor PaperUI). I can click on the switch but nothing happens on the module- the device stays as is is (on or off). Here are the logs when I want to switch it off through BasicUI:

2020-06-26 09:40:54.225 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
2020-06-26 09:40:54.229 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2010000FFC148020001058487F0FF00
2020-06-26 09:40:54.251 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
2020-06-26 09:40:54.282 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFC14802 payload D2010000FFC148028101058487F05B00 received
2020-06-26 09:40:57.202 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
2020-06-26 09:40:57.206 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2010100FFC148020001058487F0FF00
2020-06-26 09:40:57.224 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
2020-06-26 09:40:57.258 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFC14802 payload D2010100FFC148028101058487F05B00 received

Anyone having an idea what is wrong here? It might be something totally simple but I do not see it…
Thanks a lot in advance!

/KNEBB

drktfl · August 9, 2020, 7:50pm

Hi,

this is my first post, so please excuse if I should have started another thread instead of adding to this one.

I am facing a very similar issue, but with rollershutter actuators (Nodon SIN-2-RS-01) - it is the only type of actuator I currently have. I started with two of these, and could control the rollershutters both from OpenHAB / PaperUI and from the existing wall-mounted switches directly connected to the actuators. Position information was sent back to OpenHAB if operated from the switches. So everything looked good.

Then I installed a third one (same type, same configuration). That one behaves strangely: Sometimes it takes commands from openhab. But most of the time it does not. On the other hand, it reliably reports back the rollershutter positions when I operate the actuator from the switch directly connected to it. So I believe the signal is ok (should be, because all three of them are installed next to each other, and the first two still work fine). I noticed that it often works in both directions after restarting the openhab service. But some kind of configuration change (?) appears to make it “die”. But only the third one… The others are unaffected.

The debug log looks like the one KNEBB pasted above.

Any idea?

Thanks and regards,
Dirk

mdillman · August 10, 2020, 7:08pm

I have 10 of these NodOns and they work consistently without any issues. I started with one and added the others thru a period of several months.

If you want to get to the root-cause:

enable debug log of the Enocean-binding
look at the “events.log” and verify the correct command was received by the item
bind the RSSI-Channel from all nodons to an item to compare signal strength
also check that the nodon in question is correctly paired
use the latest version of the binding and do a clear-cache restart of OH

HTH
-Markus

drktfl · August 11, 2020, 6:53pm

Hi Markus,

as it seems, this indeed was related to signal strength. After bringing the RPi with the USB300 from the cellar upstairs the issues disappeared. It is not really closer to the actuators now, but much less concrete in between. RSSI was around -92 (dBm?) before, now more like -78.

Thanks!
Dirk

OlliT · January 17, 2021, 6:23pm

Hello all,

this is my first post in this forum. I apologise if I had to start a new post for my problem. But my problem seems to be very similar, so maybe it fits.

I use OpenHab 2.5.11 on Raspian and I only have NodOn shutter actuators (currently 5 of them) and a NodOn temperature sensor in use. I also have a Raspberry Zero with an EnoceanPi board. This is supposed to work as a repeater, as I also have a range problem in our house. In fact, after a lot of work, it seems to work (keyword: Ser2Net). However, I don’t want to rule out the possibility that this is somehow the cause of my problem.

All NodOn (SIN-2-RS-01 (EEP: A5-37, D2-05)) roller shutter actuators, the Gateway USB 300 Dongle, temperature sensor and the repeater (gateway, repeater mode level 1) have the status Online. I can control two of the shutter actuators via OpenHab, but for the others the console says “ITEM recieved command DOWN”, but nothing happens. Interestingly, the following message also appears: “Rollershutter_bath predicted to become DOWN” and "Roller shutter_bath changed from 0 to "If I press the wall switch, however, I see the changes in the ITEMS.

I deleted the items, i made a complete new items file and so on, but it doesn’t work. Could it be a problem with the ID’s?

Or is it possible, that the repeating from my raspberry pi zero failed? I fear, this is the point, because i can see in the Paper UI, that sometimes the actors lost their status. I tried to understand the DEBUG-Log but it is to cryptical for me. When i found out to put my Debug-Log here, i will do.

I hope, someone can help me. I love OpenHab and makes fun to learn how computer works.

Thanks in advance. Oliver

I started a new attempt and linked a new item directly to the Enocean Pi. Everything is also online, but nothing happens. I have reconfigured the Enocean Pi again. First I disabled the shell on the serial port on the Raspberry Zero, but enabled (left) the port.

My /boot/config.txt

enable_uart=1

[bluetooth]
dtoverlay=disable-bt
dtoverlay=pi3-miniuart-bt

My cmdline.txt

console=tty1 root=PARTUUID=59d7a848-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

My serial console configuration

dmesg | grep tty
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 smsc95xx.macaddr=B8:27:EB:DA:90:96 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 console=tty1 root=PARTUUID=59d7a848-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[ 0.001288] printk: console [tty1] enabled
[ 2.944070] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
[ 2.953206] 20215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud = 50000000) is a 16550
[ 6.822417] systemd[1]: Created slice system-getty.slice.

In the meantime, eocean pi went offline, so hexdump showed me the following:

hexdump -C < /dev/ttyAMA0
00000000 02 ff c5 c1 02 fd 55 00 05 01 02 db 00 ff fa 83 |…U…|
00000010 80 0a 90 55 00 21 00 02 26 00 02 0f 00 00 02 06 |…U.!..&…|
00000020 09 00 05 19 f5 07 45 4f 01 03 47 41 54 45 57 41 |…EO…GATEWA|
00000030 59 43 54 52 4c 00 00 00 00 00 cc 55 00 01 00 02 |YCTRL…U…|
00000040 65 00 00 55 00 01 00 02 65 00 00 55 00 05 01 02 |e…U…e…U…|
00000050 db 00 ff fa 83 80 0a 90 55 00 21 00 02 26 00 02 |…U.!..&…|
00000060 0f 00 00 02 06 09 00 05 19 f5 07 45 4f 01 03 47 |…EO…G|
00000070 41 54 45 57 41 59 43 54 52 4c 00 00 00 00 00 cc |ATEWAYCTRL…|
00000080 55 00 01 00 02 65 00 00 55 00 01 00 02 65 00 00 |U…e…U…e…|
00000090 55 00 0a 07 01 eb d2 00 00 00 01 ff 9f 55 05 80 |U…U…|
000000a0 00 05 12 59 b6 53 00 f7 55 00 05 01 02 db 00 ff |…Y.S…U…|
000000b0 fa 83 80 0a 90 55 00 21 00 02 26 00 02 0f 00 00 |…U.!..&…|
000000c0 02 06 09 00 05 19 f5 07 45 4f 01 03 47 41 54 45 |…EO…GATE|
000000d0 57 41 59 43 54 52 4c 00 00 00 00 00 cc 55 00 01 |WAYCTRL…U…|
000000e0 00 02 65 00 00 55 00 01 00 02 65 00 00 55 00 01 |…e…U…e…U…|

Aber a reboot of OH, the Enocean Pi went online and now i see nothing over hexdump again.

But apparently the situation has improved, at least I now see this in the openhab console:

20:03:10.736 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘Rolladen_Schlaf’ received command DOWN
20:03:10.753 [INFO ] [arthome.event.ItemStatePredictedEvent] - Rolladen_Schlaf predicted to become DOWN
20:03:10.774 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
20:03:10.779 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D264000001FFFA83810001FFFFFFFFFF00
20:03:10.806 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
20:03:10.827 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for FFFA8381 payload D264000001FFFA83810001FFFFFFFF5200 received

But unfortunately nothing is still happening. Does anyone have an idea what this could be?

What information might still be needed?

Many thanks!

mdillman · January 21, 2021, 4:20pm

If I were you, I’d do a test-setup and test-run:
Get rid of the PiZero/repeater. Move the Pi with the USB300 close to a NodOn and test if you can control it and get status. Repeat for each NodOn separately until you covered all 5.

If that works you know your setup (ID, items …) is OK.
Then it leaves only the Zero with its repeating-functionality. Try to track that down via logs there

OlliT · February 9, 2021, 5:13pm

Thanks a lot for your answer! It is not easy to move the Pi because it is installed in the control cabinet. But when I set up the actuators, I was able to reach them, just not after they were installed in the wall. So I assume that the connection as such is OK. I will set up the repeater again and report back. Thanks again!

OlliT · June 3, 2021, 12:16pm

Hello again,

several months have passed during which I could not solve the basic problem described above - getting several SIN-2-RS-01 modules to work. I am really desperate by now. In the meantime I tried to solve the problem with NODON. Since yesterday I got two completely new modules from NODON (firmware 1.5.1). Unfortunately, the same problem still arises here - I can not control the shutters from OH. Simply nothing happens.

Here again my key data and the things that work:

OH version 3.02
10 NODON modules with firmware 1.3.0
test 2 NODON modules with firmware 1.5.1
meanwhile 2 repeaters (Eltalko), the attempt to use the Enocean Pi as repeater I have given up

What works with the NODON modules:

calibration
auto discovery
status change in OH, if operation via hand switch
3 modules out of 10 work via manual control via ITEM as well as via rules

The modules goes online, after auto-discovery and setting up EEP for Sending Commands and EEP for Recieving States to “D2-05-00 Rollershutter (like SIN-2-RS-01)” manually.

I can rule out a range problem because of the two repeaters. I can put the repeater quasi directly in front of the module and still nothing happens (the repeater acknowledges the signal reception). In addition, you can see in the log that data is sent and received, e.g. status change).

So what else can I do? The only thing I haven’t done yet (again) is to clear the cache. What is the best way to do this when I have installed OH manually on the Pi? I read that you are not allowed to do this via the console then? Unfortunetly i done this for a few weeks via console before i read this. Maybe the cache isn’t clean and it could solve my problems when i do it right?

The following things have also come to my attention:

in the log (attachment) you can see that the new module with firmware 1.5.1 first error messages. (FF9F5506). That ist new.
In the json-files, there were entries from modules i had already deleted. Is this a problem?

I’ve been digging through the forums for so long now and even NODON has no more ideas. I would be very grateful for help.

OH_Log_03062021.txt (73.8 KB)

Thank your very much!

Oliver

mdillman · June 3, 2021, 4:39pm

Why ?
If the pairing works this will show up automatically (this is how it always did for me).
So:

Remove one not working thing via UI
put the Nodon into pairing more, make sure LED blinks accordingly
start discovery
Nodon should stop blinking and show up in inbox with proper EEP
bind items to channels and test

OlliT · June 3, 2021, 5:51pm

Thank you for your fast reply.

In OH 2.5 it went online automatically, in OH 3.02 only after i setting up EEP manually. After auto-discovery OH shows me " Status: UNINITIALIZED" HANDLER_CONFIGURATION_PENDING You can see this in the screenshots in the attachment.

actually I did as you say:

Remove Thing “Rollade_Buero”
put the NODON into Pairing mode, LED blinks red
start discovery
NODON stops blinking and shows up in INBOX with “enoean:rollershutter”, i click on it and add it to the THINGS, i give this the name “Rollade_Buero” again
thing status at first " HANDLER_CONFIGURATION_PENDING"
Waiting several minutes, nothing happens (see screenshot)

Setting up EEP for Sending Commands and EEP for Recieving States to “D2-05-00 Rollershutter (like SIN-2-RS-01)” manually und click “Save”, after one second it goes online (see screenshot)

Bind item to channel (see screenshot)

Nothing happens, when i click the rollershutter-arrows within the item

Thank you for your help

Oliver

mdillman · June 3, 2021, 6:36pm

Interesting would be a log while you try to pair.
My guess is: there is some collision with manual senderID you probably set during manual config of this and the other things. You could check all senderID for all other things you configured.
Have you changed any of the other IDs of other things ? Esp the enoceanID of the bridge in the past ?

What you could try is set the “next senderid” or so (can’t remember how its called in the bridge) to something like 30 or so and try if automatic pairing then works ?

mdillman · June 3, 2021, 6:50pm

What is also odd is the two different EnoceanIDs for “Rollade_Buero” thing (Thing property FF9F5506) and 05977AE5. Not sure if that is OH3 showing it this way.
Can you check if/to what the EnoceanID of the thing-property refers to ?

OlliT · June 3, 2021, 7:39pm

In the log in my text above should contain the pairing. I never changed the senderID of the bridge. But i will try your idea and push the ID from the rollershutter-module up to 30.

The working modules shows also “two” enoceanIDs. The module-id " and the generated enocean-ID with senderID. Everything looks exactly the same. Also in the json files.

I think it must be something with the Sender packet, but i cannot interprete the log in detail to detect the Problem. Or it is something strange what disappears when i clean the cache correctly.

mdillman · June 3, 2021, 7:42pm

Not from the nodon-module but in the bridge.

OlliT · June 3, 2021, 7:44pm

How i can do it ?

mdillman · June 3, 2021, 7:45pm

If you just set an arbitrary senderID on the thing of rollershutter module, how should the actor (the Nodon itself) learn it if pairing does not work properly ? I can not react because the senderID has not been announced to it without pairing

OlliT · June 3, 2021, 7:55pm

I let set the senderID from the bridge automatically. But i think i understand what you mean. I will take a fresh look at this point at the weekend. Thanks a lot for your time.

Oliver

mdillman · June 3, 2021, 8:07pm

Also try - if possible - OH3.1 Milestone just temporary. I just searched this forum for the error message in your log “is missing in properties map” and something came up for EEP D2-50-00. This is not your EEP-family but the binding developer changed something for OH3.0(2) . So it might be related to that.

OlliT · June 4, 2021, 11:49am

I set the “next device id” in the enocean-bridge thing up to “30”. It saves it, but when i start the auto-discovery the module takes the next free number “6”. I don’t know why.

The bridge base is FF9F5500 and the modules id are as FF9F5501 and so on. I think that is correct. The modules have always this enoceanId and a EnOceanId which contains the module-ID. It is a little bit confusing that we have two “enoceanID” in different notation.

My test changes nothing. The module goes online after changing the EEPs as i described above. I can see the changes of status when i use the wall switch.

Did you find any further hint in my logs? It must be exist an difference in the communication (package sending from OH to the module) compared to the other modules, but i can’t see it. However, i sent my logs to NODON and they did not find something at all.

I read the changelogs of OH 3.02 → 3.1. But i don’t think a update will be the solution. The error message “is missing in properties map” comes only with the new module (Firmware 1.5.1).

What is about my idea to clean the cache and the tmp-folder? What is your opinion?

The idea ist far-fetched, but could there be any connection that i had or have a second bridge with the enocean pi in the past? i have not yet deleted this from the thing-list but deactivated.

mdillman · June 4, 2021, 3:41pm

The ONLINE only means that things are working from OHs point of view, it is not a check if communication is good (that is not possible with Enocean).
So when you switch your NodOn it sends the new status with its Enocean-ID 05977AE5. OH receives that and links that to your Thing - that’s why you see status updates reflected.

If you want to control this Nodon, OH sends the command with a “target” Enocean-ID made up from your base-ID plus senderID 6 so complete “FF9F5506” in your case. This ID has to be registered in the Nodon via pairing, otherwise it will ignore this because it thinks this message is not for him.
So if pairing doesn’t work, you won’t be able to control from OH. Just setting the senderID of a Thing does not replace pairing.

It could be the FW that is incompatible, or some issue with the 3.02 binding version, but I doubt. I still think that something is screwed up with your (sender)IDs, because you are currently at “6” but in earlier posts you mention 10+ devices …