FHEM Forum

Update: Damit nicht jeder alles lesen muss...
https://forum.fhem.de/index.php/topic,97045.msg914670.html#msg914670

Für alle die basteln wollen: https://forum.fhem.de/index.php/topic,97045.msg914998.html#msg914998 - Hier der Link zum Beitrag und anbei auch der Link zur 165er.ino
https://github.com/enesbcs/ESPEasyPluginPlayground/blob/master/_P165_SerSwitch.ino

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Hallo zusammen,

ich habe im Arbeitszimmer einen Sonoff 2 Gang Schalter für 1x Deckenlicht und 1x zum schalten einer Intertechno Dose.
Nun ist es so, ich liege auf dem Sofa im Wohnzimmer und sehe wie auf einmal das Licht (welches genau weiß ich noch nicht) angeht und direkt wieder aus.

Am Anfang hatte ich auf den Schaltern einfach verbose 5 eingeschaltet und dachte ich finde was. Leider aber finde ich dort nichts. Nun habe ich die Hoffnung/Vermutung
das ggf. einer meiner Nachbarn auf dem gleichen IT Code ein Gerät versorgt. Ist aber auch nur geraten bzw. Vermutung.

Wie kann man in FHEM am besten prüfen, warum ein Gerät angeht/ausgeht. Erst war es mir egal aber es ist mittlerweile (ca. 2 Wochen) öfter passiert...Nun möchte ich dies
natürlich abstellen.

Ideen?

Einfach mehr loggen, also ein Logdevice für jeweils alle betroffenen Geräte.

Dann siehst Du auch eventuell, ob es überhaupt von FHEM verarbeitet wurde ...

Ein so schnelles schalten kann auftreten wenn der sonoff die WLAN Verbindung verliert (zumindest bei meinen sonoff Basic so). Solang er versucht die Verbindung auf zu bauen schalten meine alle paar Sekunden einmal kurz.

ZitatEinfach mehr loggen, also ein Logdevice für jeweils alle betroffenen Geräte.

Dann siehst Du auch eventuell, ob es überhaupt von FHEM verarbeitet wurde ...

Okay - Danke!

ZitatEin so schnelles schalten kann auftreten wenn der sonoff die WLAN Verbindung verliert (zumindest bei meinen sonoff Basic so). Solang er versucht die Verbindung auf zu bauen schalten meine alle paar Sekunden einmal kurz.

Das machen meine tatsächlich nicht. Wenn kein WLAN da ist bleibt alles so wie es ist. Hinzu kommt bei diesem Schalter das er 2m vom Router weg steht. Das hatte ich deswegen ausgeschlossen. Danke aber auch für diese Idee!

... 2m vom Router weg steht ...
Kann auch ein Problem sein ...

Zum testen einfach mal den Router abschalten (downtime 5 Minuten?) und gucken ...

Bzw:
Mit welcher Software sind die Sonoff geflasht? Eventuell kannst Du dort auch ein externes Loggingdevice angeben und dann "mehr sehen"

ZitatKann auch ein Problem sein ...

Zum testen einfach mal den Router abschalten (downtime 5 Minuten?) und gucken ...

Bzw:
Mit welcher Software sind die Sonoff geflasht? Eventuell kannst Du dort auch ein externes Loggingdevice angeben und dann "mehr sehen"

Das kann ich in der Tat sehr gut testen. Bin ITler von Beruf. Das kann ich wirklich komplett ausschließen. Habe aber auch schon einfach mal den Router ausgemacht. Klar, man muss sich ja ran tasten an den Fehler.

Weiß ich nicht aus dem Kopf. Aber es ist eine Version aus 01/19. Habe alle Schalter auf dem gleichen FW Stand.
Habe bisher keine externen Logging Geräte in einem Sonoff angelegt. Muss ich mir durchlesen. Krass ist eben das es wirklich nur klick, klack geht. Also das Licht ist weniger als ca. 1 Sekunde nur an. Am Tag fällt das also eher nie auf. Dazu kommt es zu unterschiedlichen Zeiten vor. So fällt es mir schwer ne Woche zu loggen und dann habe ich ewig lange Logs. Ab und an wurde dann ja auch wirklich geschaltet und das muss ich mir dann wohl zum testen aufschreiben nun.

Also entweder funkt Dir irgend ein DOIF/notify da rein (Event Monitor angucken)
Oder es sind wlan Probleme, woran ich im Monet eher denke da es genau das gleich Phänomen wie bei mir ist wenn einer mal seine Verbindung verliert (das ist bei mir auch einer der ca 3m vom router weg ist)

Ansonsten nachschauen ob die klemmen richtig fest sind (Wackelkontakt?)
Im log von sonoff schauen ob er zu der Zeit wo das klick Klack vor kommt neu gestartet ist?

Vermutlich wird es das eine notify sein. Aber auch das glaube ich nicht, da es so einfach ist. Aber ich habe nun alles auf LOG stehen.
Wie gesagt, bei WLAN = aus, passiert da nichts.

Ich weiß nicht genau welche der beiden Lampen es ist. Die eine wird direkt über den Draht auch geschaltet und die andere macht eigentlich nichts am Schalter selber. Der rechte der beiden Schalter geht nur an FHEM und dann via notify wird der alten Baumarkt Zwischen Steckdose gesagt, dass diese angehen soll.

Hatte heute Morgen ne Whatsapp bekommen von meiner Freundin und ins LOG gesehen. Kein neustart oder etwas anderes zu der Zeit. Der Sonoff selber hat aktuell nur ein LiveLog und kein Log was gespeichert wird. Das müsste ich noch einrichten. Aktuell logge ich via FHEM auf allen Geräten die damit zutun haben.

Anbei mal das mini notify - Ggf. habe ich ja doch etwas sinnloses getan...

define az_Stehlampe_ESP notify (ESPEasy_az_licht_strom_rechts:strom_rechts:.*) {\
if ($EVTPART1 eq "on") {\
  fhem("set az_stehlampe on");;;;\
}\
elsif ($EVTPART1 eq "off") {\
  fhem("set az_stehlampe off");;;;\
}\
}

Ach ja - Zum Thema "komische Dinge bei Sonoff" - Habe Rollo Schalter aus ein paar Sonoffs gemacht. Klappt ganz gut. Allerdings, wenn diese FHEM nicht erreichen kann man zb auf Rollo runter drücken und dann aber nicht mehr anhalten oder die Richtung wechseln. Das Rollo fährt dann komplett runter. Aber das ist erst mal unwichtig für mich. Das liegt vermutlich daran, dass der Schalter -> Fhem sagen will, das der Status eines Schalters sich geändert hat. Denke das bekommt man hin indem man weniger oft versucht den Status durch zu prügeln. Aber alles auch nur Gedanken. Das steht an letzter Stelle bei mir.

Bezüglich:

ZitatMit welcher Software sind die Sonoff geflasht? Eventuell kannst Du dort auch ein externes Loggingdevice angeben und dann "mehr sehen"

SonOff ist eine Hardware, wo Du verschiedene Firmware flashen kannst. Du schreibst etwas von 01/19, was ein Versionsstand ist. Ich wollte aber wissen, was für eine Firmware Du hast.

Bei ESPEasy weiß ich, das Du einen syslog-Server angeben kannst. Bei anderen ...????

Bezüglich "Richtig Schalten" und Deine Problemfälle: Wenn es wirklich so schnell geht, könntest Du versuchen im Log nach kurzen an/aus zu finden. Und dann in dem zeitraum andere Logs prüfen.

Idee:
Könnte man nicht auch ein FHEN drauf ansetzen? Wenn aus und vor weniger als 2sec an, dann Eintrag in ein Log

Habe aktuell aber keine Idee der Umsetzung

Hey nochmal,

ja das hätte ich erwähnen sollen. ESPeasy nutze ich natürlich. Sorry! Version ist wie oben schon gesagt eine von 01/19..

ZitatIdee:
Könnte man nicht auch ein FHEN drauf ansetzen? Wenn aus und vor weniger als 2sec an, dann Eintrag in ein Log

MEGA! Danke! Das ist doch mal eine Idee!

Hab nun aber erst mal Logs überall aktiv und das notify nochmal angepasst. So kann ich sinnloses senden von an/aus unterdrücken an die IT Dose.

define az_Stehlampe_ESP notify (ESPEasy_az_licht_strom_rechts:strom_rechts:.*) {\
if ($EVTPART1 eq "on" && ReadingsVal("az_stehlampe", "state", "0") eq "off") {\
  fhem("set az_stehlampe on");;;;\
}\
elsif ($EVTPART1 eq "off" && ReadingsVal("az_stehlampe", "state", "0") eq "on") {\
  fhem("set az_stehlampe off");;;;\
}\
}

Jetzt heißt es abwarten und schauen ob nochmal was hoch kommt. Sollte dem so sein, werde ich zuerst deine Idee testen.
Danke!

So heute hatte ich zwei mal den Fall das die Lampe an ging. Nun weiß ich schon mal welche der beiden es ist. Es ist wie vermutet die Stehlampe.
Allerdings weiß ich noch nicht woher bzw. warum sie das macht. Müsste jetzt quasi den CUL überwachen oder?


2019.02.08 12:40:47 3: CUL_443MHz IT_set: az_stehlampe on
2019.02.08 12:40:47 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.08 12:40:47 5: IT_Set: GetFn(raw): message = is00000FFF0F0F Antwort =   raw => is00000FFF0F0F
2019.02.08 12:40:47 3: CUL_443MHz IT_set: az_stehlampe off
2019.02.08 12:40:47 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.08 12:40:48 5: IT_Set: GetFn(raw): message = is00000FFF0FF0 Antwort =   raw => is00000FFF0FF0
......
2019.02.08 14:37:13 3: CUL_443MHz IT_set: az_stehlampe on
2019.02.08 14:37:13 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.08 14:37:13 5: IT_Set: GetFn(raw): message = is00000FFF0F0F Antwort =   raw => is00000FFF0F0F
2019.02.08 14:37:13 3: CUL_443MHz IT_set: az_stehlampe off
2019.02.08 14:37:13 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.08 14:37:13 5: IT_Set: GetFn(raw): message = is00000FFF0FF0 Antwort =   raw => is00000FFF0FF0


Mach doch zusätzlich Logausgaben in dein Notify, dann siehst du, ob es vom Notify kommt...

Denn wenn ein Event mit irgendwas on bzw. off kommt wird geschaltet, weil das Notify auf so ziemlich viel triggert...

So ein Event:
ESPEasy_az_licht_strom_rechts:strom_rechts:on ich sag einfach mal Bescheid

würde schalten

ESPEasy_az_licht_strom_rechts:strom_rechts:off ohje ich habe mich geirrt

ebenfalls ;)

Gruß, Joachim

Hey und danke für den Hinweis, den ich nicht ganz verstehe. Soll das bedeuten, dass ein notify sich vertun kann??? Oder aber sollte mein notify einfach anders aussehen? Hinter Strom Output kann nur on/off kommen, weswegen ich das nicht weiter vertieft habe.

Jetzt bin ich mal gespannt.... Habe so zu sagen fhem Wochenende. Also habe ich Zeit mich mit den ganzen Sachen zu beschäftigen.

Ein Notify kann sich nicht "vertun"...

Aber .* heisst nun mal alles...
...d.h. es "löst" bei allem aus was kommt und "passt"...

Und dann prüfst du $EVTPART1 und wenn das "zufällig" on oder off ist tust du was...

Mehr wollte ich nicht sagen...

Wichtiger: ich würde Logausgaben einbauen bei den Schaltbefehlen. Dann weißt du sicher, ob das Notify der Auslöser ist für die komischen Vorgänge oder eben sicher nicht...

Während der "Entwicklung" packe ich "überall" Logausgaben rein (und daher "lagere" ich [fast] alles in Subs myUtils aus), damit ich weiß was kommt (also logge ich den Event oder eben $EVTPART1 in deinem Fall, um zu sehen was tatsächlich kommt) und auch alle Befehle die ich absetze. Wenn es dann einige Zeit gut läuft nehm ich das Logging raus (oder logge nur noch den Schaltvorgang, sicher ist sicher ;)  ).

Gruß, Joachim

Ich mache bei sowas immer verbose 5 an. Von früher, bei zb Batch Dateien, kenne ich das noch mit Ausgaben einfach via Echo. So kann man einfach prüfen was drin steht. Nun müsste ich für fhem erst mal gucken was eleganter ist als verbose 5.

Aber verbose 5 hilft dir hier vermutlich nicht...

Mach doch einfach bei den Schaltbefehlen Logausgaben. Dann weisst du (ohne verbose5 "Spam") dass es das Notify ist oder eben nicht...

Gruß, Joachim

Ohne es nun groß nach zu googlen, hast du ein Example?

Ausnahmsweise ;)

Log3(undef, 3, "Subname/Kennung Ausgabe Variablen: EVTPART1: $EVTPART1 Ausgeführter Befehl")

Log3 ist (soweit ich das jetzt verfolgt habe) die aktuell zu nutzende Logfunktion (ältere/andere gehen wohl auch [noch])...
Die '3' ist (glaube ich) der "verbose-Level"...
Alles innerhalb von den Anführungszeichen kannst du nat. frei anpassen.
Ich gebe meist/immer aus "wo ich bin" bzw. wo die Logausgabe herstammt (Sub-Name, Notify-Name, ...) und dann die Variablen, mit denen ich "arbeite" (manchmal auch mehr, z.B. statt "nur" $EVTPART1 vielleicht auch den gesamten $EVENT etc.) und dann gegebenenfalls noch WAS ich getan habe ;)

Gruß, Joachim

Danke - Ich weiß, normal soll man selber googlen. Aber so geht es ausnahmsweise schneller und ich kann weiter basteln an den ganzen Dingen die noch ausstehen.
Riesen Dank!

Sachen die ich aus dem Kopf weiß sind kein Ding...
...wenn ich selber suchen muss/müsste, dann "sag" ich das schon: bitte selber suchen ;)

Viel Erfolg!

Gruß, Joachim

Also ich scheine zu dumm zu sein. Hab im Comandref, bei google usw geschaut nach Beispielen. Ich schaffe es nicht ohne Syntax Error oder anderen Fehlern das LOG3 in mein Konstrukt einzubauen.

define az_Stehlampe_ESP notify (ESPEasy_az_licht_strom_rechts:strom_rechts:.*) {\
if ($EVTPART1 eq "on" && ReadingsVal("az_stehlampe", "state", "0") eq "off") {\
  fhem("set az_stehlampe on");;;;\
}\
elsif ($EVTPART1 eq "off" && ReadingsVal("az_stehlampe", "state", "0") eq "on") {\
  fhem("set az_stehlampe off");;;;\
}\
}

Wenn ich dort
Log3(undef, 3, "Subname/Kennung Ausgabe Variablen: EVTPART1: $EVTPART1 Ausgeführter Befehl")

einbauen will, egal wie...immer wieder Fehler.

z.B.
define az_Stehlampe_ESP notify (ESPEasy_az_licht_strom_rechts:strom_rechts:.*) {\
if ($EVTPART1 eq "on" && ReadingsVal("az_stehlampe", "state", "0") eq "off") {\
  fhem("set az_stehlampe on");;;;\
  Log3(undef, 3, "ON-Teil EVTPART1: $EVTPART1 und etwas anderes...");;;;\
}\
elsif ($EVTPART1 eq "off" && ReadingsVal("az_stehlampe", "state", "0") eq "on") {\
  fhem("set az_stehlampe off");;;;\
  Log3(undef, 3, "OFF-Teil EVTPART1: $EVTPART1 und etwas anderes...");;;;\
}\
}

