batterieliste werte vergleichen und mit telegram ausgeben
-
@mickym sagte in batterieliste werte vergleichen und mit telegram ausgeben:
Bei der Gelegenheit noch ein Wort zu den enums - im iobroker. Das wird von Node-Red Adapter des iobrokers nicht unterstützt - da sind Blockly Fans im Vorteil . Insbesondere ist es bedauerlich, da man sie nicht als subscriptions nutzen kann - also generell dynamische subscriptions.
Du kannst die enum mit der ioB-List-node auslesen.
Hier mal 2 meiner Listen, die davon Gebrauch machen:
Hier das Prinzip
Das enum wird dann mit einem simplen JSONata - Ausdruck gelesen. Hier mal für die Etage:
$lookup(payload.enums, payload.enums.$sift(function($v, $k) {$k ~> /^enum.ort./}).$keys()[0])Eigentlich sollte einem Device ja nur ein Ort zugewiesen sein, aber zur Sicherheit nehme ich hier immer den ersten hinterlegten [0].
Gruß
Reiner -
@rewenode Na ich hab in den state objekten keine enums gefunden, sondern nur im common objekt der enums.
Nehmen wir dieses Folder Objekt:
In dem Objekt gibts absolut NICHTS - und somit auch nichts für die List Node zum Auslesen. Gilt auch für alle Objekte unter dem Folder.
{ "type": "folder", "common": { "name": "shelly1-C4328A" }, "from": "system.adapter.javascript.0", "user": "system.user.admin", "ts": 1628370786300, "_id": "mqtt.1.shellies.shelly1-C4328A", "acl": { "object": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }Das Einzige wo die Räume sind ist in den Enums-Objekten:
Damit könnte ich zwar aus dem Objekt die members auslesen - aber das geht mit der list Node nicht.
{ "_id": "enum.rooms.bedroom", "common": { "name": "Schlafzimmer", "members": [ "alias.0.schalter.sz_bettlampe_links", "alias.0.schalter.sz_bettlampe_rechts", "alias.0.schalter.sz_lichtschalter_schrankbeleuchtung", "alias.0.schalter.sz_schrankbeleuchtung", "alias.0.schalter.sz_steckdosendreifach", "alias.0.schalter.sz_tischlampe", "alias.0.schalter.sz_usb4fach" ], "icon": "", "color": "#37e46b" }, "type": "enum", "acl": { "object": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" }, "from": "system.adapter.admin.0", "user": "system.user.admin", "ts": 1638823013488 }Ich bekomm da nichts raus:
Mag sein, dass du den Devices Adapter nutzt - dann mag das anders sein, da dieser ja Aliases anlegt - aber bei den native Objekten scheint das nicht zu gehen.
-
@mickym Hier mal ein simpler Versuchsflow :
Das abonnierte Object ist ein Alias, kannst du also leicht nachbauen.
Es ist hier dem enum.ort.eg zugeornet.
Gruß
Reiner -
@mickym sagte in batterieliste werte vergleichen und mit telegram ausgeben:
Mag sein, dass du den Devices Adapter nutzt - dann mag das anders sein, da dieser ja Aliases anlegt - aber bei den native Objekten scheint das nicht zu gehen.
Keinen Device Adapter. Im Falle der Fensterliste sind das Aliase, die auf HM-Adapter verweisen.
Im Falle der Batterieliste sind das native Zigbee-Devices ohne Alias. Da macht ein Alias ja auch nicht unbedingt Sinn. Die Batterie hängt ha nicht an einem virtuellen device.
Gruß
Reiner -
@rewenode OK - Du hast Recht -
... aber wie gesagt ich halte das für sehr umständlich ausser man macht sich damit eigene Listen - wie gesagt die "Pollerei" finde ich aus Prinzip nicht gut.
Also es funktioniert - aber alle Objekte durchsuchen ist einfach in diesem Fall ungeeignet.
In anderen Fällen, so wie Du es beschreibst, dass Du schon über die In-Node triggerst und dann über das Objekt die Funktion ermittelst ist OK.
Aber wichtig wäre ja - wenn man mit den Enums triggern kann und das geht halt nicht. Sondern man triggert nur über die normalen Pfade auf states.
Ist schon klar, dass Du mit der Methode dann alle Objekte durchsuchen kannst und die Enum Listen wieder rekonstruierst - was in meinen Augen aber sehr umständlich ist. Wenn Du dann alle Objekte, die mit der gefragten Funktion matchen in ein Array gespeichert hast, dann kannst Du alles wieder auslesen - aber ist halt wieder Pollerei.
Was ich mit dem github Enhancement erreichen wollte ist, das man quasi mit
enum.function.battery - automatisch subscription listen erstellt. - Das können die neunen mqtt-Nodes unter mqtt v5 - wo du immer mehr subscriptions addieren kannst.
-
@mickym sagte in batterieliste werte vergleichen und mit telegram ausgeben:
"Pollerei" finde ich aus Prinzip nicht gut.
Also, ich habe genau einen State abboniert und lese auch nur das eine Objekt.
Ich bin mir auch nicht sicher, ob es viel schnelle wäre, state+object+enum im ioB zu lesen, zu kombinieren und an NR zu schicken. Sicher wäre es einfacher, wenn state und object wenigstens auf Wunsch als Einheit zu abbonieren wären.
Aber sonderlich kompliziert ist das nicht. Die Listen müssen ja ohnehin (i.d.R. per JSONata) aufbereitet werden.Gruß
Reiner -
@rewenode Nee - was ich meine - und das wäre das optimale wenn man in den iobroker-In Nodes enums angeben könnte.
In JS geht das auch: https://github.com/ioBroker/ioBroker.javascript/blob/master/docs/en/javascript.md#on---subscribe-on-changes-or-updates-of-some-state
-
Also, ich habe genau einen State abonniert und lese auch nur das eine Objekt.
Das ist aber das Problem - gerade wenn man nicht pollen will - dann sollen ja theoretisch nicht ein bestimmter State triggern. Das kann ich das wieder mit Wildcards machen - aber dann brauch ich das Enum entweder nicht analysieren oder ist einfach dummer Aufwand. Ich verstehe einfach nicht, warum man die ENUM Objekte nicht direkt mit der List Node auslesen kann.
-
@mickym sagte in batterieliste werte vergleichen und mit telegram ausgeben:
dann sollen ja theoretisch nicht ein bestimmter State triggern. Das kann ich das wieder mit Wildcards machen - aber dann brauch ich das Enum entweder nicht analysieren oder ist einfach dummer Aufwand.
Hast ja recht. Aber ich bin schonmal froh, dass ich mit vertretbarem Aufwand improvisieren kann.
-
@rewenode Und Du hast ja auch Recht
- ich hab es wieder vergessen, dass bei den List-Node Abfragen die Enums mit dabei sind. - Hatte ich zwar schon mal in anderem Zusammenhang festgestellt - aber war mir wieder entfallen.Ich hab das ja hier selbst in einem Flow angewendet: https://forum.iobroker.net/topic/50161/verfügbarkeit-von-sensoren-über-node-red-überwachen/45?_=1663374414159
Für die batteriebetrieben Devices ist in meinen Augen neben des Batterielevels die Überprüfung der Verfügbarkeit bzw. über das Pollen der Adapter den online Status zu überwachen unentbehrlich.
-
@mickym said in batterieliste werte vergleichen und mit telegram ausgeben:
Die Geräte melden sich wie gesagt selbst und wenn ich dauernd einen Datenpunkt abfrage, der von einem Gerät gar nicht aktiv gemeldet wird - dann ist das eh sinnlos. Sprich wenn der Datenpunkt im Zigbee- Adapter für das Batterielevel auf 80% steht und das Gerät die Verbindung zum iobroker verloren hat, dann steht da nach 10 Jahren immer noch 80% - da das Gerät diesen Wert nie aktualisiert hat. 10 Jahre unnütze Abfragen mit sinnlosen Ergebnissen. Hört auf zu pollen und wartet bis die Geräte sich melden!!!!
Hello,
ok, jetzt verstehe ich auch warum alle immer nur auf change gehen...klar wenn man es so sieht.im Prinzip gibt es fertige Blockly zum nachbauen die genau auf change state beruhen.
Da ich einige Sensoren verwende auf esp32 basis ist fuer mich wie du beschreibst mqtt der gemeinsame NENNER, dh. ich koennte auch diesen als letzten Status speicher verwenden.
Danke fuer Eure vielen Antworten, ich muss sagen die komplizierten Dinge lohnen sich fuer meinen Zweck nicht(lernen dauert ), ich benutzte eine vis Seite wo ich die Zustaende sowieso sehe
Eigentlich wollte ich mich nur mit Telegram beschaeftigen
