Fehler "uninitialized value in string" 00_OWX.pm

Begonnen von kaizo, 01 Juni 2018, 12:37:03

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Natürlich les ich das - aber der Thread hat doch jetzt schon einen Bart. Sieht so aus, als ob die queue leer ist - aber das sollte so gar nicht vorkommen.

LG

pah


Homalix99

Guten Morgen pah,

mag sein dass das Thema einen "Bart" hat, jedoch scheint es nicht gelöst zu sein. Es geht mir nicht nur um die Warn-Meldungen.
Die kann ich mit auskommentieren der use warnings Zeile schnell abdrehen.
Ich habe mit OWX massive Probleme.
1. OWTHERM meldet für manche DS18B20 Sensoren CRC Fehler,
2. Die Fehler im internal ERRCOUNT zählen auch bei anderen Sensoren hoch, nach einem reboot sind es plötzlich wieder ganz andere, vorher völlig unauffällige Sensoren.
3. Ein get devices am Busmaster bringt meist keinen oder zeigt zufällig nur einen von meinen 12 Sensoren an. Wenn wenig angezeigt werden, erscheint im Log die Fehlermeldung: "OWX_SER::Search CRC failed on bus 1w_Busmaster".
An der Bus-Struktur und am Bus liegt es def. nicht. Den Bus habe ich geschirmt in Sterntopologie aufgebaut und mit Speicher-Oszi das Verhalten der Bitwechsel verfolgt. Da sieht alles gut aus.
Die Probleme entstehen scheinbar durch interne Beeinflussung innerhalb fhem.
OWX auf leerer fhem-Konfig läuft ohne Probleme, die ERRCOUNT bleiben auf null.
Nur ich möchte halt keinen zweiten RasPi nur für OWX laufen lassen, sondern möchte der Ursache auf die Schliche kommen.

Gruß

Alex
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

Prof. Dr. Peter Henning

Ich habe deutlich mehr als 12 Sensoren auf einem Bus, und keine Probleme.

Das beschriebene Fehlerbild sieht eben nicht danach aus, als ob auf dem Bus alles in Ordnung wäre - sondern vielmehr nach massiven Störungen. CRC-Fehler werden nämlich nicht durch die Software erzeugt, sondern können nur auf dem Weg über den Bus entstehen.

Bei dem Stichwort "Sterntopologie" geht bei mir eine kleine rote Warnlampe an. Das hier beachtet? https://wiki.fhem.de/wiki/1-Wire_Busverlegung#Topologie

LG

pah

Homalix99

Hallo pah,
1. Sorry habe mich falsch ausgedrückt.
Ich habe eine Lineare Topologie mit sternförmiger Anordnung einzelner Gruppen,
Also genau so, wie in der 3. Abbildung gemäß Deinem Links.

2. Wenn ich das USB-Anschluss Kabel des
Denkovi Busmasters auf meinen 2. RasPi umstecke und dort das
OWX auf einer leeren FHEM Konfiguration betreibe, werden
a) immer alle Sensoren erkannt (bei get devices), auch neue, die dazukommen werden sofort erkannt
b) es gibt keine CRC Fehler und auch sonst keine Warnings
c) auch nach tagelangem Betrieb bleiben die ERRCOUNT Zähler aller Sensoren bei 0!

Nur wollte ich eben den Betrieb des 2. RasPi vermeiden.
Das ist der Beweis, dass es nicht am Bus liegt. Am RPi auf dem FHEM läuft, sind alle GPIOs in Verwendung, sowie ca 25 HomeMatic Devices am laufen und vieles mehr, was schon einiges an Last erzeugt. Irgend etwas beeinflusst da jedoch das OWX, so dass es nicht stabil läuft.
Und das möchte ich abgestellt sehen.
VG
Alexander
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

Prof. Dr. Peter Henning

ZitatIrgend etwas beeinflusst da jedoch das OWX, so dass es nicht stabil läuft.
Sorry, aber da widerspreche ich. Es gibt keinen, ich wiederhole keinen, Mechanismus, der per Software CRC-Fehler in die von 1-Wire Devices gelieferten Daten einbaut. Auch Homematic-Devices koexistieren problemlos mit OWX - ich habe da ein paar mehr, als nur 25 in Betrieb.

