Lamp randomly switching off

[okebaja]

I have an Eltako (EnOcean) installation with wireless switches throughout my house. The lamps are controlled by FUD14 and FSR14 actors. The system has been functioning correct for the last five years, since installation in the autumn of 2015. I use FHEM to control the automatic switching of the lights in my living room and garden depending on the time of the day. The lamps in the rest of the house are responding to teached-in wall switches (rockers).

Since one week one lamp in my living room is switching off at random. This lamp is controlled by a FUD14. Sometimes it switches off every few minutes, sometimes it does not switch off for more than an hour. Truly random, or so it seems. I have been experimenting lately with the Tesla module. I do not think this module is causing this but I must say that the random switching started more or less around the time I was experimenting with that module. The module has been removed already, and I even restored a backup of my Raspberry Pi, dating from *before* the random switching problems began.

In an effort to find the cause I set verbose to 5 globally. In my log I then see the following (the lamp that is randomly switching off has the id FFB14284):

Code Auswählen Erweitern

2020.06.14 21:27:22 5: TCM USB300 received ESP: 55000A0701EBA502320009FFB142840003FFFFFFFF2D00E1
2020.06.14 21:27:22 5: USB300: dispatch EnOcean:1:A5:02320009:FFB14284:00:03FFFFFFFF2D00
2020.06.14 21:27:22 5: EnOcean received via USB300: EnOcean:1:A5:02320009:FFB14284:00:03FFFFFFFF2D00

However, in the telnet "inform timer" log I see nothing when this happens.

When I switch the lamp to "on" using the normal wall switch I see this in my log:

Code Auswählen Erweitern

2020.06.14 22:06:42 5: USB300: dispatch EnOcean:1:A5:02320009:FFB14284:00:03FFFFFFFF2D00
2020.06.14 22:06:42 5: EnOcean received via USB300: EnOcean:1:A5:02320009:FFB14284:00:03FFFFFFFF2D00

And when I switch it off manually:

Code Auswählen Erweitern

2020.06.14 22:09:49 5: USB300: dispatch EnOcean:1:F6:00:FEFD20D0:20:03FFFFFFFF4900
2020.06.14 22:09:49 5: EnOcean received via USB300: EnOcean:1:F6:00:FEFD20D0:20:03FFFFFFFF4900
2020.06.14 22:09:52 5: TCM USB300 received ESP: 55000A0701EBA502000008FFB142840003FFFFFFFF2D

All my lamps have id's starting with "FFB". I noticed some log lines showing devices with different id's, for instance:

Code Auswählen Erweitern

2020.06.14 22:09:25 5: EnOcean received via USB300: EnOcean:1:A5:B400000D:0198FA20:00:03FFFFFFFF5600
2020.06.14 22:07:20 5: EnOcean received via USB300: EnOcean:1:A5:72690408:05085B09:80:0305149FED3D00

Could this indicate a similar installation in my neighborhood which is interfering? As far as I know nobody in my street uses an EnOcean installation.

Lastly, I have also tried placing FHEM in teaching mode (to see if any new devices are in play in my network) and, when I indeed discovered a few, set do_not_notify on them. However, this did not help, and by now these newly found devices are gone since I restored the backup.

So far my questions are:
1/ Does anybody recognize these kind of problems and if so, do you have tips for me?
2/ How can I debug this problem?
3/ Can I "tell" FHEM to ignore all messages for devices that are not starting with FFB?
4/ Would it be a solution to completely wipe FHEM or even the whole machine and start over? If yes, how can I achieve that without having to configure everything again? Again, I already tried a restore (without wiping first) but that did not help.

All help appreciated!

[okebaja]

Guess I am on my own.

[amenomade]

I'm not a specialist of EnOcean, but concerning your questions:

1/ I know that kind of problem for other protocols, with the neighborhood interfering with own installation and I can well imagine that smthg like that could happen for EnOcean as well

2/ I suggest you provide a 'list' of the actor and of your gateway (btw, what ID has your gateway?), and perhaps a longer extract of the Log as well, for further analysis

3/ I don't know

4/ before you come to such an extreme solution, you should wait a little bit. Perhaps someone will have an idea. And if it is a single lamp which is making problems, perhaps you can try to replace it, before renewing the whole installation

[gadget]

If your wall switches support encryption, you could try to delete all learned sensors for the FUD actor (see manual). Afterwards enable encryption and re-learn the wall switches  and also learn in the controlling device in fhem. Make sure you are using a unique subDef.