connection problem

[jerguitariste]

Is there an existing issue for this?

• I have searched the existing issues

I'm having the following issue:

I connected my raspberry pi 3 to an ecomax810P controller with the ester_X40 thermostat to RS-485 USB gateway, I regularly have connection and disconnection problems.
approximately every 30 seconds, there is a connection then a disconnection
I pressed several times on /dev/ttyUSB0 Detect sub-devices
same problem

I have following devices connected:

• ecoMAX 3xx series
• ecoMAX 8xx series
• ecoMAX 9xx series
• Expansion module B
• Expansion module C
• ecoSTER 200/ecoSTER Touch
• ecoLAMBDA
• ecoNET 300

I'm connecting to my devices using:

USB to RS-485 adapter

I'm seeing following log messages:

/dev/ttyUSB0 Connection status était déconnecté
19:16:27 - Il y a 7 minutes
/dev/ttyUSB0 Connection status était connecté
19:15:47 - Il y a 8 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:15:27 - Il y a 8 minutes
/dev/ttyUSB0 Connection status était connecté
19:14:47 - Il y a 9 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:14:27 - Il y a 9 minutes
/dev/ttyUSB0 Connection status était connecté
19:13:47 - Il y a 10 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:13:27 - Il y a 10 minutes
/dev/ttyUSB0 Connection status était connecté
19:12:47 - Il y a 11 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:12:27 - Il y a 11 minutes
/dev/ttyUSB0 Connection status était connecté
19:11:47 - Il y a 12 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:11:27 - Il y a 12 minutes
/dev/ttyUSB0 Connection status était connecté
19:10:47 - Il y a 13 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:10:27 - Il y a 13 minutes
/dev/ttyUSB0 Connection status était connecté
19:09:47 - Il y a 14 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:09:27 - Il y a 14 minutes
/dev/ttyUSB0 Connection status était connecté
19:08:48 - Il y a 15 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:08:28 - Il y a 15 minutes
/dev/ttyUSB0 Connection status était connecté
19:07:48 - Il y a 16 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:07:28 - Il y a 16 minutes
/dev/ttyUSB0 Connection status était connecté
19:06:48 - Il y a 17 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:06:28 - Il y a 17 minutes
/dev/ttyUSB0 Connection status était connecté
19:05:48 - Il y a 18 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:05:28 - Il y a 18 minutes
/dev/ttyUSB0 Connection status était connecté
19:04:48 - Il y a 19 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:04:28 - Il y a 19 minutes
/dev/ttyUSB0 Connection status était connecté
19:03:48 - Il y a 20 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:03:28 - Il y a 20 minutes
/dev/ttyUSB0 Connection status était connecté
19:02:48 - Il y a 21 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:02:28 - Il y a 21 minutes
/dev/ttyUSB0 Connection status était connecté
19:01:48 - Il y a 22 minutes
/dev/ttyUSB0 Connection status était déconnecté
19:01:28 - Il y a 22 minutes
/dev/ttyUSB0 Connection status était connecté
19:00:48 - Il y a 23 minutes

My diagnostics data:

I pressed several times on /dev/ttyUSB0 Detect sub-devices

Code of Conduct

• I agree to follow this project's Code of Conduct

[denpamusic]

Hi,

It seems that these log messages come from your OS as plum ecomax integration doesn't write to log in French. This indicates, that connection is failing on the OS level, most likely due to hardware problem. Try with different USB port on Pi or different RS485->USB adapter and see if problem persists.

FYI Detect sub-devices button is used solely to detect freshly connected modules such as thermostats and mixers. It doesn't do anything for the connection process.

[jerguitariste]

I just changed the language to English, it works acutely. to see in time

[denpamusic]

No, you misunderstood. What I meant, is that the log messages that you provided are not originating from this integration, but from the operating system. This means that the problem lies outside of the integration.

Changing language should not affect hardware in any way. If the issue is fixed it probably is due to some other factor. Try switching back to French and see if it still works

---

🇫🇷
The following translation is done by Google Translate, I tried to optimize text for it, so hopefully it does decent job.

Non, tu as mal compris. Ce que je voulais dire, c'est que les messages de journal que vous avez fournis ne proviennent pas de cette intégration, mais du système d'exploitation. Cela signifie que le problème se situe à l'extérieur de l'intégration.

Le changement de langue ne devrait en aucun cas affecter les périphériques matériels. Si le problème est résolu, cela est probablement dû à un autre facteur. Essayez de revenir au français et voyez si cela fonctionne toujours.

[jerguitariste]

I understood but just the fact of having put in English it works, I will do several tests

[denpamusic]

OK. Sorry for assuming wrong then and thanks for the heads up. Hope that you'll find what's causing the issue.

[rostislav-palivoda]

Hi, I have also connection problem.
First - I can confirm that only FTDI chip can work stable for a long time.
Second - During VM backup I detach USB device and after backup I attach it. The integration can not recover its work after the USB is attached to the Hass OS VM.

[denpamusic]

@rostislav-palivoda
Hi, thank you for the feedback!

For the first point I expected as much, especially with weaker hardware or VMs. FTDI's have pretty reliable software flow control, which works wonders on higher baudrates. Timing is crucial with RS485, as standard doesn't include any flow control at all. Adding any additional layers such as VMs and, by a lesser extent, containers, further exacerbates this problem. So chips which include proprietary automatic flow control have big advantage in stability.

The second point is interesting though. On re-connection attempt, PyPlumIO reconstructs pyserial-asyncio object from the scratch, so there really shouldn't be any difference between reconnect and full fledged restart. Do you get any log entries, that look like this: "Can't connect to the device, retrying in 20.0 seconds". If so, does USB device work on VM after pulling USB device out and plugging it back in? Does running # cat /dev/ttyUSB0 inside the VM produce any output after re-plugging the USB device?

[rostislav-palivoda]

@denpamusic
Hi! I've tried my backup script and I think I solved the problem by adding a timeout of 3 seconds in to it:

...
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" controlvm {591a8933-f0ef-4e8c-91c5-a079a383ecf9} usbdetach {58c7e37b-65a1-4b08-be0b-dbc03842b162}
TIMEOUT 3
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" controlvm {591a8933-f0ef-4e8c-91c5-a079a383ecf9} usbdetach {15cdc237-4a81-4739-a061-495abd62d800}
TIMEOUT 3

"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" snapshot {591a8933-f0ef-4e8c-91c5-a079a383ecf9} take "AutomaticBackup05"
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" snapshot {591a8933-f0ef-4e8c-91c5-a079a383ecf9} delete "AutomaticBackupOLD"

"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" controlvm {591a8933-f0ef-4e8c-91c5-a079a383ecf9} usbattach {58c7e37b-65a1-4b08-be0b-dbc03842b162}
TIMEOUT 3
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" controlvm {591a8933-f0ef-4e8c-91c5-a079a383ecf9} usbattach {15cdc237-4a81-4739-a061-495abd62d800}
TIMEOUT 3
 

Will wait for a week and let you know if anything comes up. Thanks!