Verfügbarkeit von Sensoren über Node Red überwachen
-
@mickym Wenn Du zum Beispiel nur bestimmte Textwerte (also nicht nur EINEN durchlassen willst) - kannst Du eine Switch Node mit RegEx wie folgt nutzen:
Damit wird ein payload nur durchgelassen wenn sie Schnee oder Regen ist.
In Deinem Fall hättest Du nun auch alles zigbee IDs so erfassen können.
Ich habe sowas auch immer in einem eigenen Testflow - weil ich es auch oft vergesse, wie was möglich ist:
Eine weitere Möglichkeit ist ein Array mit gültigen Werten und eine Überprüfung in einer Change Node:
Oben definiert man also ein Array mit gültigen Werten, die man unten wieder löscht. In der Mitte wird überprüft, ob die payload in den gültigen Werten enthalten ist. Du siehst die Möglichkeiten sind mannigfaltig.
-
JSON/JSONATA/RegEx sind definitv ein Thema, bei dem ich mich wirklich mal hinsetzen muss und mir das dann ins Gedächtnis einspeichern muss. Denn dass sind echt mächtige Werkzeuge, die (nicht nur hier) wirklich unzählige Möglichkeiten bieten!
-
Ich habe übrigens meine Tabelle mal um die Timestamps für die Temp und Hum erweitert (inkl. Formatieren):
Einer der nächsten Steps wäre dann demnächst diese Timestamps zur "Fehleranalyse" zu nutzen.
Beispiel: wenn ein Sensor für längere Zeit keine Aktualisierung liefert, soll das Feld dann zb. rot markiert sein.
Dazu werde ich mich dann auch mit dem Godfather der ui-table beschäftigen müssen :D.Ohne dass du mir jetzt eine Lösung nennen sollst oder ich dich wieder dazu bewege für mich Flows zu erstellen:
Ist das überhaupt möglich ohne das System zu belasten?
In meinem Kopf sieht das dann nämlich so aus, dass für 18 Werte permanent der Timestamp mit der aktuellen Uhrzeit abgeglichen wird, und wenn eine bestimmte Differenz ermittelt wird, verändere ich die Tabelle und mache ein Feld rot.
Abgesehen davon dass das nach sau viel Arbeit und Einlesen klingt, kann ich mir gut vorstellen dass das voll aufs System geht, oder?
Allgemein kann ich mir adhoc keine Möglichkeit erdenken die prüft ob seit zb. 10 Minuten eine Variable nicht aktualisiert wurde - zumindest nicht ohne dass ich 18x durchgehend eine Überprüfung mache und damit womöglich NR kille^^EDIT: theoretisch kann ich diese Überprüfung ja aber auch nur alle 10 Minuten triggern. Im schlimmsten Fall wäre das Feld dann erst rot wenn der Wert schon 19 Minuten alt ist, aber das wäre ja zumindest mal ein Anfang!
EDIT2: für die Formatierung der Timestamps habe ich eine Node aus dem Netz geklaut (contrib-moments)
-
@schmetterfliege ich habe dir ja schon mal gesagt, dass ich von der Überprüfung der Zeitstempel nichts halte und dass ich das easy über eine Trigger Node machen würde, aber das scheint wohl nicht so angekommen zu sein.
Ich finde solche Zeitstempel in einer Tabelle eher störend und würde Überwachung eher trennen. Außerdem hast du mir doch erzählt, dass der availabilty Datenpunkt zuverlässig ist. Wie gesagt was ich von solchen Pollerei Ansätzen halte, hab ich glaub schon mehrfach gesagt, aber es ist Dein System. Man kann auch jede Minute zum Fenster rausschauen, um zu überprüfen, ob es noch Tag oder Nacht ist oder man verlässt sich halt darauf, dass die Astrozeiten einen triggers, dass es jetzt hell wird.
-
Naja, ich kontrolliere leider lieber viel zu viel, als mich nur auf etwas "passives" zu verlassen - zumindest zu Anfang :D.
Aber ja, das mit der Trigger Node zu machen, macht wahrscheinlich deeeeutlich mehr Sinn.
Ich müsste da dann vermutlich 18 Trigger Nodes nutzen, oder kann man mit einem Trick über einen Trigger alle 18 prüfen (denke nicht, da der Trigger ja dann 18 Verzögerungen bräuchte)? -
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Naja, ich kontrolliere leider lieber viel zu viel, als mich nur auf etwas "passives" zu verlassen - zumindest zu Anfang :D.
Aber ja, das mit der Trigger Node zu machen, macht wahrscheinlich deeeeutlich mehr Sinn.
Ich müsste da dann vermutlich 18 Trigger Nodes nutzen, oder kann man mit einem Trick über einen Trigger alle 18 prüfen (denke nicht, da der Trigger ja dann 18 Verzögerungen bräuchte)?Du solltest Dich lieber mal mit der Genialität dieser Node befassen:
Alleine mal was diese Option bedeutet
sollte Dich zum Überlegen bringen, was das bedeutet.Alleine Deine Aussage:
In meinem Kopf sieht das dann nämlich so aus, dass für 18 Werte permanent der Timestamp mit der aktuellen Uhrzeit abgeglichen wird, und wenn eine bestimmte Differenz ermittelt wird, verändere ich die Tabelle und mache ein Feld rot.
müssten eigentlich für Dich zu Recht ein Hinweis darauf sein, dass das Unsinn ist. Am Besten machst Du dann solche ein Prüfung noch sekündlich, für eine Ereignis, was vielleicht alle 1-2 Jahre mal auftritt
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Naja, ich kontrolliere leider lieber viel zu viel, als mich nur auf etwas "passives" zu verlassen - zumindest zu Anfang :D.
Aber ja, das mit der Trigger Node zu machen, macht wahrscheinlich deeeeutlich mehr Sinn.
Ich müsste da dann vermutlich 18 Trigger Nodes nutzen, oder kann man mit einem Trick über einen Trigger alle 18 prüfen (denke nicht, da der Trigger ja dann 18 Verzögerungen bräuchte)?Du solltest Dich lieber mal mit der Genialität dieser Node befassen:
Alleine mal was diese Option bedeutet
sollte Dich zum Überlegen bringen, was das bedeutet.Da hab ich mir die Node tatsächlich nicht ordentlich angeschaut - da ist ja der "Trick"
Alleine Deine Aussage:
In meinem Kopf sieht das dann nämlich so aus, dass für 18 Werte permanent der Timestamp mit der aktuellen Uhrzeit abgeglichen wird, und wenn eine bestimmte Differenz ermittelt wird, verändere ich die Tabelle und mache ein Feld rot.
müssten eigentlich für Dich zu Recht ein Hinweis darauf sein, dass das Unsinn ist. Am Besten machst Du dann solche ein Prüfung noch sekündlich, für eine Ereignis, was vielleicht alle 1-2 Jahre mal auftritt
Dass das eine schlechte Idee ist, darauf kam ich ja auch selbst. Sind ja alles erst mal nur Gedanken.
Alles was ich in NR mache direkt zu perfektionieren ist natürlich sinnvoll, aber nicht mein Primärziel.
Im April bin ich aus der Wohnung hier raus, bis dahin sehe ich NR und allgemein mein aktuelles SmartHome als kleine Spielwiese um zu experimentieren und zu sehen, was alles geht. Je nachdem was nach April mein neues Zuhause wird, muss ich sowieso ggfs. die Hälfte rausschmeißen weil Räume wegfallen, sich ändern usw.
Und dass die Sensoren nur alle 1-2 Jahre mal keinen Wert liefern wäre schön - ist aber falsch^^
Die Wohnung ist ziemlich weitläufig, mein Raspi mit dem Conbee Stick etwa in der Mitte der Wohnung. Es kommt schon ab und zu vor, dass mal ein Sensor keine Werte mehr liefert. Ende Dezember kommen meine Zigbee Plugs, die dann hoffentlich mein Zigbee Netzwerk deutlich boosten (weil Repeater).
Abgesehen davon wird bei 9 Sensoren irgendwann demnächst die Batterie aussteigenNur mal als Beispiel: Mein PC steht im Büro direkt an der Wand zum Gästezimmer.
Wenn ich mit dem Bluetooth Headset ins Gästezimmer gehe, und mich am anderen Ende des Gästezimmers runterbeuge, verliert das Headset die Verbindung. Das sind keine 2 Meter Luftlinie und nur eine Wand (und nein, es liegt nicht am Headset oder BT Dongle, sondern an den Wänden)^^ -
@schmetterfliege Na ja - ich habe Dir ja nun oft genug gesagt, was ich von Zeitstempeln und deren Überprüfung halte - aber ich denke DU beschäftigst Du nun schon lange genug mit dem System, dass Du ja solche Dinge nun selbst überprüfen kannst. Vielleicht hilft Dir ja mein neuester Thread: https://forum.iobroker.net/topic/50086/datum-und-zeitverarbeitung-mit-nodered
wenn Du Dich so gerne mit Zeitstempeln beschäftigen willst.
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Na ja - ich habe Dir ja nun oft genug gesagt, was ich von Zeitstempeln und deren Überprüfung halte - aber ich denke DU beschäftigst Du nun schon lange genug mit dem System, dass Du ja solche Dinge nun selbst überprüfen kannst. Vielleicht hilft Dir ja mein neuester Thread: https://forum.iobroker.net/topic/50086/datum-und-zeitverarbeitung-mit-nodered
wenn Du Dich so gerne mit Zeitstempeln beschäftigen willst.Genau über den Thread kam ich ja darauf zu schauen was ich mit den Timestamps bei mir so anstellen kann :D.
U.a. eben sie mir in der Tabelle anzuzeigen, damit ich schonmal etwas habe mit dem ich nachvollziehen kann, von wann die Werte in der Tabelle sind.
Sinn oder Unsinn ist da bei mir wie gesagt erstmal Wurst. Das Einzige was ich nicht möchte, ist NR wieder ständig zu crashen weil ich zb. meine Hue Steuerung in NR in dutzende endless loops verwandelt habe die erst NR crashen und beim Neustart instant sämtliche Lichter in allen Räumen einschalten - Nachts um halb 4...
Sachen wieder rauszunehmen wenn ich damit gespielt habe ist ja nicht die Schwierigkeit
-
Hi @mickym
sorry dass ich nochmal störe
Ich überarbeite nach und nach meine Tabelle und möchte nun den tatsächlichen Raumnamen mit anzeigen.
Das Problem ist folgendes:
Der Raumname wird bei jedem Device unter "enums" gespeichert, allerdings nicht direkt als Wert sondern nochmal als Datenpunkt in dem auch der Raumname drin steht.
Kennst du eine Möglichkeit wie ich direkt an den Wert (in dem Fall "Flur 1") rankomme, ohne explizit zb. "enum.rooms.flur_1" angeben zu müssen? (sonst brauche ich ja 18 Funktionen die jeweils den entsprechenden Datenpunkt auslesen, da der ja bei jedem einzelnen Device anders aussieht)
Die Flow Objekte sehen wenn ich nur "enums" zuweise logischerweiße so aus:
Ich hoffe es ist einigermaßen verständlich was ich meine^^
-
@schmetterfliege
Nun es ist kein Datenpunkt, sondern ein Objekt unter enums. Das Problem ist durch eine split Node sehr einfach zu lösen. Das Problem ist eher, dass Du theoretisch ja einem Objekt mehrere Räume zuweisen kannst. Ich habs nun wie im admin5 gelöst und die Räume mal dann in einem kombinierten Strings aufzulisten.
Ein weiteres Problem ist, dass das enums Projekt ja nicht nur Räume als Aufzählungen enthält, sondern auch Funktionen oder selbst definierte Aufzählungen. Ich habe deshalb mal alle enum.rooms mit einer switch Node rausgefiltert:Damit kannst Du dann im Flow Kontext Deine Tabelle neben den Namen auch noch mit den Räumen initialisieren. Muss man halt noch mal eine Function Node bemühen und ggf. die bereits vorhandene Variable nochmal auslesen:
Also einfach nochmal diese 4 Nodes dazwischen (also zwischen die function Node, die die Namen schreibt und der Trigger Node) klemmen:
wichtig ist, dass das Topic erhalten bleibt also in der split Node nicht das Topic überschreiben. Ansonsten bekommst Du die Raumnamen nun direkt in der payload und musst wie gesagt nur prüfen, ob ggf. schon ein Raum gesetzt wurde. Die function Node ist deshalb leicht modifiziert, aber nicht kompliziert:
var rooms = flow.get('zigbee.' + msg.topic + '.rooms'); if (rooms === undefined) rooms = msg.payload; else rooms = rooms + ', '+ msg.payload; flow.set('zigbee.' + msg.topic + '.rooms',rooms); return msg; -
Du bist in der Tat ein Meister dieses Fachs!
Hat wunderbar funktioniert, und ich habe es (glaube ich!) auch verstanden wie das funktioniert
Nur ein kleiner Punkt:
Durch die if Abfrage in der Function Node hat es bei mir den Raumnamen immer wieder hinzugefügt, obwohl der schon existiert hat. Und zwar jedes Mal, wenn ich die Tabelle nochmal manuell initialisiert habe.
Beim ersten Ausführen war "rooms: Küche", beim zweiten dann "rooms: Küche, Küche" und so weiter.
Ich habe also diesen Teil:if (rooms === undefined) rooms = msg.payload; else rooms = rooms + ', '+ msg.payload;durch das hier ersetzt:
rooms = msg.payload;Also einfach rooms fix gesetzt und if sowie den else Teil rausgenommen.
Die ganzen Multisensoren die ich in der Tabelle anzeigen möchte sind alle auch nur einem einzigen Raum zugewiesen.
Daher aus reinem Interesse: welchen Sinn hat es, dass zb. dein Thermometer der Küche sowohl "Küche" als auch "Wohnung" zugeordnet ist? -
@schmetterfliege das ist ja auch nur für die erstmalige Initialisierung gedacht - deswegen ist das ja auch im Namensstrang. Eventuell hättest Du einfach Deine Flow Variable löschen sollen. Dieser Ast wird dann ja auch nur 1 mal nach NR Start ausgeführt. Wenn da 2 mal Küche Küche drin steht, dann passt was am Flow nicht..
-
Okay, ja dann ist das wirklich ein selbstgemachtes Problem
Dann lasse ich es - solange ich am basteln bin - noch ohne die if Abfrage.Ich bin nämlich gerade fleißig am Triggern verschiedener Äste um meine Änderungen direkt in der Tabelle anzuschauen und möchte nicht jedes Mal erst die Variablen löschen^^
Aber dann füge ich das wieder hinzu sobald ich es nicht ständig wieder trigger
Die Sache mit den 2 Zuordnungen in enums würde mich dennoch interessieren, ob das einen tieferen Sinn hat sowohl den Raum als auch die Wohnung anzugeben :D.
-
Hier mal mein aktueller Flow:
(Ich hoffe ich crashe jetzt nicht das Forum, mein browser hängt nämlich brutal wenn ich das hier paste^^)
Und so sieht die Tabelle aktuell aus:
Selbstverständlich alles in einem experimentellen Status!
Farben werden noch angepasst, timestamps irgendwann entfernt, u.U. andere Werte noch mit angezeigt, "Auto" kommt whsl noch weg usw usf. -
Hier mal die function Node - da kannst die Initialisierung öfters aufrufen und das Teil checkt nun, ob der Raum schon erfasst wurde. Aller dings wenn man einen Raum wieder wegnimmt, sollte man das ganze wirklich neu initialisieren.
var rooms = flow.get('zigbee.' + msg.topic + '.rooms'); if (rooms === undefined) rooms = msg.payload; else { rooms = rooms.split(','); rooms = rooms.filter( (v) => (v != msg.payload)); rooms.push(msg.payload); rooms = rooms.toString(); } flow.set('zigbee.' + msg.topic + '.rooms',rooms); return msg;Manuelles Löschen einer Flow Variablen geht über ein Icon
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
Hier mal die function Node - da kannst die Initialisierung öfters aufrufen und das Teil checkt nun, ob der Raum schon erfasst wurde. Aller dings wenn man einen Raum wieder wegnimmt, sollte man das ganze wirklich neu initialisieren.
var rooms = flow.get('zigbee.' + msg.topic + '.rooms'); if (rooms === undefined) rooms = msg.payload; else { rooms = rooms.split(','); rooms = rooms.filter( (v) => (v != msg.payload)); rooms.push(msg.payload); rooms = rooms.toString(); } flow.set('zigbee.' + msg.topic + '.rooms',rooms); return msg;Merci!
Allerdings stelle ich mir immer noch die Frage, weshalb ich ein Gerät 2 Räumen zuweisen sollte? Weil nur dann macht es ja auch Sinn diese Abfrage mit einzubauen, oder? -
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Merci!
Allerdings stelle ich mir immer noch die Frage, weshalb ich ein Gerät 2 Räumen zuweisen sollte? Weil nur dann macht es ja auch Sinn diese Abfrage mit einzubauen, oder?Da hast Du Recht - ich hab deshalb mal Küche und Wohnung als Beispiel genommen. Theoretisch könnte man jedem Teil als Raum zusätzlich noch Etagen etc. hinzufügen. Ob das Sinn macht oder schön ist, ist eine andere Frage, ich mache das auch nicht.
Trotzdem bin ich halt ein Freund davon, solche Situation abzufangen - sonst gibts irgendwelche Seiteneffekte später, wenn man mal nicht mehr dran denkt. In dem Fall nicht - aber Du siehst ja was bei Deinen HUE Nodes passiert - da treten einfach Situationen auf, an die evtl. niemand mehr gedacht hat.
Das Problem ist also eher, dass der iobroker es zulässt mehrere Räume einem Datenpunkt zuzuordnen und nicht ob es Sinn macht.
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Merci!
Allerdings stelle ich mir immer noch die Frage, weshalb ich ein Gerät 2 Räumen zuweisen sollte? Weil nur dann macht es ja auch Sinn diese Abfrage mit einzubauen, oder?Da hast Du Recht - ich hab deshalb mal Küche und Wohnung als Beispiel genommen. Theoretisch könnte man jedem Teil als Raum zusätzlich noch Etagen etc. hinzufügen. Ob das Sinn macht oder schön ist, ist eine andere Frage, ich mache das auch nicht.
Trotzdem bin ich halt ein Freund davon, solche Situation abzufangen - sonst gibts irgendwelche Seiteneffekte später, wenn man mal nicht mehr dran denkt. In dem Fall nicht - aber Du siehst ja was bei Deinen HUE Nodes passiert - da treten einfach Situationen auf, an die evtl. niemand mehr gedacht hat.
Das Problem ist also eher, dass der iobroker es zulässt mehrere Räume einem Datenpunkt zuzuordnen und nicht ob es Sinn macht.
Stimmt, valider Punkt!
Die Raumzuordnung ist allgemein ein wenig unglücklich implementiert.
Beispiel:
Anfangs hatte ich nur die Devices selbst einem Raum zugeordnet. Bis ich dann mal angefangen habe mit InfluxDB ein paar Sachen zu loggen und dann mit Echarts zu spielen.
Da kann man dann auch alles was man loggt in der Liste nach Räumen sortieren:
Aber: die einzelnen Datenpunkte sind gar nicht den Räumen zugeordnet, sondern nur das Device selbst.
Deshalb bin ich hingegangen und hab angefangen alle DP nochmal separat in die Räume gezogen.
Sieht dann ungefähr so in den Aufzählungen aus:
Mein Gott war das ätzend^^ Hab dann irgendwann aufgehört und nur noch das was ich loggen will in die Räume gezogen.
Im ersten screenshot sind die DP die den Raum "ausgegraut" haben nicht wirklich dem Raum zugeordnet, auch wenn der da dran steht. -
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Aber: die einzelnen Datenpunkte sind gar nicht den Räumen zugeordnet, sondern nur das Device selbst.
Deshalb bin ich hingegangen und hab angefangen alle DP nochmal separat in die Räume gezogen.
Sieht dann ungefähr so in den Aufzählungen aus:Das muss aber nicht. Normalerweise werden die Raum und Funktionszuordnungen des Gerätes auf die Datenpunkte vererbt und das scheint auch zu funktionieren:
Ich sehe eher umgekehrt das Problem, dass ich die Vererbung nicht aussetzen kann. Wenn ich bei diesen Multifunktionssensoren beim Gerät Funktionen Feuchtigkeit und Temperatur definiere - kann ich dann beim Datenpunkt humidity - die Temperatur nicht abwählen.
Aber wie gesagt eine Zuordnung der DAtenpunkte unter einem Device zu einem Raum ist nicht erforderlich.
Ich denke, dass es dann eher ein Problem des Influx Adapters war oder ist.
