[Gelöst] Modul THZ: Alle 12 Sekunden "/dev/ttyUSB0 reappeared" im Log

[MarcusR]

Liebe FHEM-Gemeinde,

Corona-bedingt habe ich endlich Zeit gefunden, meine LHZ zu warten und die Anlage dabei auch mal mit FHEM zu verbinden. Die Einrichtung klappte auch prima, allerdings habe ich jetzt ca. alle 12 Sekunden ein /dev/ttyUSB0 reappeared im Log. Und auch nur diesen Eintrag, es wechselt sich nicht mit einer "Disconnected"-Meldung ab. Darüber hinaus klappt die Abfrage von Werten als auch die Anlage selbst einwandfrei.

Verbindung: Modul THZ => FHEM auf Raspberry Pi => USB => USB-Verlängerung (stellt sich als Hub dar) => LHZ303
Zeitgleich sind am USB-Port noch ein 1-Wire-Adapter sowie ein Maus/Tastatur-Dongle angeschlossen.

Definition:

Code Auswählen Erweitern


define lwz THZ /dev/ttyUSB0@57600
setuuid lwz 5e8736c5-f33f-c353-5857-181858baa80861d3
attr lwz devStateIcon opened:10px-kreis-gruen disconnected:10px-kreis-rot
attr lwz dummy 1
attr lwz interval_sGlobal 180
attr lwz interval_sHistory 3600
attr lwz nonblocking 1
attr lwz room Heizung
attr lwz simpleReadTimeout 10
attr lwz userReadings outsideTemp {(split ' ',ReadingsVal($name,"sGlobal",0))[1]},flowTemp {(split ' ',ReadingsVal($name,"sGlobal",0))[3]},returnTemp {(split ' ',ReadingsVal($name,"sGlobal",0))[5]},hotGasTemp {(split ' ',ReadingsVal($name,"sGlobal",0))[7]},dhwTemp {(split ' ',ReadingsVal($name,"sGlobal",0))[9]},flowTempHC2 {(split ' ',ReadingsVal($name,"sGlobal",0))[11]},evaporatorTemp {(split ' ',ReadingsVal($name,"sGlobal",0))[13]},condenserTemp {(split ' ',ReadingsVal($name,"sGlobal",0))[15]},mixerOpen {(split ' ',ReadingsVal($name,"sGlobal",0))[17]},mixerClosed {(split ' ',ReadingsVal($name,"sGlobal",0))[19]},heatPipeValve {(split ' ',ReadingsVal($name,"sGlobal",0))[21]},diverterValve {(split ' ',ReadingsVal($name,"sGlobal",0))[23]},dhwPump {(split ' ',ReadingsVal($name,"sGlobal",0))[25]},heatingCircuitPump {(split ' ',ReadingsVal($name,"sGlobal",0))[27]},solarPump {(split ' ',ReadingsVal($name,"sGlobal",0))[29]},compressor {(split ' ',ReadingsVal($name,"sGlobal",0))[31]},boosterStage3 {(split ' ',ReadingsVal($name,"sGlobal",0))[33]},boosterStage2 {(split ' ',ReadingsVal($name,"sGlobal",0))[35]},boosterStage1 {(split ' ',ReadingsVal($name,"sGlobal",0))[37]},highPressureSensor {(split ' ',ReadingsVal($name,"sGlobal",0))[39]},lowPressureSensor {(split ' ',ReadingsVal($name,"sGlobal",0))[41]},evaporatorIceMonitor {(split ' ',ReadingsVal($name,"sGlobal",0))[43]},signalAnode {(split ' ',ReadingsVal($name,"sGlobal",0))[45]},evuRelease {(split ' ',ReadingsVal($name,"sGlobal",0))[47]},ovenFireplace {(split ' ',ReadingsVal($name,"sGlobal",0))[49]},STB {(split ' ',ReadingsVal($name,"sGlobal",0))[51]},outputVentilatorPower {(split ' ',ReadingsVal($name,"sGlobal",0))[53]},inputVentilatorPower {(split ' ',ReadingsVal($name,"sGlobal",0))[55]},mainVentilatorPower {(split ' ',ReadingsVal($name,"sGlobal",0))[57]},outputVentilatorSpeed {(split ' ',ReadingsVal($name,"sGlobal",0))[59]},inputVentilatorSpeed {(split ' ',ReadingsVal($name,"sGlobal",0))[61]},mainVentilatorSpeed {(split ' ',ReadingsVal($name,"sGlobal",0))[63]},outside_tempFiltered {(split ' ',ReadingsVal($name,"sGlobal",0))[65]},relHumidity {(split ' ',ReadingsVal($name,"sGlobal",0))[67]},dewPoint {(split ' ',ReadingsVal($name,"sGlobal",0))[69]},P_Nd {(split ' ',ReadingsVal($name,"sGlobal",0))[71]},P_Hd {(split ' ',ReadingsVal($name,"sGlobal",0))[73]},actualPower_Qc {(split ' ',ReadingsVal($name,"sGlobal",0))[75]},actualPower_Pel {(split ' ',ReadingsVal($name,"sGlobal",0))[77]},collectorTemp {(split ' ',ReadingsVal($name,"sGlobal",0))[79]},insideTemp {(split ' ',ReadingsVal($name,"sGlobal",0))[81]},windowOpen {(split ' ',ReadingsVal($name,"sGlobal",0))[83]},quickAirVent {(split ' ',ReadingsVal($name,"sGlobal",0))[85]},pFanstageXAirflowInlet {(split ' ',ReadingsVal($name,"sFan",0))[5]},pFanstageXAirflowOutlet {(split ' ',ReadingsVal($name,"sFan",0))[7]}
attr lwz webCmd get sGlobal


