Wenn du willst erzeuge ich dir ein Beispiel.
Ja, für mich 🤗
Datenbank URL ist ja bei mir die interne
Rest sagt mir jetzt nix, ein Beispiel wäre super
Also einfach für irgend einen Temp Sensor gestern um 12:00 und ein Beispiel am Sonntag 18:00?
Geht auch den Höchstwert eines Sensors von gestern?
Wäre toll 🤗
Edit: das hier ? In Examples
Editor
Am IPad verwende ich Runestone
Unter Windows Notepad++ (von hier kamen die Screenshots)
Und falls noch einer eine Idee hat, wie ich ohne SQL an einen Sensorwert vor z.B. 1 Minute, Stunde oder Tag
???
Hast du von mir bekommen 😉 siehe Beitrag #8
Habe mich ja jetzt etwas beschäftigt mit deinem Problem 🤗
Kannst Du uns jetzt noch erzählen was Du genau erreichen möchtest mit deinen Sensoren?
Eine Differenztemperatur eines Außen- und Innensensors, die ja immer noch falsch berechnet wird (ist ja immer noch ein Mittelwert (habe ich ja absichtlich nicht korrigiert)
Dann kam noch diese Frage:
Gibt es eine einfache Möglichkeit, wie ich z.B. vom Wert states('sensor.temperature_indoor') den Wert vor 1 Minute, Stunde Tag zu bekommen
so, jetzt noch mal ein wenig mit Erklärung:
bei zwei Sensoren brauch man eigentlich keine Variablen, aber gut (ohne hast Du ja schon oben für den Template Helfer)
diese beiden sind "deaktiviert" mit # weil ich diesen Block so schon habe! also alle template => sensor werden untereinander geschrieben
weiterer sensor fängt also nur mit - name: an
deine beiden sind nur deaktiviert und dafür meine zum testen
die weitere Variable "c" zur Berechnung habe ich nur für Dich gemacht, weil Du die ja anscheinend magst
eine eineindeutige unique_id ist wichtig um diese in der WebUI abändern kann
YAML:
#template:
# - sensor:
- name: 'Differenztemperatur Forum'
state: >
# {% set a = states('sensor.temperature_indoor') | float %}
# {% set b = states('sensor.temperature_garden') | float %}
{% set a = states('sensor.esp32_4_am2302_temperature') | float(0) %}
{% set b = states('sensor.ds18b20_dt_sp1_116_temperature') | float(0) %}
{% set c = ((a+b) / 2) %}
{{ c |float |round(1) }}
unit_of_measurement: '°C'
device-class: temperature
state_class: measurement
unique_id: differenztemperatur_forum_0000000000device_class: temperature
Böser Böser Fehler 
hier ist ein TAB anstelle Leerzeichen !!
Fehler kommt aber beim Konfiguration Prüfen, er sagt aber nicht warum
Also IMMER Konfiguration Prüfen und am besten einen anständigen EDITOR verwenden und alle Zeichen einblenden
habe den Fehler natürlich auch gleich nicht gefunden
Das mit dem Template habe ich jetzt auch so probiert:
kannst du mal bitte deine komplette configuration.yaml posten? auch gerne per PN zu mir?
sonst wird das schwierig
den Wert vor 1 Minute
Das geht mit temmplate trigger
Beispiel für 10 min
template:
# temperatur 10min vorher
- trigger:
- platform: time_pattern
minutes: "/1"
sensor:
- name: 10min temperature history
state: "{{ states('sensor.uni_128_temperature_4') }}"
attributes:
min0: "{{ states('sensor.uni_128_temperature_4')|float(0) }}"
min1: "{{ this.attributes['min0'] }}"
min2: "{{ this.attributes['min1'] }}"
min3: "{{ this.attributes['min2'] }}"
min4: "{{ this.attributes['min3'] }}"
min5: "{{ this.attributes['min4'] }}"
min6: "{{ this.attributes['min5'] }}"
min7: "{{ this.attributes['min6'] }}"
min8: "{{ this.attributes['min7'] }}"
min9: "{{ this.attributes['min8'] }}"
min10: "{{ this.attributes['min9'] }}"
# Abfrage waere dann
# {{ state_attr('sensor.10min_temperature_history', 'min10') }}und wieder Helfer Template beim letzten
WICHTIG !!! bei YAML:
template:
gibt es nur 1x
alle weiteren Template kommen dann darunter in einem Block => vielleicht ist das der Fehler von Oben
Laut einem schweizer YT Kanal soll der grüne Draht (6) an Ground (Minus).
Sorry, das ist ja klar das der UNI in Rauch aufgeht 🤨
Quell: https://kb.shelly.cloud/knowledge-base/shelly-plus-uni
Pin6 zu GND = Kurzschluss
Pin6 (+5 VDC) kann auch 12VDC (Motorrad Batterie hat aber 13-14V)
Habe auch einen UNI (Gen1) mit Anschluss für die Bordsteckdose, Problem: der saugt natürlich die Batterie leer 😉
Also besser zum überwintern ein Ladegeräte mit „Erhaltung Modus)
da ich ja ein YAML Fan bin habe ich mir das auch mal angesehen:
das passt auch nicht: "device classes" "weather" kenne ich nicht und ist hier auch nicht beschrieben:
Sensor entity | Home Assistant Developer Docs (home-assistant.io)
Nachdem das so in die configuration.yaml gespeichert wurde sollte auf jeden fall die Konfiguration geprüft werden
und siehe DA:
in deinem Fall ist es auf jeden fall:
device_class: temperature
state_class: measurement dass die Wirkkette funktioniert?
Template Editor: ist nicht gleich Template Helfer oder Yaml Sensor
Der Template Editor berechnet nur das in den {xxxxxxxxxx}
das schnellste bei dir ist also ein Helfer-Template-Sensor wie HighFive schon angemerkt hat 
Zustandstemplate:
Meins zum testen:
{{ ((states('sensor.esp32_4_am2302_temperature')|float(0) +
states('sensor.esp32_4_am2302_temperature')|float(0))/2) |round(2)}}
Deins wäre also:
{{ ((states('sensor.temperature_indoor')|float(0) +
states('sensor.temperature_garden')|float(0))/2) |round(2)}}Auch die Anmerkung von
((a +b) / 2) ist für mich der MITTELwert und nicht eine DIFFERENZ.
stimme ich zu, da du hier einen Innensensor und einen Außensensor verwendest und dein Name des Sensors "Differenztemperatur" heißt !!
also wäre es ja einfach Innensensor minus Außensensor (dann noch ABS um vielleicht noch das Vorzeichen zu eliminieren)
Hallo Martin,
Ich bin gestern auch drüber gestolpert 🤗
Der Fensterkontakt hat in der Szene diese Möglichkeit:
Sollte also passen.
mein Test (mit schalte jede Minute) hat ja nicht funktioniert und der Zustand wurde nicht beachtet
Dann habe ich mir den Zustand in der App angesehen und dieser wurde nicht (mehr) aktualisiert. Zugegeben, ich verwende ja HA, daher weiß ich nicht wie lange das so ist. Im Log war die letzte Zustandsänderung schon lange her und als BLE-Beobachter war ein Shelly zwei Stockwerke entfernt 😝
Hier im Wohnzimmer ist eigentlich noch ein pro 3EM konfiguriert als BLE-Beobachter, der wollte anscheinend nicht. Also weiter gesucht, anscheinend müssen die BLE-Beobachter in der Cloud sein. Das war mir gar nicht mehr so bewusst, nun gut, diese beiden sind aber in der Cloud gewesen! Also mal auf die schnelle einen Mini 1 Gen3 aktiviert als BLE-Beobachter und Cloud => und sofort waren alle DW fleißig wieder dabei den Status zu übergeben.
Ich mach mal gleich wieder eine Test Szene.
Trotzdem kann ich nur wärmstens Empfehlen so etwas nur in einem übergeordnetem System zu machen, da wäre es in einer Automation auch eindeutig eine Bedingung und nicht im „Außlöser“
Dort hat du ja ein HTTP Request
Schau dir mal die Temperatur an 😉
Fw Update zeigt dein Screenshot, wird aber wahrscheinlich nicht helfen
Der Eintrag ?? Im Log, keine Ahnung
Shelly 1PM zur Steuerung einer etwa 2.7kW Last
Das ist auf Dauer zu viel für den 1PM 😎 er wird wegen Overload abschalten und neu starten
Haben wir gerade hier:
Hast du einen Gen1 1PM oder einen Gen2 Plus 1PM?
Und Willkommen im Forum 🤗
Die Wandler passen nicht an deinen Plus 1PM (Hardware/Software)
Das Schaltrelais aus dem Beitrag #11 kannst Du am Ausgang O des Plus 1PM verwenden, dann wird aber nur die Leistung des Relais erfasst und nicht mehr den Verbraucher dahinter. Dafür benötigst Du natürlich den PM eigentlich nicht.
Beispiel ein 1 mini Gen3
Quelle: https://community.shelly.cloud/gallery/image/…ng/?context=new
das stimmt so eigenlich lt. Shelly-Website nicht
ich denke mir das ja nicht aus 🤓
Quelle: https://kb.shelly.cloud/knowledge-base/shelly-plus-1pm
Zum Glück das ich HA verwende
Schau dir mal bitte den Status des BLU in der Cloud an!!
Mein Test als Szene:
Tür ist zu und trotzdem schaltet mein Button (LED Licht) jede Minute um !!
ist ja eigentlich kein Wunder, da er in der App angekippt ist
er aktualisiert sich bei mir in der App nicht wirklich
In HA macht er das sofort!
hier reagieren beide sofort und richtig, in der App ändert sich das gerade überhaupt nicht
wenn die Türe offen ist
hier ist doch die crux 
mehr als 0 W sollte funktionieren
- der Trigger (wenn:) funktioniert wenn er bei Null ist und dann größer wird => also OK Aber wenn schon Größer ist => dann kein Trigger mehr
so sollte es auch bei der Tür sein also wird er nicht getriggert wenn er Offen war
Teste doch einfach eine neue Szene, nur mit dem Türsensor und einer Benachrichtigung => die wird nur ausgelöst wenn der Zustand vorher GESCHLOSSEN war
EDIT: ich schaue mir das gerade an, Zustand ist ja kein Trigger
Geräte => Shelly => Bei TRV auf die drei Punkte => löschen