Hab durch verbose 5 im notify zumindest festgestellt, dass der "Fehler", des selbstständigem an/aus immer 2-3 mal am Tag passiert. Die Uhrzeiten sind aber immer anders. Und ich weiß, wie schon gesagt es ist die Stehlampe (rechter Knopf am Schalter). Mit LOG3 bin ich leider nicht weiter gekommen :(

Anstatt in der cfg rumzueditieren, solltest Du probieren, es in FHEM selber zu machen ...

Vermute mal du meinst den DEF in dem notify? Wenn ja, das habe ich natürlich auch getan.
Ich habe leider kein Lösung gefunden die mir keinen Error oder Syntax Error rauß geschoben hat.

Die LOG 3 Methode habe ich versucht mit zusätzlichen {} oder ; usw versucht einzubinden. Aus einem mir einfach nicht begreiflichem Grund, bekomme ich das nicht hin.

Aktuell bin ich wieder auf Verbose 5 aber dort werden mir leider die Variablen nicht aufgelöst und die Idee mit LOG scheint ja genau das zu sein, was ich brauche...

Ich komm mit den ganzen ";" nicht mit. Könntest Du mir bitte das geben, was Du um def des Notivy schreibst?

Wenn man jetzt nur wüsste wie genau der Worlaut dieses Errors ist. Ja dann...
Und ich gebe Werniemann Recht. Damit wir Dir besser helfen können solltest Du ein list vom notify geben und versuchen alles in der FHEMWEB zu konfigurieren. Dafür ist sie da.

Nur überflogen, denke aber das hier:

Log3(undef, 3, "OFF-Teil EVTPART1...

wird schonmal nicht gehen ohne das undef in ' zu setzen .... aber gerade nicht probiert da mobil.

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

Das passt schon. undef wird immer ohne '' oder "" gesetzt.
undef ist eigentlich eine Funktion.

Hallo nochmal,

das steht nun drin:

(ESPEasy_az_licht_strom_rechts:strom_rechts:.(on|off)) {
if ($EVTPART1 eq "on" && ReadingsVal("az_stehlampe", "state", "0") eq "off") {
  fhem("set az_stehlampe on");;
  Log3(undef, 3, "EVENT: $EVENT, EVTPART1: $EVTPART1");;
}
elsif ($EVTPART1 eq "off" && ReadingsVal("az_stehlampe", "state", "0") eq "on") {
  fhem("set az_stehlampe off");;
  Log3(undef, 3, "EVENT: $EVENT, EVTPART1: $EVTPART1");;
}
}


und dies ergibt im log, das hier (das hier ist einmal on und off):
2019.02.12 12:55:12 4: az_Stehlampe_ESP exec {
if ($EVTPART1 eq "on" && ReadingsVal("az_stehlampe", "state", "0") eq "off") {
  fhem("set az_stehlampe on");;;;
  Log3(undef, 3, "EVENT: $EVENT, EVTPART1: $EVTPART1");;;;
}
elsif ($EVTPART1 eq "off" && ReadingsVal("az_stehlampe", "state", "0") eq "on") {
  fhem("set az_stehlampe off");;;;
  Log3(undef, 3, "EVENT: $EVENT, EVTPART1: $EVTPART1");;;;
}
}
2019.02.12 12:55:12 3: CUL_443MHz IT_set: az_stehlampe on
2019.02.12 12:55:12 2: AttrTemplates: got 53 entries
2019.02.12 12:55:12 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.12 12:55:13 5: IT_Set: GetFn(raw): message = is00000FFF0F0F Antwort =   raw => is00000FFF0F0F
2019.02.12 12:55:15 5: Triggering az_Stehlampe_ESP
2019.02.12 12:55:15 4: az_Stehlampe_ESP exec {
if ($EVTPART1 eq "on" && ReadingsVal("az_stehlampe", "state", "0") eq "off") {
  fhem("set az_stehlampe on");;;;
  Log3(undef, 3, "EVENT: $EVENT, EVTPART1: $EVTPART1");;;;
}
elsif ($EVTPART1 eq "off" && ReadingsVal("az_stehlampe", "state", "0") eq "on") {
  fhem("set az_stehlampe off");;;;
  Log3(undef, 3, "EVENT: $EVENT, EVTPART1: $EVTPART1");;;;
}
}
2019.02.12 12:55:15 3: CUL_443MHz IT_set: az_stehlampe off
2019.02.12 12:55:15 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.12 12:55:15 5: IT_Set: GetFn(raw): message = is00000FFF0FF0 Antwort =   raw => is00000FFF0FF0

Vielleicht verstehe ich das nicht ABER es wird im Log auch nichts zu den Variablen gesagt. Was nun genau drin steht, weiß ich nicht. Warum (vermutlich) das modify einfach mal auslöst, weiß ich auch nicht. Für mich sieht das notify super aus. Aber das kann ja nicht sein.....


(ESPEasy_az_licht_strom_rechts:strom_rechts:.(on|off)) {
  fhem("set az_stehlampe $EVTPART1") if ( ReadingsVal('az_stehlampe', 'state', 0) ne $EVTPART1);
  Log3(undef, 3, "EVENT: $EVENT, EVTPART1: $EVTPART1");
}


Schau mal ob es so nicht einfacher und übersichtlicher wäre.

Der ist natürlich schöner als meiner.
Würde nur gerne wissen, warum es ab und an auslöst. Dein neuer Code ist super, versteh mich nicht falsch.

Aber wenn ich wieder und wieder auf sowas stoße, möchte ich euch nicht immer nerven müssen. Werde deinen Code sicher übernehmen, zuerst aber möchte ich gerne verstehen :)

Hab aktuell mehrere Baustellen und versuche die alle nach und nach abzuarbeiten. Nur für die, die sich wundern, warum ich verschiedene Threads aktuell offen habe...

Hy ewentuell ein Taster/Schalter an GPIO 14?? Dann muss der entprellt werden.
Quasi ein Wiederstand von VCC nach GPIO 14 ewentuell ein Kondensator zwischen GND und GPIO 14 Werte habe ich grad nicht im Kopf.
Das Verhalten schließt darauf.

Gesendet von meinem SNE-LX1 mit Tapatalk

Ohne jetzt genau Deinen Event zu kennen sollte das hier

(ESPEasy_az_licht_strom_rechts:strom_rechts:.(on|off)) {
   if ($EVTPART1 eq "on" && ReadingsVal("az_stehlampe", "state", "0") eq "off") {
      fhem("set az_stehlampe on");
      Log3(undef, 3, "EVENT: $EVENT, EVTPART1: $EVTPART1");
   }
   elsif ($EVTPART1 eq "off" && ReadingsVal("az_stehlampe", "state", "0") eq "on") {
     fhem("set az_stehlampe off");
     Log3(undef, 3, "EVENT: $EVENT, EVTPART1: $EVTPART1");
  }
}

eigentlich funktionieren.
Aber mal davon ab. Wenn Du wissen willst was da genau los ist kannst Du auch Deinen ESPEasy_az_licht_strom_rechts mittels Logfile überwachen. Dann siehst welche Events wann kommen.

Zitat von: Gasmast3r am 12 Februar 2019, 13:14:55
Hy ewentuell ein Taster/Schalter an GPIO 14?? Dann muss der entprellt werden.
Quasi ein Wiederstand von VCC nach GPIO 14 ewentuell ein Kondensator zwischen GND und GPIO 14 Werte habe ich grad nicht im Kopf.
Das Verhalten schließt darauf.

Gesendet von meinem SNE-LX1 mit Tapatalk

Ist ein Sonoff T1 EU (2-Gang) - Ist nix auf GPIO 14 aktuell.

Werde einfach alles per File loggen müssen, wie sich das hier anhört. Es ist immer nur diese Lampe.
Zum Thema LOG3 verstehe ich nicht warum er mir leider nicht sagt was in $EVENT usw. steht. Das würde ich natürlich auch gerne verstehen.

Da diese ja Sonoff Schalter -> Fhem -> Intertechno funkt, habe ich noch die Hoffnung, dass einfach jemand meinen IT Code auch nutzt. Diese Baumarkt Dosen haben ja sehr viele Leute.

In $EVENT und auch in $EVTPART1 sollte eigentlich etwas drin stehen. Alternativ mache statt Log3 einfach


Log1("EVENT ist: $EVENT, EVTPART1 ist: $EVTPART1");


Wie hast du die in Fhem angebunden Espeasy Bridge?
Dann schalte mal ein RSSI feed dazu das die Dinger nicht immer auf absend gehen ewentuell ist ja das dein problem

Gesendet von meinem SNE-LX1 mit Tapatalk

Jo per Bridge....

Man kann mittlerweile in der FW von espeasy auch die Button in intervallen senden lassen. Man muss nicht zwangsläufig auf einen "Fake wert" gehen. Rssi sende ich aber tatsächlich mit, hatte es eben immer so.

Ich habe das Problem bei den Basic wenn ich per GPIO 14 schalte und eben das er ohne RSSI Feed zu oft absend Presend schaltet.

Gesendet von meinem SNE-LX1 mit Tapatalk

Also online/offline Probleme hatte ich bisher nie bei den SONOFFS. Hatte mir da einige Anleitungen angesehen und auch mal getestet ob das alles noch so stimmt. Das ist also "leider" rauß.

Wenn ich den kurzen Code nehme:
(ESPEasy_az_licht_strom_rechts:strom_rechts:.(on|off)) {
  fhem("set az_stehlampe $EVTPART1") if ( ReadingsVal('az_stehlampe', 'state', 0) ne $EVTPART1);
  Log3(undef, 3, "EVENT: $EVENT, EVTPART1: $EVTPART1");
}

Kommt das dabei rauß:
2019.02.12 14:27:51 3: CUL_443MHz IT_set: az_stehlampe on
2019.02.12 14:27:51 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.12 14:27:51 5: IT_Set: GetFn(raw): message = is00000FFF0F0F Antwort =   raw => is00000FFF0F0F
2019.02.12 14:27:51 1: ERROR evaluating my $SELF='az_Stehlampe_ESP';my $TYPE='ESPEasy';my $EVTPART0='strom_rechts:';my $EVTPART1='on';my $NAME='ESPEasy_az_licht_strom_rechts';my $EVENT='strom_rechts: on';{
  fhem("set az_stehlampe $EVTPART1") if ( ReadingsVal('az_stehlampe', 'state', 0) ne $EVTPART1);
  Log1("EVENT ist: $EVENT, EVTPART1 ist: $EVTPART1");
}: Undefined subroutine &main::Log1 called at (eval 220) line 3.

2019.02.12 14:27:53 3: CUL_443MHz IT_set: az_stehlampe off
2019.02.12 14:27:53 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.12 14:27:54 5: IT_Set: GetFn(raw): message = is00000FFF0FF0 Antwort =   raw => is00000FFF0FF0
2019.02.12 14:27:54 1: ERROR evaluating my $TYPE='ESPEasy';my $SELF='az_Stehlampe_ESP';my $EVTPART0='strom_rechts:';my $EVTPART1='off';my $NAME='ESPEasy_az_licht_strom_rechts';my $EVENT='strom_rechts: off';{
  fhem("set az_stehlampe $EVTPART1") if ( ReadingsVal('az_stehlampe', 'state', 0) ne $EVTPART1);
  Log1("EVENT ist: $EVENT, EVTPART1 ist: $EVTPART1");
}: Undefined subroutine &main::Log1 called at (eval 223) line 3.

Jetzt stehen zwar Dinge in den Parts aber es sieht für mich noch immer nicht aus, als würde LOG sauber laufen bei mir.

Sorry mein Fehler


Log(1,"TEXT");


Und auch meiner... Hab oben sogar nichtmal das richtige eingefügt :(


define az_Stehlampe_ESP notify (ESPEasy_az_licht_strom_rechts:strom_rechts:.(on|off)) {
  fhem("set az_stehlampe $EVTPART1") if ( ReadingsVal('az_stehlampe', 'state', 0) ne $EVTPART1);
  Log(1,"EVENT ist: $EVENT, EVTPART1 ist: $EVTPART1");
}



Nun, nach meiner und deiner Verbesserung sieht es so aus:
2019.02.12 14:48:37 3: CUL_443MHz IT_set: az_stehlampe on
2019.02.12 14:48:37 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.12 14:48:37 5: IT_Set: GetFn(raw): message = is00000FFF0F0F Antwort =   raw => is00000FFF0F0F
2019.02.12 14:48:37 1: EVENT ist: strom_rechts: on, EVTPART1 ist: on
2019.02.12 14:48:39 3: CUL_443MHz IT_set: az_stehlampe off
2019.02.12 14:48:39 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.12 14:48:39 5: IT_Set: GetFn(raw): message = is00000FFF0FF0 Antwort =   raw => is00000FFF0FF0
2019.02.12 14:48:39 1: EVENT ist: strom_rechts: off, EVTPART1 ist: off

Das ist super und werde ich nun öfter verwenden um diverse Dinge zu prüfen! DANKE!

Filelog bei dem device geht leider nicht:
attr ESPEasy_az_licht_strom_rechts FileLog ./log/ESPEasy_az_licht_strom_rechts-%Y.log ESPEasy_az_licht_strom_rechts
attr ESPEasy_az_licht_strom_rechts logtype text
attr ESPEasy_az_licht_strom_rechts room hidden

Der Befehl, für das Gerät ist FHEM unbekannt.
ESPEasy_az_licht_strom_rechts: unknown attribute ?, choose one of alias comment eventMap group room suppressReading userReadings verbose IODev Interval adjustValue colorpicker deepsleep disable disableRiskyCmds disabledForIntervals displayTextEncode displayTextWidth do_not_notify event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat timestamp-on-change-reading mapLightCmds maxCmdDuration parseCmdResponse pollGPIOs presenceCheck readingPrefixGPIO readingSuffixGPIOState readingSwitchText rgbGPIOs setState useSetExtensions userSetCmds wwcwGPIOs alexaName alexaRoom cmdIcon devStateIcon devStateIcon devStateStyle genericDeviceType homebridgeMapping icon sortby webCmd webCmdLabel widgetOverride userattr

Gibt es hier auch einen Trick? Normal kann ich ja bei allen Geräten ein LOG anlegen (zumindest wo ich es bisher brauchte)...

https://fhem.de/commandref.html#FileLogdefine

ich Depp! Danke!

Und gewöhne Dir bitte ab in der Fonfigdatei rum zu fuschen. Du kannst wirklich ausnahmslos alles über FHEMWEB konfigurieren. Zur Not frage mich einfach wie das über FHEMWEB geht. Da antworte ich dann gerne noch.

Mache es lieber, wenn ich alles auf einen Blick sehe. Hab verschiedene Konfigs includet aber auch ein Backup auf mein NAS. Also wenn hier was kaputt gehen sollte, wäre es mir egal.
Also bei notify zb macht es ja sogar Sinn. Alleine (wie auch bei mir) wegen den ";" und "\" usw.

Würde zu gerne mal neben einem von euch Profis sitzen und sehen, wie ihr so arbeitet. Hier sind einige Namen, die man überall liest.

Zu meinem eigentlichem Problem: Jetzt muss ich erst mal warten, bis es wieder passiert.

Zitat von: 87insane am 12 Februar 2019, 15:08:45
Also bei notify zb macht es ja sogar Sinn. Alleine (wie auch bei mir) wegen den ";" und "\" usw.

Es macht NIE Sinn!
Und includes habe ich vor mehreren Jahren abgeschafft (beim Wechsel zu configDB, da KANN man gar nicht in der cfg direkt rumpfuschen (das ist der richtige Ausdruck!)).

Wenn du cfg-Auszüge importieren mußt, hilft https://wiki.fhem.de/wiki/Import_von_Code_Snippets, ansonsten kann ich nur empfehlen, die Möglichkeiten von FHEMWEB zu nutzen, Fehler bei der Eingabe gleich zu bemängeln.

Just my2ct

Habe "früher" auch included ... aber bei einer richtigen "Raumbenamung"  braucht man es wirklich nicht.

Hinweis: Ein Gerät kann in mehr als ein Raum sein. Da finde ich die Übersicht sogar besser (sehr vieil besser) als in der fhem.cfg

Hmm, das mit der (mehrfachen) Raum-Zuweisung ist in dem Zusammenhang hilfreich.

Vielleicht in dem Zusammenhang noch interessant:
- Bildung von gegliederten Räumen: "room Steuerung->Interfaces" oder "room Steuerung->Z_CUL_HM_intern", dazu noch ein nettes Gruppen-Attribut, und schon ist alles recht übersichtlich :) . Bei mir gibt's nur noch "normale" Räume (einschl. Heizung und Garten, alles was irgendwie "intern" ist (und alle Logiken etc), befindet sich in einem Unterraum bei Steuerung.
- "list" (kennt ihr die Optionen -r und -R?!?)

(Mind. das mit den Unterräumen ist nach meiner Kenntnis nirgends im Wiki verarbeitet, ich habe nur noch keine Idee, wo sowas gut aufgehoben wäre.)

"->" erzeugt Unterräume?

Stimmt .. da war doch was ..... schon wieder etwas, was ich umsetzen wollte und vergessen habe ...

Kannst du mal ein Bild oder so zeigen von deiner Gliederung. Bisher stand das noch nicht auf meiner Liste aber gerade hört sich das echt genial an.
Wollte erst mal alles am laufen haben und mich um Ordnung in den Räumen später kümmern. Habe ja diverse Konfigs und darin meine Gliederung. Mit den ganzen Infos von euch, macht das aber tatsächlich nur noch bedingt Sinn.

Irgendwo hatte ich schon ein Bild gemacht für's Wiki ;D , finde aber grade den Stick nicht...

Aber bitte: das ist keine Raketenwissenschaft, zwei bis 4 Geräte mal eben mit einem passenden Attribut versehen (2 Unterräume...), und du siehst "live", wie es funktioniert. "Schade" ist eigentlich nur, dass ich den "Steuerung"-Raum komplett leeren mußte, sonst gibt es in der ersten Raumdarstellung zwei Räume "Steuerung"- einen mit den "direkt" im Raum befindlichen Geräten, direkt drunter dann den mit den Unterräumen.

Zitat von: 87insane am 12 Februar 2019, 15:37:35
Mit den ganzen Infos von euch, macht das aber tatsächlich nur noch bedingt Sinn.

Schön, wenn wir dich überzeugen konnten.

OT:
Jetzt fehlt nur noch die Info, wie ich Geräte aus einem Raum automatisch in einen Unterraum "verschiebe", d.h. denn attr raum per "Raumliste" veränder ... suche mich gerade "wie blöde". Aber DAS ist ein anderes Thema ... (und ich schon wieder etwas neues gelernt)

Zitat von: Wernieman am 12 Februar 2019, 15:51:08
OT:
Jetzt fehlt nur noch die Info, wie ich Geräte aus einem Raum automatisch in einen Unterraum "verschiebe", d.h. denn attr raum per "Raumliste" veränder ... suche mich gerade "wie blöde". Aber DAS ist ein anderes Thema ... (und ich schon wieder etwas neues gelernt)

Vielleicht hilft das hier:
https://wiki.fhem.de/wiki/Cmdalias#roomrename

OT: FHEM-Forum .. hier werden sie geholfen ;o)

