FHEM Forum

([+00:00:30] and [FritzBox3:box_ipExtern] ne "-") (setreading dummy_internetausfall logEntry 1) DOELSE (setreading dummy_internetausfall logEntry 0)

So ziehe ich mir die externe IP raus, schreibe sie wie eben in einem anderen Beitrag erfragt in einen Dummy und erstelle dann ein Plot draus.
Ist an dem DOIF etwas falsch oder kann das tatsächlich sein das ich so viele Verbindungsabbrüche (siehe Anhang) habe?

Deckt sich das denn mit dem Systemlog der Fritzbox?

Ich denke Du hast einen gewaltigen Denkfehler in Deiner Vorgehensweise.

Du machst das mit dem DOIF völlig asynchron mit der Übertragung der Readings der Fritzbox. Da kann nach dem Zufallsprinzip wahrscheinlich alles rauskommen. Ich weiß nicht ob die Readings überschrieben oder temporär gelöscht werden. Ich kann das zumindest mit einem Test (deine DEF) genauso nachvollziehen.

Schau Dir mal im Event Monitor an was da passiert! Du triggerst durch Zeit und Fritzbox reading!
Im Abstand von 1 minute passiert genau dies:

Zitat2018-04-17_19:54:01 dummy_internetausfall logEntry: 0
2018-04-17_19:54:19 dummy_internetausfall logEntry: 1

Mach doch einfach ein userReadings wie hier ->
https://forum.fhem.de/index.php/topic,87065.msg794989.html#msg794989

Oder lass den teil einfach weg: [+00:00:30] and

Gruß Otto

Du meinst einfach das DOIF auf eine Veränderung triggern lassen anstatt auf zeitbassierend?
Muss dann auch das "do always" raus?

Ich würde sagen: Ja  ;)

Okay, Plot erstellen fällt dann wohl flach, denn der letzte Eintrag ist dann schon von gestern Abend.
Kann man das kompensieren bei dieser Methode?

Moin,
Ich habe gestern mal beide Varianten in meine FB7412 (Namen bei Code Übernahme an den Aktuellen anpassen!) als userReadings eingetragen:
attr FB7412 userReadings online {(ReadingsVal($name,"box_ipExtern", "") eq "-") ? 0:1}, onlineB {ReadingsVal($name,"box_ipExtern", "") ne "-"}
onlineB ist die sparsamste Variante und liefert den direkten booleschen Wert, d.h. wahr (1) wenn die Box online ist und falsch (undef -> nix) wenn die Box offline ist.
online liefert 1 und 0 - was sowohl als Zahl als auch direkt wahr/falsch auswertbar ist. Ich würde diese Variante als universeller bevorzugen.

Wenn Du einen Plot erzeugen willst, kannst Du in der Frequenz Deiner FB Abfrage (INTERVAL) einen Eintrag im FileLog deiner Wahl erzeugen und dies auch als Plot darstellen.
Falls Du (wie ich)attr FB7412 event-on-change-reading .* gesetzt hast kann Du mitattr FB7412 event-on-update-reading onlinedie kontinuierliche Erzeugung der Werte im Log für das eine Reading wieder aktivieren.

Um mit einem notify darauf zu reagieren wäre event-on-update-reading dann allerdings kontraproduktiv! Wenn man beides will gibt es sicher viele Varianten. Spontane Idee: einfach zwei userReadings machen.

Edit: zur Vollständigkeit noch das FileLog
define FileLog_FBonline FileLog ./log/FBonline-%Y-%m.log FB7412:online.*


Edit2: mit einem DOIF kann man direkt reagieren, die Eigenschaft vom DOIF erzeugt dann keine erneute Reaktion bei wiederholtem Event
define di_FBonline DOIF ([FB7412:online])(<Code für das Internet ist wieder da>) DOELSE (<Code für das Internet ist gerade weg>)

Gruß Otto

Zitat von: Otto123 am 18 April 2018, 09:47:41

Code Auswählen Erweitern

attr FB7412 online userReadings {(ReadingsVal($name,"box_ipExtern", "") eq "-") ? 0:1}, onlineB {ReadingsVal($name,"box_ipExtern", "") ne "-"}

Kann es sein das das sich da ein Fehler eingeschlichen hat?

ZitatFritzBox3: unknown attribute online. Type 'attr FritzBox3 ?' for a detailed list.

Ich kann es nicht so ganz zurückverfolgen. Entweder ist "online" und "userReadings" vertauscht, oder ich check es nicht  ;D


EDIT:
Hab jetzt zwei neue Readings in der FB, das "online" und das "onlineB". Auch dein Filelog hab ich neu angelegt. Es bleibt jedoch leer.

