ich schaue eigentlich nie in die Log-Datei, jetzt sehe ich da dies…
die zugehörige Automation sieht so aus …
kann da jetzt keinen Fehler erkennen …
ich schaue eigentlich nie in die Log-Datei, jetzt sehe ich da dies…
die zugehörige Automation sieht so aus …
kann da jetzt keinen Fehler erkennen …
Entferne doch einfach das W bei Wert-Template.
das hat leider keine Lösung gebracht, der Fehler besteht weiterhin …
# VerbrauchAktuell
- name: "VerbrauchAktuell"
unique_id: "VerbrauchAktuell"
unit_of_measurement: 'W'
device_class: "energy"
state: >-
{{ float(states('sensor.tasmota_SM_76_7_0')) | round(0) / 1 }}
okay, gehe bitte mal in deine Automation und klicke dann rechts oben auf die 3 Punkte. Dort dann “Edit in YAML”.
Hier entfernst du die Zeile
value_template: ""
Dann abspeichern.
Unter Wert-Template/value_template kannst du die Kondition als Template eingeben. Dadurch, dass du dort ein W stehen hattest und das dann entfernt hast, steht dort nun ein leerer String(’ ') und der ersetzt alles was obendrüber steht. Mit dem Löschen der Zeile sollte das Problem behoben sein.
Besten Dank für die Hilfe, die Fehlermeldung ist jetzt weg.
Was dazu führt, daß ich jetzt viel zu oft die Meldung bekomme, daß das BKW genug Strom produziert.
ich müsste in meine Automation noch einbauen, daß diese Meldung max. 1x pro Tag ausgegeben wird.
Und noch eine Frage zum Error-Report:
Sollte man da regelmässig reinschauen?
Viele Fehler treten nur temporär auf und sind beim nächsten Mal verschwunden …
Es lohnt sich schon immer mal ins log zu schauen, so verpasst man nix und steht am Ende nicht vor einem total kaputten System. Gerade weil das System meistens ja auch lebt, also viel irgendwo verändert wird, man ist halt nie fertig mit dem Smarthome.
Ich habe da aber auch Fehler drin, dass z.B. mein TV manchmal nicht erreicht wird. Der ist halt in irgendeinem Energiesparmodus und meldet sich irgendwann wieder, deshalb kann man den Fehler einfach ignorieren. Wird bei dir wahrscheinlich ähnliche Fehler geben, grade wenn sich manche selbst lösen.
habe eine neue Fehlermeldung:
sensor:
- platform: template
sensors:
nextsunrise:
entity_id: sun.sun
friendly_name: 'Next Sunrise'
value_template: >
{{ as_timestamp(states.sun.sun.attributes.next_rising) | timestamp_custom(' %H:%M Uhr ') | replace(" 0", " 0") }}
icon_template: mdi:weather-sunset-up
nextsunset:
entity_id: sun.sun
friendly_name: 'Next Sunset'
value_template: >
{{ as_timestamp(states.sun.sun.attributes.next_setting) | timestamp_custom(' %H:%M Uhr ') | replace(" 0", " 0") }}
icon_template: mdi:weather-sunset-down
und im dashboard kommt das auch
könnte es daran liegen, daß ich da dies
entity_id: sun.sun
2x stehen habe?
Da steht doch was du machen sollst. Die Zeile entity_id aus dem Code löschen. Es gibt auch eine Integration Sonne. Meine die ist sogar standardmäßig installiert, die hat bereits fertige Entitäten mit Sonnenauf- und Untergang.
danke, das war die Lösung, habe aber schon wieder einen Fehler:
Entity sensor.stromverbrauch from integration template has state class total_increasing, but its state is not strictly increasing. Triggered by state 1623.0 (1623.976) with last_updated set to 2023-08-24T22:34:46.312150+00:00.
bei meinem Sensor “stromvervrauch” handelt es sich um einen manuell in der config erstellter template Sensor:
template:
- sensor:
# StromVerbrauch
- name: "StromVerbrauch"
unique_id: "StromVerbrauch"
unit_of_measurement: 'kWh'
device_class: "energy"
state_class: "total_increasing"
state: >-
{{ float(states('sensor.tasmota_sm_1_8_0')) | round(0) / 1000 }}
# StromErzeugung
- name: "StromErzeugung"
unique_id: "StromErzeugung"
unit_of_measurement: 'kWh'
device_class: "energy"
state_class: "total_increasing"
state: >-
{{ float(states('sensor.tasmota_sm_2_8_0')) | round(0) / 1000 }}
von diesen Sensoren habe ich mehrere definiert aber nur dieser verursacht einen Fehler. bei state_class, was ja auch korrekt ist, denn der Wert erhöht sich ja nicht kontinuierlich. Manchmal ist es sogar negativ, wenn mehr Strom vom BKW kommt als wir in dem Moment verbrauchen
1.8.0 ist Strombezug und 2.8.0 ist Einspeisung. Beides sind gemäß OBIS Gesamtzählerstande, diese sind per Definition steigend und können keine negativen Werte haben. Wenn du mehr einspeist als verbrauchst steigt 1.8.0 nicht mehr, dafür aber 2.8.0.
Der Wert der negativ werden kann ist 16.7.0 dieser stellt die momentane Leistung in Watt dar.
der Fehler war beim nächsten Neustart weg, nachdem ich zuvor bei state_class auf total geändert hatte. Hab aber schon wieder den nächsten Fehler - ja bin aktuell auf Fehlersuche - nachdem ich zuvor kaum ins Protokoll gaschaut hatte.
der template Sensor:
sensor.HM-600_CH1_P_DC
kommt mittels ahoyDTU und MQTT und stammt von meiner Solarzelle #1.
# ErzeugungSol1
- name: "ErzeugungSol1"
unique_id: "ErzeugungSol1"
unit_of_measurement: W
device_class: energy
state: >-
{{ float(states('sensor.HM-600_CH1_P_DC')) | round(0) / 1 }}
# ErzeugungSol2
- name: "ErzeugungSol2"
unique_id: "ErzeugungSol2"
unit_of_measurement: 'W'
device_class: "energy"
state: >-
{{ float(states('sensor.HM-600_CH2_P_DC')) | round(0) / 1 }}
analog dazu gibt es eine Solarzelle#2, die keinen Fehler verursacht.
einziger sichtbarer Unterschied sind die Hochkomme bei “W”
Die Meldung im Log ist doch aber eindeutig. Zu der Zeit, wo dein Template das erste Mal gerendert wurde, lieferte der Sensor (noch) den Wert ‘unknown’ und es war kein Default angegeben.
Du könntest {{ float(states('sensor.HM-600_CH1_P_DC'),0) | round(0) / 1 }}
benutzen, um den Fehler zu vermeiden.
der Fehler ist jetzt nicht mehr aufgetaucht. Neuer Fehler hat wohl mit zigbee zu tun:
Logger: zigpy.zcl
Source: runner.py:179
First occurred: 00:51:16 (50 occurrences)
Last logged: 00:52:22
Dazu gibt es ganz unterschiedliche Tipps:
Man soll eine SSD verwenden (habe ich schon)
Man soll 2,4GHz WLAN dort abschalten, wo die Basis steht (hab in der Etage gar keinen WLAN Router)
Man soll auf MariaDB umstellen (wieso das ??)
ich hab aktuell per zigbee intergriert
5x power plug
2x Temp-Sensor
1x Tür Kontakt
und wollte das eigentlich noch weiter ausbauen …
wenn ich mir mein zigbee-Netz anschaue, kann ich da keine Auffälligkeiten sehen
O.g. Fehler kommt immer wieder, ist also keine einmalige Sache.