Da ich mich mit der Handhabung und Adressierung von USB-Geräten unter Debian überhaupt nicht auskenne, hoffe ich, dass mir hier jemand helfen kann:

• Können in Debian mehrere USB-Geräte einfach über /dev/ttyusb0 adressiert werden, d.h. ist meine Definition richtig?
• Woher könnte die Fehlermeldung kommen?
• Wie kann ich die Ursache beheben oder zur Not auch nur die Meldung abstellen? (verbose=0 hat nicht geholfen)

Vielen Dank, viele Grüße & bleibt alle gesund
Marcus

<-------------- UPDATE -------------->
Nach einigen Versuchen konnte ich die Ursache per Ausschlussverfahren auf die USB-Verlängerung zurückführen, die ich verwendet habe, um die Strecke zwischen dem RPi, auf dem FHEM läuft, und der Heizung zu überbrücken. Bislang lief die Verlängerung (Ist technisch gesehen ein USB-gespeister Hub mit einem langen Kabel dran) zwar zuverlässig, wenn auch etwas langsam. Aber ohne die Verlängerung habe ich seit Tagen Messwerte und keinen Fehler im Log.

[immi]

Hi MarcusR,
>>Können in Debian mehrere USB-Geräte einfach über /dev/ttyusb0 adressiert werden, d.h. ist meine Definition richtig?
bitte dummy und nonblocking nicht verwenden


Wenn Du keine verbesserung hast,  dann Deine usb verbindung ist nicht stabil.

moglichkeit 1 usbkabel zu lang.
Hast Du betrachtet die möglichkeit die USB-Verlängerung wegzunehmen, deine Raspi direkt neben die LHz303 zu haben? Ethernet kabel kann auch sehr lang sein.

moglichkeit 2 Spannungsversorgung deines Raspi
Hast Du betrachtet die möglichkeit andere Spannungsversorgung (mit oder ohne Erde) zu verwenden?
Hast Du betrachtet die möglichkeit RS232 zu verwenden? Es ist stabiler ... EMV von  LHZ303

moglichkeit 3
Konflikt mit one-wire --> kontrolliere masse und erde

Du kannst gern hier weitersuchen; Dein Problem würde bereit lange ausdiskutiert.
https://forum.fhem.de/index.php/topic,33452.0.html

l.g.
Immi

[MarcusR]

Hi Immi,

