Alarmierung ja aber keine Alarmschauer?
-
@asgothian said in [Alarmierung ja aber keine Alarmschauer?]
...oder der Sensor schlecht platziert.
Was wäre den der richtige Platz für den Sensor?
@claus1993 Du willst erkennen wenn der Gefrierschrank auftaut. Dann würde ich den Sensor oben im Gefrierschrank ca. 1/3 nach innen versetzt platzieren. Damit spricht er nicht sofort an wenn die Tür geöffnet wird, sollte aber rechtzeitig warm werden bevor irgendetwas antaut.
A.
-
@claus1993 Du willst erkennen wenn der Gefrierschrank auftaut. Dann würde ich den Sensor oben im Gefrierschrank ca. 1/3 nach innen versetzt platzieren. Damit spricht er nicht sofort an wenn die Tür geöffnet wird, sollte aber rechtzeitig warm werden bevor irgendetwas antaut.
A.
Danke für Euer Feedback. Zu den Lösungsmöglichkeiten gefällt mir die Einbringung weiterer Hardware auch nicht wirklich.
Zur Position des Fühlers (DS18B20 im wasserdichten Metallrohr) habe ich mich am orginal Fühler orientiert und in im oberen 1/3 des Schranks aber recht weit an der Rückwand positioniert. Dabei aber auf eine freie Ausrichtung in der Luft geachtet, damit nicht durch Vereisungen der Sensor mit Eis verdeckt wird und so praktisch unbrauchbar für die 2-Punkt Regelung wird. Grob sollte er also gemäß Eurer Empfehlung positioniert sein.
Egal ob eine Änderung gemessen wird ein Update kommt alle 10 Sekunden per MQTT. Möchte aber nicht vernachlässigen, dass WLAN Verbindungen durchaus mal gestört sein können.
Ich habe immer ein ungutes Gefühl irgendwelche Timer laufen zu lassen, deswegen auch meine Frage. Ich könnte ja somit auch bei einer Grenzüberschreitung (-16°C) einen Counter laufen lassen der mit jeder Aktualisierung (normal alle 10 Sekunden) um 1 erhöht wird. Bei zB 6 (für 1 Minute als Alarmintervall) lasse ich Alarmieren und setze den Counter wieder auf 0. Birgt das Risiko wenn nicht jeder MQTT Wert per Wlan durch kommt. Eine zusätzliche Prüfung der MQTT Verbindung auf "Connected" löst das bei einer "schwankenden" Verbindung dann auch nicht in dem Zusammenhang. So gingen Zählungen verloren und die Connected-Prüfung setzt sich regelmäßig selber zurück ohne Alarmierung. Also doch ein besser ein Timer?
-
Danke für Euer Feedback. Zu den Lösungsmöglichkeiten gefällt mir die Einbringung weiterer Hardware auch nicht wirklich.
Zur Position des Fühlers (DS18B20 im wasserdichten Metallrohr) habe ich mich am orginal Fühler orientiert und in im oberen 1/3 des Schranks aber recht weit an der Rückwand positioniert. Dabei aber auf eine freie Ausrichtung in der Luft geachtet, damit nicht durch Vereisungen der Sensor mit Eis verdeckt wird und so praktisch unbrauchbar für die 2-Punkt Regelung wird. Grob sollte er also gemäß Eurer Empfehlung positioniert sein.
Egal ob eine Änderung gemessen wird ein Update kommt alle 10 Sekunden per MQTT. Möchte aber nicht vernachlässigen, dass WLAN Verbindungen durchaus mal gestört sein können.
Ich habe immer ein ungutes Gefühl irgendwelche Timer laufen zu lassen, deswegen auch meine Frage. Ich könnte ja somit auch bei einer Grenzüberschreitung (-16°C) einen Counter laufen lassen der mit jeder Aktualisierung (normal alle 10 Sekunden) um 1 erhöht wird. Bei zB 6 (für 1 Minute als Alarmintervall) lasse ich Alarmieren und setze den Counter wieder auf 0. Birgt das Risiko wenn nicht jeder MQTT Wert per Wlan durch kommt. Eine zusätzliche Prüfung der MQTT Verbindung auf "Connected" löst das bei einer "schwankenden" Verbindung dann auch nicht in dem Zusammenhang. So gingen Zählungen verloren und die Connected-Prüfung setzt sich regelmäßig selber zurück ohne Alarmierung. Also doch ein besser ein Timer?
@pete0815 said in Alarmierung ja aber keine Alarmschauer?:
So gingen Zählungen verloren und die Connected-Prüfung setzt sich regelmäßig selber zurück ohne Alarmierung. Also doch ein besser ein Timer?
Für die Temperaturüberwachung nicht.
Du hast eine regelmässige Änderung des Wertes.
Jetzt gibt es 2 Optionen:
Option A - der Wert wird regelmässig aktualisiert. Dann gilt die folgende Logik:
Wert steigt das erste mal über die Warngrenze - Zeit merken, Zeit der Warnmeldung löschen
Wert wird aktualisiert über der Warngrenze, schauen ob die oben angegebene Zeit lange genug her ist um zu warnen => Letzte Warnmeldung schon lange genug her => dann Warnung senden. Zeit der Warnmeldung merken. Ansonsten nix tun
Wert sinkt unter die Warngrenze - Alle gemerkten Zeiten löschen, nix tun.Option B- Die Aktualisierungen bleiben aus, Dann muss dein Timer zuschlagen, der (bei 10 sekunden Intervall alle 60 - 120 sekunden laufen sollte) 2 Dinge macht:
- Warnung triggern, analog zu oben, Sprich das auslösen einer 2. Warnung durch Merken wann die letzte Warnung verschickt wurde und einen Zeitvergleich blockieren.
- Das obige Skript triggern, damit auch eine Temperaturwarnung kommt sofern die Aktualisierung ausbleibt während die Temperatur zu hoch ist.
A.
Das Thema "der Wert passiert die Warngrenze" lässt sich über die dem Trigger Objekt obj mitgegebenen Informationen Lösen, da es auch den Wert beinhaltet den der State vor der auslösenden Änderung hatte.
-
@pete0815 said in Alarmierung ja aber keine Alarmschauer?:
So gingen Zählungen verloren und die Connected-Prüfung setzt sich regelmäßig selber zurück ohne Alarmierung. Also doch ein besser ein Timer?
Für die Temperaturüberwachung nicht.
Du hast eine regelmässige Änderung des Wertes.
Jetzt gibt es 2 Optionen:
Option A - der Wert wird regelmässig aktualisiert. Dann gilt die folgende Logik:
Wert steigt das erste mal über die Warngrenze - Zeit merken, Zeit der Warnmeldung löschen
Wert wird aktualisiert über der Warngrenze, schauen ob die oben angegebene Zeit lange genug her ist um zu warnen => Letzte Warnmeldung schon lange genug her => dann Warnung senden. Zeit der Warnmeldung merken. Ansonsten nix tun
Wert sinkt unter die Warngrenze - Alle gemerkten Zeiten löschen, nix tun.Option B- Die Aktualisierungen bleiben aus, Dann muss dein Timer zuschlagen, der (bei 10 sekunden Intervall alle 60 - 120 sekunden laufen sollte) 2 Dinge macht:
- Warnung triggern, analog zu oben, Sprich das auslösen einer 2. Warnung durch Merken wann die letzte Warnung verschickt wurde und einen Zeitvergleich blockieren.
- Das obige Skript triggern, damit auch eine Temperaturwarnung kommt sofern die Aktualisierung ausbleibt während die Temperatur zu hoch ist.
A.
Das Thema "der Wert passiert die Warngrenze" lässt sich über die dem Trigger Objekt obj mitgegebenen Informationen Lösen, da es auch den Wert beinhaltet den der State vor der auslösenden Änderung hatte.
@asgothian said in Alarmierung ja aber keine Alarmschauer?:
Option A - der Wert wird regelmässig aktualisiert. Dann gilt die folgende Logik:
Danke, hab mich mal versucht:
Option B- Die Aktualisierungen bleiben aus, Dann muss dein Timer zuschlagen, der (bei 10 sekunden Intervall alle 60 - 120 sekunden laufen sollte) 2 Dinge macht:
- Warnung triggern, analog zu oben, Sprich das auslösen einer 2. Warnung durch Merken wann die letzte Warnung verschickt wurde und einen Zeitvergleich blockieren.
- Das obige Skript triggern, damit auch eine Temperaturwarnung kommt sofern die Aktualisierung ausbleibt während die Temperatur zu hoch ist.
Danke, überlege gerade ob es hier nicht Sinn macht auf den MQTT DP status LWT -> connected bzw. disconnected zu triggern und dann einen Timer laufen zu lassen der alle 15 Minuten einen Alarm verschickt, wenn keine Aktualisierung erfolgt. Das unabhängig von einer Temperatur. Aber wie lässt sicht dieser Trigger nutzen? Das ist ja kein "einfacher" true/false binär DP. Muss man hier den Text auswerten?
Das Thema "der Wert passiert die Warngrenze" lässt sich über die dem Trigger Objekt obj mitgegebenen Informationen Lösen, da es auch den Wert beinhaltet den der State vor der auslösenden Änderung hatte.
Sorry das verstehe ich nicht, was Du damit meinst.
-
@asgothian said in Alarmierung ja aber keine Alarmschauer?:
Option A - der Wert wird regelmässig aktualisiert. Dann gilt die folgende Logik:
Danke, hab mich mal versucht:
Option B- Die Aktualisierungen bleiben aus, Dann muss dein Timer zuschlagen, der (bei 10 sekunden Intervall alle 60 - 120 sekunden laufen sollte) 2 Dinge macht:
- Warnung triggern, analog zu oben, Sprich das auslösen einer 2. Warnung durch Merken wann die letzte Warnung verschickt wurde und einen Zeitvergleich blockieren.
- Das obige Skript triggern, damit auch eine Temperaturwarnung kommt sofern die Aktualisierung ausbleibt während die Temperatur zu hoch ist.
Danke, überlege gerade ob es hier nicht Sinn macht auf den MQTT DP status LWT -> connected bzw. disconnected zu triggern und dann einen Timer laufen zu lassen der alle 15 Minuten einen Alarm verschickt, wenn keine Aktualisierung erfolgt. Das unabhängig von einer Temperatur. Aber wie lässt sicht dieser Trigger nutzen? Das ist ja kein "einfacher" true/false binär DP. Muss man hier den Text auswerten?
Das Thema "der Wert passiert die Warngrenze" lässt sich über die dem Trigger Objekt obj mitgegebenen Informationen Lösen, da es auch den Wert beinhaltet den der State vor der auslösenden Änderung hatte.
Sorry das verstehe ich nicht, was Du damit meinst.
@pete0815 Du hast im trigger Bereich einen Extra Baustein:
Damit kannst du Folgendes tun:
Damit bekommst du 5 Minuten (300 sekunden) nach dem die Temperatur die Warngrenze (hier -10 Grad) unterschritten hat eine Meldung.
Das war mit diesem Satz gemeint.
A.
-
@pete0815 Du hast im trigger Bereich einen Extra Baustein:
Damit kannst du Folgendes tun:
Damit bekommst du 5 Minuten (300 sekunden) nach dem die Temperatur die Warngrenze (hier -10 Grad) unterschritten hat eine Meldung.
Das war mit diesem Satz gemeint.
A.
@asgothian
Vielen Dank!
Denke soweit das Prinzip verstanden zu haben. Habe jedoch versucht Informationen zu finden welche "Standardvariablen" einem Object immer mitgegeben werden bzw. existieren. Hast Du hier einen Tip?
Bei der Doku und google war ich nicht erfolgreich, was auch an den Suchbegriffen liegen mag.Hintergrund ist, dass ich nicht weiß ob die von Dir gezeigten "Standardvariablen" previous value & state value immer so existieren oder ich ggf. die Deutsche Übersetzung hierfür verwenden muß bei mir.
Thx
-
@asgothian
Vielen Dank!
Denke soweit das Prinzip verstanden zu haben. Habe jedoch versucht Informationen zu finden welche "Standardvariablen" einem Object immer mitgegeben werden bzw. existieren. Hast Du hier einen Tip?
Bei der Doku und google war ich nicht erfolgreich, was auch an den Suchbegriffen liegen mag.Hintergrund ist, dass ich nicht weiß ob die von Dir gezeigten "Standardvariablen" previous value & state value immer so existieren oder ich ggf. die Deutsche Übersetzung hierfür verwenden muß bei mir.
Thx
@pete0815 Du musst schon den im ersten Bild genommenen Baustein aus dem Trigger Bereich wählen. Der Baustein listet die Werte auf auf die du den einstellen kannst. Auch wenn die Farbe wie eine Variable aussieht ist es ein anderer Baustein.
A.
-
@pete0815 Du musst schon den im ersten Bild genommenen Baustein aus dem Trigger Bereich wählen. Der Baustein listet die Werte auf auf die du den einstellen kannst. Auch wenn die Farbe wie eine Variable aussieht ist es ein anderer Baustein.
A.
@asgothian
Danke! Jetzt verstanden :)Option A ist angepasst und schaut so aus:
@asgothian said in Alarmierung ja aber keine Alarmschauer?:
Option B- Die Aktualisierungen bleiben aus, Dann muss dein Timer zuschlagen, der (bei 10 sekunden Intervall alle 60 - 120 sekunden laufen sollte) 2 Dinge macht:
- Warnung triggern, analog zu oben, Sprich das auslösen einer 2. Warnung durch Merken wann die letzte Warnung verschickt wurde und einen Zeitvergleich blockieren.
Dies schaut dann für mich so aus:
Hierbei noch unsicher, da der Timer nur initial einmal und dann endlos laufen soll. Kann bzw. wird so ein Timer ggf. mehrfach gestartet also mit jeder Aktualisierung ein weiterer Timer?- Das obige Skript triggern, damit auch eine Temperaturwarnung kommt sofern die Aktualisierung ausbleibt während die Temperatur zu hoch ist.
Hier fehlt mir die Idee. Sehe derzeit nur die Möglichkeit den Trigger der Option A auszulösen indem ich per Blockly den Temperaturwert aktualisiere (nicht verändere). Diese "manuelle" Aktualisierung hebelt die Wirkung der Logik der Option B aber aus.
-
@asgothian
Danke! Jetzt verstanden :)Option A ist angepasst und schaut so aus:
@asgothian said in Alarmierung ja aber keine Alarmschauer?:
Option B- Die Aktualisierungen bleiben aus, Dann muss dein Timer zuschlagen, der (bei 10 sekunden Intervall alle 60 - 120 sekunden laufen sollte) 2 Dinge macht:
- Warnung triggern, analog zu oben, Sprich das auslösen einer 2. Warnung durch Merken wann die letzte Warnung verschickt wurde und einen Zeitvergleich blockieren.
Dies schaut dann für mich so aus:
Hierbei noch unsicher, da der Timer nur initial einmal und dann endlos laufen soll. Kann bzw. wird so ein Timer ggf. mehrfach gestartet also mit jeder Aktualisierung ein weiterer Timer?- Das obige Skript triggern, damit auch eine Temperaturwarnung kommt sofern die Aktualisierung ausbleibt während die Temperatur zu hoch ist.
Hier fehlt mir die Idee. Sehe derzeit nur die Möglichkeit den Trigger der Option A auszulösen indem ich per Blockly den Temperaturwert aktualisiere (nicht verändere). Diese "manuelle" Aktualisierung hebelt die Wirkung der Logik der Option B aber aus.
@pete0815 Der erste Teil sieht gut aus, mit einem Caveat: Fällt der Kühlschrank kurz vor Mitternacht aus bekommst du keine Meldung.
Das liegt daran das du "Sekunden seit Tagesanfang" genommen hast. Deswegen hatte ich nur "Sekunden" genommen
Der Zweite Teil passt so nicht.
So würde ich da ran gehen.
Damit bekommst du
- Eine Meldung wenn die Aktualisierung für 5 Minuten ausgefallen ist
- Alle 5 Minuten eine Meldung solange das so ist.
Wenn die Meldungen seltener kommen sollen würde ich das mit einem Zähler realisieren.
A.
-
@pete0815 Der erste Teil sieht gut aus, mit einem Caveat: Fällt der Kühlschrank kurz vor Mitternacht aus bekommst du keine Meldung.
Das liegt daran das du "Sekunden seit Tagesanfang" genommen hast. Deswegen hatte ich nur "Sekunden" genommen
Der Zweite Teil passt so nicht.
So würde ich da ran gehen.
Damit bekommst du
- Eine Meldung wenn die Aktualisierung für 5 Minuten ausgefallen ist
- Alle 5 Minuten eine Meldung solange das so ist.
Wenn die Meldungen seltener kommen sollen würde ich das mit einem Zähler realisieren.
A.
@asgothian Vielen Dank!
Die Definition der TempWarnLimit Variable reicht ja aus, wenn ich sie für Option A und B einmal setze auf einem Blockly Skript, oder?
wäre dann so
Option A:
Option B:
-
@asgothian Vielen Dank!
Die Definition der TempWarnLimit Variable reicht ja aus, wenn ich sie für Option A und B einmal setze auf einem Blockly Skript, oder?
wäre dann so
Option A:
Option B:
-
@asgothian Vielen Dank! Eingebaut, getestet und funktioniert.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren AnmeldenSupport us
347
Online32.7k
Benutzer82.6k
Themen1.3m
Beiträge