Ja sorry: vertauscht, ich habe die DEF kopiert und wollte es dann noch "schön" machen. Ich habe den Post geändert.  :-[

In dem FileLog musst Du natürlich Deinen FB Namen eintragen
FB7412:online.* -> FritzBox3:online.*

Und das FritzBox3 Device muss natürlich regelmäßig die Events liefern - sonst wird nicht geloggt.

Ist eingetragen:

Internals:
   CFGFN     
   DEF        /media/usbstick/FileLog_FBonline-%Y-%m.log FritzBox3:online.*
   NAME       FileLog_FBonline
   NOTIFYDEV  FritzBox3
   NR         27353
   NTFY_ORDER 50-FileLog_FBonline
   REGEXP     FritzBox3:online.*
   STATE      active
   TYPE       FileLog
   currentlogfile /media/usbstick/FileLog_FBonline-2018-04.log
   logfile    /media/usbstick/FileLog_FBonline-%Y-%m.log
Attributes:
   group      FritzBox
   room       FritzBox

FritzBox (gekürzt):
Internals:
   APICHECKED 1
   CHANGED   
   DEF        192.168.178.1
   HOST       192.168.178.1
   INTERVAL   300
   LUAQUERY   1
   M3U_LOCAL  /opt/fhem//www/images/FritzBox3.m3u
   M3U_URL    unknown
   MODEL      FRITZ!Box 7362 SL (UI)
   NAME       FritzBox3
   NR         239
   REMOTE     1
   SECPORT    49443
   STATE      Anrufbeantworter: 0 Nachrichten
   TELNET     0
   TR064      1
   TYPE       FRITZBOX
   WEBCM      0
   READINGS:
     2018-04-18 12:07:10   online          1
     2018-04-18 12:07:10   onlineB         1
Attributes:
   alias      Fritzbox WLan
   allowTR064Command 1
   event-on-change-reading online
   group      FritzBox
   icon       it_router
   room       FritzBox
   stateFormat Anrufbeantworter: tam1_newMsg Nachrichten
   userReadings online {(ReadingsVal($name,"box_ipExtern", "") eq "-") ? 0:1}, onlineB {ReadingsVal($name,"box_ipExtern", "") ne "-"}


Da hat sich jetzt bei Dir der Fehler eingeschlichen:
event-on-change-reading online

In deinem Fall diese Attribute einfach löschen  ;)

Ah, dann hab ich das falsch verstanden. Ich dachte anlegen :D
Jetzt hab ich nach einem "set update" auch etwas drin stehen:

Zitat2018-04-18_12:21:48 FritzBox3 online: 1
2018-04-18_12:21:48 FritzBox3 onlineB: 1

Das Fritzboxupdate läuft jetzt ohne das event-on-change-reading aber nicht selbstständig, oder?
Denn dieses kontinuierliche schreiben in das Log bleibt aus.

EDIT:
Ah, doch, hab INTERVAL vergessen. Ist 300 ne gute Zeit oder empfiehlst du etwas mehr oder weniger?
In meinem Fall geht es um ständige Abbrüche die ich Protokollieren möchte. 300 Sekunden finde ich dann etwas zu viel, in der Zeit kann das Netz x-mal weg und wieder da sein.

Minimum ist eine Minute sinnvoll, auf keinen Fall kürzer!

Die Frage ist aber wie schnell die FB überhaupt den Ausfall ermittelt. Die nächtliche Zwangstrennung hat bei mir letzte Nacht keinen Event erzeugt!

Zitat von: Otto123 am 18 April 2018, 12:42:27
Minimum ist eine Minute sinnvoll, auf keinen Fall kürzer!

Die Frage ist aber wie schnell die FB überhaupt den Ausfall ermittelt. Die nächtliche Zwangstrennung hat bei mir letzte Nacht keinen Event erzeugt!

Okay, und bei welchem Takt war das? Ein Reconnect dauert bei mir gute 60 Sekunden wenn ich die Hammer-Meisel-Stecker-aus-der-Dose-zieh-Methode anwende.

Ich habe derzeit 60 sec in der Abfrage. Aber was die Zwangstrennung genau macht weiß ich nicht, ich denke die ist relativ kurz.

Wenn Du sagst es dauert 60 sec. dann sollte man die FB vielleicht gar nicht öfter als 120 sec abfragen. 

Okay, hab alles angepasst und läuft aktuell, ich beobachte das mal ein oder zwei Tage.

Vielen Dank für deine vorzügliche Hilfe, immer brav mit Erklärung und nicht einfach nur Code hingerotzt!
Danke schön  :)

Die Box setzt (meines Wissens) die IP auch nach einem Abbuch nicht sofort auf 0, sondern probiert erst ein reconnect und dabei eventuell wird die IP 0. Für die Zwangstrennung, welche relativ schnell gehen sollte, also nicht gerade optimal. Da müste man auch auf IP Änderungen trickern (Weiß nur aktuell auf die schnelle nicht wie)

Hallo Werner,

ja die Zwangstrennung ist ja an sich gar nicht so interessant. Stecker raus wird zuverlässig erkannt (bei mir).

Internetausfall ist ja irgendwas komplexeres, da ist sicher "Alles" möglich.

Die Frage ist eben wirklich, was dann genau das Kriterium ist, im Zweifelsfall die Erreichbarkeit einer Adresse im Internet die garantiert online ist  ;)

Aber wenn es bei accessburn häufiger ist, schaun wir doch mal was raus kommt.

Schönen Abend
Otto