Regelmäßig Ausreißer (Wert statt Differenz) bei Tasmota Energie

[MacAndreas]

Hallo,

ich habe teilweise mehrmals am Tag Ausreißer bei Strom und Gas. Dabei wird der ausgelesene Zählerstand gespeichert und nicht die Differenz. Es ist bei Gas, Strom Erzeugung und Bezug.

Jetzt habe ihc mir gedacht, ich passe den Sensor (Helfer) so an, dass wenn er über 500 ist der Wert 0 sein soll. Aber da habe ich wohl einen Fehler im Code…

Das ist der Sensor mit den Ausreißern:

  - sensor:
    # Stromzähler Verbrauch
      - name: "Stromzähler Verbrauch"
        unique_id: "StromzVerbrauch"
        state: "{{ (states('sensor.strom_zahler_mt691_total_in')) | float(0) | round(3) }}"
        unit_of_measurement: 'kWh'
        device_class: "energy"
        state_class: "total_increasing"

Und hier mein Versuch einen Ausreißer auf 0 zu setzten sollte er größer als 500 sein:

  - sensor:
    # Stromzähler Keller Verbrauch REM: Angepasst, um werte über 500 zu vermeiden
      - name: "Stromzähler Verbrauch Bereinigt"
        unique_id: "StromzVerbrauchBer"
        state: >
          {% set v = states('sensor.strom_zahler_mt691_total_in')|float(0)|round(3) %}
          {{ 0 if v > 500 else v }}
        unit_of_measurement: 'kWh'
        device_class: "energy"
        state_class: "total_increasing"

Es werden zwar die Werte größer 500 auf 0 gesetzt, allerdings auch alle anderen…

Kann mir bitte jemand helfen? Vielen Dank…

Gruß Andreas

[Dudelino]

Moin, den Part
{{ 0 if v > 500 else v }}
verstehe ich nicht (also ich weiß, was du damit machen willst, aber auf logische Sicht funktioniert das in meinem Kopf nicht), bin aber auch keine Profi. Ich kann dir nur meinen angepassten Zählersensor zur Verfügung stellen, der seit einem Jahr solche Sprünge bei mir herausfiltert:

- sensor:
    - name: "Stromverbrauch Gesamt Korrigiert"
      unique_id: strom_gesamt_korrigiert_filtered
      unit_of_measurement: "kWh"
      device_class: energy
      state_class: total_increasing
      state: >
        {% set raw_val = states('sensor.tasmota_lk13be_total') | float(-1) %}
        {% set old_val = states('sensor.stromverbrauch_gesamt_korrigiert') | float(0) %}
        
        {% if raw_val > 0 %}
          {{ raw_val }}
        {% else %}
          {{ old_val }}
        {% endif %}
      availability: >
        {{ states('sensor.tasmota_lk13be_total') not in ['unavailable', 'unknown', 'none'] }}

Das eigentliche Problem ist nämlich, dass der Sensor in HA bei einem Verbindungsverlust (bei mir zumindest egal ob von HA oder den Stromleser) kurz den Wert “0" bekommt und der nächste Wert der eigentliche Zählerwert ist, weshalb dann die Differenz als aktueller Wertesprung gelesen wird (hoffe, das war einigermaßen verständlich).

[MacAndreas]

Hallo und Danke für die Antwort!

@Dudelino

den Part
{{ 0 if v > 500 else v }} verstehe ich nicht

Dazu gehört die Zeile darüber:

