[OBIS V2] - Jetzt auch mit SML-Unterstützung

[ioT4db]

Die ready function wird ständig durchlaufen, selbst wenn der Zähler verbunden ist ! Mein Log ist jetzt ca. 1km länger 

Code Auswählen Erweitern


2021.02.06 14:13:41 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:40 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:40 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:40 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:41 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:41 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:41 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W

usw.

wenn der Zähler wieder auf open ist, kommt die Meldung bei mir nicht mehr...

[gvzdus]

Jo, dann ist auch klar, was das Problem ist:
Wie kommt der "Rein/Raus-State" bei Dir rein?

Wenn Du Dir die Perl-Zeile anguckst:

Code Auswählen Erweitern

if($hash->{STATE} eq "disconnected");


Das bedeutet: Nur, wenn der State genau "disconnected" ist, dann wird der Open gemacht. Bei Dir endet es aber nur auf disconnected.
Ich würde jetzt eher sagen: "Kannst Du Dich vom State-Überbügeln verabschieden?". Dieser Vergleich auf "disconnected" ist ziemlicher Standard über viele Module.

[gvzdus]

Zur "Stecker-Zieh"-Problematik:
Das ist ein generelles Problem. Vor allem, bei uns ja nur gelesen wird. Würde auch regelmäßig geschrieben, würde FHEM irgendwann auffallen, dass die Gegenseite nicht mehr antwortet.
Es gibt 2 Workarounds:

• TCP Keepalive zu nutzen. Damit würde es immerhin - bei typischen Default-Werten - nach ein paar Stunden auffallen. Nachteil: Lässt sich m.W. bei Rasbian nur global parametrisieren
• Einen "Lebenszeichen"-Timer setzen: Kommt 5 Minuten nichts an, wird die Verbindung einmal geclosed und neu aufgebaut

[hdgucken]

Jo, dann ist auch klar, was das Problem ist:
Wie kommt der "Rein/Raus-State" bei Dir rein?

Wenn Du Dir die Perl-Zeile anguckst:

Code Auswählen Erweitern

if($hash->{STATE} eq "disconnected");


Das bedeutet: Nur, wenn der State genau "disconnected" ist, dann wird der Open gemacht. Bei Dir endet es aber nur auf disconnected.
Ich würde jetzt eher sagen: "Kannst Du Dich vom State-Überbügeln verabschieden?". Dieser Vergleich auf "disconnected" ist ziemlicher Standard über viele Module.

Gerade getestet: ohne stateformat, Status opened, Stecker gezogen, Status bleibt opened ! Gerät verbindet sich also auch nicht neu.

[gvzdus]

Ja, siehe oben: Ein sehr generelles Problem bei "Read-Only" TCP-Verbindungen!
Auf jeden Fall wissen wir jetzt schon mal: Das "stateformat" macht den Reconnect bei "sauberem Shutdown statt Steckerziehen" kaputt.

[hdgucken]

Ja, siehe oben: Ein sehr generelles Problem bei "Read-Only" TCP-Verbindungen!
Auf jeden Fall wissen wir jetzt schon mal: Das "stateformat" macht den Reconnect bei "sauberem Shutdown statt Steckerziehen" kaputt.

Stimmt, an das stateformat hatte ich schon mal gedacht, bin leider wieder von abgekommen 
Jetzt müssen wir uns was einfallen lassen, wie wir den Verbindungsverlust mitbekommen ...

[gvzdus]

Aus CPU-Gründen würde ich sagen:
1) Ein Internal "LastMessageTime", das bei jedem Datenpaket auf gettimeofday gesetzt wird
2) Ein Attribut "deadManTimeout" in Sekunden
2) Ein 60-Sekunden-Intervall-Job, der prüft, ob "gettimeofday - LastMessageTime > deadManTimeout". Wenn ja, close + open

Erscheint mir billiger, als bei jedem Paket einen InternalTimer zu starten und den alten zu löschen.

