NodeRED: alternative zyklische Fenster-Offen-Meldung

Eine „einfache“ Fenster-Offen-Meldung unter Nutzung von NodeRED und Telegram habe ich Dir im Beitrag „NodeRED: zyklische Fenster-Offen-Meldung„ vorgestellt.
Falls viele Fenster geöffnet sind, wie bei warmen Außentemperaturen nicht unüblich, wird es jedoch schnell unübersichtlich. Diese Anleitung erweitert daher obige Lösung um folgende Punkte:

• Das erste Fenster, welches geöffnet wurde, startet einen zyklischen Timer.
• Nach Ablauf des Timers wird eine Meldung ausgegeben, in der steht, welche Fenster oder Türen noch geöffnet sind.
• Jedes weitere geöffnete Fenster wird lediglich registriert und bei der zyklischen Benachrichtigung mit ausgegeben.
• Wird ein Fenster geschlossen, so wird die Benachrichtigung aktualisiert.
• Das letzte geschlossene Fenster stoppt den Timer.
• Die ChatID wird nicht mehr fest vorgegeben sondern aus dem globalen Kontext ausgelesen. Dadurch ist eine Deaktivierung oder ein dynamisches Umkonfigurieren per WebUI möglich.
• Die Dauer, die das jeweilige Fenster bereits geöffnet ist, wird mit ausgegeben.
• Die Benachrichtigung gibt getrennte Zeilen für Fenster und Türen aus.

Voraussetzungen

Die Voraussetzungen sind die selben, wie im Artikel „NodeRED: zyklische Fenster-Offen-Meldung„:

• Du benötigst einen eingerichteten Telegram-Bot in NodeRED, wie beispielsweise im Artikel „Einrichten eines Telegram-Bots“ beschrieben.
• An Hardware benötigst Du einen eingerichteten Fenstersensor. Im Artikel „Aqara ZigBee-Sensor mit Homematic IP-Thermostat nutzen“ ist beschrieben, wie Du einen ZigBee-Sensor einrichtest, den Du auch für diesen Zweck benutzen kannst.

Vorgehensweise

Bis Du eine Meldung in Deinem Telegram-Messenger siehst, sind grob folgende Schritte notwendig:

1. Anlegen Deiner Telegram-Chat-ID im globalen Kontext.
2. Konfiguration der Daten für die Nachrichtenerstellung: hier teilst Du mit, ob eine Tür oder ein Fenster geöffnet wurde und in welchem Raum sie sich befindet.
3. Dann wird im Subflow Fenstermeldung die Nachricht erstellt und versendet.

In den nachfolgenden Absätzen findest du eine detailliertere Beschreibung.

Konfiguration der Daten „Meldungsdaten festlegen“

Die Konfiguration kannst Du in einem Change-Node erledigen. Es werden folgende Parameter benötigt:

• msg.topic: Das ist eine eindeutige Raumbezeichnung, welche zur Speicherung des Zustands sowie zur Ausgabe der Meldung benutzt wird. Solltest Du gleichzeitig viele Fenster/Türen geöffnet haben (bspw. im Sommer), so empfiehlt sich der Übersichtlichkeit halber eine Kurzform (bspw. „WoZi“).
• msg.type: Der type dient der Unterscheidung zwischen Tür und Fenster. Falls es mehrere Fenster gibt, kannst Du hier auch „Fenster links“ oder ähnlich angeben. Es muss jedoch auf alle Fälle Fenster und Tür enthalten sein, damit die Ausgabe diese unterscheiden kann.
• Im Unterschied zur Lösung „NodeRED: zyklische Fenster-Offen-Meldung„ liest der hier vorgestellte NodeRED-Flow die ChatID aus dem globalen Kontext. Das hat den Vorteil, dass Du die Benachrichtigung deaktivieren oder umleiten kannst (bspw. für Testzwecke von der TG-Gruppe auf Deinen TG-Account).

Erstellen des Nachrichtentexts

Der Text, die im Messenger erscheinen soll, wird abhängig von den Eingangsparameter erstellt. Dabei wird die Markdown-Syntax für die Formatierungen Fett und Kursiv benutzt.

Die Erstellung erfolgt im SubFlow „peripherals message„. Ich umreisse grob, wie er funktioniert, da er recht umfangreich ist.

1. Wird ein Fenster oder eine Tür (ich spreche im weiteren Verlauf von „Objekt“) geöffnet, wird im globalen Kontext ein Listeneintrag angelegt, welcher den Zustand, die Öffnungszeit sowie die mitgegebenen Daten anlegt.
2. Falls noch keine Benachrichtigungsschleife läuft, wird eine gestartet. Ich habe hier zyklische Benachrichtigung von 10min gewählt.
3. Läuft bereits eine Schleife und wurde ein weiteres Objekt geöffnet, so wird lediglich ein Eintrag im globalen Kontext hinzugefügt.
4. Wurde ein Objekt geschlossen, so wird ermittelt, ob es das letzte offene Objekt war. Falls nicht, wird die Ausgabe lediglich aktualisiert. Anderenfalls wird eine Meldung ausgegeben, dass alle Objekte geschlossen sind. Zudem wird der Timer gestoppt.
5. In diesem SubFlow erfolgt auch bereits eine Konfiguration der Chat-Daten. So wird die letzte gesendete Nachrichtennummer und die Quelle für die chatId in das Msg-Objekt gepackt.

Versand

Der Subflow „sendMessage“ ist für den Versand per Telegram zuständig. Da er bei mir nicht nur für das Senden von Fensterbenachrichtigungen genutzt wird, habe ich ihn in einen separaten SubFlow gekapselt.

1. Falls der Msg-Parameter eine Zeichenkette ist (wie sie es in diesem Beispiel ist), so wird die chatId aus dem Property notificationReceiver.peripherals des globalen Kontexts gelesen. Falls die chatId nicht definiert ist, wird keine Nachricht versendet (=Benachrichtigung ausgeschalten). Falls die chatId eine Zahl ist, so wird diese Zahl direkt als chatId verwendet.
2. Falls es ein vorhergendes Nachrichtenobjekt, sprich eine bereits gesendete Nachricht gibt, so wird das gelöscht, ehe die Nachricht gesendet wird. Durch das Löschen erhält die Nachricht einen aktuellen Zeitstempel. Würde man die letzte Nachricht lediglich editieren, so würde der Zeitstempel der Telegram-Nachricht nicht aktualisiert werden.

NodeRED-Flow

Im nachfolgenden Flow musst Du nach dem Einfügen des Beispiel noch folgende Einstellungen durchführen:

1. Deine ChatId im Switch-Node „Meldungsdaten festlegen“ eintragen.
2. Deinen ChatBot in den beiden Telegram-Nodes im SubFlow „sendMessage“ konfigurieren.

Fazit

Diese Benachrichtigung stellt den Status deiner Fenster und Türen kompakt und übersichtlich im Chat dar. Gerade im Sommer, wenn viele Fenster geöffnet sind, ist das von Vorteil.