I setup openHAB on my Synology yesterday using docker and still seeing some globalcache broken pipe issue. Will try to replace the power supply of the globalcache ( I’ve already factory erased it…) and I will also try to unplug it from my smart home system to see if it might be some sort of issue with this.
@mhilbush do you think it’s possible to rescue the error and try the command again ? I don’t think it is as the error appears later in the code and not in the rules but as I’m not an expert I prefer to ask 
Thanks a lot
I’ll take a look.
I don’t know if that helps but when the broken pipe errors occurs pinging the global cache device works just fine. (I’m pinging the device every one second and tried to find a failed ping when the broken pipe error occurs)
This is not surprising. I have every reason to believe the iTach is alive.
When the iTach is configured for serial operation, the binding makes 2 connections to the iTach.
The first connection is a persistent connection to the iTach’s command port. The binding sends a getversion command every 60 seconds to make sure the connection is open and the iTach is alive. If the getversion fails, the connection is marked offline, then a scheduled job runs to try to reconnect. From what I saw in the log, the getversion commands are successful, which suggests the iTach is alive and well, and there’s a viable connection between the binding and the iTach.
The second connection is a persistent connection to the port for sending/receiving serial commands. This is the connection that is failing when the binding tries to send a serial command to the iTach.
Thanks for the explanation. If you have any idea and how to debug this I would be more than happy to help. I don’t really know how to find the root cause and try to fix it and as I primarily want to use my openhab for timer and scheduler it’s quite a blocking issue.
I did not have any broken pipe issue for the last 3 days. I left the house so no one is using the smart home directly on the control panel in the home (so no status update from these command is sent to the global cache) and no one is using the network (as the house is empty).
I will need to investigate further but I am sending some commands (that generate feedback from lighting solution to the global cache and then OpenHab) every 5 minutes for the past 3 days and I have not seen any errors.
So I guess it’s either a feedback receive from the lightning that create the issue with the GC Connection, or an issue with the router (It’s a brand new EdgeRouter ER-X, so hopefully that’s not it).
Also I’m using a Rasperry Pi 2 and I’m wondering if it can be an hardware limitation (CPU or RAM?)
It’s possible that this is keeping the connection alive.
I doubt the RPi’s CPU/memory is the cause of the issue.
I did try the 5 minutes things when I was there and I got more broken pipe errors than when I did schedule the “keep-alive” command every 3 hours. Now even sending a command every 3 hours works fine