DANKE

Zitat von: Wernieman am 12 Februar 2019, 16:00:44
OT: FHEM-Forum .. hier werden sie geholfen ;o)

DANKE

:) Gerne!
(Vielleicht hast du ein Bild für 87insane, dann wären wir fast wieder on-topic ::) . Oder wolltest gleich den Wiki-Artikel schreiben?)

Zitat von: Wernieman am 12 Februar 2019, 15:34:44
Stimmt .. da war doch was ..... schon wieder etwas, was ich umsetzen wollte und vergessen habe ...

Ging mir auch so. Neulich habe ich angefangen, mein UI zu renovieren, und da bin ich wieder drauf gekommen, dass da doch was war mit diesen verdammten Unterräumen. Hätte ich das bloß schon länger mal gemacht :( .
Jetzt ist in "unsorted" bloß noch was, wenn ich irgendein temporäres Device erzeuge oder autocreate irgendwas aufschnappt, das es nicht zuordnen kann, alle HM-internen Devices (das ist echt unübersichtlich mit den RT's und mehrkanaligen!) haben ein neues Zuhause, und das ganze praktisch mit 0 Aufwand.
Gehört für mich zwischenzeitlich einfach in die Kategorie "Sollte man kennen".

EDIT: Doch noch geschafft, einen screenshot zu machen...
Man sieht übrigens auch ein "besonderes" devStateIcon für eine HM-Thermostaten :) . Code folgt bei Gelegenheit :) .

Das wird in jedem Fall auch ein Doing auf meiner Liste. Zuerst möchte ich aber meine "Probleme" weg bekommen. Danach kommt die Schönheit. Habe gerade die Logs geprüft und heute Nacht ist natürlich nichts an/aus gegangen. Werde also länger warten müssen.

Am Wochenende werde ich zuerst weiter an meiner "Letzter Alexa Wecker und dann mach etwas"-Schaltung basteln, über die ich auch schon hier im Forum etwas schrieb und auch dazu fragte. Mit Perl wird es ganz langsam etwas besser und ich freue mich immer wieder, wenn einer was sinnvolles schreibt. Auch wenn es am eigentlichem Thema vorbei geht, was hier geschrieben wurde...Die Kollegen, die Probleme wie ich haben, werden das hier dankbar lesen und sich erfreuen an neuen Ideen für Räume usw. :)

Mach' wie du denkst :) .

Bei mir war das eine Aktion von unter einer Stunde (devspec incl. FILTER sei Dank, ganz ohne room-rename), und wenn man eine Idee hat, wie man es haben möchte, kann man bei neuen Devices ja auch gleich richtig sortieren, dann dauert es kaum länger... Eine gute devspec-Übung ist das nebenbei auch noch, kann man immer brauchen :) .

Für Dich/Euch ist das natürlich schnell gemacht. Da ich nicht so viel kann wie ihr, dauert es vermutlich eher einen ganzen SAM Mittag.
Ich warte quasi voller Ungeduld auf das nächste Webinar ;)

Zitat... Eine gute devspec-Übung ...

Jetzt hast Du mich "voll erwischt" ... mit devspec stehe ich aktuell auf dem Krigsfuß und hätte aktuell nicht mal eine Idee, es umzusetzen

Zitat von: Wernieman am 13 Februar 2019, 08:14:23
Jetzt hast Du mich "voll erwischt" ... mit devspec stehe ich aktuell auf dem Krigsfuß und hätte aktuell nicht mal eine Idee, es umzusetzen

;D
War nicht beabsichtigt, dich voll zu erwischen... Dann halt weiter OT:

attr ist ja auch nur ein FHEM-Kommando, man kann also z.B. auch "attr <devspec> room Steuerung->Wasauchimmer" anwenden, siehe https://fhem.de/commandref_DE.html#devspec. Was da nicht explizit steht: man kann auch mehrere FILTER hintereinanderhängen ;) .

Wenn ich mir nicht sicher bin, mache ich das in der Regel so, dass ich erst mal mit "list" übe, bis ich nur noch die wirklichen Zieldevices beieinander habe, und dann den "Echtbefehlt" (hier: attr) absetze. Das room-attr hat halt den Nachteil, dass es erst mal überschreibend wirkt. Es gibt da aber ein unscheinbares Parameterchen ("-a"), das eventuell weiterhilft, siehe https://fhem.de/commandref_DE.html#attr. Dazu sollte man aber erst mal alle Geräte aus unsorted raus haben, also damit anfangen.

In meinem Fall war es einfach, ich habe erst mal in den meisten Fällen zunächst nur noch den Steuerungs-Unterraum angegeben und dann nachträglich die relativ wenigen Geräte, die (auch) in anderen Räumen sein sollten dann noch dahin gepackt - ganz klassisch über Gecklicke.... War - wie gesagt - eigentlich keine große Sache.

Seit eben finden sich die Unterräume auch im Wiki :) :
https://wiki.fhem.de/wiki/Trick_der_Woche#Unterr.C3.A4ume_anlegen

Vielleicht erinnert sich im März jemand dran, wie das mit dem "-a" ging...

Moin moin...

es ist wieder passiert.

Anbei was ich loggen konnte:

FHEM LOG:
2019.02.19 08:47:14 3: CUL_443MHz IT_set: az_stehlampe on
2019.02.19 08:47:14 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.19 08:47:14 5: IT_Set: GetFn(raw): message = is00000FFF0F0F Antwort =   raw => is00000FFF0F0F
2019.02.19 08:47:14 1: az_Stehlampe_ESP notify -- EVENT ist: strom_rechts: on, EVTPART1 ist: on
2019.02.19 08:47:14 3: CUL_443MHz IT_set: az_stehlampe off
2019.02.19 08:47:14 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.19 08:47:14 5: IT_Set: GetFn(raw): message = is00000FFF0FF0 Antwort =   raw => is00000FFF0FF0
2019.02.19 08:47:14 1: az_Stehlampe_ESP notify -- EVENT ist: strom_rechts: off, EVTPART1 ist: off

Sonoff ESPeasy LOG:
2019-02-19_08:47:14 ESPEasy_az_licht_strom_rechts strom_rechts: on
2019-02-19_08:47:14 ESPEasy_az_licht_strom_rechts str: on
2019-02-19_08:47:14 ESPEasy_az_licht_strom_rechts strom_rechts: off
2019-02-19_08:47:14 ESPEasy_az_licht_strom_rechts str: off

433 MHz IT LOG:
2019-02-19_08:47:14 az_stehlampe An
2019-02-19_08:47:14 az_stehlampe Aus

Sieht so aus als würde der Input tatsächlich durch den Schalter kommen. Also würde das notify korrekt auslösen und FHEM-Seitig wäre alles ok. Zumindest sehe ich das so. Hoffe das ist korrekt.

Ich sende speziell bei diesem Schalter zwar RSSI aber ich sende auch den Zustand der Relays alle 180 Sekunden. In den neueren FW von ESPeasy muss man keinen "Fake-Wert" mehr senden, da man jedem angelegtem Gerät sagen kann wann es seinen Status senden soll. Habe leider hier keinen Screenshot oder so, da ich nicht zuhause bin. Aber die, die ESPeasy nutzen, werden es schonmal gesehen haben. Ich würde als nächstes eine noch neuere FW von ESPeasy drauf flashen und erneut testen. Sollte es bleiben, wird es vermutlich mit dem senden des Status zu tun haben.... Hoffe ich...

Zitat2019.02.19 08:47:14 5: IT_Set: GetFn(raw): message = is00000FFF0F0F Antwort =   raw => is00000FFF0F0F

Vor dem Schalten k9ommt immer die IT?

Könnte da etwas "prellen"?

Das wundert mich weil:

Das hier ist aktuell das notify:
(ESPEasy_az_licht_strom_rechts:strom_rechts:.(on|off)) {
  fhem("set az_stehlampe $EVTPART1") if ( ReadingsVal('az_stehlampe', 'state', 0) ne $EVTPART1);
  Log(1,"az_Stehlampe_ESP notify -- EVENT ist: $EVENT, EVTPART1 ist: $EVTPART1");
}

Das reagiert nur auf den ESP Schalter. Wieso geht also beim aktivieren von IT der Schalter auch an?

Wenn ich den Schalter trigger, steht auch IT an erster Stelle. Vermutlich da es schnell reagiert. Anbei ein LOG Auszug wenn ich es normal schalte:
2019.02.19 09:52:41 3: CUL_443MHz IT_set: az_stehlampe on
2019.02.19 09:52:41 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.19 09:52:41 5: IT_Set: GetFn(raw): message = is00000FFF0F0F Antwort =   raw => is00000FFF0F0F
2019.02.19 09:52:41 1: az_Stehlampe_ESP notify -- EVENT ist: strom_rechts: on, EVTPART1 ist: on
2019.02.19 09:52:43 3: CUL_443MHz IT_set: az_stehlampe off
2019.02.19 09:52:43 5: CUL_443MHz IT_set: Type=CUL Protocol=V1
2019.02.19 09:52:43 5: IT_Set: GetFn(raw): message = is00000FFF0FF0 Antwort =   raw => is00000FFF0FF0
2019.02.19 09:52:43 1: az_Stehlampe_ESP notify -- EVENT ist: strom_rechts: off, EVTPART1 ist: off

Hier sieht man, es ist genauso. Tatsächlich sieht man ja Stunden:Minuten:Sekunden und alles ist genau in der gleichen Sekunde wenn geschaltet wird.

Was würdet ihr nun testen? Ich würde, wie oben schon geschrieben, den ESP Schalter erst mal neu flashen und wenn das nicht hilft, ggf. die Sendeeinstellungen überarbeiten. Ich finde leider aber auch keine vernünftigen Anleitungen mit der aktuellen ESP Version bzw. einer halbwegs aktuellen Version. Eine Art best-practice fehlt mir an der Stelle.

Dann mal eine andere Empfehlung:
Richte Dir einen syslog-Server und lasse espeasy dorthin loggen (info).

Tippe auf "Schalter-Prellen" ....

Btw:
Wie ist denn der Schalter an den esp angeschlossen?

Syslog Server müsste ich dann noch machen. Vermutlich wird der mir aber auch nur loggen was wir schon wissen. Wenn ich in die live LOGs sehe und laufen lasse, sehe ich ja auch nicht woher der Befehl kommt....

ZitatTippe auf "Schalter-Prellen" ....

Ist das Interna vom Syslog Server? Oder was meinst du damit?

ZitatWie ist denn der Schalter an den esp angeschlossen?

Es ist ein fertiger Sonoff T1 EU, den ich einfach umgeflashed hab. Also Serielles Kabel dran und die FW rüber gespielt.

Also nichts "Hardwaregebasteltes".

"Schalterprellen" hast Du eigentlich beim Ein/Aus-schalten, das es kein sauberes Signal gibt, sondern mehrere kleine. In Deinem falle tippe ich darauf, das der abgeschaltete Schalter (getrennt) induktiv einfach mal in Signal bekommt. Beim Selberbau würde ich jetzt eine Enststöhrung (RC oder Ähnliches) empfehlen. bei einem fertigen Produkt dagegen ...

Wie hast Du den schalter in espeasy konfiguriert?

Mal ganz doof gefragt: Es gibt nicht zufällig auch einen Eventhandler, der auf den IT-Code reagiert?

ZitatWie hast Du den schalter in espeasy konfiguriert?

Kann ich aktuell keine Screenshots von machen, erst heute am späten Nachmittag. An sich ist es Standard. Einzig ich sende alle 180 Sekunden anstatt RSSI, den Status des Relays.
Was ich aber dazu noch erwähnen muss. Der Schalter hat zwei Relays. Der linke geht direkt an die Deckenlampe. Die macht diese Probleme nicht. Der rechte Schalter steuert das Relay aber es steckt nichts drin (kein Kabel), da er ja nur an FHEM senden soll und die LED des Schalters nur mit dem Relay angeht. Kann es ggf. auch daran liegen? Deine Prell-Theorie impliziert sowas ja. Ggf. reicht es ja einfach ein Kabel ein zu stecken und ne Klemme drauf zu machen. Werde ich auch testen.

ZitatMal ganz doof gefragt: Es gibt nicht zufällig auch einen Eventhandler, der auf den IT-Code reagiert?

Keinen, der auch den Sonoff Schalter aktivieren würde. Ich habe eine IR/RF Wandlung drin. Diese reagiert aber auf Pseudo Codes und geht nicht in Richtung Sonoff. Das schließe ich in diesem Fall aus. Wenn es ein Nachbar wäre oder ein weiteres z.B. notify, würde das Verhalten des Schalters nicht beeinflusst. Also er würde einfach aus bleiben.

Zitat von: 87insane am 19 Februar 2019, 11:49:40
Keinen, der auch den Sonoff Schalter aktivieren würde. Ich habe eine IR/RF Wandlung drin. Diese reagiert aber auf Pseudo Codes und geht nicht in Richtung Sonoff. Das schließe ich in diesem Fall aus. Wenn es ein Nachbar wäre oder ein weiteres z.B. notify, würde das Verhalten des Schalters nicht beeinflusst. Also er würde einfach aus bleiben.

Die Frage war nicht, ob es ein notify gibt, das irgendwas mit dem Sonoff macht, sondern die Frage war, ob es eines gibt, das das Senden von IT-Code veranlassen könnte. Sorry, wenn das nicht klar genug formuliert war.
In dem Fall kann es nämlich sein, dass das die beobachtete Kette auslöst...

Es gibt dafür nur das eine. Also leider nein

Gesendet von meinem LG-H850 mit Tapatalk

Was mich auch noch fehlt:

Zitat
Wie hast Du den schalter in espeasy konfiguriert?

https://forum.fhem.de/index.php/topic,97045.msg908313.html#msg908313

Screenshots kann ich heute ab ca. 16:20 einhängen...

Dachte eher: Switch oder ..... ;o)

Ja ja, klar...als Switch. Das einzige was anders ist, ist das senden der relays anstelle von rssi. Damit ich kein absent bekomme.

EDIT: Mein PC zuhause hat sich natürlich heute dafür entschieden, dass meine SSD mal neu muss. Muss also zuerst das Problem beheben, bevor ich Screenshots anhängen kann. Allerdings sind meine Schalter alle gleich eingestellt. Sowohl Relays als auch Taster selber sind als Switch eingestellt. Die Relays auf normal und die Taster auf low (damit sie sofort reagiern und nicht erst beim los lassen). Hinzu eben noch das senden vom Zustand der Relays.

Kann es ggf. sein, dass ein Gerät, welches ein Relay schaltet, wirklich immer ein Kabel drin stecken haben muss damit es nicht induktiv oder so schaltet? Ich meine die Idee kam hier ja und ich weiß das leider nicht.

Okay - Dann eben via Notebook. Fhem geht im Moment vor :)

Anbei mal Screens vom kompletten Schalter. Habe nur eine Seite genommen, da die andere genau so ist. Heißt nur anders. Sieht man aber in der hw_uebersicht

In Rule 4 habe ich noch:
on System#Boot do
   GPIO,5,0
   GPIO,12,0
endon

