Readings werden zwischen verschiedenen Geräten kopiert

[rr2000]

Hi,

ich bin gerade dabei zwei Module für die Integration von smarthomatic-Geräten in FHEM vorzubereiten. Es handelt sich dabei um ein Opensource/Openhardware Projekt von Uwe Freese (siehe http://www.smarthomatic.org). Bevor ich es hier zum Review einstelle hätte ich gerne noch ein merkwürdiges Verhalten von FHEM verstanden und die daraus resultierenden Problem für die Implementierung gelöst:
Angenommen wir haben drei Geräte:

Code Auswählen Erweitern


shc_base : Basisstation
├─> shc_deva : Gerät A - ein Umweltsensor der Feuchtigkeitsmesswerte (humidity) liefert
└─> shc_devb : Gerät B - ein Umweltsensor der Temperaturmesswerte (temperature) liefert


Nachdem die ersten Messwerte von den Sensoren eingetroffen sind werden diese in den Readings gespeichert:

Code Auswählen Erweitern


shc_deva ─>{READINGS}{humidity}{VAL} = 55.3
shc_devb ─>{READINGS}{temperature}{VAL} = 23.4


Aber nacheiniger Zeit enthalten die Readings von Gerät A auch ein temperature-Reading und umgekehrt ein humidity-Reading (bei meinen Debugversuchen bin ich zu dem Schluss gekommen, dass das irgendwo im Bereich readingsBulkUpdate() liegt, bin mir aber nicht sicher):

Code Auswählen Erweitern


shc_deva ─>{READINGS}{humidity}{VAL} = 55.3
           {READINGS}{temperature} = 0         # temperature ist definiert, enthält aber weder {VAL} noch {TIME}
shc_devb ─>{READINGS}{temperature}{VAL} = 23.4
           {READINGS}{humidity} = 0            # humidity ist definiert, enthält aber weder {VAL} noch {TIME}


Wenn man FHEM neustartet, erhalten die unvollständigen Readings über WriteStatefile und ReadStatefile Default-Wert für {VAL} und {TIME}. Ab hier sehen dann die Readings so aus:

Code Auswählen Erweitern


shc_deva ─>{READINGS}{humidity}{VAL} = 55.3
           {READINGS}{temperature}{VAL} = 0
shc_devb ─>{READINGS}{temperature}{VAL} = 23.4
           {READINGS}{humidity}{VAL} = 0

Hat dieses Verhalten schon jemand beobachtet, ist das gewollt? Leider habe ich im Forum und im Wiki nichts dazu entdecken können. Könnt Ihr mir weiterhelfen?

Gruß,
Stefan

[justme1968]

das ist kein normales verhalten.

verwendest du dispatch/parse? könnte es sein das du zwischendurch aus versehen readings in das falsche device steckst?

gruss
  andre

[rr2000]

Hi Andre,

ja ich verwende dispatch/parse! Letztendlich hab ich als Grundlage sogar die Module von Dir verwendet, 36_Jeelink.pm und 36_PCA301.pm. D.h. die Struktur ist damit ähnlich . Die smarthomatic Module habe ich ausgegiebig überprüft und gedebuggt. Als Ursache kann ich den Code eigentlich ausschließen. Übrigens: Uwe Freese der Kopf von smarthomatic hat sich das ganz unabhängig von mir durchgesehen und kam zu dem gleichen Ergebnis: Irgendwo im Bereich von readingsBeginUpdate(), readingsBulkUpdate() und readingsEndUpdate(), oder den dahinterliegenden Mechanismen liegt der Fehler...

Gruß,
Stefan

[rudolfkoenig]

Irgendwo im Bereich von readingsBeginUpdate(), readingsBulkUpdate() und readingsEndUpdate(), oder den dahinterliegenden Mechanismen liegt der Fehler...

Das mag schon sein, allerdings schaffen z.Zt. etwa 200 Module diesen Fehler nicht auszuloesen. Ihr muesst uns schon verraten, wie man das macht.

[Joachim]

Moin rr2000,

kann ich so bestätigen, war allerdings bisher zu faul zum suchen wo der Fehler liegt.
In der Anlage mal zwei Bilder von einem Temperatursensor DS18B20 angebunden mit OWX/OWTHERM.
Zum rekonstruieren:
- FHEM beenden
- fhem.save löschen
- FHEM neu starten, erster Screenshot (vorher.jpg)
- in der Weboberfläche Save config drücken
- Seite neu laden
- et voila, zweiter Screenshot (falschesReading.jpg

Gruß Joachim

[rr2000]

Das mag schon sein, allerdings schaffen z.Zt. etwa 200 Module diesen Fehler nicht auszuloesen. Ihr muesst uns schon verraten, wie man das macht.

Ja ich weiß, daher vermutlich auch kein Eintrag im Forum
Ich skizzieren mal den Code wo ich die Readings, abhängig von Geräte- bzw. Message-Typ, eintrage. An keiner anderen Stelle werden die Readings sonst angetastet. Wenn gewünscht kann ich auch den gesamten Code posten.

Code Auswählen Erweitern


sub SHC_Dev_Parse($$)
{   ...   # Überprüfe Vorraussetzungen und dekodiere Nachricht
  readingsBeginUpdate($rhash);
  given ($msggroupname) {
    when ('Weather') {
      given ($msgname) {
        when ('Temperature') {
          my $tmp = $parser->getField("Temperature") / 100;    # parser returns centigrade

          readingsBulkUpdate($rhash, "temperature", $tmp);
        }
        when ('HumidityTemperature') {
          my $hum = $parser->getField("Humidity") / 10;        # parser returns 1/10 percent
          my $tmp = $parser->getField("Temperature") / 100;    # parser returns centigrade

          readingsBulkUpdate($rhash, "humidity",    $hum);
          readingsBulkUpdate($rhash, "temperature", $tmp);
        }
       ...
      }
      ...
    }
   ... # Setze state_str aus verfügbaren Readings zusammen
   readingsBulkUpdate($rhash, "state", $state_str);

   readingsEndUpdate($rhash, 1);    # Do triggers to update log file
   return @list;
}


Hinweis: Bitte nicht irritieren lassen, dass ich hier einmal die Temperatur und einmal die Temperatur plus Feuchte schreibe. Die Fehlerbeschreibung sollte möglichst einfach und verständlich sein, daher hab ich die Details weggelassen. Das Problem tritt auch mit vielen anderen Messwerte (Entfernung, Helligikeit, Luftdruck) auf (siehe Screenshots).

Gruß,
Stefan

[rudolfkoenig]

@rr2000: der Code schaut fuer mich ok aus. readingsBulkUpdate setzt die Readings ueber setReadingsVal, und dieser setzt immer VAL und TIME.

Meiner Ansicht nach ist das Problem anderswo zu suchen: irgendwer greift ohne eine Pruefung direkt auf
{READINGS}{humidity}{VAL} zu, auch wenn es noch nicht existiert, oder was aehnliches.

Sonst hilft hier mAn nur debug-Ausgabe zu streuen: ich wuerde in SHC_Dev_Parse am Anfgang
und am Ende alle Readings ausgeben, und schauen, welche Operation den Schaden anrichtet.

[Joachim]

@ Rudi,

Meiner Ansicht nach ist das Problem anderswo zu suchen: irgendwer greift ohne eine Pruefung direkt auf
{READINGS}{humidity}{VAL} zu, auch wenn es noch nicht existiert, oder was aehnliches.

Meintest Du mich?

[rr2000]

Sonst hilft hier mAn nur debug-Ausgabe zu streuen: ich wuerde in SHC_Dev_Parse am Anfgang
und am Ende alle Readings ausgeben, und schauen, welche Operation den Schaden anrichtet.

Genau das haben ich/wir versucht, über Debug-Ausgaben in SHC_Dev_Parse dem ganzen auf die Schliche zu kommen. Ergebnis: Es passiert nicht in SHC_Dev_Parse.

Mit Elipse und EPIC habe ich versucht im FHEM Code fündig zu werden. Das ist allerdings kläglich gescheitert, da bei EPIC die watch Funktion nicht geht.

[Joachim]

@ rr2000, @ Rudi,

das Problem liegt irgendwo in der fhem.pl!

Wie ich oben schon geschrieben habe, kann ich dieses Problem unter ganz anderen Vorraussetzungen bei mir reproduzieren.
Bei mir läuft FHEM auf einer FB7390, nur mit OWX/OWTHERM. Also ein Modul welches mit dem von rr2000 keine Gemeinsamkeit hat.
--> die einzige Gemeinsamkeit ist, dass auch hier unter noch nicht näher bekannten Umständen Phantom Readings auftauchen, die dann auch reproduzierbar sind. In meinem Fall das Reading Feuchte, welches es bei einem OWX Temperatursensor nicht gibt.

Gruß Joachim

[rudolfkoenig]

das Problem liegt irgendwo in der fhem.pl!

Ich finde wir sollten abstimmen.

[Joachim]

Moin Rudi,

ich fühle mich gerade, mit verlaub gesagt, von Dir verarscht.
Warum:
Ich versuche Dir bei der Eingrenzung des Problems zu helfen, es wird von Dir nicht auf dieses Hilfsangebot eingegangen, sondern ignoriert,
Wenn ich dann ein zweites mal versuche zu helfen, gibt es einen dummen Kommentar:

Ich finde wir sollten abstimmen.

Das bringt weder rr2000, Dich, noch mich weiter.
Wenn die Informationen von mir zu spärlich waren, sag, was Du zusätzlich noch brauchst.
Ansonsten bin ich hier raus.

Gruß Joachim

[justme1968]

debugging per abstimmung. wenn sich das bewährt eröffnet das natürlich unglaubliche möglichkeiten

als vorlage zur abstimmung schlage ich vor das ihr ein minimal setup aus genau euren beiden modulen zusammen stellt mit dem das problem reproduzierbar ist.

nicht vorhandene hardware lässt sich auf unix ebene wunderbar mit einem fifo der als directio geöffnet wird simulieren. da kann man dann auf shell ebene einfach die daten rein pipen.

[rudolfkoenig]

ich fühle mich gerade, mit verlaub gesagt, von Dir verarscht.

Tut mir leid, ich muss mir staerker einpraegen, dass meine Witze auch falsch verstanden werden koennen.

Leider hilft mir dein Beispiel gar nicht: Du sagst, dass das gleiche Problem (was mAn gar nicht so gleich ist, s.u) bei dir auch auftritt, deswegen muss die Ursache fhem.pl sein. Das kann zwar sein, eine logische Schlussfolgerung ist das aber nicht. In beiden Faellen koennte Benutzercode im notify/watchdog/etc oder ein Bug im jeweiligen Modul oder was anderes die Ursache sein. Oder Bug(s) in fhem.pl.

Bzgl. "gleiches Problem": bei rr2000 gibt es einen neuen Hash-Eintrag mit Wert 0, ohne VAL und TIME. Bei dir gibt es korrekte VAL und TIME Eintraege. Meiner Ansicht nach ist es wahrscheinlicher, dass die beiden Faelle komplett andere (und nicht in fhem.pl zu suchende) Ursachen habe. Mag sein, dass ich mich irre, das ist nur mein Bauchgefuehl.

[rr2000]

Bzgl. "gleiches Problem": bei rr2000 gibt es einen neuen Hash-Eintrag mit Wert 0, ohne VAL und TIME. Bei dir gibt es korrekte VAL und TIME Eintraege. Meiner Ansicht nach ist es wahrscheinlicher, dass die beiden Faelle komplett andere (und nicht in fhem.pl zu suchende) Ursachen habe. Mag sein, dass ich mich irre, das ist nur mein Bauchgefuehl.

Die korreten VAL und TIME Einträge entstehen erst beim neu starten. In der Funktion WriteStatefile und ReadStatefile werden die vorher unkorrekten Einträge mit default-Werten versorgt und damit zu korrekten Einträgen.
Ich nehme an Joachim hat den unkorrekten Hash-Eintrag auch, er wird nur nirgendwo im Webinterface angezeigt. Man kann ihn nur durch Debug-Ausgaben sichtbar machen.