@Garagenlöter Deine Erfahrungen mit Wilm sind leider offensichtlich genauso wechselhaft wie meine. Bitte beobachte die Stabilität und melde deine Ergebnisse zurück. Da ich es nicht genau eingrenzen kann, kann dabei alles interessant sein. Wie gesagt lief bei mir anfangs ein NodeMCU auch 16 Tage lang stabil ohne einen einzigen Fehler durch. Auch wenn ich es momentan kaum noch glaube, beweist es ein Screenshot des Ping-Counters, der alle 22 Sekunden hochzählt und definitiv einen entsprechend hohen Wert hatte.
Inzwischen ist die Stabilität - für mich immer noch unerklärlich - leider sehr viel schlechter.
Allerdings muss man die verschiedenen Effekte unterscheiden:
- Der Aktor erscheint in der Web-Übersicht der Fritzbox, wirft aber alle 24-28 Minuten einen Stacktrace und bootet. Dies ist sehr reproduzierbar und tritt an unterschiedlicher ESP-Hardware gleichartig auf.
- Der Aktor erscheint in der Web-Übersicht der Fritzbox, lässt sich aber nicht darüber schalten und springt schnell in seinen ursprünglichen Schaltzustand zurück.
- Der Aktor verbindet sich trotz anfänglicher korrekter Verbindung (wie lange etwa?) nicht mehr erneut.
Ob alle Effekte die gleiche Ursache haben, ist mir nicht klar.
Zuerst hatte ich nur die Fritzbox in Verdacht. Inzwischen vermute ich den Fehler eher in der Version des Cores des ESP. Ich verwende zur Zeit noch 2.6.3. Mit welchen Versionen habt ihr gute Erfahrungen gemacht?
Zu den Hardwareanpassungen:
Bei "#define LED_ANT" ist der jeweils gültige GPIO der LED anzugeben. Beim NodeMCU ist es 2, bei Sonoff-Basic ist es glaube ich GPIO13.
Der Taster "#define BUTTON" ist wohl immer bei GPIO0 zu finden, da er auch zum Start des Programmiermodus verwendet wird.
"Rot" im Logtext ist nur ein Hinweis auf eine Funktion für meine Katzenklappe. Jedes Toggeln des Buttons hat ein 5-sekündiges Low-Signal unter GPIO12 "#define RELAIS1" zu Folge. Bei Tests mit anderer Hardware verwirrt es nur und sollte dort besser nicht verwendet werden.
Zu den Daten in der *.export-Datei:
In der mit fb_tools entpackten Exportdatei befindet sich neben für mich wenig aussagekräftigen Dateien eine binäre ahanet.cfg. Bisher habe ich dort aber nichts identifiziert, was auf eine schlagartige Änderung der Kommunikation schließen könnte. Dennoch hat sie mit den 546E und Wilm-Aktoren zu tun.
Der erste long ist eine Länge bis zum nächsten long, usw. Es gibt immer einen Header mit 24 Bytes und dann einen Eintrag je aha-Aktor mit Konfigurationsdaten.
Hier alle Dateien aus der Export-Datei, die mit aha zu tun haben. Nur die letzte ist für Wilm interessant.
HTML:
-------------------------------------------------- CFGFILE:ahausr.cfg
/*
* /var/tmp.cfg
* Sun Nov 15 16:22:24 2020
*/
meta { encoding = "utf-8"; }
ahausrcfg {
}
-------------------------------------------------- BINFILE:aha.cfg
<?xml version="1.0"?>
<groups />
-------------------------------------------------- BINFILE:ahadect.cfg
<?xml version="1.0"?>
<config major="1" minor="0" type="ahacfg">
<devicelist>
<device id="16">
<aha>
<device_param sort_index="1">Katzenhaus</device_param>
<relay_times table_use="7" enable="0" />
<temp offset="0" />
</aha>
</device>
</devicelist>
</config>
-------------------------------------------------- BINFILE:ahapushmail.cfg
<section name="Pushmail">
<variable name="pushmail_list">
</variable>
</section>
-------------------------------------------------- BINFILE:ahanet.cfg
00000018 Länge
0000 1000 FFFF FFFF FFFF FF01 01DC 5010 ???
00022018 Kennung bei Anmeldung
000000BC Länge
00001000000000000000 =???
0001 ???
0200000000000000000003E800000B7401000000 =???
xxxx3Axxxx3Axxxx3Axxxx3Axxxx3Axxxx000000 "xx:xx:xx:xx:xx:xx"
576F686E7A696D6D6572000000000000000000000000000000000000... "Wohnzimmer"
30362E3530000000000000000000000000000000 "06.50"
0000000200000280000000000000 =???
0002 ???
00000000000000000000000000000000 =???
...
