NEWS
Verfügbarkeit von Sensoren über Node Red überwachen
-
@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? -
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..
-
@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. -
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 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
-
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? -
@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. ;)
-
@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. -
@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.
-
@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.
-
@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:
-
@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
-
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.
-
@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). -
@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.
-
@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"...
-
@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 Weil Du im zweiten nach Device filterst. Im ersten State. ;) Und Temperatur ist kein Device sondern ein State.
-
Wird glaube ich Zeit für's Bettchen :dizzy_face:
Gut's Nächtle, und vielen Dank für all deinen Input! :)
@schmetterfliege Jo schlaf gut. :bed:
-
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 :)
557
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge