There is a nicer way and it’s easy.
You can find an expiration timer in the item metadata menu.
1 Like
That is a lot easier indeed! Thanks!
It happened again… I assume something breaks in the EnOcean binding at some point…
Who is the maintainer of the binding? Our logs might be of help to him.
It happened again… This is a bit of a disappointment, after the money I spent changing my hardware…
I’ll try to get some logs tomorrow. I assume there’s no other option than filing an issue on GitHub, as there’s no dedicated topic here?
I don’t think this is the right threat for this kind of problem;)
This may have different reasons. One is that OH crashes due to any reasons like faulty bindings or rules that are programmed incorrectly. When this happens, OH may restart and in example loose the port for your connection to your EnOcean devices.
As said above, I had this problem, too. But it had nothing to do with the EnOcean binding itself but rather the reasons I wrote above.
If I where you, I would go a few steps back and disable all other bindings and rules for some time. When it happens again, I don’t know where to look for.
Edit: I remember for sure there was a faulty version of the Miele Binding that fucked up my system on a daily basis. Including the EnOcean things. I could switch within OH but nothing happened in the Eltako devices.
I couldn’t believe it first but after removing the Miele Binding, everything went smooth. My system has an uptime of 1800+ hours and no problems at all.
How did you find out this?
I think somebody pointed me in the right direction, when I posted my logs to find the error. There where multiple errors for the Miele Binding each time just right before everything went south 
Which other Bindings do you use? I strongly recommend to disable them for some time to make sure, the EnOcean binding is running smooth. Which it does for me with a similar setup on a Pi 4 on OH 4.1
Also at some time I had the Systeminfo Binding installed and monitored CPU load, Temps and RAM availability. This way I could see exactly when OH crashed partially.
This allowed me to search the log at the critical moment.
Edit: I found the thread where I searched for help:
1 Like
Thanks. I’ll look into that.
But openHAB doesn’t crash. It’s only the EnOcean switches which don’t receive their status anymore. The rest works…
And are you able to switch the lights or anything Eltako related when this happened?
Edit: Ah sorry, you wrote this above.
I’m logging on TRACE level now. We’ll see where it goes.
This didn’t happen again, so I switch back to default level logging. The same day, the issue appeared again…
Is this some kind of ‘observer effect’? Can the log level influence the behavior of the binding? 
(I changed the log level back to TRACE…)
Mmm now the status updates don’t seem to work at all, even right after Linux box reboot. I reinstalled the binding, after which the updates worked again. But after a new update, they again don’t.
Yesterday, I did some installing and removing and whatnot if non-openHAB stuff on the Linux box. Maybe some important background file was removed or something like that? My paranoia is going into overdrive 
I rarely got this problem, too, that the switches linked to my enocean thing don’t get updates anymore. Mainly after a reboot of my Pi.
In this case it helps, when I disable the bridge (FGW-14) and enable it again. All enocean things show “online” btw, eben when the problem occurs.
So I think it definitely has something to do with the ports, my bridge is connected to. But I am noob, I don’t know anything;)
After the reinitiated bridge, it works again and doesn’t stop working.
Sorry, can’t provide any more help;(
Maybe you should think about using another bridge. FGW-14 USB and the USB Dongle 300 seem to work for most users. Edit: Sorry, you ARE using a fgw-14. The USB 300 is like 30€.
Reinitiating the gateway indeed kicks everything in gear. But after a reboot, updates are again not received, until I manually reinitiate the bridge.
If I search events.log after a reboot, the keyword enocean doesn’t appear until I start the reinitiation of the gateway. But since the gateway did accept commands, it must have been initiated somehow.
I’m TRACE logging the binding, and after the reinitiation entries like Received header appear, but not before.
Do you know who maintains the binding? On github I see user names like lovery, dilyanpalauzov, @ccutrer, @holgerf, @fruggy83, jlaur, @dalgwen, @lsiepel. (A dedicated discussion here in the community, I didn’t find, so I’m shamelessly tagging who I can tag here. :))
Best to file an issue at GitHub with the debug (or trace) level set to the binding. It should range from just before the last update u til it no longer receives updates.
Probably some exception that causes the thread to be killed.
There is no update until I reinitiate the gateway.
….
Then the same log starting from openHAB start u til the bridge is restarted and the first update works again…
That’s what I did; I just wanted to clarify 
The problem keeps arising, be it rarely. I just posted some more logs: [enocean] Gateway doesn't issue updates (but it does send commands) · Issue #17693 · openhab/openhab-addons · GitHub.