Most of the modules which doesn’t work, i deleted in OH. Number 6 is the next free number.
The question is, confirm the log that the module is not paired correctly?
Do you know how i can delete the cache and tmp safely in a manual Installation?
Stop OH and you can safely remove tmp and cache.
The best way to check if pairing works is looking at the device itself. As I wrote, put the Nodon into pairing, LED blinks, start discovery in OH, LED needs to stop blinking almost immediatly (less than 1-2 seconds).
Also delete the old bridge/gateway
Unfortunately, the measures have not brought success. I did the pairing exactly as specified. The module acknowledges the successful pairing with two green lights according to the instructions. I have also moved the repeater to the office again, the RSSI value increases to -83 (previously -92). Is this a bad value?
I will try again next days with the old modules. Both in the office and in other rooms. This will take a few days.
What I don’t understand is that there is no indication from the log what goes wrong during pairing. :-/
Greetings Oliver
If the device acknowledges the pairing, this is good. Question: did it then show up in the inbox ? (you did remove the thing before scan/pair, did you ?)
If you still suspect firmware issues then remove one working noodon from OH, factory reset it and try if pairing works and you can control the device afterwards. If so, this could mean firmware is involved, but it also other factors (like the repeaters & range issues) could be in the play.
I think you will need to test more methodically (eg. remove unknown factors like signal-strength, repeater, binding version, prior misconfiguration without proper factory-reset of device and/or OH itself of the equation).
Esp the latter: get an additional USB-Bridge/Stick, install fresh OH (eg 3.1.Mx) on a Laptop, stand directly by the nodon and try to pair/control. If you want to get advanced, change the baseID of the additional gateway to be the same as the existing one: FF9F5500. If you then create a thing manually on the test/dev install and assign senderID 6 (same as “production”) the nodon will react to either installation as it simply checks if it is paired to that ID, not who sends it.
This way you can walk around in the house, pair every Nodon to your “mobile” install and check that you can control it from there.
If your raspi then later can’t control it (you dont need to pair again, just keep IDs the same), its range, software-version, repater or other left-over config.
HTH
-Markus
No, that actually doesn’t happen! After starting the pairing mode and the scan “enocean:rollershutter” is displayed. I click on that and can add this as thing to OH. But in fact this does not appear in the inbox. I seem to remember that this was the case with the first ones back then though. what could this mean?
Yes, always. Most of the time I have reset the module all the way.
By the way, after I cleared the cache, I tried again to set the next free ID to 30 on the bridge. The bridge went offline. Only after I deleted the number, the bridge was available again.
One more thing came to mind. It wouldn’t explain why it didn’t work already under OH 2.5, but maybe when I migrated from 2.5 to 3.02 there are leftovers from the installation that are interfering now that I fixed the original missing range problem. I’m not sure if I ran “apt purge openhab2” during the migration. Therefore I will try the following:
sudo systemctl stop openhab
sudo apt purge openhab2
sudo apt install --reinstall openhab → - will this affect my working Things and Items?
sudo openhab-cli reset-ownership
Is this worth a try?
I am not yet ready for this 
Best regards
Oliver
I can only tell you what I would do if I had this type of issues. Either you don’t care what you currently have running and are wiping it (or at least you might with your re-install attempt) to get a fresh start and rule out some of the possible causes.
Or you try my proposed green-field approach with minimal or no impact on what you currently have working.
Or you do nothing and accept what you have working and not working.
It is up to you.
You won’t believe it, but I made it work! I am so surprised myself that I first have to understand which steps I have made in detail.
I basically went like this:
- reactivated my EnoceanPi and manually added it as a bridge in OH.
- put the module in the office (firmware 1.5.1) in pairing mode.
- detected twice with two gateways, added both (irrelevant to success).
- not surprisingly both module do not go online
- continue with the Thing, which I have assigned to the EnoceanPi
5a. set EEP for Recieving States to D2-05-00 Rollershutter (like SIN-2-RS-01) - set EEP for Sending Commands to Gateway command - blinds (A5_38_08 sub command 0x07)
- added the TeachIn command to a switch item under channel “Shows advanced”
- set the module into pairing mode again
- switch item to “ON”
- and now it comes: Afterwards manually set in Thing EEP for Sending Commands to D2-05-00 Rollershutter (like SIN-2-RS-01)
- the module goes online and accepts the commands
Basically, it is the procedure that is explained at EnOcean - Bindings | openHAB in the Pairing / Actuators section for actuators which does not support UTE teach-ins.
Probably you can omit the first auto-scan and set up the module manually right away.
The next days I have a lot to do, but then I will test if the procedure works also with the older modules and with my USB gateway. Hopefully it can be solved the same way!
I can only hope that it helps someone here to solve the same or similar problems faster.
Thanks again to you Markus Dillmann and to Nodon, who supported me really great!