Wie ich soeben bemerkte, macht der Schalter beim neustart genau dieses Verhalten. Und das wegen den Rules in Set 4. Nun frage ich mich wie ich sonst dem Schalter sage, dass nach einem neustart immer alles aus sein soll.

Die folge Frage wäre, warum startet er überhaupt neu?

EDIT:
Wenn ich die Rule rauß nehme, passiert es nicht mehr ABER dann ist der rechte der beide Schalter am leuchten obwohl er aus ist. Das Thema hatte ich mit der Rule erschlagen, damals. Lustig ist, das die LEDs nur mit dem Relay geschaltet werden können. Wenn ich den Schalter OHNE die Rule neu starte und dann am Ausgang gegen Messe sind es 0V die rauß kommen. Also ist die LED aktiv aber das Relay aus. Dazu hatte ich schon mal einen Thread aber bisher ohne Erfolg. Wie macht ihr das? Im besten Falle meldet sich ggf. jemand mit halbwegs aktueller ESPeasy FW und Sonoff T1 EU / 2-Gang.
PS: Wenn ich den Schalter neustarte und die Rule ist rauß. Dann leuchtet die LED ja. Wenn ich dann einmal auf die Taste mit der LED drücke, geht diese aus aber es passiert nichts weiter (es wird nichts geschaltet). Das ist schonmal gut aber es kann ja kaum richtig sein....


EDIT2: Interessant ist, dass ich GPIO 5 für das Relay auf der rechten Seite eingestellt habe. Wenn ich (einfach zum testen) GPIO 4 anstelle von 5 eingebe und das überall ändere auf 4. Dann kann man trotzdem schalten ABER ohne das die LED angeht oder ausgeht. Sie bleibt einfach dunkel.

d.h. nach einem solchen Verhalten (Kurzer Lichtimpuls) hattest Du ein reboot des ESP?

Ja!

Habe jetzt gerade das Thema wieder gehabt und im ESP geschaut warum.
Ich sehe hier:

Boot: Manual reboot (53)
Reset Reason: Hardware Watchdog

Wie ich dort nun genauer weiter suchen muss, muss ich auch erst mal googlen.

d.h. er hat das WLAN verloren und deshalb rebootet.

Sicher das es nur WLAN sein kann? Hab alle schalter mal geprüft heute morgen. Alle sind nie länger an als 24,25 Stunden und laufen dann in ein Reset. Die schalter sind an unterschiedlichen Orten. Die rssi werte sind von sehr gut<50 bis hin zu 78+. Es muss aufgrund dessen ja einen anderen Grund geben oder aber probleme in der espeasy Firmware. Kann man das mit einem Syslog Server auslesen?

Wie kann ich weiter debuggen? Wenn es wirklich WLAN sein sollte, was mögen die ESP easy geräte nicht? Bei mir sind sie im N Netzwerk mit DHCP Reservierung für jeden Schalter.  Ansonsten gibt es keine Reglementierung für die Schalter. Bin aktuell echt ratlos. Da es anscheinend alle sind. Die Rollo Schalter machen nach reboot keine komischen Dinge. Die schalter, die für Licht genommen werden, mit den einfacheren regeln laufen in komisches verhalten. Würde das gerne alles sauber haben aber bin ideenlos. Ggf hilft ne neue FW, wenn ggf WLAN issues behoben wurden. Aber wenn dem nicht so ist...?

Zu WLAN und - v.a. den ESP-Dingern - gibt es bereits Dutzende Beiträge...

Häufigstes Problem: "Falscher" AP (Fritzbox) iVm. zu vielen Geräten (so ab Mitte 20 wird's gerne lustig - Handys usw. bitte mitzählen).

Naja - die Schalter laufen ja über WLAN und ich kann sie kontrollieren. Weswegen es ja der richtige sein muss. Ich habe aktuell aktiv:

1 x Router im AZ
1 x Repeater im Flur

X Geräte im WLAN. Es sind ca. 40 Geräte im Netzwerk (Kabel u. WLAN). Der Router kommt mit der Verwaltung aber gut hinterher. Ich habe keine 0815 Hardware von der Tcom oder so.

Ein Gedanke wäre, dass die Dinger ggf. mit dem N draft nicht komplett klar kommen. Das könnte ich leicht testen. Interessanter wäre es natürlich den genauen Fehler zu haben. Habe gelesen, dass die Dinger auch bei Loop (fehlerhafter Code) WLAN trennen und dann neu starten. Gibt es eine Möglichkeit an den genauen Fehler zu kommen? Werde gleich mal nach den anderen Threads gucken.
Das Rollo in der Küche so wie auch der Schalter im Bad, laufen über den Repeater. In der ESP FW kann man leider nicht sagen, zu welchem AP (mac Adresse) er sich verbinden soll. Man kann nur auswählen wie das Netzwerk heißt. Sobald das geschehen ist, verbindet er sich immer einfach nur mit der stärkeren Sendequelle. Was aber auch egal ist, da einige der anderen Schalter auch direkt am eigentlichem Router hängen und die machen die gleichen Probleme.

Na ja, du kannst noch 10x behaupten, dass da kein Problem ist, weil da keines sein darf ;) .

Tatsache ist, dass die AVM-Büchsen, die du da scheinbar hast (warum verschweigst du das?!? Danach war indirekt, aber doch hoffentlich an sich klar gefragt...), eben genau zu den unmotivierten Reboots der ESP-basierten Geräte passen. Kannst du gerne wegdiskutieren wollen, aber ich bin dann mal raus aus der Diskussion ;D .

Ich denke du hast es missverstanden. Ich diskutiere nicht, ich bin verzweifelt.

Ich habe KEIN AVM! Würde ich auch nicht kaufen! Aus welchem Schluss, LOG oder sonst was, ziehst du diese "Erkenntnis"?
Ich habe einen Netgear Router R7500 und einen DLINK Repeater, da mein anderer gerade platt ist, hatte den für draußen genutzt.

Ich gebe mir Mühe alle Fragen zu beantworten und damit weiter zu kommen. Aber hier einfach Unterstellungen zu machen, ist wenig zielführend!

Hinzu kann es ja sein, das ggf. Problem mit der Koexistenz von 20/40Mhz oder aber dem N draft bestehen. Das sagte ich aber auch vorhin. Was ich leider nicht gefunden habe, ist ein Weg, genau zu prüfen, was der Schalter sagt in diesem Moment. Die Erkenntnis das ein HW Watchdog nur auf WLAN Probleme zurück zu führen ist, ist mir auch nicht ganz schlüssig. Vermute mal, das ist Erfahrung.

EDIT:
In den neueren Versionen von ESP habe ich mal das changelog angesehen. Aktuell steht z.B. dies drin:

[WiFi] Allow force to B/G to improve WiFi stability.
[WiFi] Correct fall-back when B/G only mode cannot connect
[WiFi] Add option to set wifi off and restart wifi when connection lost

ggf. bringt das schon was. So würde ich den n draft anlassen können. Aber es genauer zu wissen, wäre natürlich super!

Sorry für die falsche Unterstellung.

Jedenfalls ist es so, dass du nicht der einzige bist, bei dem die ESP's ab einer gewissen Anzahl spontane Reboots hinlegen und keiner so richtig weiß, was die eigentliche Ursache ist - Router, Firmware, EMV-Themen....
Statistisch gesehen tritt das halt bei bestimmten Hardware-Kombinationen häufiger auf, aber sowas wie gesicherte Erkenntnis hat wohl keiner. Ist einer der Gründe, warum ich sehr ungern WLAN-Gerätschaften in mein FHEM integriere und manchmal vielleicht über's Ziel rausschieße, wenn es nahe liegt, dass "sowas" mal wieder Probleme macht ;D .

Kleine Nachfrage:

Alle Deine esp8266 rebooten innerhalb von 24h?
Also keine uptime >24??

Mein letzter "Problemkandidat":
GIT version: mega-20190121
Local Time: 2019-02-20 11:00:41
Uptime: 16 days 10 hours 49 minutes

Heute Morgen schaute ich nach ob alle betroffen sind. Leider sind es tatsächlich alle...

Einer war einen Tag und 2 Stunden an. Alle anderen hatten heute nacht (verschiedenste Zeiten) einen reset gemacht (also unter 24h).


Hatte oben zwar schonmal gefragt aber kann der Syslog Server sowas genauer anzeigen? Habe noch keinen aufgesetzt, da mein Rechner ja auch noch defekt war (kommt echt alles zusammen im Moment). Wenn er es eingrenzen könnte, würde ich ASAP einen einrichten und laufen lassen. Ggf. bringt die Analyse ja anderen auch noch was.

ZitatMein letzter "Problemkandidat":
Code: [Auswählen]
GIT version:   mega-20190121
Local Time:   2019-02-20 11:00:41
Uptime:   16 days 10 hours 49 minutes

Lustig.... Meine sind aktuell alle auf mega-20190121. Aber sowas wie 16 Tage.... Das ist ja schon Luxus :)

EDIT: Da ich aktuell ja noch alles mit logge was den Schalter im AZ angeht, habe ich gerade mal geschaut..... Er steht seit ich das LOG aktivierte auf present in FHEM. Nicht ein einziges absent. Dies würde ja umgekehrt heißen, das zumindest FHEM immer genug Infos bekommen hat, bzw. die Intervalle nicht überschritten wurden. Das ist wenigstens etwas....

Gibt es so ne art Liste, in der drin steht was ESPEASY nicht mag an WLAN Einstellungen? Kann zum testen mal die Koexistenz + n draft aus machen. Das ist schonmal eine Idee. Hinzu würde ich einen Schalter mal auf die neue ESPeasy Version anheben, in der auch im Changelog steht, dass dort wifi Seitig was geändert wurde (Release mega-20190215).

Habe die Version drauf, da mit "älteren" genau dieser esp sich heufiger aus dem WLAN verabschiedet hatte.

Bezüglich Present:
Fhem sagt nur das er absent ist, wenn er sich nicht X-Sekunden (einstellbar) gemeldet hat. Da ein reboot dieser Dinger bekanntlich sehr schnell ist, dürfte innerhalb dieser Zeit immer ein "Datum" kommen. Ich glaube (Hinweis: glauben<>wissen), das es im Default eine Zeit von 5 Minuten war.

Bzw:
Wenn Du die uptime bei den RSSI Werten mitsendest (habe ich bei mir so), könntest Du Dir eine Alarmierung/Info bauen, wenn die uptime kleiner wird, da dann ein reboot stattgefunden haben müsste.

Bezüglich Syslog:
Ich weiß nicht, was der esp beim log "info" alles mitloggt, habe es bei mir auf "error" stehen. Natürlich muß das WLAN laufen, solche Fehler wird er "schlecht" senden können. Aber wie immer gilt: In einem solchem Falle ist jeder "Brotkrumen" an Info sinnvoll! Schließlich sind wir nur dadurch darauf gekommen, das es schon auf esp/wlan-Seite passiert.

Habe übrigens deshalb bei mir deshalb ein eigenes WLAN nur für die esp aufgespannt. Meine Zotac hatte ein freien, hostapd fähigen, WLAN-Controller .... ;o)

Hmmmm...

Kann man auf einem ESP direkt in ein LOG File schreiben? Ich meine Platz wäre ja noch und so könnte er vor dem Restart alles mit schreiben...?

Wie gehen wir/ich nun vor?
- Als erstes wollte ich einen Schalter auf die aktuelle ESPeasy FW bringen. Die anderen lasse FW-Seitig unberührt.
- Zusätzlich werde ich die Koexistenz abschalten (20/40Mhz).

Danach kann ich ja leider erstmal nur warten. Hinzu würde ich gerne den n draft aus machen aber das erst wenn die beiden Dinge oben nix gebracht haben. Habe es so vor, da ich sonst nicht weiß, was es am Ende war.
Weitere Ideen / Anregungen nehme ich aber gerne auf! 

ob lokales log möglich ... mir nicht bekannt. Deren Flash-Speicher mag häufig auch kein mehrmaliges überschreiben.

1. Koexistenz ist nun aus.
2. Schalter im AZ mit mega-20190216 geflasht und hängt nun im Netzwerk.

Was mir gerade noch aufgefallen ist: Der Schalter vom Bad hat nun Uptime:   1 days 11 hours 44 minutes. An diesem hatte ich aber auch nichts geändert. Der Router neustart von 5 min hat ihn nicht interessiert. Aber der hängt auch hinter einem Repeater. ABER auch die Schalter die auf dem Hauptrouter hängen haben in den 5min noch keinen Stress gemacht und liefen bzw. laufen weiter.

Das mit dem internen Log werde ich mal googlen. Also bei den Sonoff T1 habe ich bei meinem Test-Schalter auf meinem Tisch bestimmt schon 25 mal was anderes drauf geflasht. Bisher ist es okay für ihn. Ohne internes Log, sehe ich wenig chancen (deine Begründung, weiter oben...). Aber trotzdem werde ich extern mit loggen. Dafür muss ich mir noch einen Server basteln. Ich sehe die chance das er ggf. vor seinem Reboot noch genug in das externe Log schreibt, um zu wissen warum er sich neustartet.

EDIT: Noch nicht an aber in der neuen FW vorhanden...(siehe Screen)

Für einen syslog-Server reicht ein minimales Unix .... am besten gleich mit rsyslog
apt-get install rsyslog

Und mit den Zeilen:

module(load="imuxsock") # provides support for local system logging
module(load="imklog")   # provides kernel logging support

# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")

# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")

# Enable non-kernel facility klog messages
$KLogPermitNonKernelFacility on

# Log remote hosts to separate log file
$template PerHostLog,"/var/log/remote-hosts/%HOSTNAME%.log"
$template RemoteHostFileFormat,"%TIMESTAMP% %HOSTNAME% %syslogfacility-text% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::space-cc,drop-last-lf%\n"

$template Incoming-logs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log"
*.*  ?Incoming-logs
& ~


Hinweis:
Obiges ist KEINE komplette Config ....

Hab es mir einfach gemacht. Hab auf meinem Synology einfach im Protokollcenter den Empfang aktiv gesetzt und den ESPeasy´s (az_licht, bz_licht) verraten wohin diese loggen sollen.
Aktuell habe ich das Loglevel erstmal nur auf Error. Sollte das nicht reichen, muss ich es tiefer stellen.

Nun warte ich mal ab....

Die oben genannten Änderungen + Syslog sind aktiv. Weitere Ideen? Will auch nicht zu viel auf einmal machen. Aber wenn ich schon mal ein weiteres doing habe, wäre es super. Logge ja jetzt in FHEM und Syslog auf den beiden Schaltern. AZ ist mit neuer FW, BZ ist mit der älteren FW. So kann ich auch direkt sehen ob die neuere FW Verbesserung bringt. Bin gespannt was ich morgen sehe wenn ich rein schaue :)

Synology hatte ich wirklich vergessen .. ;o)
(Danke für den Tipp, auch wenn ich dort jetzt "senden" eingerichtet habe ;o) )

Auf Error loggt espeasy wirklich nur error, aber z.B. keine Schalterbetätigung. Eventuell solltest Du das Logging höher stellen ... mindestens Warning, wenn nicht sogar erstmal Info ..

Schön zu hören... Ihr Urgesteine vergesst auch Dinge :) :-P

Ich hatte auch erst überlegt wo ich den installiere. Danach eben, welche Geräte eigentlich eh immer an sind. Ist ja kein großer Job. Naja und dann eben....
Hab die Logs auf normal debug stehen. So müllt der zwar schon viel aber das lässt sich am Ende ja rauß selektieren.

Danke schonmal...


EDIT: Kein Problem. Bin ja froh wenn ich auch mal was beitragen kann :) - Hab auf dem kleineren von beiden echt alles am laufen. Sehr praktisch... Keiner brauch einen eigenen PXE Server. Aber naja :-P

PS: Hab jetzt schon von beiden Schaltern immer wieder:
EspEasy: WD : Uptime 132 ConnectFailures 0 FreeMem 19472 WiFiStatus 3

Bedeutet laut Wiki (https://www.letscontrolit.com/wiki/index.php/Wifi (https://www.letscontrolit.com/wiki/index.php/Wifi))

=

Zitat3   Deauthenticated because sending STA is leaving (or has left) IBSS or ESS   The access point went offline, deauthenticating the client.

Kann aber beide erreichen.... Die ganze Zeit.

Naja .. dafür reicht eine kurze Störung des WLANs, welche Du selber nicht merkst ...

Aber in der Zeit macht er doch kein reboot?

P.S. der syslog geht auch über WLAN .. also muß es zu der Zeit funktioniert haben ;o)

Guten Morgen,

