Everything always works well at first, but after about 24 hours I don’t get any more feedback and can’t send anything anymore. Only after a restart of Home Assistant does it work for a while.
After a few attempts, it looks to me as if it has something to do with the roller shutter actuators (FSB14). In the Log Viewer, the cylic bus query usually aborts suddenly after an FSB14 actuator has been activated.
Sorry, my mistake.
It turned out that it was due to a bad usb connection. Replaced the cable and now apparently runs stably. Strange that problem always came only when activating the FSB14
I am also using Eltako Baureihe 14 with fhem and I am interesting to connect my RS485 environment to HA. I am using a FAM14 and I heard, that the USB-connection is not running smoothly. This means I have to order a FGW14 USB.
My question:
does anyone know if this integration is also running with the FGW14-IP?
…yes, I think also that this will not work. I had a phonecall with the eltako developement round about two, three months ago and I was told that there is something in planning with BR14 and mqtt as gateway for the RS485Bus…Do I wait or do I buy the USB gateway.
Does anyone know how long the USB Cable can be? My HA-Server is not in the immediate vicinity
In the Eltako description I had read that the usb line may have a maximum of 4.5 meters, otherwise a usb hub must be in between. I use an aktive usb cable with 5 meters.
Hello @netzgauner,
I also experienced problems with usb-connections and invested a bit about how to make the eltako integration more stable. It actually uses a dedicated serial port and for me it looked like HA does not support reconnects of serial ports in case of connection loss. Couldn’t find something in the dev docs or community. I was just able to establish the serial port during the start phase of the eltako integration and in case of failures I was only able to fix it by manually restarting HA.
If you have any ideas how this could be made more stable in an automated fashion please let me know.
Hi philipp14,
thanks for your work on the eltako integration.
Would it be possible to restart the integration automatically if there are problems with the USB connection? Wouldn’t be the prettiest variant but better than HA restart.
Then it would of course be good if the current values of the FAB14 were stored, so that not all shutters would be displayed as open.
Establishing Automatic Reconnection:
I’ve explored a bit how that could be possible. Unfortunately I haven’t found no way how to detect if the connection is broken nor a way to automatically reconnect or restart the integration.
I tested reconnecting which didn’t work at all. HA is quite well secured by the underlying Linux and the surrounding is giving the integration the already established serial port. There is no direct access to the serial port (USB connection), it runs in a different environment/container.
If you find any way how that could be realized, I’m happy to support and to implement this feature.
Health Checks and Restart from our Side:
Maybe it could be possible to run a frequently executed test which checks the connection and can trigger a restart. It feels quite wrong but could be an intermediate solution.
Do you know other integrations and how they solve it?
I’ve just looked into Wifi and Bluetooth connected devices. But this is different because in this kind of connections interruptions are expected from HA and reconnecting is a support function by the platform.
Getting the Current State of the Eltako Devices so that you know where your shutters are:
I guess I can help here. There is a mode for FMA14 in which FAM14 polls constantly for all device states and puts them on the bus that applies to all. HA gets informed about the current state and changes it in case.
Downside is it happens quite often even per second which makes the bus quite chatty.
I wanted to start an tutorial in which I described the setting: https://github.com/grimmpp/home-assistant-eltako/blob/f6ba30d72efeef278d6c4db743a297461126eb21/tutorials/simple_eltako_setup.md but you can also find it in the manual. Check out Mode Switch BA (for Betriebsart) and position 4.
If you plugin the USB cable into FAM14 you can also trigger the devices manually to send a state info message by using the eltako14bus command enumerate. Unfortunately the gateway is filtering such commands from outside because of security reasons (It doesn’t distinguish if the command is coming via air or cable).
Unfortunately, I’m not really familiar with the topic of development integrations and can’t really help with it.
To 1. Establishing Automatic Reconnection:
How to detect if the connection is broken:
Is it not possible, as you described in 3. to check if the constantly poll is working ?
To 2. Health Checks and Restart from our Side:
I only found a way to restart an integration via a url and an access token.
As it is described here. Page is in German language.
To 3. Getting the Current State of the Eltako Devices
My FAM14 is on BA=4. But in the log viewer I see this cyclic status messages only bring the FSR14 and FUD14.
A signal comes from the FSB 14 only when the status changes.
I noticed another small mistake. When the roller shutters (FSB14) move from below to an intermediate position, “closed” is displayed with the value. From above in intermediate position “opened” with value.
However, it would probably always have to be “open” with value in an intermediate location.
Otherwise, there will be problems with creating a scene. With “closed” in the intermediate position, the roller shutter always lowers completely by aktivating the scene.
can you check what status message went over the bus and how value changed function should behave?
Unfortunately I have right now no proper setup to test the shutter actor.
Just cross-checked this. Via MQTT using a different method. Always displayed openly with the appropriate value. Except, of course, the shutter is completely closed.
However, MQTT does not display a working status, i.e. open or close.
But, the MQTT solution is not via USB but wireless.
About the value changed funktion.
As I said, I don’t really know anything about it. But is it possible that there must also something like a “self._attr_is_closed = False” be in line 214 or after line 201?
I am currently testing your HACS Component/Eltako Integration, @philipp14. I have a basic experimental Eltako Bus Setup with FAM14, FGW14-USB, FUD14, FSR14-4x and some Wall Switches.
Just some little info considering USB-Cables via FGW14-USB. I tried connecting the FGW14-USB via USB-RJ45-Extenders (cheap LogiLink) via Cat7a cable of around 10-15m which at first failed (it worked when directly connected to me HA running Pi). I added a USB-Y-Splitter cable (2 male to 1 female / power splitter) I had lying around on the FGW14-USB side and plugged it to USB power supply - it could connect now.
Before I got this log entry when trying to add the integration and selecting the USB path:
...
File "/config/custom_components/eltako/gateway.py", line 141, in validate_path
serial.Serial(path, 57600, timeout=2)
File "/usr/local/lib/python3.10/site-packages/serial/serialutil.py", line 244, in __init__
self.open()
File "/usr/local/lib/python3.10/site-packages/serial/serialposix.py", line 336, in open
self._update_dtr_state()
File "/usr/local/lib/python3.10/site-packages/serial/serialposix.py", line 713, in _update_dtr_state
fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_DTR_str)
OSError: [Errno 5] I/O error
File "/usr/local/lib/python3.10/site-packages/serial/serialposix.py", line 336, in open
self._update_dtr_state()
File "/usr/local/lib/python3.10/site-packages/serial/serialposix.py", line 713, in _update_dtr_state
fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_DTR_str)
OSError: [Errno 5] I/O error
