Beiträge von Einstein67

    Ich kenne den S20 leider nicht auswendig, aber hast du keine andere Möglichkeit als die ausgerechnet TX und RX

    Den S20 gibt es in vielen unterschiedlichen Versionen. Bei manchen ist der GPIO14 als Lötauge verfügbar, bei den meisten ist aber nur RX/TX vorhanden.


    Aus eigener Erfahrung kann ich aber sagen, dass der BME an RX/TX überhaupt keine Probleme macht.


    Ich würde bei so einem Verhalten die "blank.bin" draufflashen und erstmal mit der Tasmota-sensors Version testen. Verkabelung kontrollieren bzw. den Sensor mal direkt an der Platine anschließen ... wenn dann die Werte immer noch verrückt spielen ist wohl der BME defekt.

    Ich hab die Version 8.3.1.6 am laufen. Und verwende die Rule wie beschrieben.


    Code
    t1: pool temp
    t2: panel temp
    var1: in valid panel temp range?
    var2: off threshold temp for panel
    var3: on threshold temp for panel
    mem3: lowest valid panel temp

    Aber du hast recht, wenn du den mem3-Wert zum schalten verwendest gibt es keine Hysterese. Allerdings ist dies ja nur ein Grenzwert und sollte im Normalbetrieb nie erreicht werden.

    Schau mal unter Informationen, was der "Grund für Neustart" war.


    Ein mehrfacher Bootloop kann die Rules deaktivieren!


    Code
    Setoption36
    Boot loop defaults restoration control.
    0 = disable boot loop control
    1..200 = set number of boot loops (a restart caused by any exception or watchdog timer within less than BOOT_LOOP_TIME (default 10 seconds) before beginning to restore settings (default = 1). Once this number is reached, subsequent restarts will:
    1st restart: disable ESP8285 generic GPIOs interfering with flash SPI
    2nd restart: disable rules causing boot loop
    3rd restart: disable all rules
    4th restart: reset user defined GPIOs to disable any attached peripherals
    5th restart: reset module to Sonoff Basic (1)

    Man kann 16 Codes mit dem Befehl "RfKey<x>" speichern. Ich hab da mal was mit virtuellen Relaise gebastelt.


    Code
    rule1
    on RfReceived#RfKey=1 do power1 1 endon
    on RfReceived#RfKey=2 do power1 0 endon
    oder direkt mit dem RF-Code
    rule1
    on RfReceived#Data=0x98E154 do power1 1 endon
    on RfReceived#Data=0x98E158 do power1 0 endon


    So bekommt man immerhin einen Zustand im Webinterface angezeigt.


    Aber mittlerweile verarbeite ich die Signale im IOBroker ...

    Ich hab mit Core2.7.1 auch überhaupt keine Probleme. MQTT-Reconnects hab ich schon ewig keine mehr gesehen.


    Ich hatte allerdings, nach einem Firmware Update meines OpenWRT-Routers, das Problem dass sich die Webinterface einiger Tasmota Geräte erst nach mehren Versuchen öffnen liesen.


    Ursache dafür war dass sich der Core2.7.x viel strenger an die Draft-N Spezifikationen hält, als alle Cores davor. Auch der aktuell Kernel von OpenWRT (und viele andere Router) verhält sich sensibler beim Verbindungsaufbau ....


    Naja, aber alles kein Problem! Theo hat das Problem erkannt und "Setoption 41" eingebaut mit dem man das ARP (Wifi keep alive) steuern kann. Den Wert auf 90s gestellt und die Webinterface sind wieder in Millisekunden offen.


    Also mein Fazit zum Core2.7.1

    MQTT --- Rockstable

    HTTP ---- nach Änderung von SO41 ebenso stabil

    Stimmt, ich hab beim Log die Minuten mit den Sekunden verwechselt, und dachte alle 60 Sekunden werden die Werte geschickt :)

    Und auch überlesen dass der Log nicht aus der Tasmota-Konsole ist ....


    Also ich finde schon dass das ziemlich viel MQTT-Verkehr ist ...


    EDIT: Also ich würde es sooooo manchen:


    Mit Rule1 die Rule2 alle 2 (5 würden wohl auch reichen) Minuten starten und nach einem Durchlauf wieder beenden.


    Ergibt dann folgenden Datenverkehr