Update: Ich habe mal in der Entwickler-Ecke gefragt...

[ioT4db]

Jo, dann ist auch klar, was das Problem ist:
Wie kommt der "Rein/Raus-State" bei Dir rein?
...

Mann o mann, irre was alles so beeinflussende Faktoren sein können. Bin zwar nicht der große Programmierer, aber wenn du mir die Code-Zeile so "präsentierst" macht auf einmal alles Sinn. Immerhin ist das Problem gefunden und man kann reagieren.

Danke an der Stelle also nochmal für Eure Zeit und Mühen!!!!

In Deiner Code-Zeile prüfst Du ja auf STATE was zu guter letzt ja das stateFormat übernimmt. Der Reading state bleibt davon unberührt, also dort steht weiterhin "open" oder "disconnected". Vermutlich ist es aber auch keine Lösung hier auf "state" zu prüfen.

Also mein stateFormat sieht so aus:

Code Auswählen Erweitern


{sprintf("aktuell: %.0f W", ReadingsVal($name,"power",0) ) . " / " . sprintf("rein: %.0f kWh", (ReadingsVal($name,"total_consumption",0) / 1000) ) . " / " . sprintf("raus: %.0f kWh", (ReadingsVal($name,"total_feed",0) / 1000) ) . " / ". ReadingsVal($name,"state",0)}


Vom stateFormat verabschieden ginge schon, dann muss ich abwägen zwischen Funktionalität und schöner Anzeige direkt im Device...

VG

[hdgucken]

Mir ist noch was aufgefalen: sollte im STATE nicht "CONNECTED" stehen, wenn die Verbindung aufgebaut wurde ? Tut es nämlich nicht.
Laut DevIo sollte es aber so sein, suche gerade nach der Ursache.

Dann hab ich schon immer die folgende Fehlermeldung im Log:

Code Auswählen Erweitern

PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 855, <$fh> line 3876.
wenn wir schon mal dabei sind, vielleicht kriegen wir das auch noch weg 

Habe plötzlich auch die Readings feed_L1, feed_L2 und feed_L3, obwohl mein Zähler die definitiv nicht sendet und dann auch noch mit falschen Werten,
siehe Bild. Da muss beim parsen was irgendwas schieflaufen, die Readings sind auch schon etwas älter.

[ioT4db]

Bei mir steht im STATE opened bzw disconnected (wenn kein stateFormat angelegt ist), jedoch nie "connected"

Wegen der "Stecker-Zieh"-Problematik...um das zu verstehen habe ich eben auch mal getestet. Es gäbe ja 2 Möglichkeiten:

Gerät war auf opened und Kommunikation lief problemlos:
> nun habe ich zuerst mal den USB-Stecker am ser2net-Raspi gezogen: Resultat waren ständige disconnects und reappers im Sekundentakt > dann den Stecker wieder dran und er hat sich wieder richtig verbunden.
> Lan-Stecker am ser2net-Raspi gezogen, da war Stille. Da ich kein Polling aktiv habe war das auch korrekt, kamen halt keine Pakete mehr rein. Lan-Stecker wieder dran und die Kommunikation lief weiter

[gvzdus]

In Deinem Fall 2 "wissen" ja auch Client (FHEM) und Server (ser2net) voneinander, daher läuft es wieder an.
Wenn Du einen Fall 3 nimmst: "Steckerziehen" beim Server: Dann könnte es ewig hängen, weil der Client auf Pakete wartet, während der Server neu gestartet auf eine neue Verbindung wartet.

P.S.:
https://forum.fhem.de/index.php/topic,118547.0.html - Chef sagt: "Mach' selber im Modul". Dann mal loslegen...

[ioT4db]

mh, was die Antwort von Chefe bedeutet, da müsstest Du mir kurz auf die Sprünge helfen. Da komm ich tlws. nich mehr mit. Betrifft es das Problem, was wir mit "stateFormat entfernen" "gelöst haben oder eher das "Stecker ziehen Problem" oder n´beiden?