Alles zusammen problemlos auf einem Raspberry Pi 3 (den ich erst vor kurzer Zeit durch andere Hardware ersetzt habe).

Also, woran kann es liegen? Ich lese "alle GPIOs in Verwendung". Da scheint mir ein Problem zu liegen, denn vieles auf der unteren Ebene des Raspberry Pi ist eben nicht in der Hardware realisiert, sondern wird emuliert - beispielsweise der serielle Port. Hier haben wir schon vor Jahren Latenzen gemessen, die sich bis zu 90 Minuten (!!) aufgeschaukelt haben. Muss irgendwo unter EBUS noch im Forum zu finden sein.

ich tippe also darauf, dass durch das "alle GPIOs in Verwendung" erhebliche Timing-Probleme bei der Abfrage des (seriellen) USB-Devices auftreten.

LG

pah

Homalix99

Hallo pah,

ich denke auch, dass Deine Vermutung eher zutrifft. Ich beobachte das Verhalten meiner Fhem Installation dahingehend ja schon längere Zeit. Da sind auch schon sehr kuriose Dinge passiert, die ich mir nicht erklären konnte, aber reproduzierbar waren.
Als Beispiel: Öffnen eines Fenster (via GPIO verbunden) löste z. B. innerhalb von 20 Sek. immer eine Warning aus (weiß aber nicht mehr, ob es eine aus dem Modul OBIS oder OWX war. Diese Effekte waren jedoch kurz nach restart vom RPi noch nicht vorhanden sondenn, wie Du beschreibst haben die sich aufgeschaukelt.
Nun werde ich aber nicht mehr die Zeit investieren, nach einer Lösung zu suchen, zumal es wirklick von den GPIOs her zu kommen scheint, sondern betreibe jetzt eben den zweiten RPi nur mit OWX und arbeite mit fhem2fhem. Seither läuft alles perfekt.
Vielen Dank nochmal für Deine Antwort.

VG

Alexander
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

wbini

Hallo Homalix99,

kann das mit den Timintgsproblemen bestätigen, habe seit langem auch das gleiche Problem. Und genau wie bei Dir, ist auf einem nackigem Pi 3 (ohne Verwendung der GPIOs) das Log-File frei von 1Wire-Prpblemen.
Da mich ein paar CRC-Fehler im Log nicht stören, bin ich mit meinen fhem noch auf meinem alten Pi 2 drauf.
Die Menge an WARNINGS "fhem.pl: Use of uninitialized value in string eq at ./FHEM/00_OWX.pm line 1545." sind dank Änderung der Zeile 1545 weg:
     if( ($qlen==1) || (($qlen > 1) && $queue->[1]{$hash} && ($queue->[1]{$hash} eq $slave)) ){
und das Logfile dadurch sehr übersichtlich.

Gruß,
wbini

Homalix99

Hallo wbini,

da bin ich irgendwie froh, endlich die Ursache für diese Fehlverhalten zu wissen. Ich habe da schon viel Zeit investiert und bin auf keinen grünen Zweig gekommen. Bei OWX konnte ich max. 10 Sensoren einigermassen stabil am Laufen halten. Jeder weitere der hinzukam verursachte (nicht unbedingt beim hinzugekommenen selbst) massiv CRC Fehler. Auf der ERRCOUNT bei den einzelnen Sensoren blieb nur bei Null, wenn nicht mehr als 4-6 Sensoren angeschlossen waren.
Auch aus anderen Modulen wie OBIS (auch via USB angebunden) kamen von Zeit zu Zeit seltsame Perl-Warnings.
Jetzt habe ich am alten RPi nur OWX am Laufen, gerade 13 Sensoren ohne irgendwelche Auffälligkeiten.
Wollte halt den Dauerbetrieb eines zweiten RPi vermeiden, geht aber nicht anders.
Da fällt mir gerade noch ein, wie ich vor OWX meine (damals) 10 Sensoren über GPIO4 betrieben hatte, führte das schon zu erheblichen Verzögerungen. Das 99_perfmon.pm hat im Log häufig bis zu 4 Sekunden delay und apptime zeigte schön, dass es ausschließlich von den Sensoren kam. Jetzt ist mir das klar.

VG

Alex
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)