Verfügbarkeit von Sensoren über Node Red überwachen
-
@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.
-
@mickym
Stimmt, das scheint echt ein Problem von InfluxDB zu sein:
Ich sehe ja dass die Räume vererbt wurden.
Ich schätze mal dass InfluxDB nicht die "Räume" anschaut, sondern die Auflistungen von Iobroker durchgeht.
Und da dürften in deinem Fall nur die Devices drin stehen, nicht aber die einzelnen Datenpunkte.
Doofes Influx! :D.Wie hast du es eigentlich geschafft die Funktionen in enums zuzuweisen? Ist das auch ein Aqara Sensor?
Bei mir ist die einzige Funktion die ich bei so ziemlich allen Objekten habe "color" (was auch immer das sein soll?!)- und die ist default nicht aktiv:
Entsprechend ist in meinen enums auch wirklich nur der Raum den ich zugewiesen habe drin.
-
@schmetterfliege Ja sind auch Aqara Sensoren
Die Funktionen ordnest Du doch einfach über die nächste Spalte zu:
-
Oh man, mir wird erst gerade bewusst dass "Funktionen" ebenfalls eine Aufzählung wie Räume sind die man manuell definiert:
Aber ich glaube ich lasse da zur Sicherheit erst mal die Finger von weg.
Wäre zwar verlockend da jetzt Zeit zu investieren, aber damit fange ich mal lieber nicht morgens um 5 an :D.Edit: "Color" habe ich aber nicht angelegt oO
-
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
"Color" habe ich aber nicht angelegt oO
Das war wahrscheinlich einer der Core Entwickler des iobrokers. Kannst aber auch Löschen. Und nein Du musst das nicht nutzen. Ich finde die Funktionen in der Form eh nicht so dolle. Ausser im Admin kannst zumindest im NodeRed nicht danach filtern und geben Dir somit erst mal keinen Mehrwert.
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
"Color" habe ich aber nicht angelegt oO
Das war wahrscheinlich einer der Core Entwickler des iobrokers. Kannst aber auch Löschen. Und nein Du musst das nicht nutzen. Ich finde die Funktionen in der Form eh nicht so dolle. Ausser im Admin kannst zumindest im NodeRed nicht danach filtern und geben Dir somit erst mal keinen Mehrwert.
Danke!
Schade eigentlich dass die keinen Mehrwert liefern, andererseits wüsste ich nicht welchen Mehrwert es für mich hätte.
Mir fällt spontan kein DP ein bei dem nicht im "Name" schon die Funktion steckt (*.humidity). -
@schmetterfliege Na wäre doch toll, wenn man statt zigbee.0..humidity - mit function.humidity. alle Feuchtigkeitswerte bekäme egal von welchem Adapter. Aber wie gesagt, dass wird mit dem Design eher schwierig - außerdem ist der Admin5 mit seinen Prüfungen etc. eher eine Katastrophe als in meinen Augen ein Weg zu neuen Verbesserungen.
-
@mickym said in Verfügbarkeit von Sensoren über Node Red überwachen:
@schmetterfliege Na wäre doch toll, wenn man statt zigbee.0..humidity - mit function.humidity. alle Feuchtigkeitswerte bekäme egal von welchem Adapter. Aber wie gesagt, dass wird mit dem Design eher schwierig - außerdem ist der Admin5 mit seinen Prüfungen etc. eher eine Katastrophe als in meinen Augen ein Weg zu neuen Verbesserungen.
Ok das wäre echt genial. Manno!
Bezüglich "zigbee.0..humidity" werde ich bald blöd...
Wenn ich eine neue List Node setze und damit die Temp von allen Sensoren auslese, klappt das jetzt plötzlich.
Wenn ich aber eine vorhandene List node aus dem "Flow" für die Tabelle kopieren, und statt "zigbee.0." -> "zigbee.0.*.temperature" rein mache, bekomme ich gar keine Ausgabe...
Bin ich doof und sehe den Unterschied zwischen den beiden Nodes nicht?
EDIT: nevermind.. "Device" vs. "State"...
-
@schmetterfliege Weil Du im zweiten nach Device filterst. Im ersten State.
Und Temperatur ist kein Device sondern ein State. -
-
@schmetterfliege Jo schlaf gut.
-
Hi Micky,
Ich habe mir mal noch eine zweite Tabelle erstellt in der ich von allen Zigbee Devices die Verfügbarkeit und Voltage anzeige.
Funktioniert auch soweit, nur bekomme ich das mit den Farben für die Verfügbarkeit nicht wirklich hin.
Die Funktion welche die Tabelle "baut" sieht so aus:
In der Tabelle sieht das Ganze so aus:
Den Wert der Verfügbarkeit muss ich als String speichern, weil bei False ansonsten "0" angezeigt wird.
Was ich nicht verstehe: wieso ist der Hintergrund bei der Verfügbarkeit überall Grün? Wo nimmt er diese Farbe her?
Und wie schaffe ich es, dass bei "False" stattdessen Rot angezeigt wird? Habe einige Versuche gemacht, aber bekomme es nicht hin.
Wenn ich den Wert als boolean speicher, wird bei dem einen der nicht verfügbar ist wie gesagt "0" angezeigt und der Hintergrund ist Grau. Warum, weiß ich allerdings nicht (also wieso dann kein Hintergrund da ist).Hast du da eine Idee?
Edit: nur für den Fall dass du dich fragst wieso der nicht verfügbar ist wenn die Voltage so hoch ist: ich vermute ich habe den versehentlich mit einem Tradfri Device gepaired, weil der Motion Sensor direkt beim Zigbee Stick ist und man die Tradfri Dimmer paired indem man den beim pairen direkt an den Stick hält. Daher reportet der aktuell vermutlich nichts an den Stick, sondern fälschlicherweiße an einen der neu angelernten Dimmer. Muss den nur mal neu pairen, ist aber gerade gut um meine Tabelle testen zu können
-
@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:
Was ich nicht verstehe: wieso ist der Hintergrund bei der Verfügbarkeit überall Grün? Wo nimmt er diese Farbe her?
Und wie schaffe ich es, dass bei "False" stattdessen Rot angezeigt wird? Habe einige Versuche gemacht, aber bekomme es nicht hin.
Wenn ich den Wert als boolean speicher, wird bei dem einen der nicht verfügbar ist wie gesagt "0" angezeigt und der Hintergrund ist Grau. Warum, weiß ich allerdings nicht (also wieso dann kein Hintergrund da ist).
Hast du da eine Idee?Nun ich habe mich nich nicht in der Tiefe damit beschäftigt - aber für True/False finde ich einen Fortschrittsbalken als denkbar ungeeignet. Und das bei False dann 0 rauskommt und Grau ist auch richtig - weil es sich um einen Fortschrittsbalken handelt.
Nachdem Du keine Farbe für den Fortschrittsbalken angegeben hast, ist es auch richtig dass er dann default nimmt.
Prüf mal den Color Picker - das Grün entspricht genau dem Default: #2DC214
Wie gesagt, ich würde für true und false was anderes nehmen - wahrscheinlich ein Icon oder so - muss mal sehen. Wie gesagt ich hab mich damit noch nicht in der Tiefe beschäftigt, aber ein Fortschrittsbalken für true/false halte ich für denkbar ungeeignet. Hier übrigens mal die Formate alle aufgelistet: http://tabulator.info/docs/4.4/format.
Das einfachste wäre wohl ein color formater indem Du true als green und false als red mit einer change Node übersetzt.
oder Du nimmst den HTML Formater um Text und Hintergrund darzustellen - dafür hab ich kein Beispiel gefunden - aber das Thermostat Beispiel hat ja auch funktionen - die anscheinend HTML Code ausspuken. An dem Beispiel werde ich aber selbst noch bissi rumprobieren, allerdings finde ich Deine Art über eine Function Node sehr unübersichtlich. Mit der Change NOde kann man das über den JSON Formatter viel schöner sehen.