vielen Dank für Deine Rückmeldung!

>>Können in Debian mehrere USB-Geräte einfach über /dev/ttyusb0 adressiert werden, d.h. ist meine Definition richtig?
bitte dummy und nonblocking nicht verwenden

Ich hab beide Attribute mal rausgenommen. Warum werden sie denn nicht unterstützt? Bei "nonblocking=0" hätte ich Angst, dass das Modul FHEM blockieren kann, die Erfahrung hab ich bei einigen anderen gemacht :/
Ich lass es jetzt mal ein paar Tage laufen und schaue, ob der Fehler wieder auftritt.

Wenn Du keine verbesserung hast,  dann Deine usb verbindung ist nicht stabil.

moglichkeit 1 usbkabel zu lang.
Hast Du betrachtet die möglichkeit die USB-Verlängerung wegzunehmen, deine Raspi direkt neben die LHz303 zu haben? Ethernet kabel kann auch sehr lang sein.

Klar, hab ich. Aber FHEM läuft bei mir auf einem RasPi im Schaltschrank, der ist nicht sehr mobil  Falls der Fehler aber noch auftritt, würde ich es mal mit einem zweiten RasPi probieren, den ich dann in der Heizung plaztieren kann, dann ist die USB-Leitung nicht zu lang.

moglichkeit 2 Spannungsversorgung deines Raspi
Hast Du betrachtet die möglichkeit andere Spannungsversorgung (mit oder ohne Erde) zu verwenden?

Nein, bislang nicht. Die Spannungsversorgung erfolgt über ein Meanwell-Netzteil, dass glaube ich keine Erdung hat. Vermutest Du ein unausgeglichenes Potential als Störungsquelle auf dem USB?

Hast Du betrachtet die möglichkeit RS232 zu verwenden? Es ist stabiler ... EMV von  LHZ303

Ja, habe ich. Die zusätzliche Komplexität und Fehlerquelle durch eine RS232/USB Bridge wollte ich mir aber gerne sparen. Wäre aber Plan B, falls ich USB gar nicht stabil zum Laufen bekomme.

moglichkeit 3
Konflikt mit one-wire --> kontrolliere masse und erde

One-Wire ist ebenfalls nicht geerdet, das läuft über einen USB-Adapter am RasPi. Meinst Du, dass sich GND erden soll?

Viele Grüße
Marcus

[immi]

Hi Immi,

vielen Dank für Deine Rückmeldung!
Ich hab beide Attribute mal rausgenommen. Warum werden sie denn nicht unterstützt? Bei "nonblocking=0" hätte ich Angst, dass das Modul FHEM blockieren kann, die Erfahrung hab ich bei einigen anderen gemacht :/
Ich lass es jetzt mal ein paar Tage laufen und schaue, ob der Fehler wieder auftritt.
Klar, hab ich. Aber FHEM läuft bei mir auf einem RasPi im Schaltschrank, der ist nicht sehr mobil  Falls der Fehler aber noch auftritt, würde ich es mal mit einem zweiten RasPi probieren, den ich dann in der Heizung plaztieren kann, dann ist die USB-Leitung nicht zu lang.
Nein, bislang nicht. Die Spannungsversorgung erfolgt über ein Meanwell-Netzteil, dass glaube ich keine Erdung hat. Vermutest Du ein unausgeglichenes Potential als Störungsquelle auf dem USB?
Ja, habe ich. Die zusätzliche Komplexität und Fehlerquelle durch eine RS232/USB Bridge wollte ich mir aber gerne sparen. Wäre aber Plan B, falls ich USB gar nicht stabil zum Laufen bekomme.
One-Wire ist ebenfalls nicht geerdet, das läuft über einen USB-Adapter am RasPi. Meinst Du, dass sich GND erden soll?

Viele Grüße
Marcus

hi markus
I have not finished to programm and  evaluate the nonblocking feature. With your firmware, you should see very very small improvements; I started it for much older firmwares which block fhem for some ms.
Therefore avoid it for now (unless you can debug it).

