Hi,
ich habe heute ein FHEM update gemacht und nun sind alle ESPeasy Devices absent und lassen sich nicht mehr schalten? Ist das ein Bug?
Gerade nochmal geschaut: wenn ich am ESPEasy Device von Hand schalte, dann wird die Statusänderung an FHEM gemeldet und angezeigt. Also z.B. am Sonoff S20 den Taster drücken und die Statusänderung geht an FHEM durch.
Im Logfile sieht es mir so aus, als wenn FHEM denkt, dass die Devices in den Sleep Mode gehen. Ist aber bei allen ESP Devices ausgeschaltet
2018.12.27 09:01:36 4: Connection accepted from ESP_easy_Bridge_192.168.2.142_17583
2018.12.27 09:01:36 4: ESPEasy ESP_easy_Bridge_192.168.2.142_17583: Peer address 192.168.2.142 accepted
2018.12.27 09:01:36 5: ESPEasy ESP_easy_Bridge_192.168.2.142_17583: Received header: {'Connection' => 'close','Host' => '184723648','Content-Length' => 287}
2018.12.27 09:01:36 5: ESPEasy ESP_easy_Bridge_192.168.2.142_17583: Received content: {"module":"ESPEasy","version":"1.04","data":{"ESP":{"name":"S20_005","unit":5,"version":2,"build":20000,"build_notes":" - Mega","build_git":"(custom)","node_type_id":17,"sleep":1,"ip":"192.168.2.142"},"SENSOR":{"0":{"deviceName":"S20_005","valueName":"RSSI","type":1,"value":"-45.00"}}}}
2018.12.27 09:01:36 4: ESPEasy ESP_easy_Bridge_192.168.2.142_17583: No basic authentication required
2018.12.27 09:01:36 4: ESPEasy ESP_easy_Bridge_192.168.2.142_17583: Send http close '200 OK'
2018.12.27 09:01:36 4: ESPEasy ESP_easy_Bridge_192.168.2.142_17583: Src:'S20_005'/'S20_005' => ident:S20_005_S20_005 dev:ESPEasy_S20_005_S20_005 combinedDevice:0
2018.12.27 09:01:36 5: ESP_easy_Bridge: dispatch S20_005_S20_005::192.168.2.142::1::0::1::r||sleepState||awaked for 1s (-3s): 1545897694.52152||0
2018.12.27 09:01:36 5: ESP_easy_Bridge: dispatch S20_005_S20_005::192.168.2.142::1::0::1::i||unit||5||0|||i||sleep||1||0|||i||build||20000||0|||i||build_git||(custom)||0|||i||build_notes|| - Mega||0|||i||version||2||0|||i||node_type_id||17||0|||r||RSSI||-45.00||1
2018.12.27 09:01:36 4: ESPEasy ESP_easy_Bridge_192.168.2.142_17583: Closing tcp session.
Wie gesagt: Update nur auf FHEM Seiten.
Ansonsten habe ich in der FHEM Log seit dem Update folgende "lustige" Einträge. Die kommen im 10 Sekunden Rhythmus un dmüllen mir mein Log-File voll
[Thu Dec 27 08:44:11 2018] fhem.pl: Use of uninitialized value $cmd in string ne at /opt/fhem/FHEM/SetExtensions.pm line 79.
[Thu Dec 27 08:44:11 2018] fhem.pl: Use of uninitialized value $cmd in uc at /opt/fhem/FHEM/SetExtensions.pm line 81.
[Thu Dec 27 07:44:48 2018] fhem.pl: Use of uninitialized value $value in string ne at /opt/fhem/FHEM/SetExtensions.pm line 76.
[Thu Dec 27 07:44:48 2018] fhem.pl: Use of uninitialized value $cmd in string ne at /opt/fhem/FHEM/SetExtensions.pm line 76.
[Thu Dec 27 07:44:48 2018] fhem.pl: Use of uninitialized value $cmd in uc at /opt/fhem/FHEM/SetExtensions.pm line 78.
Der ESP meldet, dass er den deep sleep mode benutzt:
Zitat2018.12.27 09:01:36 5: ESPEasy ESP_easy_Bridge_192.168.2.142_17583: Received content: {"module":"ESPEasy","version":"1.04","data":{"ESP":{"name":"S20_005","unit":5,"version":2,"build":20000,"build_notes":" - Mega","build_git":"(custom)","node_type_id":17,"sleep":1,"ip":"192.168.2.142"},"SENSOR":{"0":{"deviceName":"S20_005","valueName":"RSSI","type":1,"value":"-45.00"}}}}
Meine Vermutung ist, dass Du den sleep mode in der ESP Firmware aktiviert hast, er aber nicht benutzt wird, da GPIO16 und RST nicht gebrückt sind. Schau mal bitte nach und deaktivierte das ggf.
Ob die Logeinträge bzgl. SetExtensions vom ESPEasy Modul ausgelöst werden kann ich (noch?) nicht erkennen. Hast Du die SetExtensions überhaupt per Attribut aktiviert? Schalte mal Stacktrace ein, vielleicht siehst Du dann mehr.
Ein List von Device und Bridge wäre auch hilfreich.
Edit: Hat sonst noch jemand dieses Problem nach dem Update?
Hi,
Sleep habe ich mir nochmal angesehen. Bei manchen war das aktiv bei anderen war es inaktiv. Es gab aber keinen Unterschied in FHEM ob an oder aus. Ich habe jetzt bei allen das deepsleep ausgeschaltet und alle ESP nochmal neu gebootet. Kein Unterschied.
Selbst wenn ich parallel zu FHEM die Konfigseite des ESP aufmache (er also definitiv wach ist)
Wie gesagt, habe ich an den ESPs ja nichts verändert; die laufen mit der Konfig seit 2 Jahren ohne Probleme.
Ich habe auf dem RPi jetzt mal das komplette Programm an Updates gefahren. Also apt-get upgrade, apt-get dist-upgrade sowie neueste Firmware mittels rpi-update gemacht. Jetzt gehen die ESPeasy Geräte teilweise wieder ?! Sprich zwei Stück gehen, drei Stück gehen nicht. Ich schau mal, ob es da offensichtliche Unterschiede in den jeweiligen Konfigs gibt
ZitatBei manchen war das aktiv bei anderen war es inaktiv. Es gab aber keinen Unterschied
Das ist schwer zu glauben, aber vielleicht benutzt Du eine Firmware Version mit einem Bug an dieser Stelle? Wird denn weiterhin "sleep=1" in den Internals geschickt?
Die rpi Updates machen in diesem Zusammenhang keinen Sinn.
Die lists und stacktrace fehlen mir noch zur weiteren Analyse.
Ich habe eine neue Version ins svn eingecheckt (revision 18075), die das das deepsleep bei älteren ESP Easy Firmware Versionen ignorieren sollte. Bitte testen.
Hi zusammen,
abgesehen vom ESP Schalter. Kann es sein das du in FHEM ggf. den Intervall verändert hast oder aber dieser einfach nicht mehr zu deinem RSSI senden passt?
Die Schalter gehen nur auf absent wenn in einer gewissen Zeit keine Info kommt. Nun sehen wir hier aber leider kein LIST deiner Geräte und auch nicht wie
dein ESP eingestellt ist. In den neuen Mega FW für die ESPs brauch man RSSI auch nicht mehr zwangsläufig. Dort kann man einen Intervall direkt für die jeweilige Taste setzen.
Prüfe mal wie lange es dauert, bis einer der Schalter nach manueller Bedienung benötigt, um dann auf absent zu springen.
Intervall? Weiß jetzt nicht genau, was du damit meinst. Da hatte ich bisher nichts gemacht und auch im Zuge des Update nichts verändert. Was muß ich da tun?
Auf jeden Fall gehen jetzt alle fünf S20 wieder. Reihenfolge wie folgt:
1. im ESPeasy das Sleep disablen
2. in FHEM das attribut presencecheck auf 0 setzen
3. S20 ausstecken und wieder einstecken (einfacher Reboot reicht nicht)
4. sicher stellen dass der S20 im WLAN angemeldet ist (Config Seite aufrufen)
5. Raspberry neu booten (einfaches shutdown restart einfaches FHEM reicht nicht)
6. dann gehen alle S20 in FHEM auf "initialized". Dann einmal On und einmal off im FHEM drücken und es geht wieder
Gerade fiel mir ein, dass dies nur meine S20 betroffen hat. Die H801 RGB Controller waren nicht betroffen, obwohl die das Sleep ebenfalls auf enabled haben.
ach so, hier mal die List der Devices. Einmal exemplarisch ein S20, einmal ein H801 RGB und einmal die ESPeasy Bridge.
Und ja, unser Hamster hat in seiner Behausung RGB Beleuchtung. Fragt nicht, das ist eine andere Geschichte ... :-)
Eine verläßliche Analyse kann ich aufgrund mehrerer Änderungen deinerseits, ohne Logs und Lists zwischendurch, nicht weiter leisten.
Zitatin FHEM das attribut presencecheck auf 0 setzen
Das ist ohne weitere Belege für mich so nicht nachzuvollziehen.
ZitatGerade fiel mir ein, dass dies nur meine S20 betroffen hat.
Die Hardware ist dem ESPEasy Modul egal, es geht nur um die Konfiguration.
Kann ich das "SetExtensions Problem" auch von meiner List streichen? Liefert tacktrace etwas mehr Informationen?
Ich verstehe deinen absent Check hier auch nicht ganz... Ich selber löse das über den RSSI Wert bei älteren ESP mega Geräten und bei neuen über den Schalter selber (Die FW unterstützt es ja mittlerweile).
So ist dann z.B. ein Gerät angelegt:
define ESPEasy_az_licht_strom_rechts ESPEasy 192.168.xxx.xxx 80 espBridge az_licht_strom_rechts
attr ESPEasy_az_licht_strom_rechts IODev espBridge
attr ESPEasy_az_licht_strom_rechts Interval 300
attr ESPEasy_az_licht_strom_rechts alexaName Arbeitszimmer Stehlampe
attr ESPEasy_az_licht_strom_rechts devStateIcon on:ios-on-green:off off:ios-off:on absent:10px-kreis-rot:statusRequest .*:ios-NACK:check
attr ESPEasy_az_licht_strom_rechts eventMap /gpio 5 on:on/gpio 5 off:off/status gpio 5:check/
attr ESPEasy_az_licht_strom_rechts group ESPEasy Device
attr ESPEasy_az_licht_strom_rechts icon light_floor_lamp
attr ESPEasy_az_licht_strom_rechts presenceCheck 1
attr ESPEasy_az_licht_strom_rechts readingSwitchText 1
attr ESPEasy_az_licht_strom_rechts room Alexa,Arbeitszimmer,ESPEasy
attr ESPEasy_az_licht_strom_rechts stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"strom_rechts","")}
Das Stateformat übernimmt hier die Prüfung auf dem Reading "strom_rechts" oder eben RSSI bei dir.
Mir kommt es vor, als würde sich da bei dir eher was verschluckt haben. Wie dev0 aber schon sagte, ist es schwer das zu verstehen ohne die nötigen Infos. Das alles hier ist reines Glaskugel raten....
ZitatKann ich das "SetExtensions Problem" auch von meiner List streichen?
nein, Logfile ist immer noch voll damit.
ZitatDas ist ohne weitere Belege für mich so nicht nachzuvollziehen.
naja, Beleg ist, wenn es 0 ist geht es, wenn es 1 ist geht es nicht. Ich habe mal im Code des Perl Moduls nach gesehen, da ich vermutete "if( absent){ don't send anything;" aber ich habe nichts dergleichen gesehen. Warum das also mit diesem Attribut geht / nicht geht ist mir auch nicht klar. Ist aber so.
ZitatEine verläßliche Analyse kann ich aufgrund mehrerer Änderungen deinerseits, ohne Logs und Lists zwischendurch, nicht weiter leisten.
Ich kann mich nun also entscheiden: entweder meine Frau ist sickig, weil das Licht-Zeugs nicht mehr geht oder du kannst keinen Support leisten. ;D Ich hab mich jetzt erstmal für meine Frau entschieden, da das FHEM das produktiv System ist
Wenn Du mir aber sagst, was ich loggen soll, dann mach ich das gerne.
ZitatMir kommt es vor, als würde sich da bei dir eher was verschluckt haben.
hmmm. Ich hatte gestern schon alles neu gebootet: Router, S20, RPi
ZitatWie dev0 aber schon sagte, ist es schwer das zu verstehen ohne die nötigen Infos. Das alles hier ist reines Glaskugel raten....
wie gesagt, was soll ich loggen, dann poste ich das gerne. Die Listings der Devices stehen ja im vorigen Thread
ZitatDie Hardware ist dem ESPEasy Modul egal, es geht nur um die Konfiguration.
yup, aber die Configs der S20 und H801 sind identisch. Mit H801 gehts, mit S20 gings nicht. FW Stand ist der gleiche.
Hier mal der Log Auszug wegen SetExzensions. Das kommt ca. alle 26 Sekunden:
[Fri Dec 28 12:15:10 2018] fhem.pl: Use of uninitialized value $d in hash element at fhem.pl line 4376.
[Fri Dec 28 12:15:10 2018] fhem.pl: Use of uninitialized value $cmd in string ne at /opt/fhem/FHEM/SetExtensions.pm line 76.
[Fri Dec 28 12:15:10 2018] fhem.pl: Use of uninitialized value $cmd in uc at /opt/fhem/FHEM/SetExtensions.pm line 78.
[Fri Dec 28 12:15:10 2018] fhem.pl: Use of uninitialized value $d in hash element at fhem.pl line 4376.
[Fri Dec 28 12:15:10 2018] fhem.pl: Use of uninitialized value $d in hash element at fhem.pl line 4376.
Die lists der 3 Geräte sind mit der Version 2.11 erstellt worden. Ich hatte Dich gebeten die gestern aktualisierte Version aus dem svn zu testen (2.12).
Der presenceCheck hat keine direkte Auswirkung auf die Funktionalität des Modul, das kann nicht die von Dir beschriebenen Auswirkungen haben.
Die Logeinträge bzgl. "Use of uninitialized value ... at /opt/fhem/FHEM/SetExtensions.pm" hängen mit der Aktualisierung der "SetExtensions.pm" zusammen. Bitte teste die aktuelle ESPEasy Modul Version (revision 18082 aka v2.13) aus dem svn repository, die ich in gerade eingecheckt habe incl. FHEM Neustart und zeige die "lists" der Geräte, wenn es nicht funktioniert.
Von welcher FHEM Revision bzw. ESPEasy Modul Veriosn hast Du ursprünglich aktualisiert?
Ich habe eine weitere Version (v2.14 / 18088) eingecheckt. Bitte diese Version testen. Steht ab 8:00 Uhr via update bereit.
Edit: Wenn es die Logmeldungen weiterhin gibt, dann ist es aus meiner Sicht eine Unverträglichkeit von eventMap Attribut und den setExtensions. Dafür bin ich dann aber nicht weiter zuständig.
Edit2: Statt on/off via eventMap bereitzustellen, kann man die Befehle auch via userSetCmds definieren:
attr <dev> userSetCmds ( on => {url=>"/control?cmd=gpio,12,1"}, off => {url=>"/control?cmd=gpio,12,0"} )
Hi,
Danke ! Ich mach ich gleich mal den update und werde berichten. Ich kam jetzt halt nur nicht dazu, wegen Familienbesuch die letzten zwei Tage.
Von welcher Version ich ursprünglich ugedatet habe weiß ich nicht, die war aber mindestens 6 Monate alt. Ich mache ein FHEM Update nur noch dann, wenn ich gesichert zwei Wochen am Stück zu Hause bin (und nicht auf Dienstreise). Sprich ich mach das update, schaue mir was nicht geht und versuche das dann zu lösen.
So update heute morgen gemacht, PI neu gebootet und mal laufen lassen. Effekt ist der gleiche:
[Sun Dec 30 14:59:56 2018] fhem.pl: Use of uninitialized value $value in string ne at /opt/fhem/FHEM/SetExtensions.pm line 76.
[Sun Dec 30 14:59:56 2018] fhem.pl: Use of uninitialized value $cmd in string ne at /opt/fhem/FHEM/SetExtensions.pm line 76.
[Sun Dec 30 14:59:56 2018] fhem.pl: Use of uninitialized value $cmd in uc at /opt/fhem/FHEM/SetExtensions.pm line 78.
[Sun Dec 30 14:59:56 2018] fhem.pl: Use of uninitialized value $d in hash element at fhem.pl line 4376.
[Sun Dec 30 14:59:56 2018] fhem.pl: Use of uninitialized value $d in hash element at fhem.pl line 4376.
Bitte füge doch vor Zeile #76 folgendes ein
if( !defined( $cmd ) ) {
mache eine Fehlerbehandlung oder setze $cmd = "";
}
Dann ist wenigstens die Fehlermeldung nicht dauernd im Log
ZitatBitte füge doch vor Zeile #76 folgendes ein
Ich bin nicht der Autor bzw. Maintainer der der setExtensions.pm. Siehe: https://fhem.de/MAINTAINER.txt