er hat die ganze Zeit über Probleme, ist aber erreichbar. Nach einer ewigen Zeit startet er dann neu aus irgendwelchen Bedingungen. Ich vermute fast, nach Zeit x oder Versuch x.
Habe hier mal das Log vom AZ Schalter. Dieser ist um 06:11:20 neugestartet. Kein weiteres mal. Leider erkenne ich im LOG nur nicht warum. Hier sieht man nur das er ein paar Sekunden weg war.
Das Log ist hier leider nicht aussagekräftig genug. Ich werde ein Log Level tiefer (debug more) gehen und nochmal abwarten.

2019-02-21 06:12:02 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1 ConnectFailures 0 FreeMem 19704 WiFiStatus 3
2019-02-21 06:12:00 Debug 192.168.20.50 kern az_licht EspEasy: EVENT: Clock#Time=Thu,07:12 Processing time:27 milliSeconds
2019-02-21 06:12:00 Notice 192.168.20.50 kern az_licht EspEasy: EVENT: Clock#Time=Thu,07:12
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 closing connection
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (187/443)
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 303 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: EVENT: Clock#Time=Thu,07:11 Processing time:24 milliSeconds
2019-02-21 06:11:46 Notice 192.168.20.50 kern az_licht EspEasy: EVENT: Clock#Time=Thu,07:11
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: EVENT: Time#Initialized Processing time:27 milliSeconds
2019-02-21 06:11:46 Notice 192.168.20.50 kern az_licht EspEasy: EVENT: Time#Initialized
2019-02-21 06:11:46 Notice 192.168.20.50 kern az_licht EspEasy: Current Time Zone: DST time start: 2019-01-28 02:00:00 offset: 120 minSTD time start: 2019-12-29 03:00:00 offset: 60 min
2019-02-21 06:11:46 Notice 192.168.20.50 kern az_licht EspEasy: Time adjusted by -1550725891041.52 msec. Wander: -430757191.96 msec/second
2019-02-21 06:11:46 Notice 192.168.20.50 kern az_licht EspEasy: NTP : NTP replied: delay 30 mSec Accuracy increased by 0.473 seconds
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 closing connection
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (185/441)
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 301 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 closing connection
2019-02-21 06:11:46 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-21 06:11:45 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (187/443)
2019-02-21 06:11:45 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 303 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-21 06:11:45 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-21 06:11:45 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 closing connection
2019-02-21 06:11:45 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-21 06:11:45 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (185/441)
2019-02-21 06:11:45 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 301 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-21 06:11:45 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-21 06:11:45 Notice 192.168.20.50 kern az_licht EspEasy: Webserver: start
2019-02-21 06:11:20 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 189539/2161/9/82.90
2019-02-21 06:11:20 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 3697693 avgLoopDuration: 153.25 loopCounterMax: 245901 loopCounterLast: 189539 countFindPluginId: 0
2019-02-21 06:11:19 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 824 ConnectFailures 0 FreeMem 19392 WiFiStatus 3
2019-02-21 06:11:00 Debug 192.168.20.50 kern az_licht EspEasy: EVENT: Clock#Time=Thu,07:11 Processing time:26 milliSeconds
2019-02-21 06:11:00 Notice 192.168.20.50 kern az_licht EspEasy: EVENT: Clock#Time=Thu,07:11
2019-02-21 06:10:50 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 188355/2160/9/82.40
2019-02-21 06:10:50 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 3697693 avgLoopDuration: 154.24 loopCounterMax: 245901 loopCounterLast: 188355 countFindPluginId: 0
2019-02-21 06:10:49 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 824 ConnectFailures 0 FreeMem 19392 WiFiStatus 3
2019-02-21 06:10:38 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 closing connection
2019-02-21 06:10:38 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-21 06:10:38 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (187/443)
2019-02-21 06:10:38 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 303 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-21 06:10:38 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-21 06:10:38 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 closing connection
2019-02-21 06:10:38 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-21 06:10:38 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (185/441)
2019-02-21 06:10:38 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 301 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-21 06:10:38 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-21 06:10:38 Debug 192.168.20.50 kern az_licht EspEasy: EVENT: strom_rechts#strom_rechts=0.00 Processing time:24 milliSeconds
2019-02-21 06:10:38 Notice 192.168.20.50 kern az_licht EspEasy: EVENT: strom_rechts#strom_rechts=0.00
2019-02-21 06:10:38 Notice 192.168.20.50 kern az_licht EspEasy: SW : State 0.00
2019-02-21 06:10:38 Debug 192.168.20.50 kern az_licht EspEasy: EVENT: strom_links#strom_links=0.00 Processing time:27 milliSeconds
2019-02-21 06:10:38 Notice 192.168.20.50 kern az_licht EspEasy: EVENT: strom_links#strom_links=0.00
2019-02-21 06:10:38 Notice 192.168.20.50 kern az_licht EspEasy: SW : State 0.00
2019-02-21 06:10:20 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 189472/2161/9/82.80
2019-02-21 06:10:20 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 3697693 avgLoopDuration: 153.30 loopCounterMax: 245901 loopCounterLast: 189472 countFindPluginId: 0
2019-02-21 06:10:19 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 823 ConnectFailures 0 FreeMem 19392 WiFiStatus 3

Hinzu habe ich im AZ Schalter mal Force WiFi B/G: aktiviert. Die 20/40MHz Koexistenz ist im Router wieder aktiv. Diese war wohl nicht schuld.

Mal eine andere Frage .. wie voll ist Dein WLAN, bzw. der Verwendete WLAN-Kanal?

Stört eventuell ein Nachbar?

Hab autohopping aktiv. An sich wohne ich WLAN Seitig ganz gut hier. Alles Einfamilien-Häuser mit alten Leuten die teils nicht mal WLAN haben. Hab gerade nochmal geprüft was passiert bei WLAN komplett aus. Habe nun nur noch den Hauptrouter aktiv und komplett nur noch b/g. Auf meinem Channel sind aktuell +/- 3 keine weiteren WLANs. Also optimal.


EDIT:
Folgendes ist mir noch aufgefallen. In dem Moment wo wirklich kein Router da ist spucken die Schalter aus: Last Disconnect Reason:   (201) No AP found
In diesem Moment wird das Fallback WLAN der Schalter auch aktiv. Also wenn wirklich keine Verbindung besteht. Nachdem der Router wieder da ist, verschwinden die Fallback WLAN auf einmal und alle Geräte sind wieder am Router angemeldet.
Habe aktuell nur b/g an und den Hauptrouter und trotzdem Status 3. So langsam gehen mir die Ideen aus...

Mir auch ... Du hast nicht eventuell einen WLAN-Controller rumliegen,? Nur mal um ein ESP-Wlan aufzubauen?

Alternativ einen hostap-fähige WLAN-Hardware?

Hab noch ein paar alte Router die man durchaus nehmen könnte. Die reichen zum testen.

Nur mal so am Rande:
Von einem sporadischen Licht-schalten zu einem WLAN-Problem ... der Weg ist jetzt wirklich nicht gradlinig .. ;o)

pumabaer sagte auf Seite 1 bereits so etwas. Ich kann es bis jetzt nicht fassen.
Für mich ist das schon ein wenig komisch.

- Die ESPs melden sich ganz normal am WLAN an, lassen sich schalten und laufen ganz normal.
- Ich sehe die im Router
- Die Dinger selber schalten ihr Fallback WLAN aus
- Trotz verbundenem und laufendem WLAN bekomme ich Status 3
- Achja... Router für mehr als 10min weg und die machen trotzdem nicht den Fehler, den sie nach einigen Stunden machen. Die bauen, wie sie es sollen, ihr Fallback WLAN auf.

Also irgendwas passt da nicht!

EDIT:
Ggf. sind wir auch auf dem Holzweg. Die Zeile heißt ja:
WD : Uptime 42 ConnectFailures 0 FreeMem 17088 WiFiStatus 3

Er sagt der Status vom WIFI ist 3 aber er hat 0 ConnectFailures.

jep .. und was mich wundert, das Sie dann irgendwann einen reboot hinlegen. Eine uptime >24h solltest Du auf jedem Fall hinkriegen.

Nur .. irgendwo müssen wir mal anfangen und deshalb die Frage nach einem unabängigem WLAN. Am besten sogar in einem eigenen Netz. Wenn es DANN funktioniert, können wir zurückbauen und uns dem Fehler annähern. Wenn es DANN NICHT funktioniert, bin ich mit "meinem Latein" aktuell am Ende ....

Bzw:
hast Du in den ESPs für Zeitserver/Fhem-Server IPs oder DNS-Namen eingetragen?

Die haben alle pool.ntp.org drin. Erreichen ihn auch... Könnte das auch über das NAS via IP spiegeln. Macht das einen Unterschied?

Das mit dem eigenen Netz und WLAN wäre machbar. Suche gerade bei google nach dem Reset Reason 53. Denke, das gibt ggf. mehr Aufschluss.

EDIT: Mache gerade ein issue auf github auf. Mal sehen was die Kollegen sagen. (https://github.com/letscontrolit/ESPEasy/issues/2342 (https://github.com/letscontrolit/ESPEasy/issues/2342))
PS: Mein Englisch ist schlecht aber ich hoffe es reicht dafür....

Kannst Du nicht einen Zeitserver auf der Synology aufsetzen?

Und dann gegen diese Deine ESP ... hat den Vorteil, das Deine ganzen Geräte nur eine Zeit haben ... die der Synology.

Mach ich genau so, mit der Ausnahme das es ein "normaler" ntp auf dem fhem-Server ist. Sogar in der Firma mist es so eingerichtet. Es ist nivcht wichtig, das ein gerät die "richtige" Zeit hat, sondern das ALLE Geräte die GLEICHE Zeit haben. Nur dann macht Logfiles-lesen richtig Sinn ... ;o)

Ja klar könnte ich das. Aber alles was relevant ist loggt zeitlich korrekt. Der syslog nimmt synology zeit. Die ESPs sind mir egal. Die differenz kenne ich ja. Also wenn man es ganz perfekt will, hast du ja recht. An solche dinge gehe ich aber erst wenn die groben Schnitzer weg sind. Wir sehen hier ja zb eine echt lange geschichte.

Gesendet von meinem LG-H850 mit Tapatalk

ZitatDie haben alle pool.ntp.org drin

Ich würde Dir jetzt mal raten, das bei den ESP abzuschalten. Also entweder im Netz oder gar nicht .... schließlich sind die Zeiten über die Internetverbindung deutlich lamgsamer ... und "multithreading" bei den "kleinen" ....

Zitat von: Wernieman am 21 Februar 2019, 14:25:00
Ich würde Dir jetzt mal raten, das bei den ESP abzuschalten. Also entweder im Netz oder gar nicht .... schließlich sind die Zeiten über die Internetverbindung deutlich lamgsamer ... und "multithreading" bei den "kleinen" ....

Nur interessehalber: Könnte das mit den längeren Zeiten ggf. gerade bei den Fritzboxen dazu führen, dass die ESP's nicht mehr wollen?
DAS wäre dann tatsächlich ein Ansatzpunkt für den Nutzerkreis, der diese Hardware (auch) nutzt...

(Habe übrigens auch einen Netgear (r7800 mit DD-WRT) am laufen. Die deckt aber leider nicht das ganze Haus zuverlässig ab, die Fritte darf daher immer noch ein bißchen WLAN...).

Mal abgesehen von meiner nicht vorhandenen Fritz! Box ...

Ich werde mal eben die NTPs einfach ganz aus machen. Wenn es daran liegt oder ggf. Verbesserung schafft, werde ich weiter berichten. Interessant wäre eine aktuelle Liste mit allen Hardware/Software Watchdog Fehlermeldungen. Habe immer nur "halbe/alte" gefunden.

(Hab auch DDWRT drauf, finde ich x mal besser. Zum testen hatte ich aber auch noch einen alten Asus dran...OHNE Erfolg.)

Aktuell greife ich jeden Strohhalm, was das hier angeht ;)

ZitatDAS wäre dann tatsächlich ein Ansatzpunkt für den Nutzerkreis, der diese Hardware (auch) nutzt...

Ich würde es jetzt nicht als FritzBox-Problem beschreiben. Stecke auch nicht tief in ESPeasy drin, um sagen zu können, ob so etwas Probleme macht oder nicht.

Aber grundsätzlich sollten solche "kleinen Dinger" nicht mit dem "großen Weiten Netz" belastet werden. Und das wäre ein ntp zu pool.ntp.org definitf.

Übrigens kann die Fritte, DDWRT und viele andere Geräte (wie die synology) gleich auch ntp-Server fürs Lokale Netz machen. Ein Zentraler Zeitserver ist für mich immer noch mein Favorit.

Habe die FritzBox auch nur wegen der eingebauten Telefonie. Habe es nirgendwo besser bzw. zu einem vergleichbaren Preis/Leistung gefunden. Der Nachteil ist eben, das es eine eierlegende Wollmichsau für Enduser ist. Wenn (Betonung auf Wenn) man sich auskennt, ist ein Alternativrouter besser. Aber sooo viel verkehrt macht AVM mit seinen Geräten nicht. Im Kommerziellen Umfeld sind sie sogar wegen Ihrer Updatepolitik ziemlich ungeschlagen. Sind die einzigen, die auch für "out of lifing" Produkte noch Updates raus geben. Das kenne ich von anderen Anbietern wenig. Da werden teilweise noch Geräte offiziell Vertrieben, für die es keine Updates mehr gibt ....

Zitat von: 87insane am 21 Februar 2019, 14:40:07
Mal abgesehen von meiner nicht vorhandenen Fritz! Box ...

:)
Sorry, das hattest du hinreichend deutlich gesagt und das sollte hier auch nicht nochmals unterstellt werden ::) .

Meine Fritte darf - wie geschildert - auch WLAN, und seit 7.x scheint das Teil auch insgesamt wieder sehr stabil zu laufen. Wegen meiner 2 ESP8266-Geräte (eines davon praktisch unvermeidlich, die MiLight-Bridge), die sowieso die meiste Zeit nur rumdümpeln/nicht genutzt werden, mache ich mir auch nicht die Mühe, da irgendwas speziell rumzukonfigurieren oder eine komplexe WLAN-Struktur aufzusetzen...

Zitat von: Wernieman am 21 Februar 2019, 15:48:57
Aber grundsätzlich sollten solche "kleinen Dinger" nicht mit dem "großen Weiten Netz" belastet werden. Und das wäre ein ntp zu pool.ntp.org definitf.

Das ist - verbunden mit dem Hinweis, dass jeder moderne Router das "mitmachen" kann - eine Sache, die man "geplagten" usern als einfachen Tip an die Hand geben kann!

(Dabei geht es nicht um meine eigenen Belange, ich will WLAN-Geräte auch aus anderen Gründen möglichst nicht in meiner HA haben! Nur darum, was ggf. sinnvollerweise weitergegeben werden kann...)

Der ewige Kampf Apple gegen Android...AVM gegen den Rest usw.

Ich denke dieser Kampf wird in jedem Haushalt separat entschieden. Ich selber mag Geräte bei denen ich auch die Kontrolle habe. Nicht um sonst flashe ich so gut wie jedes Handy direkt um....


NTP ist aktuell einfach aus. Sollte dies einen Unterschied machen, werde ich es melden. Ich denke aber das eine Ping Zeit hier keine Rolle spielen kann solange diese unter 100 ist. Wir reden hier aber nicht davon das ich nur 56k habe. Im Durchschnitt liegt meine Ping gegen die WAN Strecke bei 12 für Kleinstgeräte. Also denke ich, ist das okay. Zum testen würde ich aber auch einfach das Internet löschen wenn helfen würde :-P

Zitat:)
Sorry, das hattest du hinreichend deutlich gesagt und das sollte hier auch nicht nochmals unterstellt werden ::) .

Wollte heute mal die Diva spielen :-P

Im github ist leider auch noch kein Response...Mal abwarten... Bisher ist es auch noch nicht wieder passiert. Wir reden aber erst über 05:15 Std. ....

OT

Zitatzum testen würde ich aber auch einfach das Internet löschen wenn helfen würde :-P

Erzähle blos keinen Ami, das Du "das Internet" löschen willst .... *griiiiins*
Sonst kommen gleich die Navy Seals bei Dir vorbei ....

(YMMD)

Habe den Ausnahme Zustand ausgerufen. Ich darf alles ;)

Gesendet von meinem LG-H850 mit Tapatalk

Zwischenstand...

Sind aktuell bei 21:33h. Entweder der kritische moment kommt gleich oder aber NTP hat ggf was gebracht. Bin sehr gespannt.

aber NTP hat ggf was gebracht
Hoffen wir ....

Und nun geht es weiter....

Leider hat es nicht geholfen. Zudem finde ich im LOG unter debug more nicht einen Hinweis.