Concerning the ground/earth, some people noticed problems with some raspi charger in connection to a direct usb to the heatpump.
Link below: you have to read lots of pages.
It  can also depend to your heatpump and its grounding concept.
I never had issues with my usb2serial adapter and  a long serial cable (despite my soldering of the cable is very bad

What I do not understand is the 12s period, in which you get the problem.
Just tell me if you get some improvements by removing the nonblocking.
Keep your fhem updated;
stay safe and healthy
immi

[Beta-User]

Some additional remarks:

I assume, it's still the PI2 from the signature we're talking about? If it's a 4th gen. model, the problem may be related to a faulty USB implementation.

In general, imo it's best practice to address all tty stuff in "by-id" manner (or, if not possible due to identical USB data (CHG340)) "by-path" (see wiki: mehrere USB-Geräte... for details). Otherwise the problem may be related to other USB stuff trying to use the same connection. So are there any other USB devices attached to the Pi?

[MarcusR]

I have not finished to programm and  evaluate the nonblocking feature. With your firmware, you should see very very small improvements; I started it for much older firmwares which block fhem for some ms.
Therefore avoid it for now (unless you can debug it).
What I do not understand is the 12s period, in which you get the problem.
Just tell me if you get some improvements by removing the nonblocking.

I can't do a debugging due to knowledge and time. But since I removed the nonblocking attribute, the error appears way less often on the log:

Code Auswählen Erweitern


2020.05.10 02:59:28 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.10 02:59:29 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.10 03:27:17 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.10 03:27:18 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.10 04:37:16 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.10 04:37:16 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.10 06:23:08 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.10 06:23:09 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.10 07:43:10 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.10 07:43:11 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.10 23:45:36 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.10 23:45:36 1: /dev/ttyUSB0 reappeared (lwz)
-------------
2020.05.11 05:48:43 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.11 05:48:43 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.11 08:53:27 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.11 08:53:28 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.11 09:29:31 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.11 09:29:32 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.11 12:08:33 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.11 12:08:33 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.11 12:59:40 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.11 12:59:41 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.11 15:19:48 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.11 15:19:49 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.11 16:19:24 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.11 16:19:24 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.11 17:37:54 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.11 17:37:55 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.11 17:57:02 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.11 17:57:02 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.11 19:10:58 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.11 19:10:58 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.11 20:51:00 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.11 20:51:00 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.11 23:01:13 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.11 23:01:14 1: /dev/ttyUSB0 reappeared (lwz)
2020.05.11 23:48:11 1: /dev/ttyUSB0 disconnected, waiting to reappear (lwz)
2020.05.11 23:48:12 1: /dev/ttyUSB0 reappeared (lwz)


Keep your fhem updated;

It is up to date.

I assume, it's still the PI2 from the signature we're talking about? If it's a 4th gen. model, the problem may be related to a faulty USB implementation.

Actually, it's still the PI2.

In general, imo it's best practice to address all tty stuff in "by-id" manner (or, if not possible due to identical USB data (CHG340)) "by-path" (see wiki: mehrere USB-Geräte... for details). Otherwise the problem may be related to other USB stuff trying to use the same connection. So are there any other USB devices attached to the Pi?

Yes, there are. This is why I suspected an incorrect / inaccurate adressing of the USB device. I'll look up the wiki page and try to address the heat pump USB device by id. Thanks for the tip!

Regards
Marcus

[MarcusR]

This is why I suspected an incorrect / inaccurate adressing of the USB device. I'll look up the wiki page and try to address the heat pump USB device by id. Thanks for the tip!

I tried addressing the USB device by ID as well as different baud-rates and a fresh FHEM on a RPi 4. In every case, I got the same error after a while.

Only after I connected the heat pump without USB extension (which is actually an USB powered hub with a long cable on it) directory to the RPi 4, I got no errors since activating.

So, basically the USB extension caused these errors even if other devices worked well with it. Now I have to find a way to let the RPi 4 close or within the heat pump and try to define a FHEM2FHEM connection to get the measurement values.

Anyway, thank you all for your help and support!

Kind regards
Marcus