Regarding your question: I can share your experience of having problems to reconnect. Sometimes it works just fine, sometimes I have to restart OH.
I actually found a workaround a while ago: I create a virtual serial device as a proxy via socat and use this virtual device in openHAB. This way socat is handling reconnections. This works very well for me.
So you are using socat on the very same device OpenHAB is running on?
udev ==> ttyUSB0 ==> socat ==> ttyUSB_socat ==> openhab
Yes socat is running on the same host, however my setup is a bit different because my gateway is not connected directly to the openHAB machine but via TCP. However this should work with a connected usb device as well. So I have:
TCP Gateway → Socat (TCP socket to tty0) → Second Socat (tty0 to tty1) → openHAB uses tty1
The second Socat creates a pair of virtual serial devices that are “always connected” so openHAB won’t have to deal with reconnects. The first Socat instance writes all data received from the socket to tty0 and vice versa.
I can even unplug the gateway and plug it back in later without openHAB noticing that it was offline.
Can you please share the command line for the second socat?
In my case I am using a serial connection provided via USB. However, sometimes the USB device stops working, so I have to reset the USB device. This again sometimes changes the device’s name from ttyUSB0 to ttyUSB2 and vice versa. I cover this by having appropriate UDEV rules, always linking the device to ttyFGW14. However, OH sometimes has a hard time resuming the communication.
Today’s attempts by implementing a socat from ttyFGW14 to ttySOCAT_FGW14 didn’t bring any improvements - disconnects still will be discovered by OH, reconnect rarely works, only a restart of the OH service seems to be helpful.
Sure this is the code I use:
#!/bin/bash # https://community.openhab.org/t/cant-use-forwarded-socat-serial-port-in-lgtvserial-binding-ioexception/97965 # https://community.openhab.org/t/forwarding-of-serial-and-usb-ports-over-the-network-to-openhab/46597 # use while loop to restart socat on connection end while /bin/true; do socat -d -d -s -T 1200 -lf /openhab/userdata/logs/socat_proxy.log pty,link=/dev/ttyNET0,raw,user=openhab,group=openhab,mode=777 pty,link=/dev/ttyNET1,raw,echo=0 sleep 1 done &> /dev/null &
In the comments you find references to the threads where I got the idea from. You probably don’t need the -T 1200, it was working for me so I did not try to remove this.
Edit: For completeness this is the first socat command:
#!/bin/bash # https://community.openhab.org/t/cant-use-forwarded-socat-serial-port-in-lgtvserial-binding-ioexception/97965 # https://community.openhab.org/t/forwarding-of-serial-and-usb-ports-over-the-network-to-openhab/46597 # use while loop to restart socat on connection end sleep 5 while /bin/true; do socat -d -d -s -T 600 -lf /openhab/userdata/logs/socat.log /dev/ttyNET1,raw tcp:10.9.50.202:9999,connect-timeout=30,forever,intervall=10 sleep 1 done &> /dev/null &
Thanks for your help!
By this, I learned that my chain needs to look like this:
udev ==> ttyUSB0 (file) ==> socat ==> ttyUSB_socatA (pty) => socat => ttyUSB_socatB (pty) ==> openhab
Finally I was able to reset ttyUSB0 without having OH notice this. However: it still didn’t work.
So I think I’ll stick with my current solution: taking a heartbeat and perform increasing action if this is missing:
- reset the usb device
- reset the usb device and restart OH
- restart the whole VM
Seems to work
Hm… Too bad to hear that it didn’t work for you
After using the enocean binding for a couple of months I can say that it works great for most of the time, however I still see some problems from time to time that may be related to race conditions between the bridge coming online and child things getting initialized.
During my nightly backups I stop OH for a couple of seconds/minutes and recreate the container afterwards causing the binding to reinitialize the bridge and child things. Most of the time everything works fine but sometimes (estimated 10% of restarts) I discover that the child things either don’t come back online after the reboot (maybe 90% of the failed reboots) or pretend to be online but don’t receive any updates after that even though they are online (last received message remains at the time when the reboot takes place). I cannot remember I ever had the bridge in an offline state after a reboot so I assume that bridge reconnections are working just fine.
Could the first problem be related to the connectorTask of the EnoceanBridgeHandler waiting for the bridge to come online while child things are already trying to get initialized? Please note that I really have no clue at all how the core implementation of thing initialization works so I might be completely on the wrong track here… However my reconnection issues are quite real so I suspect some multithreading problems here… Maybe there are other users out there who can help to get to the bottom of this. If you need more input from my side I’m also happy to help
thanks a lot for these hints and your work on the binding
I have not realized such problems in my environments. However I am not restarting my prod env in a such regular basis and my dev env has not many things. So I am maybe not really representativ
I have just a few questions.
Problem 1: child things do not come back online
- Which status do your things have in this case? Still “Bridge offline” or any configuration error?
- What happens if you disable and re-enable such a thing through the gui?
- Do you really see any received message in this case?
Problem 2: child things just pretend to be only
- Is this the case for all things or just a few?
- Which log messages do you get? First the bridge should go online, then the things should go online (initializeThing thing id bridge status ONLINE), afterwards you should see a “Listener added: (EnOceanId as long)”.
- What happens if you receive a message for such a thing? If you see “ESP Packet payload xxx for ID received” the ThingHandler has received the message from the bridge and is online.
I can’t answer all questions right away. I will check the log files when this happens again.
The things say „Bridge offline“. When I disable and reenable them through the gui they immediately work perfectly fine. But I only see received messages after I reenabled the things, when they are still in Bridge offline state I don’t get any messages. To be more precise: I do not get any updates on item level, I would also need to check the logs to see if there’s something happening on the binding level.
I would need to wait for this rather rare case to check the logs in detail. However I can answer your first question: it’s usually only the case for a single device, all other devices are working fine.
Ok today it happened again (Case 1):
The affected thing remains in state “ERROR: BRIDGE” and in the details it says: Status: OFFLINE - BRIDGE_OFFLINE.
And the good news is that I actually see an exception in the logs:
2021-10-18 03:15:05.588 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred during notification about bridge status change on thing 'enocean:windowSashHandleSensor:160542a4f3:058A42A4': null java.util.ConcurrentModificationException: null at java.util.HashMap.computeIfAbsent(HashMap.java:1134) ~[?:?] at org.openhab.binding.enocean.internal.transceiver.EnOceanTransceiver.addPacketListener(EnOceanTransceiver.java:378) ~[?:?] at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.addPacketListener(EnOceanBridgeHandler.java:383) ~[?:?] at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.addPacketListener(EnOceanBridgeHandler.java:378) ~[?:?] at org.openhab.binding.enocean.internal.handler.EnOceanBaseSensorHandler.validateConfig(EnOceanBaseSensorHandler.java:105) ~[?:?] at org.openhab.binding.enocean.internal.handler.EnOceanBaseThingHandler.initializeThing(EnOceanBaseThingHandler.java:99) ~[?:?] at org.openhab.binding.enocean.internal.handler.EnOceanBaseThingHandler.bridgeStatusChanged(EnOceanBaseThingHandler.java:259) ~[?:?] at org.openhab.core.thing.internal.ThingManagerImpl$5.run(ThingManagerImpl.java:964) [bundleFile:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?] at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?] at java.lang.Thread.run(Thread.java:829) [?:?]
So maybe a ConcurrentHashMap should be used for the listeners. This will probably get worse the more sensors are in place.
I found this exception in my logs this weekend too. However I had to really often stop and restart my prod openhab environment, even with my approx 70 enocean things. So I build up a things file with 200 entries in my dev env. With this file I could reliable reproduce this problem. Reason for this problem is that the ThingManagerImpl indeed starts a new thread for each thing of a bridge to inform them about its status update (notifyThingsAboutBridgeStatusChange). I was not aware of this. Different threads accessing a single collection is never a good idea
However I implemented a slightly different solution. I will update your PR later. Many thanks for your observation.
Ok perfect, maybe this will also fix the second really rare case for me. I think this might also be related.
@fruggy83 Hi Daniel,
is there some progress on the ReCom and ReMan implementation?
Background of my question is that I’m testing the OPUS 2 Bridge for roller shutters, I want to use in a new extension of my house. But I’m not able to use it with homegear properly. And I hate the idea of maintaining two installations. So I really would like to see this in OpenHab.
Can I do something to speed up things. I can’t write code, but I can test, document or even sponsor you with the Opus Device…
PS: Your implementation works very well. I have now Eltako, NOD-ON and Peha devices. They all work perfect. Thank You!
Has anyone else used the EEP A5-10-12?
Is there a workaround to the missing humidity channel. Right now it gets slammed into setpoint channel. Temperature is displayed incorrectly item is valued 12,1 while actual temperature is 28,5. (Correct conversion 0…250 should be 0…40 °C (Value)/250*40)
In this thread I found similar issue with A5-10-10 that was fixed. git Issue 81
The quote " I had to update all EEP from A5-10-10 onwards." Implies the fix did not reach A5-10-12 correctly
Daniel, can you please flix the A5-10-12 to contain the RH value?
The eep was fixed.
I use the humidity channel with this eep.
Please read here:
I am not sure if it is already fixed in official binding, I use the openocean addon and it is working perfectly.
Thanks for the quick answer. Indeed I still had the 3.2.0.M4 version of Official enocean binding installed that comes with latest Tesing release. My bad.
Ater unisnstall and restart with only openocean jar I now see the correct chumidity channel
Does anyone know when does the official binding get the updates?
is there anyone using EEP A5-30-03. Couldn’t find any information about it in any documentation so far. Some proprietary sensor from Pentair/Jung Pumpen is using it and it’s on me integrating it to the existing openHab setup.
That gives me some headache cause using one of the existing enocean gateways listed on the manufacturers website only for a single sensor would be very pricy.
Any advice would be appreciated.
In my opinion even the cheapest gateway solutions don’t really justify their use when only used with one single sensor. Cost was a factor for me as well so I used an enOcean Pi module on an esp32 microcontroller which you would still need to pay something above 30€ for in Germany. However I soon realised that the antenna on the enOcean Pi is rather weak so I replaced it with an Eltako antenna which I think cost me another 30€. This is still relatively cheap in total but still questionable when only used with a single sensor (you probably don’t need a better antenna though if you only need to receive from one device).
Since this setup is working very reliably however I could recommend to try something similar. The only thing I’m still missing badly is a neat little case for my gateway to get rid of the mess on my cupboard…
Edit: the EEP A5-30-03 does not seem to be supported yet though. So this would still require some coding on your end unless you find someone else willing to do it.