[ioT4db]

Jo, dann ist auch klar, was das Problem ist:
Wie kommt der "Rein/Raus-State" bei Dir rein?

Wenn Du Dir die Perl-Zeile anguckst:

Code Auswählen Erweitern

if($hash->{STATE} eq "disconnected");


Das bedeutet: Nur, wenn der State genau "disconnected" ist, dann wird der Open gemacht. Bei Dir endet es aber nur auf disconnected.
Ich würde jetzt eher sagen: "Kannst Du Dich vom State-Überbügeln verabschieden?". Dieser Vergleich auf "disconnected" ist ziemlicher Standard über viele Module.

ich bin da jetzt mal recht pragmatisch rangegangen und habe die Zeile in

Code Auswählen Erweitern

if($hash->{STATE} = ".*disconnected.*");
geändert, was bei mir dazu führt, dass der Reconnect auch mit (MEINEM) stateFormat funktioniert. Mir fehlt da ein wenig der Weitblick bzw. die Erfahrug, ob das ein Ansatz wäre. Zumal ja ein stateFormat auch ganz ohne die Info zu opened/disconnected auskommen kann.

Grüße

[gvzdus]

Das ist eher so mitteloptimal, Deine Lösung. Wenn ich das richtig lese, vergleichst Du nichts, und wendest keine Suche an, sondern setzt schlichtweg STATE auf ".*disconnected.*"

Nimm' mal lieber die angehängte Version... Die verhält sich wie von mir beschrieben: Kommen für "resetAfterNoDataTime" Sekunden keine Daten an, wird die Verbindung getrennt und neu initialisiert. Default: 90 Sekunden. Prüfung alle 60 Sekunden, also worst case nach 259 Sekunden.

Es sollte in allen Fällen greifen, auch mit friesischem State-Format!
Hoffe, Ihr habt noch Strom zum Testen! In Grevenbroich ging vor 30 Minuten der Eisregen runter.

P.S. Upps, Moment...
P.P.S. Jetzt aber.

[ioT4db]

jo,
funktioniert

Code Auswählen Erweitern

2021.02.06 22:23:02.629 StromZ2: ReadyFn for StromZ2 called, state is aktuell: 563 W / rein: 723 kWh / raus: 3410 kWh / disconnected
2021.02.06 22:23:02.630 StromZ1: ReadyFn for StromZ1 called, state is aktuell: 627 W / rein: 3004 kWh / raus: 3183 kWh / disconnected
2021.02.06 22:23:02.654 StromZ2: ReadyFn for StromZ2 called, state is aktuell: 563 W / rein: 723 kWh / raus: 3410 kWh / disconnected
2021.02.06 22:23:02.654 StromZ1: ReadyFn for StromZ1 called, state is aktuell: 627 W / rein: 3004 kWh / raus: 3183 kWh / disconnected
2021.02.06 22:23:02.655 3: No data received for 98 seconds, resetting connection
2021.02.06 22:23:02.656 3: No data received for 98 seconds, resetting connection
2021.02.06 22:24:02.656 3: No data received for 158 seconds, resetting connection
2021.02.06 22:24:02.658 3: No data received for 158 seconds, resetting connection
2021.02.06 22:24:02.660 3: Init done
2021.02.06 22:24:02.661 1: 192.168.41.150:20002 reappeared (StromZ2)
2021.02.06 22:24:02.671 3: Init done
2021.02.06 22:24:02.671 1: 192.168.41.150:20001 reappeared (StromZ1)


Der Log-Eintrag für die ReadyFN Funktion ist aber noch drin

Das ist eher so mitteloptimal...

Das dachte ich mir schon, war quasi mein erster Code für überhaupt ein Fhem-Modul 

VG

PS: Strom ist noch da, da mein Forenname nicht direkt nen geografischen, sondern eher andere Gründe hat - wohne nahe Mainz