Auszug aus dem LOG (Um 11:26:32 wurde das Licht an/aus geschaltet. Da war er also wieder oben. Kurz davor lese ich leider nichts interessantes):
2019-02-22 11:26:33 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-22 11:26:33 Debug 192.168.20.50 kern az_licht EspEasy: HTTP/1.1 200 OK
2019-02-22 11:26:33 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (187/443)
2019-02-22 11:26:33 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 303 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-22 11:26:33 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: TaskSettings index: 3
2019-02-22 11:26:33 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-22 11:26:33 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: ControllerSettings index: 0
2019-02-22 11:26:33 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 closing connection
2019-02-22 11:26:33 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-22 11:26:33 Debug 192.168.20.50 kern az_licht EspEasy: HTTP/1.1 200 OK
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (185/441)
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 301 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: TaskSettings index: 2
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: ControllerSettings index: 0
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 closing connection
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: HTTP/1.1 200 OK
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (187/443)
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 303 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: TaskSettings index: 3
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: ControllerSettings index: 0
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 closing connection
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: HTTP/1.1 200 OK
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (185/441)
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 301 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: TaskSettings index: 2
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: ControllerSettings index: 0
2019-02-22 11:26:32 Debug 192.168.20.50 kern az_licht EspEasy: WIFI : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
2019-02-22 11:26:32 Notice 192.168.20.50 kern az_licht EspEasy: Webserver: start
2019-02-22 11:25:34 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 187874/2162/9/82.10
2019-02-22 11:25:34 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 6372418 avgLoopDuration: 154.70 loopCounterMax: 245901 loopCounterLast: 187874 countFindPluginId: 0
2019-02-22 11:25:34 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1461 ConnectFailures 0 FreeMem 16032 WiFiStatus 3
2019-02-22 11:25:34 Debug 192.168.20.50 kern az_licht EspEasy: 2: lowest: 9496 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240
2019-02-22 11:25:34 Debug 192.168.20.50 kern az_licht EspEasy: 1: lowest: 9744 LoadControllerSettings-> 10400 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate
2019-02-22 11:25:34 Debug 192.168.20.50 kern az_licht EspEasy: Memtrace 0: lowest: 10000 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240 ruleMatch-
2019-02-22 11:25:04 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 182711/2120/9/79.90
2019-02-22 11:25:04 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 6372418 avgLoopDuration: 159.20 loopCounterMax: 245901 loopCounterLast: 182712 countFindPluginId: 0
2019-02-22 11:25:04 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1460 ConnectFailures 0 FreeMem 16032 WiFiStatus 3
2019-02-22 11:25:04 Debug 192.168.20.50 kern az_licht EspEasy: 2: lowest: 9496 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240
2019-02-22 11:25:04 Debug 192.168.20.50 kern az_licht EspEasy: 1: lowest: 9744 LoadControllerSettings-> 10400 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate
2019-02-22 11:25:04 Debug 192.168.20.50 kern az_licht EspEasy: Memtrace 0: lowest: 10000 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240 ruleMatch-
2019-02-22 11:25:03 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 closing connection
2019-02-22 11:25:03 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-22 11:25:03 Debug 192.168.20.50 kern az_licht EspEasy: HTTP/1.1 200 OK
2019-02-22 11:25:03 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (187/443)
2019-02-22 11:25:03 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 303 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-22 11:25:03 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: TaskSettings index: 3
2019-02-22 11:25:03 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-22 11:25:03 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: ControllerSettings index: 0
2019-02-22 11:25:03 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 closing connection
2019-02-22 11:25:03 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-22 11:25:03 Debug 192.168.20.50 kern az_licht EspEasy: HTTP/1.1 200 OK
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (185/441)
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 301 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: TaskSettings index: 2
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: ControllerSettings index: 0
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: ControllerSettings index: 0
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: EVENT: strom_rechts#strom_rechts=0.00 Processing time:49 milliSeconds
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,12,0
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: else
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,5,0
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: if [taste_rechts#taste_rechts]=1
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 100: taste_rechts#taste_rechts do
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: endif
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,12,1
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: else
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,12,0
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: if [taste_links#taste_links]=1
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 100: taste_links#taste_links do
2019-02-22 11:25:02 Notice 192.168.20.50 kern az_licht EspEasy: EVENT: strom_rechts#strom_rechts=0.00
2019-02-22 11:25:02 Notice 192.168.20.50 kern az_licht EspEasy: SW : State 0.00
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: TaskSettings index: 3
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: ControllerSettings index: 0
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: EVENT: strom_links#strom_links=0.00 Processing time:51 milliSeconds
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,12,0
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,5,0
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: endif
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,5,1
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: else
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,5,0
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: if [taste_rechts#taste_rechts]=1
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 100: taste_rechts#taste_rechts do
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: endif
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,12,1
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: else
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,12,0
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: if [taste_links#taste_links]=1
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 100: taste_links#taste_links do
2019-02-22 11:25:02 Notice 192.168.20.50 kern az_licht EspEasy: EVENT: strom_links#strom_links=0.00
2019-02-22 11:25:02 Notice 192.168.20.50 kern az_licht EspEasy: SW : State 0.00
2019-02-22 11:25:02 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: TaskSettings index: 2
2019-02-22 11:24:34 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 187678/2162/9/81.90
2019-02-22 11:24:34 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 6372418 avgLoopDuration: 154.85 loopCounterMax: 245901 loopCounterLast: 187678 countFindPluginId: 0
2019-02-22 11:24:34 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1460 ConnectFailures 0 FreeMem 16032 WiFiStatus 3
2019-02-22 11:24:34 Debug 192.168.20.50 kern az_licht EspEasy: 2: lowest: 9496 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240
2019-02-22 11:24:34 Debug 192.168.20.50 kern az_licht EspEasy: 1: lowest: 9744 LoadControllerSettings-> 10400 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate
2019-02-22 11:24:34 Debug 192.168.20.50 kern az_licht EspEasy: Memtrace 0: lowest: 10000 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240 ruleMatch-
2019-02-22 11:24:04 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 187648/2162/9/81.90
2019-02-22 11:24:04 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 6372418 avgLoopDuration: 154.89 loopCounterMax: 245901 loopCounterLast: 187648 countFindPluginId: 0
2019-02-22 11:24:04 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1459 ConnectFailures 0 FreeMem 16032 WiFiStatus 3
2019-02-22 11:24:04 Debug 192.168.20.50 kern az_licht EspEasy: 2: lowest: 9496 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240
2019-02-22 11:24:04 Debug 192.168.20.50 kern az_licht EspEasy: 1: lowest: 9744 LoadControllerSettings-> 10400 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate
2019-02-22 11:24:04 Debug 192.168.20.50 kern az_licht EspEasy: Memtrace 0: lowest: 10000 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240 ruleMatch-
2019-02-22 11:23:34 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 187585/2162/9/82.00
2019-02-22 11:23:34 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 6372418 avgLoopDuration: 154.94 loopCounterMax: 245901 loopCounterLast: 187585 countFindPluginId: 0
2019-02-22 11:23:34 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1459 ConnectFailures 0 FreeMem 16032 WiFiStatus 3
2019-02-22 11:23:34 Debug 192.168.20.50 kern az_licht EspEasy: 2: lowest: 9496 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240
2019-02-22 11:23:34 Debug 192.168.20.50 kern az_licht EspEasy: 1: lowest: 9744 LoadControllerSettings-> 10400 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate
2019-02-22 11:23:34 Debug 192.168.20.50 kern az_licht EspEasy: Memtrace 0: lowest: 10000 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240 ruleMatch-
2019-02-22 11:23:04 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 187546/2162/9/81.90
2019-02-22 11:23:04 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 6372418 avgLoopDuration: 154.98 loopCounterMax: 245901 loopCounterLast: 187546 countFindPluginId: 0
2019-02-22 11:23:04 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1458 ConnectFailures 0 FreeMem 16032 WiFiStatus 3
2019-02-22 11:23:04 Debug 192.168.20.50 kern az_licht EspEasy: 2: lowest: 9496 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240
2019-02-22 11:23:04 Debug 192.168.20.50 kern az_licht EspEasy: 1: lowest: 9744 LoadControllerSettings-> 10400 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate
2019-02-22 11:23:04 Debug 192.168.20.50 kern az_licht EspEasy: Memtrace 0: lowest: 10000 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240 ruleMatch-
2019-02-22 11:22:34 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 187561/2162/9/82.00
2019-02-22 11:22:34 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 6372418 avgLoopDuration: 154.96 loopCounterMax: 245901 loopCounterLast: 187561 countFindPluginId: 0
2019-02-22 11:22:34 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1458 ConnectFailures 0 FreeMem 15928 WiFiStatus 3
2019-02-22 11:22:34 Debug 192.168.20.50 kern az_licht EspEasy: 2: lowest: 9496 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240
2019-02-22 11:22:34 Debug 192.168.20.50 kern az_licht EspEasy: 1: lowest: 9744 LoadControllerSettings-> 10400 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate
2019-02-22 11:22:34 Debug 192.168.20.50 kern az_licht EspEasy: Memtrace 0: lowest: 10000 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240 ruleMatch-
2019-02-22 11:22:04 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 185854/2156/9/81.20
2019-02-22 11:22:04 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 6372418 avgLoopDuration: 156.43 loopCounterMax: 245901 loopCounterLast: 185854 countFindPluginId: 0
2019-02-22 11:22:04 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1457 ConnectFailures 0 FreeMem 16032 WiFiStatus 3
2019-02-22 11:22:04 Debug 192.168.20.50 kern az_licht EspEasy: 2: lowest: 9496 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240
2019-02-22 11:22:04 Debug 192.168.20.50 kern az_licht EspEasy: 1: lowest: 9744 LoadControllerSettings-> 10400 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate
2019-02-22 11:22:04 Debug 192.168.20.50 kern az_licht EspEasy: Memtrace 0: lowest: 10000 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240 ruleMatch-
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 closing connection
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: HTTP/1.1 200 OK
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (187/443)
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 303 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: TaskSettings index: 3
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: ControllerSettings index: 0
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 closing connection
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 Success! HTTP/1.1 200 OK
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: HTTP/1.1 200 OK
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 written to client (185/441)
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: POST /ESPEasy HTTP/1.1 Content-Length: 301 Host: 192.168.20.3:8383 User-Agent: ESP Easy/20103/Feb 16 2019 03:06:46 Connection: close
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: TaskSettings index: 2
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: HTTP : C009 connecting to 192.168.20.3:8383
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: ControllerSettings index: 0
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: ControllerSettings index: 0
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: EVENT: strom_rechts#strom_rechts=0.00 Processing time:53 milliSeconds
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,12,0
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,5,0
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 100: system#boot do
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: endif
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,5,1
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: else
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,5,0
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: if [taste_rechts#taste_rechts]=1
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 100: taste_rechts#taste_rechts do
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: endif
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,12,1
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: else
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,12,0
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: if [taste_links#taste_links]=1
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 100: taste_links#taste_links do
2019-02-22 11:21:42 Notice 192.168.20.50 kern az_licht EspEasy: EVENT: strom_rechts#strom_rechts=0.00
2019-02-22 11:21:42 Notice 192.168.20.50 kern az_licht EspEasy: SW : State 0.00
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: TaskSettings index: 3
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: ControllerSettings index: 0
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,12,0
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,5,0
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 100: system#boot do
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: endif
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,5,1
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: else
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,5,0
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: if [taste_rechts#taste_rechts]=1
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 100: taste_rechts#taste_rechts do
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: endif
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,12,1
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: else
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: gpio,12,0
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 101: if [taste_links#taste_links]=1
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: RuleDebug: 100: taste_links#taste_links do
2019-02-22 11:21:42 Notice 192.168.20.50 kern az_licht EspEasy: EVENT: strom_links#strom_links=0.00
2019-02-22 11:21:42 Notice 192.168.20.50 kern az_licht EspEasy: SW : State 0.00
2019-02-22 11:21:42 Debug 192.168.20.50 kern az_licht EspEasy: Read settings: TaskSettings index: 2
2019-02-22 11:21:34 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 187923/2162/9/82.10
2019-02-22 11:21:34 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 6372418 avgLoopDuration: 154.65 loopCounterMax: 245901 loopCounterLast: 187923 countFindPluginId: 0
2019-02-22 11:21:34 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1457 ConnectFailures 0 FreeMem 16032 WiFiStatus 3
2019-02-22 11:21:34 Debug 192.168.20.50 kern az_licht EspEasy: 2: lowest: 9496 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240
2019-02-22 11:21:34 Debug 192.168.20.50 kern az_licht EspEasy: 1: lowest: 9744 LoadControllerSettings-> 10400 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate
2019-02-22 11:21:34 Debug 192.168.20.50 kern az_licht EspEasy: Memtrace 0: lowest: 10000 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240 ruleMatch-
2019-02-22 11:21:04 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 187828/2162/9/82.10
2019-02-22 11:21:04 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 6372418 avgLoopDuration: 154.74 loopCounterMax: 245901 loopCounterLast: 187828 countFindPluginId: 0
2019-02-22 11:21:04 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1456 ConnectFailures 0 FreeMem 16032 WiFiStatus 3
2019-02-22 11:21:04 Debug 192.168.20.50 kern az_licht EspEasy: 2: lowest: 9496 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240
2019-02-22 11:21:04 Debug 192.168.20.50 kern az_licht EspEasy: 1: lowest: 9744 LoadControllerSettings-> 10400 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate
2019-02-22 11:21:04 Debug 192.168.20.50 kern az_licht EspEasy: Memtrace 0: lowest: 10000 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240 ruleMatch-
2019-02-22 11:20:34 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 187945/2162/9/82.10
2019-02-22 11:20:34 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 6372418 avgLoopDuration: 154.63 loopCounterMax: 245901 loopCounterLast: 187945 countFindPluginId: 0
2019-02-22 11:20:34 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1456 ConnectFailures 0 FreeMem 16032 WiFiStatus 3
2019-02-22 11:20:34 Debug 192.168.20.50 kern az_licht EspEasy: 2: lowest: 9496 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240
2019-02-22 11:20:34 Debug 192.168.20.50 kern az_licht EspEasy: 1: lowest: 9744 LoadControllerSettings-> 10400 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate
2019-02-22 11:20:34 Debug 192.168.20.50 kern az_licht EspEasy: Memtrace 0: lowest: 10000 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240 ruleMatch-
2019-02-22 11:20:04 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 187465/2162/9/82.00
2019-02-22 11:20:04 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 6372418 avgLoopDuration: 155.05 loopCounterMax: 245901 loopCounterLast: 187465 countFindPluginId: 0
2019-02-22 11:20:04 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1455 ConnectFailures 0 FreeMem 16032 WiFiStatus 3
2019-02-22 11:20:04 Debug 192.168.20.50 kern az_licht EspEasy: 2: lowest: 9496 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240
2019-02-22 11:20:04 Debug 192.168.20.50 kern az_licht EspEasy: 1: lowest: 9744 LoadControllerSettings-> 10400 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate
2019-02-22 11:20:04 Debug 192.168.20.50 kern az_licht EspEasy: Memtrace 0: lowest: 10000 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240 ruleMatch-


Werde nachher mal die DHCP Reservierung rauß nehmen und ne feste IP im Schalter eintragen. Weitere Ideen habe ich nicht mehr. Im github ist leider auch noch keine Reaktion.
Ggf. ist es auch kein WLAN Problem.

LINK: (https://www.espressif.com/en/support/explore/faq (https://www.espressif.com/en/support/explore/faq))
The hardware watchdog interrupt interval is 0.8*2048 ms, that is 1638.4 ms. The interrupt handling interval is 0.8*8192 ms, equal to 6553.6 ms. The interrupt handling interval is the time limit to feed the watchdog after the interrupt occurs. If the interrupt handling interval expires, it will trigger a hardware watchdog reset. As a result, in the cases where there is only hardware watchdog, if a program runs for over 6553.6 ms, then it could cause a hardware watchdog reset. If the program runs for over 8192 ms, then it will invoke a watchdog reset for sure. 

The software watchdog is based on MAC timer and task arrangement. The interrupt interval is 1600 ms, so is the interrupt handling interval. As a result, in the cases where there are both software and hardware watchdogs, if a program runs for over 1600 ms, then it could cause a software watchdog reset. If the program runs for over 3200 ms, then it will invoke a watchdog reset for sure.

Meine Betrachtung kommt wegen diesen Zeilen hier:
2019-02-22 11:25:34 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 187874/2162/9/82.10

= over 8192 ms - Nur das Warum fehlt mir :(

Um 11:25:04 ist er noch drunter..
2019-02-22 11:25:04 Debug 192.168.20.50 kern az_licht EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 182711/2120/9/79.90

Dazwischen passiert das hier (kann ich nur leider nichts mit anfangen):
2019-02-22 11:25:34 Debug 192.168.20.50 kern az_licht EspEasy: LoopStats: shortestLoop: 122 longestLoop: 6372418 avgLoopDuration: 154.70 loopCounterMax: 245901 loopCounterLast: 187874 countFindPluginId: 0
2019-02-22 11:25:34 Notice 192.168.20.50 kern az_licht EspEasy: WD : Uptime 1461 ConnectFailures 0 FreeMem 16032 WiFiStatus 3
2019-02-22 11:25:34 Debug 192.168.20.50 kern az_licht EspEasy: 2: lowest: 9496 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240
2019-02-22 11:25:34 Debug 192.168.20.50 kern az_licht EspEasy: 1: lowest: 9744 LoadControllerSettings-> 10400 LoadFromFile-> 10416 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate
2019-02-22 11:25:34 Debug 192.168.20.50 kern az_licht EspEasy: Memtrace 0: lowest: 10000 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 PluginCall_s (0)-> 11008 rulesProcessing-> 11048 rulesProcessingFile-> 10488 parseTemplate-> 10280 parseTemplate3-> 10240 ruleMatch-


Verwendest Du eigentlich "sleep"?

Zitat von: 87insane am 22 Februar 2019, 13:27:02
= over 8192 ms - Nur das Warum fehlt mir :(

wo ist er denn da über 8192 ms??

@Wernieman: Nein. Ich hatte mal gelesen, das es Probleme macht. Noch mehr davon brauche ich erst mal nicht ;)

@nils_: Ich lese das hier so: 2019-02-22   11:25:34   Debug   192.168.20.50   kern   az_licht   EspEasy: Scheduler stats: (called/tasks/max_length/idle%) 187874/2162/9/82.10

82.10 > 81.92

Denke das der Punkt hier egal ist bzw. einfach nur um die Zahl besser lesen zu können. Dazu würde der Fakt passen, dass direkt danach die ganze Kiste rebootet.

also nach dem, was vorher steht:

Zitat(called/tasks/max_length/idle%)

ist das die idle% ,.... und dann wäre 82,10 gar nicht sooo schlecht ...

Außer es überschreitet eben diese magische Grenze. Ich bin mir bei dem . noch nicht so sicher. Denk den punkt weg und genau da startet das ding neu.

Gesendet von meinem LG-H850 mit Tapatalk

Der "." steht dort, wo man "in Deutschland" den "," setzt.  Also kann man Ihn nicht einfach wegmachen ....

Hast Du eigentlich ntp nur bei dem problemgerät oder bei allen geändert? Was sagt die uptime Deiner anderen espeasy-Geräte?

Wenn dem so ist.... Dann habe ich gar keinen Anhaltspunkt mehr :-\

Hab NTP bei zwei Geräten aus gemacht. Bei dem AZ und dem BZ Schalter. Egal was wir bisher getestet haben, nichts hat eine Veränderung gebracht. Die Zeiten sind immer so zwischen 20 - 30 Std.

Aber nicht zu gleichen Uhrzeit?

Meine Obi-Steckdose hat z.B. folgende Uptime:
Uptime: 23 days 3 hours 38 minutes

Deshalb verstehe ich Deine 20-30 Stunden nicht ....

Glaube wir verstehen uns gerade nicht...

Also ALLE ESPeasy Geräte sind immer ca. 20-30 std an und dann kommt der reboot. Natürlich ist das hier ein ~ Wert. Gucke aktuell immer mal in die ganzen Schalter rein.

Habe mir extra niochmals Deine Konfig (Irgendwo am "Anfang" dieses Threads) angesehen und erkenne nicht komisches.

Übrigens habe ich ir genau von der Dose mal einige Systemvariablen Anzeige lassen.

Zum Vergleich:
System status
%iswifi% 3
%isntp% 1


zu finden unter Tools->System Variables

Btw. dort ist auch zu finden:
Tools->Flash->rules1.txt
Hast Du wirklich nur das stehen, was Du uns schon mal mitgeteilt hast?

Was meinst du genau mit dem Punkt Systemvariablen? Also ich habe dort wie auch im EventLog immer wifi = 3

Ja ich habe nichts anderes darin (Rule 2,3,4 sind leer). Ich kann dir auch die ganze Konfig sendet wenn du willst....



Muss aber mal sagen, du hast echt Durchhaltevermögen! Danke!

Bei mir laufen die espeasy im Schnitt 30 - 120 Tage bis zum watchdog reset.

Zitat von: DasQ am 23 Februar 2019, 15:29:14
Bei mir laufen die espeasy im Schnitt 30 - 120 Tage bis zum watchdog reset.

Das freut mich und wünsche ich mir auch !

Hast du ne Ahnung, wie man heraus findet warum das so ist? Ideen habe ich keine mehr!


EDIT: Hab aus Verzweifelung gerade mal die Value Namen angepasst. Bei mir ist es ja sonst Taskname = Valuename. Sieht nun so aus (natürlich auch die Geräte):
on taste_links#v_taste_links do
if [taste_links#v_taste_links]=1
  gpio,12,0
else
  gpio,12,1
endif
endon

on taste_rechts#v_taste_rechts do
if [taste_rechts#v_taste_rechts]=1
  gpio,5,0
else
  gpio,5,1
endif
endon

on System#Boot do
   GPIO,5,0
   GPIO,12,0
endon

PS: Lieb das du auch eines meiner anderen Themen offen hast ;) Ich nerve hier schon gewaltig :-P

EDIT: Hat auch nichts gebracht.
Boot: Manual reboot (12)
Reset Reason: Hardware Watchdog

Schwer ohne zu wissen was du wie angeschlossen hast. Aber in 98% der Fälle liegt's einfach an einer unsauberen Verdrahtung oder falschen Schaltplänen.
Dann klappt halt einfach mal die Spannung weg, oder ein Eingang flattert oder man hat ganz einfach Fehler in der Konfiguration.

Dazu kommt noch, das man bei den verwendeten espeasy Versionen, auch ganz gut mal sein kann das die ein oder andere nicht rund läuft.

Naja - Das sind fertige Schalter. Steht alles hier auch im Thread.
Hab mithilfe von einigen Kollegen hier echt viel probiert aber nun ist wohl ende in der Ideenkammer :\


Habt ihr ggf. Screenshots von allen Einstellungen von euren Schaltern usw? Ich meine es kann ja auch nur Kleinkram sein, den man im Vergleich sieht...

Und warum versuchst nicht mal tasmota?

Espeasy auf Sonoff läuft doch eher bescheiden ...

Meine Sonoff mit tasmota rennen wie teufel

Weil ich dafür wieder einen dritten Weg habe und nicht so frei sein kann. Meine Rollo Schaltung lässt sich damit nicht abbilden.
https://forum.fhem.de/index.php/topic,89136.msg816224.html#msg816224

Leider war ich beim schreiben der Anleitung noch echt glücklich. Das lässt nach x Tests echt nach!

EDIT:
Hab mir nun zusätzlich einen Schalter zum testen neben den PC gelegt. Dieser hat erstmal nur die Rules und Geräte drin. Keinen Controler oder sonst was. Werde nun nach und nach immer mehr rein nehmen und beobachten. Zuerst warte ich nun ob er an bleibt mit den Settings.

Zitat von: 87insane am 23 Februar 2019, 17:33:41
Meine Rollo Schaltung lässt sich damit nicht abbilden.

Halte ich für ein Gerücht ...

Kannst mir mal erklären was tasmota nicht kann?

BTW. Wenn ich mir das set1 in deiner Anleitung ansehe wundert mich aber auch nicht das des bei dir so eigenartig funktioniert ... die verschachtelte if kann in mein augen nicht funktinieren.

Alleine das ich SW Seitig die Relays gegeneinander schützen kann.... Guck dir mal meine Anleitung an. Hatte alles mal probiert mit dem Mitbewerber aber das geht ohne dritten weg ja so oder so nicht.
Können dazu gerne auch per PM weiter texten. Würde hier gerne weiter kommen. Ist NICHT böse gemeint. Hab echt nur Sorge, alles am Ende wieder zurück bauen zu müssen. Ich kann einfach nicht begreifen was hier falsch ist!

Also ich kann mein Sonoff 4ch hardwareseitig durch dipswitches verriegeln ...

Und softwareseitig in tasmota geht's natürlich auch ...

https://github.com/arendst/Sonoff-Tasmota/wiki/Commands

P.s. Zu deiner Anleitung hab ich im vorigen posting was gesagt ...

Das geile ist, bei den neuen ESP Firmwares ist das alte nicht mehr funktional. Es steht ja auch da wie es vorher war.

Verbesserungen sind aber gerne gesehen! Dazu machen das ja auch die normalen Schalter. Bei den Rollos hat es nur keine Auswirkung, da diese nicht einfach an/aus gehen. Diese booten nur neu (vermutlich wegen der IFs).

Sorry war aus Gesundheitlichen Gründen etwas im Off ... habe mir jetzt die letzten 10 Beiträge durchgelesen und verstehe aktuell gar nichts mehr.

Hast Du gesehen, das meine Dosen bei Wifi auch die 3 stehen haben, aber eine uptime mehrere Tage? Also scheinbar ist DAS nicht Dein Problem ...

Habe hier nur keine sonoff, sondern Obi und Selbstbau esp8266-Geräte.

Liege auch flach und deswegen kurz...

Bei WiFi 3 auch im Syslog sichtbar. Bin mittlerweile wieder weg von der WLAN Theorie. Weiß aber auch nicht mehr weiter. Hab nun nen Schalter geflasht und einfach so angeschlossen. Nehme da nun nach und nach konfig weg um zu gucken wann er länger läuft. Danach kann man ggf weitere Rück-Schlüsse ziehen.

Das ist mir jetzt zu viel zu schreiben aber ich werde hier, wenn ich wieder fit bin mal ein mega komisches Phänomen beschreiben. Hat hiermit nix zu tun, ist aber bestimmt ein fehler in der espbridge. Genug gespoilert... Schönen Sonntag euch allen noch.

Gesendet von meinem LG-H850 mit Tapatalk

Auch Dir und gute Gesundheit!

Kleines Update:

Den Testschalter, den ich 1 zu 1 kopiert habe vom AZ Schalter, habe ich mittlerweile fast zwei Tage am laufen.
Das einzige was anders ist bisher, ich habe aus der Devices-Übersicht die beiden Relays gelöscht.

In wie fern das zusammen hängen kann? k.A.! Aber ich warte noch ein wenig ab. Immerhin wäre damit die Laufzeit zum aktuellen Zeitpunkt schon erheblich verlängert. Immer noch kein richtiger Sieg aber ein Anfang.

D.h. ein unbeabsichtigter reboot?

Die gleiche espeasy-Version?

Gleiche Version, nur die relays gelöscht, bisher kein Reboot

Gesendet von meinem LG-H850 mit Tapatalk

Guten Morgen,

der Schalter ist vor einer Stunde neu gestartet aber schon sehr lange abgeblieben durch das entfernen der Relays.
Nun werde ich (da ich nichts mehr entfernen kann ohne das der Schalter nutzlos wird), die neuste FW (ESPEasy_mega-20190301) flashen und diese über factory reset direkt auf den Schalter einstellen. Ich weiß das die Voreinstellungen für die ältere Version des Schalters sind. Passe die Unterschiede natürlich an.

Mal sehen was dann passiert. geflasht wird die Datei: ESP_Easy_mega-20190301_normal_ESP8266_1M.bin
Ich bräuchte hier mal jemanden, der auch Sonoff T1 EU nutzt und ggf. noch ein wenig mehr Ideen und Erfahrung hat.

Habe kein SONOFF sondern Obi, aber trotzdem eine Frage/Hinweis

Hast Du ein Passwort in espeasy vergeben? Wenn ja, dann kommt bei den neuesten Versionen eine User/Passwort-Abfrage. Hat mich einige Zeit gekostet rauszufinden, das User=admin

Ja, habe ich überall drin. Ne das war mir bekannt. Dadurch, dass ich seit Wochen jeden Tag nach den Releasechanges gucke... traurig aber wahr!

Und ich dacht ja immer, da nimmt man die speziel dafür kompilierte espeasy Version .....


https://forum.fhem.de/index.php?topic=83394.0

Zitat von: DasQ am 01 März 2019, 16:12:58
Und ich dacht ja immer, da nimmt man die speziel dafür kompilierte espeasy Version .....


https://forum.fhem.de/index.php?topic=83394.0

Was du genau sagen willst, geht leider unter....mir zumindest...
Den Thread habe ich auch schon mal gelesen. Aber was steht da drin außer CE oder kein CE. T1 oder Touch, Tasmota oder lieber espeasy....usw.

Hab ich was überlesen?

@87insane

Sry, hätte auch was sagen können. Weshalb störst du dich so an MQTT. Wenn es doch nachweislich mit Tasmota schon klappt, warum noch weiter unbedingt mit ESP Easy. So wie ich es verstanden habe belastet die Definition eines MQTT2_Server das System unmerklich. Mehr ist auch nicht nötig ausser das Attribute autocreate und die Aktivierung im Device. Das ganze dauert keine 5 Minuten und die Sache ist gegessen. Mit dem Eifer den Beta-User die letzten Monate in die Entwicklung neuer Templates gesteckt hat, um zu zeigen wie einfach die Integration eines MQTT(2)-DEVICE sein kann werden in Zukunft sehr viele lesende FHEM-User meiner Meinung nach ihre stetig steigende Anzahl an MQTT-Unterstützendende Geräte über diesen Weg einbinden.

Wie gesagt 5 Minuten dauert die Einrichtung, wie lange wurde darüber geredet  ;D

Gruß

Thomas

Zitat aus dem gepostet Link

Zitat von: M_I_B am 31 Januar 2018, 19:25:28
[Einklink]
Der EFM8BB1 ist ein kleines Universal- Ferkel von Silicon Labs. Da wird m.E. nur die Sensorfunktion und (ich kenne die Tasten nur von Bildern) die Ansteuerung der LED's genutzt. Das Teil quakt via C2- Interface mit dem ESP. Der ESP kennt nativ keinen C2 Stack; dsa ist so'n SiliconLabs Dingens. Das ist also m.E. per Software in den ESP implementiert worden. Ich kenne das C2- Interface auch nicht. Scheint so eine I²C Vergewaltigung zu sein. Um das letztlich in EasyESP nutzen zu können, müsste da wer von den Machern dieses Protokoll in ESPeasy implementieren...

Datenblatt:
https://www.silabs.com/documents/public/data-sheets/efm8bb1-datasheet.pdf

Note:
https://www.silabs.com/documents/public/application-notes/AN127.pdf

[/Einklink]

Und jetzt weißt warum dein espeasy nicht ordentlich funzt...

Ich nutze und das schrieb ich auch, Sonoff T1 EU (2-Gang).
Mich wundert das sie nicht korrekt laufen mit ESPeasy. Wäre es ein reines HW Problem, würde es mit Tasmota auch nicht korrekt laufen und das macht es ja.

Also wenn ich nicht drumherum komme, werde ich auch Tasmota nehmen. Aber es wäre schöner das mit Begründung zu machen.... Im Webinar am Freitag haben auch noch ein paar Kollegen ein paar Ideen eingeworfen. Letztlich bin ich nur noch nicht dazu gekommen.

EDIT:
Hab gerade mal geschaut nach einer sauberen Anleitung wie ich MTTQ 2 sauber installiere für FHEM. Wenn ich es korrekt verstanden hatte am Freitag, kann ich mit MTTQ 2 die Geräte über FHEM direkt ansprechen. Die Wikis hatte ich gelesen und sehen erst mal gut aus. Möchte es nur richtig machen und nicht einfach "rein klatschen" und fertig. Gibt es da ne Art BestPractice Guide?

Bei der Nutzung von MQTT2_Server ist meiner Meinung nach nicht mehr nötig wie die Definition dessen und los gehts  :)


define MQTT2_FHEM_Server MQTT2_SERVER 1883 global
attr MQTT2_FHEM_Server autocreate 1

Das sollte es gewesen sein, wie hier (https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele) gleich am Anfang beschrieben.

Das kam mir so kurz vor. Deswegen auch meine frage. Das ist in der tat wirklich schöner geworden. Danke!


Ps: werde aber weiterhin espeasy im auge halten und auch testen. Um meine Problemchen aber weg zu bekommen, werde ich erst mal wechseln müssen. Schade eigentlich. Für espeasy und zb Rollo Steuerung gibt es mittlerweile echt viel zum nachlesen. Für tasmota muss ich erst mal suchen.....

Danke an der stelle hier, an alle die mich unterstützt haben :)

Aber wir sind uns alle einig hier...?

....zum aktuellem Zeitpunkt laufen die T1 Schalter nicht sauber mit ESPeasy und die Lösung ist aktuell Tasmota....

Wenn dem so ist, würde ich dies hier erstmal als "Gelöst" betrachten und bei Änderungen kann sich gerne jemand melden bzw. würde ich das auch tun, wenn ich was mitbekomme oder höre/lese.

Zitat von: 87insane am 04 März 2019, 14:30:28
Aber wir sind uns alle einig hier...?

Na ja, ich würde mal sagen, jein: Ich bin noch nicht überzeugt, dass WLAN an sich eine Lösung ist ;) .

Aber zu ESPEasy noch zwei Anmerkungen:- Könnte sein, dass eine andere Firmwareversion besser ist, habe dazu neulich im vorbeigehen hier was gesehen: https://forum.mysensors.org/topic/10199/waf-in-jeopardy-today- Man kann auch mit ESPEasyMQTT betreiben; könnte sein, dass es das ggf. einfacher macht, was Event-Benennung usw. angeht.

Habe ja selber schon x FW getestet und bei allen ist es gleich (deswegen schrieb ich ja, zum aktuellen Zeitpunkt.)... Tatsächlich ist es bei Tasmota anders und läuft.

Ich weiß, WLAN magst du nicht :-P

 ;D 8) ::)

(da ich hier ganz am Anfang mal was gepostet hatte, fühlte ich mich durch "alle einig... Lösung" persönlich angesprochen :P . Daher die Klarstellung...

(Ist schon witzig, die meisten Sachen, die mir im Rahmen der mqtt2.templates über den Weg gelaufen sind, waren ESP-basiert :o , ich leiste also eine art "Beihilfe zum Selbstmord", also werde mit Tasmota@MQTT2 glücklich :P ) Es ist in der Tat (meistens) super-Easy mit MQTT2, da passiert ganz viel "von allein" bzw. mit den templates fast von allein.

Also viel Freude damit...

Zitat von: Beta-User am 04 März 2019, 16:15:35
;D 8) ::)

(da ich hier ganz am Anfang mal was gepostet hatte, fühlte ich mich durch "alle einig... Lösung" persönlich angesprochen :P . Daher die Klarstellung...

(Ist schon witzig, die meisten Sachen, die mir im Rahmen der mqtt2.templates über den Weg gelaufen sind, waren ESP-basiert :o , ich leiste also eine art "Beihilfe zum Selbstmord", also werde mit Tasmota@MQTT2 glücklich :P ) Es ist in der Tat (meistens) super-Easy mit MQTT2, da passiert ganz viel "von allein" bzw. mit den templates fast von allein.

Also viel Freude damit...

Denke, jeder der jemandem Hilft darf sich als "Löser" betrachten. Hier waren echt viele Ideen und keine sinnlosen Antworten. Lob geht nach wie vor an alle :)

Ich weiß noch nicht wie ich die Rollo Schaltung mit den Tasmotas machen soll, da die leider nicht so ein Ruleset haben wie die ESPeasys ABER zuerst kümmere ich mich am WE um die normalen Schalter. Ich meine, mir ist bewusst das es am Ende die billigste sch**** ist aber auch das ist ja nur eine Mietswohnung. Wenn ich diese übernehmen sollte o.ä. würde ich vermutlich auch nochmal nahe bei 0 anfangen. Wichtig ist aktuell nur, dass es sauber läuft und von Kind bis Oma/Opa, alle es bedienen können wie gewohnt. Jeder hat andere Bedürfnisse. Kinder lernen schnell und Oma/Opa wollen sowas eben nicht lernen, daher die Taster.

Ja eigentlich habe ich gestern schon was dazu geschrieb, aber hab's dann wieder gelöscht.

Aber um es verständlicher zu erklären warum der Sonoff Touch eine Sonderling darstellt, erklär ich's nochmals einfacher.
Im Touch ist ein 2. IC verbaut, der die sensorik der kapazitiven Taster und LED Steuerung, bedient. Dieser IC ist in der tasmota Firmware implementiert, nicht aber in espeasy.

Es gibt im espeasy Forum einen Lösungsansatz, der aber für die Vorgänger Version des Touch, als Plugin geschriebene wurde.

Zitatcountcobolt wrote: ↑17 Jun 2018, 16:13
sorry is this is a stupid question, but will your firmware work with the Sonoff T1 2Gang (similar to the dual?). I both 2 and want to be able to control them using ESPEasy and Domoticz.


This plugin will not work with any Sonoff T1. According to Tasmota wiki:
"When pushing a button, the touch chip lift the power high to the EFM8BB1, and the EFM8BB1 chip ties the signal line for each button low, for the full duration of the keypress. There is no serial data, that i have seen at all."
The device's operation is somewhat obscure to me, i am using my own T1 2Gang with Tasmota without problmes. :)

https://www.letscontrolit.com/forum/viewtopic.php?f=6&t=3245&start=150


Und naja zu dem WLAN kann ich nur sagen, das es eben für viele, die Lösung der Wahl ist.
Verschlüsselt, Ohne großen verkablungsaufwand, lässt sich so gut wie alles nachträglich versmarten.
Ich wohn zur Miete und mir würde mein Vermieter den Kopf abdrehen, wenn er wüsste was ich hier alles homeautomatisiert hab.
Klar würde ich lieber alles verkabeln ... aber der Aufwand ...
Und selbst wenn ich's verkabeln könnte, oft geht's halt auch einfach nicht.

Hatte deinen Beitrag aber noch gesehen vor dem löschen ;)

Generell ist es schade aber dann ist es eben so. Mir ist auch erst seit Freitag bekannt das FHEM MQTT2 so einfach mitnehmen kann. Alleine diese Tatsache macht es ja schon um einiges einfacher.

Mit deiner Info haben wir zumindest wirklich eine abschließende Aussage! Finde ich gut... Ich mag nicht, wenn etwas nicht geht und ich nicht verstehen kann warum. In so einem "Schwebe-Zustand" will man ja nicht einfach aufgeben.

Thema WLAN ist vermutlich Ansichtssache. Finde es auf der einen Seite gut ABER habe die Dinge auch gerne getrennt. Aufgrund dessen gehen ja auch andere Dinge OHNE Kabel. Verstehe beide Seiten und nutze ja auch 433Mhz/868Mhz/WLAN. Also habe ich schon mal ein großes Spektrum. Ob das nun wieder gut oder schlecht ist, soll in meinen Augen jeder für sich selber wissen.

Apple oder Android = Würde die gleiche Diskussion ergeben ;)

Genau aus dem Grunde habe ich bei mir ein esp8266-WLAN geschaffen .. und damit eine echte Trennung. Nur der FHEM-Server ist noch in diesem WLAN (bzw. stellt es sogar eigentlich zur Verfügung). So sind auch "xterne" Einflüsse ausgeschieden,.

WLAN hat den Vorteil, das es mehr kann als nur "Daten zu übertragen". OTA und einfach Sensoren selber bauen ist super einfach. WLAN hat den Nachteil, das es eben mehr kann als nur "Daten übertragen). Also die Angeschlossenen Geräte mehr Strom verbrauchen müssen.
(Hinweis: Obiges bewust etwas sehr einfach dargestellt)

So hat jede Produkt Seine Vor/Nachteile.

Genau deshalb habe ich bei mir FHEM. Es gibt eben eine Lösung, die diese verschiedenen "Produkte" Verheiraten kann ...

Zitat von: DasQ am 05 März 2019, 08:35:07
Verschlüsselt, Ohne großen verkablungsaufwand, lässt sich so gut wie alles nachträglich versmarten.

Wenn Selberbau, Verschlüsselt und nachträglich versmartet bei mir benötigt wird: MySensors ;) .
Wenn man den RFM nimmt, benötigt man keinen extra Verschlüsselungschip. (Ich kann die kritische Infrastruktur mit zwei Kabeln erreichen, daher nehme ich dafür die RS485-Variante).

Aber zugegebenermaßen: Das coden bei MySensors ist aufwändiger als bei dem WLAN-Gedönse. Dafür sind batterie-gestützte Dinge gar kein Problem und auch der Wechsel des Transport-Layers ist keine größere Sache (v.a. wenn man hardwareserial für RS485 nutzt und auf den Nodes möglichst den SPI-Port für die SPI-Nutzung frei hält).

Zitat von: Beta-User am 04 März 2019, 16:15:35
;D 8) ::)