{% set v =

in v steht der von Tasmota gelieferte (vielleicht viel zu hohe) Wert. Als Ergebnis soll dann 0 geliefert werden, wenn der Wert über 500 ist, sonst der richtige Wert… aber wie geschrieben, es funktioniert nicht…

Ich probiere Deine Lösung mal aus und melde mich bei Gelegenheit wieder…

Gruß Andreas

PS: ich glaube, das fehlt noch was… wo kommt denn sensor.stromverbrauch_gesamt_korrigiert her?

[Dudelino]

Nee, da fehlt nichts. Da bezieht er sich auf dich selbst, bzw. seinen aktuellen (alten) Wert.

[MacAndreas]

Das dachte ich auch, aber die sind unterschiedlich:

@Dudelino

    unique_id: strom_gesamt_korrigiert_filtered
...
        {% set old_val = states('sensor.stromverbrauch_gesamt_korrigiert') |         

Oder bin ich mal wieder auf einem Auge blind?

Gruß Andreas

[Osorkon]

Die Entity Id wird vom Namen abgeleitet und nicht von der unique ID!

Wenn ein Energy Sensor regelmäßig nicht verfügbar ist, empfiehlt es sich eher einen Verbrauchszähler zu erstellen, mit dieser aktivierten Option

Gruß Osorkon

[crazy-to-bike]

Hallo,

da hänge ich mich mal an, weil mein Problem vielleicht - zumindest bei meinen Tasmota-Entitäten - einen ähnlichen Urpsrung haben könnte, wo ich das gerade lese.

Aber das Abfangen funktioniert nicht bzw. liefert dann völlig falsche Werte für den Gesamtzählerstand (also state), nämlich quasi eine Nullung desselben.

[MacAndreas]

Hm, ich habe es so gemacht wie es @Dudelino vorgeschlagen hat und es funktioniert seit dem problemlos.

Kontrolliere doch mal ob Du nicht versehentlich einen Schreibfehler im Sensor hast.

[crazy-to-bike]

Die Sensoren habe ich per c&p übernommen, die sind definitiv nicht falsch. Was ich bislang nicht in der Sensor-Definition habe, ist availability.
Was ich im Skript oben im ersten Moment nicht verstanden habe, ist die -1 bei float(-1). Und da fällt es mir plötzlich wie Schuppen von den Augen: Das Problem liegt wohl an dem float(2) hinter der Entität, das ich so aus Beispielen wie dem oben übernommen habe.
Denn | float(-1) bedeutet - und eigentlich weiß ich das aus der Programmierung z.B. mit Pyhon:
Versuche, den vorherigen Wert in einen Gleitkomma‑Zahl (float) umzuwandeln.
Falls das nicht gelingt (z. B. weil der Wert kein gültiger Zahlen‑String ist), liefere stattdessen den Standardwert -1.

Das erklärt auch, warum es mir gleich nach Aktivierung den Zählerstand nur quasi nullt. Bei meiner hier geposteten Entität wird aus ~ 63.000 nämlich reprozuzierbar grundsätzlich umgehend 2, was an dem | float(2) liegt. Also das float mal ganz weglassen und neu testen …

[MacAndreas]

Ich sehe oben im Beispiel kein float(2)…

Und ein einfaches Kopieren des Beispiels oben wird bei Dir nur funktionieren wenn Deine Sensoren genauso heißen wie im Beispiel…

Edit: vorher hatte ich das Ganze falsch verstanden…

[crazy-to-bike]

@MacAndreas

Ich sehe oben im Beispiel kein float(2)…

Voila:

@Dudelino

{% set raw_val = states('sensor.tasmota_lk13be_total') | float(-1) %}
        {% set old_val = states('sensor.stromverbrauch_gesamt_korrigiert') | float(0) %}

Was in der Klammer hinter float steht, ist für das, was programmtechnisch grundsätzlich passiert, völlig irrelevant.

@MacAndreas

Und ein einfaches Kopieren des Beispiels oben wird bei Dir nur funktionieren wenn Deine Sensoren genauso heißen wie im Beispiel…

Das ist ja selbstverständlich. Daher siehe Ausreisser und nicht nachvollziehbare, falsche neue state-Werte beim Versuch, die Ausreißer abzufangen

[Thomassh]

Ich hatte dir im anderen Strang schon geschrieben das es an einem Sensor von dir liegt.
Wenn du float jetzt weg lässt bekommst du nur einen String das klappt dann erst recht nicht.

[crazy-to-bike]

@Thomassh

Wenn du float jetzt weg lässt bekommst du nur einen String das klappt dann erst recht nicht.

Das habe ich auch gemerkt. Aber von dem, was float(2) bei der Programmierung macht (s.o.) abgeleitet, ist diese | float(eine Zahl) Ergänzung, die meist hinter sensor-states angegeben wird, doch auch humbug

[Thomassh]

nein ist es nicht, float brauchst du zum rechnen wenn da kein standardwert angegeben wird bricht das ganze einfach ab oder gibt falsche Werte zurück, daher ein Standardwert.

[MacAndreas]

@crazy-to-bike

Voila:

@Dudelino

{% set raw_val = states('sensor.tasmota_lk13be_total') | float(-1) %}
        {% set old_val = states('sensor.stromverbrauch_gesamt_korrigiert') | float(0) %}

ich sehe float(-1) und float(0), aber kein float(2)… deshalb bin ich raus…

[crazy-to-bike]

Ja, habe ich inzwischen auch festgestellt. Aber … das hat mich auf einen neuen Ansatz für die Problemlösung gebracht…

state: >
        {% set neuer_wert = states('sensor.bitshake_smartmeterreader_ertrag_pv_alt') | float(6900) + 56120.32 %}
        {% set alter_wert = states('sensor.gesamtertrag_pv_alt') | float(neuer_wert) %}
        {% set differenz = neuer_wert - alter_wert %}
        {% if 0 < differenz <= 0.5 %}
          {{ neuer_wert }}
        {% else %}
          {{ alter_wert }}
        {% endif %}

Das gibt für sensor.gesamtertrag_pv_alt im Augenblick des Neuladens der Config auch den tatsächlichen, aktuellen Wert 63029.6 aus. Jetzt muss sich nur noch zeigen, ob dieser auch steigt, wenn sensor.bitshake_smartmeterreader_ertrag_pv_alt' steigt …

[crazy-to-bike]

@MacAndreas

ich sehe float(-1) und float(0), aber kein float(2)… deshalb bin ich raus…

und deshalb

@crazy-to-bike

Was in der Klammer hinter float steht, ist für das, was programmtechnisch grundsätzlich passiert, völlig irrelevant.

und Ausreisser und nicht nachvollziehbare, falsche neue state-Werte beim Versuch, die Ausreißer abzufangen

Da wäre das mit float(2) durchaus zu erkennen und erschließen gewesen

[crazy-to-bike]

@crazy-to-bike

Jetzt muss sich nur noch zeigen, ob dieser auch steigt, wenn sensor.bitshake_smartmeterreader_ertrag_pv_alt' steigt …

was es tut.

Ich habe deshalb damit eine grundsätzlich für alles, wo int / float gesetzt werden muss, deutlich verbesserte Lösung für euch, indem kein konstanter Wert genommen wird wie bei z.B. float(0), sondern die Variable “neuer Wert”, siehe vorletzter Post.

[Sir_Toby]

Hier mal ein Tasmota Script mit Einträgen die Ausreißer verhindern.:

Die Zeile “if (sml[1]>0) {“ musst du auf dein Script anpassen. Die Zahl in der [ ] ist die Zeile mit vom Gesamtverbrauch, bei >0 kannst du deinen Tatsächlichen Gesamtverbrauch minus 10kWh eintragen. So sendet Tasmota nur Werte wenn der Verbrauchswert >0 bzw. >Gesamtverbrauch ist. Du musst auch mal schauen warum du so viele Ausreißer hast. Es liegt meistens an Reboots. Tasmota hat die Eigenschaft bei schlechter Wlan-Verbindung neu zu starten. Vielleicht kannst du den Wlan-Empfang am Lesekopf, durch irgendwelche Maßnahmen, verbessern. Wenn du Hilfe mit dem Script brauchst, stelle dein Script hier in ein Codefenster. Dann schau ich mir das mal an.

[crazy-to-bike]

Danke erstmal.
Der WLAN-Repeater ist 5 cm neben dem Stromkasten, in dem die Tasmota hängen und die Signalqualität ist 100%. Da gibt’s nichts zu verbessern.
Das mit dem Script schaue ich an, sobald ich dazu komme.