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

    Gitpod Development 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

    Alexa Sprachsteuerung

    mosquitto/bash/html/cgi auf Wyse5070

    Einmal editiert, zuletzt von HoerMirAuf (1. Februar 2022 um 14:25)

  • 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

    Gitpod Development 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

    Alexa Sprachsteuerung

    mosquitto/bash/html/cgi auf Wyse5070

  • 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

    Gitpod Development 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

    Alexa Sprachsteuerung

    mosquitto/bash/html/cgi auf Wyse5070

  • 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

    Gitpod Development 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

    Alexa Sprachsteuerung

    mosquitto/bash/html/cgi auf Wyse5070

  • 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

    Gitpod Development 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

    Alexa Sprachsteuerung

    mosquitto/bash/html/cgi auf Wyse5070

    Einmal editiert, zuletzt von HoerMirAuf (4. Februar 2022 um 09:29)

  • 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!)

  • Hallo Kuddl,

    was ist aus deinem Problem geworden?

    Welche Einstellungen hast du in Tasmota letztlich gemacht?

    Wificonfig = 5 ist vermutlich besser als der Default (4).

    Hast du savedata auf 0 gesetzt?

    Ich habe kürzlich meine Rollodrive60 Gurtwickler ebenfalls mit einer Fernsteuermöglichkeit über Tasmota ausgerüstet.

    Dazu schalte ich die Kontakte für Hoch und Runter mit Relais und ESP-01, die ich um GPIO4 und GPIO5 gepimpt habe (s. Bild)

    Bei mir fällt gelegentlich das Internet aus und habe daher Bedenken bzgl. der Timerfunktion.

    Wi-Fi schalte ich allerdings nicht aus.

    Ich habe übrigens auch eine Schaltbox mit 4 Steckdosen für meine Multimediageräte gebaut und dabei festgestellt, dass die Reset Leitung der ESP Boards sehr empfindlich reagiert.

    Ich hatte den Reset zunächst über ein Kabel zu einem Taster an meiner Frontblende geführt und hatte damit beim Schalten der Lasten sehr häufig Resets. Schließlich habe ich auf die Reset Taster verzichtet und den Reset Eingang über Pullups direkt an V+ gelegt sowie zusätzlich mit 100nF geblockt.

  • RST bleibt frei und EN lege ich ohne Widerstand auf V+ (siehe Bild orange Brücke) (Tasmota ist ohnehin schmerzloser als ESP8266basic als OS)

    Hier bei der Umsetzung für WLAN ESP-Tasmota für Schellenberg Rollodrive 35 (mein Beitrag für den CO2-Emissionsabbau ).

    Einmal hoch und einmal runter das Rollo am Tag ist zu wenig Automatisierung bei den Möglichkeiten mit Tasmota in den aktuellen globalen Krisen.

    In Abhängigkeit von der Außentemperatur, der Tageszeit und Jahreszeit sollte es selektiv pro Rollo und Zimmer erfolgen.

    D.h. -

    - Im Winter erst hoch wenn es hell ist auch wenn die feste Zeit (Aufstehzeit) schon durch ist (Skript blockt - um Wärme im Raum zu halten) .

    - Mittags im Sommer bei über 25 Grad 2/3 runter, um eintretendes Infrarotlicht zu blocken und Klimaanlagenstrom zu sparen

    - Um 22 Uhr 10% "Rollo Auf" in den Monaten Mai -September (wenn nicht im Urlaub), um Lüftung zu ermöglichen

    - 30 Minuten nach Sonnenaufgang in den Monaten Mai-August die 10% schließen, um den Biolärm der Vögel zu blocken

    - 30 Minuten vor dem Regen im Winter um 50% abfahren um Auskühlung zu vermeiden

    usw.

    weitere Bauelemente:

    MP1584EN 24V to 3.3 V

    ESP8266-01S

    PC817 Optokoppler

    3 Mal editiert, zuletzt von karoCB (18. August 2022 um 13:40)

  • Nachtrag:

    Normal ist, alle zusätzlichen Hausautomatisierungen in Geräten mit dem komfortablen Shelly UNI (2 mini Relais und IN/OUT-Beschaltungen sowie 12-36 V Versorgungstoleranz) zu versuchen.

    Wenn der Raum jedoch im Zielgerät wie beim Gurtwickler 35 nicht ausreicht und die vorhanden 5V am Gerät für einen ESP8266-01S Betrieb wesentlich zu klein ausgeprägt ist, muss ein Komponentensplitt erfolgen (siehe Bild Seitenansicht Leiterplatte)

    Einmal editiert, zuletzt von karoCB (19. August 2022 um 14:12)