(da ich hier ganz am Anfang mal was gepostet hatte, fühlte ich mich durch "alle einig... Lösung" persönlich angesprochen :P . Daher die Klarstellung...

(Ist schon witzig, die meisten Sachen, die mir im Rahmen der mqtt2.templates über den Weg gelaufen sind, waren ESP-basiert :o , ich leiste also eine art "Beihilfe zum Selbstmord", also werde mit Tasmota@MQTT2 glücklich :P ) Es ist in der Tat (meistens) super-Easy mit MQTT2, da passiert ganz viel "von allein" bzw. mit den templates fast von allein.

Also viel Freude damit...

An dieser Stelle muss ich nun mal kurz erwähnen, wie MEGA GEIL ich die Geschichte aktuell finde. Bei der Einrichtung hatte ich Probleme mit meinem autocreate aber das war ich selber Schuld.
Danach wählte ich ein Template aus, habe Kleinigkeiten angepasst und bin fasziniert!

1. Reagiert das Schalten etwas schneller!
2. Finde ich die EventMaps sehr gut gewählt. Alleine das ich beide Relays schalten kann und darunter noch das Webinterface aufrufbar wäre.
3. Er sendet den verbundenen WiFi Channel mit. Ganz ohne das man was tun muss. 

Das ist dir wirklich sehr gut gelungen! Danke!


Was ich noch nicht weiß:
- Die RSSI steht immer auf 100. Hat das einen Sinn? / Vermute ja das ist nicht der RSSI sondern die Signalstärke....
- Habe aktuell für meine Sonoff T1 EU (2-Gang) - Tasmota 2CH unified ausgewählt. Ich habe leider keine Ahnung ob es noch eine bessere Wahl gibt für den Schalter.
- Warum muss man eine IP manuell eingeben im stateFormat? Ich will nicht heulen, aber der Schalter meldet sich ja mit IP.
- Woher kommt der online Status und wie wird dieser gesendet? Bei ESPeasy muss man dafür immer etwas vom Schalter in einem Intervall an FHEM senden. Macht Tosmata das alleine? Ich weiß, das ist nicht dein Fachgebiet aber ggf. kannst du es ja beantworten.


Für das normale nutzen von simplen Schaltern ist das okay. ABER ich dachte darüber nach meine Rollo Schalter auch mit Tasmota zu flashen. Allerdings finde ich keine Möglichkeit die Relays SW Seitig gegeneinander zu verriegeln. Bei ESPeasy habe ich die Rules dafür. Gibt es da einen Trick bei Tasmota? (ggf. habe ich es schon gefunden. Lese aber noch...)

nochmal @Beta-User: Geile Sache. Danke für deine Mühen mit MQTT2/FHEM! Ich finde gerade keine Worte. Hatte nen halben Tag eingeplant und es waren mit flashen des Schalters ggf. 10 min!

btw. ist das hier jetzt eigentlich offtopic

und ich weis jetzt nicht ob dir die rules in tasmota da weiter helfen

https://github.com/arendst/Sonoff-Tasmota/wiki/Commands#rules

aber interlock müsste die verrieglung sein

https://github.com/arendst/Sonoff-Tasmota/wiki/Commands#control

Relay interlock mode and group selection. Introduced in v6.4.1.11
0 = set self-locking mode for all relays (default)
1 = set interlock mode for selected relays
Add up to 8 relays in 1 to 4 interlock groups, each separated by a space. For example
1,2 3,4 = Group Relay1 and Relay2 in group 1 and Relay3 and Relay4 in group 2 (note the space between the two group declarations)
1,2,3 = group Relay1, Relay2 and Relay3 in a single interlock group
1 3 2,4 = Relay1 is in group 1, Relay3 in group 2, Relay2 and Relay4 in group 3

Wollte nix neues aufmachen und den Kontext weiter führen, ohne die Leute zu verwirren .... Danke Dir!

Zitat von: 87insane am 08 März 2019, 15:33:24
Das ist dir wirklich sehr gut gelungen! Danke!

Danke, hört man immer wieder gern 8) !

