Timer-Verhalten ohne WLAN-Verbindung

  • Hallo zusammen,

    ich bin neu hier und grüße euch alle.

    Ich habe 7 alte Rolladensteuerungen (Rollomat 9200) umgebaut und mit ESP-12F ausgerüstet. Diese habe ich mit Tasmota 10.1.0.1 geflasht und nutze GPIO4 und GPIO5 als Ausgänge. Das Hoch- und Runterfahren der Rollos erfolgt ganz simpel zeitplangesteuert ohne ioBroker: Hochfahren zu einer festen Uhrzeit, runterfahren bei Sonnenuntergang.

    In der Regel ist unser WLAN-Router nachts abgeschaltet. Dabei ergibt sich folgender Effekt: 6 der 7 Rollos fahren auch bei abgeschaltetem WLAN wie gewünscht morgens hoch, 1 Rollo aber nicht. Ist WLAN eingeschaltet, fahren alle morgens wie gewünscht hoch. Ich sehe keinen Unterschied in den Einstellungen, aber irgend etwas muss ja anders sein. Hat jemand eine Idee, woran es liegen könnte?

    Gruß

    Kuddel

  • Hi


    Schwer zu sagen ohne sich einen Log anzuschauen und den gibt's nicht ohne WLAN ;)

    Generell arbeiten Timer und Rule unter Tasmota nicht wenn kein Uhrzeit gesetzt ist.


    Sollte aus irgendeinem Grund Tasmota in der Zeit ohne WLAN eine Neustart durchführen war's das mit den Timer, da kein Zeitsync.

    Mögliche Ursache wäre z.B. der Wifimanager der zu nem alternativen WLAN verbindet wenn ein 2. eingetragen sein sollte.


    Interessant wäre da ob es unterschiede gibt in den WLAN Einstellungen und was die Konsole ausgibt wenn du bei den Geräten jeweils wificonfig eingibst.


    WifiConfig0 = disable Wi-Fi Manager and reboot (used with alternate AP)
    2 = set Wi-Fi Manager as the current configuration tool and start Wi-Fi Manager (web server at 192.168.4.1) for 3 minutes, then reboot and try to connect Wi-Fi network
    4 = retry other AP without rebooting (default)
    5 = wait until selected AP is available again without rebooting
    6 = Wi-Fi parameters can only be entered via commands in the serial console
    7 = set Wi-Fi Manager (web server at 192.168.4.1) as the current configuration tool restricted to reset settings only.


    - Evtl. mal auf wificonfig 5 stellen

    - Andere Lösung wäre auch, die Konfig bei einem Gerät bei dem es die Probleme nicht gibt zu sichern und im Problemgerät einzuspielen und neu anzupassen (wenn überhaupt nötig)

    - eine RTC-Clock anschließen

    benzino77 Tasmocompiler

    Gitpod Master Release


    Sonoff-Basic / Sonoff-RF / Sonoff-Touch / Sonoff S20 / PowStro Basic / MagicHome / Sonoff-RF-Bridge mit diversen 433MHz RF Sender/Empfänger / Shelly_1 / ESP-WiFi-Dimmer / Gosund SP111 / ESP12E / WEMOS D1 Mini / ESP32Cam

    Sensoren: BME280/BMP280/HC-SR501/HC-SR04/ACS712/INA219/MHZ19B/DS3231

    mosquitto/bash/html/cgi auf RPI 2B+/Sprachsteuerung via IFTTT/4xGoogle-Home-Mini

    Einmal editiert, zuletzt von HoerMirAuf ()

  • Danke, das könnte die Ursache sein. wificonfig 4 ist eingestellt. Es könnte sein, dass ich dieses eine Gerät zu Beginn meines Umbaus an einem anderen AP angemeldet hatte. Auf jeden Fall ein guter Tipp von dir. Ich stell jetzt mal wificonfig 5 ein. Mal sehen, ob es dann morgen früh geht.

    Kann man mit einem Befehl auslesen, ob eine zweiter AP eingetragen ist ? (ich finde kein command in der Liste dazu).

  • Hi.


    Kann man mit einem Befehl auslesen, ob eine zweiter AP eingetragen ist

    gibt es.


    In der Konsole

    ssid1

    ssid2


    Zeigt die hinterlegten WLAN's

    benzino77 Tasmocompiler

    Gitpod Master Release


    Sonoff-Basic / Sonoff-RF / Sonoff-Touch / Sonoff S20 / PowStro Basic / MagicHome / Sonoff-RF-Bridge mit diversen 433MHz RF Sender/Empfänger / Shelly_1 / ESP-WiFi-Dimmer / Gosund SP111 / ESP12E / WEMOS D1 Mini / ESP32Cam

    Sensoren: BME280/BMP280/HC-SR501/HC-SR04/ACS712/INA219/MHZ19B/DS3231

    mosquitto/bash/html/cgi auf RPI 2B+/Sprachsteuerung via IFTTT/4xGoogle-Home-Mini

  • Also, wificonfig 5 hat es leider doch nicht gebracht, Rollo blieb heute morgen wieder unten. Es ist auch nur ssid1 definiert. Werde jetzt die Konfiguration eines anderen Rollos auslesen und einspielen. Kann ich irgendwie erkennen, ob der Chip nachts zwischenzeitlich einen Reset ausgeführt hat ? Also z.B. indem ich einem Parameter per Konsole einen Wert gebe, der bei einem Reset wieder auf einen Defaultwert zurückgesetzt wird?

  • Hi.


    Kannst du.

    Setzt einfach eine Variable in der Konsole auf irgendeinen Wert:

    var1 TEST

    Der Inhalt läßt sich in der Konsole mir var1 auslesen ... Variableninhalte überleben einen Neustart nicht und sie wäre dann leer.


    Du kannst aber auch ganz einfach unter "Information" die Anzahl der Neustart's ansehen und auch den Grund für den letzten Neustart.

    benzino77 Tasmocompiler

    Gitpod Master Release


    Sonoff-Basic / Sonoff-RF / Sonoff-Touch / Sonoff S20 / PowStro Basic / MagicHome / Sonoff-RF-Bridge mit diversen 433MHz RF Sender/Empfänger / Shelly_1 / ESP-WiFi-Dimmer / Gosund SP111 / ESP12E / WEMOS D1 Mini / ESP32Cam

    Sensoren: BME280/BMP280/HC-SR501/HC-SR04/ACS712/INA219/MHZ19B/DS3231

    mosquitto/bash/html/cgi auf RPI 2B+/Sprachsteuerung via IFTTT/4xGoogle-Home-Mini

  • Hallo,
    also anhand der Anzahl der Startvoränge und der Laufzeit ist jetzt klar, dass ungewollte Neustarts durchgeführt werden, und wenn dann kein WLAN da ist, fehlt natürlich die richtige Zeit. Anstatt die Konfiguration von einem anderen Gerät einzuspielen, hab ich gestern abend erst mal einen Kondensator am Chip zwischen VCC und GND angelötet. Hat aber nichts gebracht. Über Nacht wieder Neustart, als Grund steht da: Software/System restart. Der Neustart in der Nacht wurde aber wohl auch nicht richtig durchgeführt, denn bei Sonnenaufgang und Sonnenuntergang stehen völlig unsinnige Zeiten (obwohl Latitude und Longitude und Timezone stimmen) und die Zeit ist auch daneben (Jahr 1970..), obwohl jetzt WLAN verbunden ist. Hab jetzt "Neustart" angeklickt und danach stimmt die Zeit und auch Sonnenaufgang und Sonnenuntergang. Spiele jetzt die Konfiguration eines anderen Geräts ein, mal sehen ob das was bringt.

    Danke auf jeden Fall für die Tipps!

  • Hi.


    Wenn sich im Configfile was geklemmt hat kann es durchaus zu solchen Fehlern kommen. Das mit dem einspeielen einer anderen COnfig kann da schon helfen.


    Könnte auch sein das beim flashen der FW was nicht ganz gepasst hat und es deshalb zu so einem unkonventionellen Verhalten kommt.

    Wenn das mit dem Configfile nichts bring, würde ich das Ding platt machen, mit ner blank.bin und anschließend mit dem passenden bin neu flashen.

    benzino77 Tasmocompiler

    Gitpod Master Release


    Sonoff-Basic / Sonoff-RF / Sonoff-Touch / Sonoff S20 / PowStro Basic / MagicHome / Sonoff-RF-Bridge mit diversen 433MHz RF Sender/Empfänger / Shelly_1 / ESP-WiFi-Dimmer / Gosund SP111 / ESP12E / WEMOS D1 Mini / ESP32Cam

    Sensoren: BME280/BMP280/HC-SR501/HC-SR04/ACS712/INA219/MHZ19B/DS3231

    mosquitto/bash/html/cgi auf RPI 2B+/Sprachsteuerung via IFTTT/4xGoogle-Home-Mini

  • ich würde auch dem Vorschlag von HMA als 1. folgen!


    Aber es gibt auch noch die Alternative das es einen täglichen WLAN-Aufbau über einen Repeater bei dir gibt, bei dem ein Neustart gewünscht wird - diese beiden Optionen sind dann für Tasmota entscheidend.

    SetOption56Wi-Fi network scan to select strongest signal on restart (network has to be visible)

    0 = disable (default)

    1 = enable
    SetOption57Wi-Fi network re-scan every 44 minutes with alternate to +10dB stronger signal if detected (only visible networks)

    0 = disable

    1 = enable (default)
  • Einen Repeater hab ich nicht im Einsatz, und es ist auch nur AP eingetragen. Fals die Config vom anderen Gerät nicht hilft, werde ich mal neu flashen. Eine Frage dazu: Geflasht hab ich mit esptool.py, also erst gelöscht (erase_flash) und dann geflasht (write_flash). Wird denn mit dem Tool beim Flashen oder danach nicht automatisch ein Verify durchgeführt, um zu überprüfen, ob der Inhalt im Flash auch stimmt? Zweite Frage: Ist erase_flash nicht so gut wie blank.bin zu flashen?

  • Hi...


    Ich kann das jetzt nicht sicher sagen aber ich glaub esptool.py setzt nur ein "gelöscht Flag" (gibt aber auch Tools die komlpett bitweise löschen). Ist wie bei ner Festplatte, die Daten sind immer noch vorhanden. Klemmt jetzt beim schreiben der FW etwas das zum Bsp. ein "Date-Ende-Bit" fehlt oder ein Überschreibfehler auftritt, dann kann es sein das Teile der alten Daten gelesen werden die natürlich nicht zum Rest passen und für Abstürze sorgen.


    Was den verify betrifft: Kann auch schon sein das die FW sauber geflasht wurde. Aber die überschreibt ja nur ihren Speicherbereich. Das config-file liegt meist in einem folgenden Speicherbereich der dann nicht überschrieben wird. Ich hatte es schon öfters das nach einem flashen die alte Config oder korrumpierte Teile davon noch vorhanden waren. (Man wartet auf den Tasmota-AP und stellt erstaunt fest das das Ding sich bereits ins WLAN eingbucht hat obwohl es jungfräulich sein sollte)


    Flasht man ne passende blank.bin ( 512kb - 4MB ) überschreibt man jedes Bit im gesamten Speicher mit ner sauber definierten 0. Also keine Reste.

    Ich selbst mach in der Regel beides. Erst Speicher löschen, dann die blank.bin passend zum Flash-Speicher und dann die FW.

    benzino77 Tasmocompiler

    Gitpod Master Release


    Sonoff-Basic / Sonoff-RF / Sonoff-Touch / Sonoff S20 / PowStro Basic / MagicHome / Sonoff-RF-Bridge mit diversen 433MHz RF Sender/Empfänger / Shelly_1 / ESP-WiFi-Dimmer / Gosund SP111 / ESP12E / WEMOS D1 Mini / ESP32Cam

    Sensoren: BME280/BMP280/HC-SR501/HC-SR04/ACS712/INA219/MHZ19B/DS3231

    mosquitto/bash/html/cgi auf RPI 2B+/Sprachsteuerung via IFTTT/4xGoogle-Home-Mini

    Einmal editiert, zuletzt von HoerMirAuf ()

  • Hi,

    vorgestern habe ich blank_4MB geflasht, dann auch noch mit esptool erase_flash ausgeführt und anschließend Tasmota geflasht. Ergebnis: gleiches Fehlerverhalten wie vorher: während der AP ausgeschaltet ist, werden fehlerhaft mehrere Restarts durchgeführt (solange der AP eingeschaltet ist, kommt kein einziger fehlerhafter Restart vor).

    Gestern hab dann den ESP12 Chip ausgelötet und durch einen anderen ersetzt, gleiches Tasmota.bin geflascht und gleiche Konfiguration eingespielt. Und siehe da, letzte Nacht gab es bei ausgeschaltetem AP keinen fehlerhaften Restart. Problem gelöst, warum sich der ausgelötete Chip so verhält, ist aber unklar.

    Jetzt hab ich noch eine Frage: nach jedem Aus- und Einschalten des AP erhöht sich bei den Steuerungen die Anzahl der Flash-Schreibzyklen um zwei.

    Es scheint also so, dass beim Ausschalten des AP etwas im Flash gespeichert wird und beim Einschalten des AP auch wieder. Es wird ja auch eine Speicheradresse angegeben. Was wird denn da gespeichert ?

  • Ich vermute das Schaltzustände gesichert werden - SetOption 0 mal probieren

    SetOption0Save power state and use after restart (=SaveState)

    0 = disable (see note below)

    1 = enable (default)

    Note: Power state means on/off state of eg. relays, lights, but other parameters like color, color temperature, brightness, dimmer, etc. are still saved when changed. To disable saving other parameters see SaveData.
  • Kann sein, dass die Schaltzustände gespeichert werden. Ist bei mir aber nicht nötig, da für die Ansteuerung der Rollos immer nur ein kurzer Impuls ausgegeben wird, die Ausgänge ansonsten also immer OFF sind. Dass Abschalten/Einschalten des AP wird wohl auch als Parameteränderung angesehen und führt jeweils zu einem Speichervorgang im Flash. Hab das jetzt mit SavaData 0 abgeschaltet. (aus deinem Hinweis oben entnommen, danke!)