Was die templates angeht, ist es aber so, dass das nur eine Sammlung von Dingen ist, die mir jemand anderes jeweils zugespielt hat, ggf. nach dem einen oder anderen Schubs... (wie anderswo geschrieben: ich habe weder einen shelly noch irgeneinen tasmota-geflashten ESP8266 hier rumliegen :P )

Von daher in deine Richtung einen Schubs: Wenn es möglich ist, die tasmotas als Rolladenaktor zu konfigurieren, ist das sicher für den einen oder anderen auch interessant. Meine Bitte wäre daher,  ein template dafür zu liefern, z.B. für den 2-er!
Dazu wäre es zum einen sinnvoll, die Grundkonfiguration des Aktors passend zu machen (die Verriegelung); ich gehe davon aus, dass das auch vie MQTT möglich ist - schau dir dazu die Umstellung der tasmotas auf Klein- bzw. Großschreibung an.

Dann sollten die Befehle in der setList "Rolladenaktor"-optimiert werden, also "up", "down", "stop_up" (?) ...

Spiel doch damit ein wenig rum; ggf. kannst du gerne einen eigenen Thread dazu aufmachen, dann finden sich ggf. auch Helfer, die das gut finden und einen ESP zur Hand haben ;) . Ort wäre in MQTT, bei "bugs, Anregungen..."-Thread einen Link darauf, und schon wird das was werden 8) .

Hey - werde ich machen.

Für die konfig des schalters selber gibt es was fast fertiges.

Einen thread wie ich es bei espeasy schon getan habe, werde ich machen. Aktuell bin ich noch die Basics am lernen. Mit tasmota habe ich bisher nix gemacht und auch die Templates muss ich erst mal verstehen. Hatte das gestern abend angefangen aber an der stelle hier, muss ich tasmota und mqtt lernen. Ich weis bisher nicht mal wie ich über fhem überhaupt was an den schalter senden kann. An/aus ist klar aber ich würde über pct steuern wollen usw.

Ggf schaffe ich es aber schon an diesem we. Hängt von dem Geburtstag nachher ab ;)

Gesendet von meinem LG-H850 mit Tapatalk

Laß dir Zeit, das eilt nicht.

Wenn tasmota eine echte Zeitsteuerung unterstützt, geht es ggf. auch mit pct (oder was ähnlichem). Wenn nicht, würde ich an deiner Stelle weiter bei ROLLO bleiben, das tut ja und muß ggf. nur etwas angepaßt werden... Aber man sollte m.E. eben den Aktor selber so darstellen, dass klar ist, dass das keine "normalen" Relais mehr sind; mich mehr, nicht weniger.

Ansonsten ist MQTT echt easy. Du mußt halt erst mal wissen, was das Zielgerät eigentlich an welcher Stelle (Topic) in welchem Format (payload) haben will. Mit MQTT2 ist man da sehr flexibel, was die Benennung/Übersetzung von FHEM-internen Benennungen und Werten in eine passende payload angeht. Da kann ich dann gerne auch helfen, wenn du mit den vorhandenen Beispielen nicht weiterkommst.
Aber bitte erst die mal ansehen und ggf. dazu dann konkrete Fragen stellen und gleich mitliefern, was das Gerät an welcher Stelle denn haben will; ggf. direkt mit dem publish über das IO (MQTT2_SERVER) vorab testen, ob das paßt, dann bekommen wir das schon hin!

Guten Morgen,

wollte nur mal folgendes nachmelden....

1. Mit Tasmota habe ich nun wirklich funktionierende Schalter - Testschalter1 ist nun schon Up seit: Uptime 5T16:04:57
2. Es gibt einen Fix für die ESPeasy´s indem man die 165er ino tauscht. Ob das wirklich funktioniert weiß ich nicht und wird auch nicht offiziell mit eingebaut. Müsste man selber anpassen. Dazu geht das auch nur bis CORE 2.42. Alles darüber geht nicht mehr.

Meine Empfehlung, auch wenn ich dagegen war - Tasmota. Mit den Templates und von Beta-User usw, sind das nur wenige Minuten an Einrichtung! Da ich kein Programmiere bin dauert die Template Erstellung bei mir zwar länger aber ihr könnt ja mal vorbeischauen und Eure Ideen melden.... https://forum.fhem.de/index.php/topic,98366.msg917091.html#msg917091


DANKE AN ALLE HIER!