batterieliste werte vergleichen und mit telegram ausgeben
-
Hi,
ich komme mit blockly nicht zurecht und eher noch mit node red (Generation die noch Maschinensprache programmiert hat)Ich habe eine Liste erstellt und wuerde gerne nach schedule die werte der Liste durchlaufen und falls kleiner als wert x in Telegram das Geraet (die id) mir zuschicken.
Habt ihr hier ein paar Tipps fuer mich , ein Tutorial oder ein Video?
Vielen Dank. -
@fred-freund Na wenn Liste ist Array oder Objekt - dann einfach split Node nutzen? NodeRed ist auch intuitiver, da man nicht soviel Zeit mit Puzzeln verdaddelt - auch wenn ich die Generation gleich nach der Maschinensprache bin.
-
@mickym @mickym Hallo und Danke, ja muss erst mit dem iobroker listobject zurechtkommen.
also so einfach loopen durch das array tut das nicht
ich denke ich haette sollen irgendwie Aliases anlegen, muesste wenn ich weiss Batterie von xxx ist leer nach der ID suchen was das ist.
waere cool wenn man den ganzen IBROKER durchsuchen koennte und diese dann ausgeben..aber way over my knowledge
Scheint es wird ein groesseres Projekt fuer mich! -
@fred-freund vergiss das. Mit den enum Geschichten kannst unter NodeRed eh nichts anfangen und sowas liest man in meinen Augen nicht aus dem System, sondern läßt die Geräte triggern. Zudem bieten auch nicht alle Geräte das gleiche Format in Form von Prozentwerten, manche gibts auch nur mit true oder falls. Also vergiß enum und Werte auslesen, sondern lass die Geräte triggern.
Falls es sich um die Zigbee und Z-Wave Geräte handelt, langen dann doch 2 iobroker in nodes und eine Switch Node und die Sache ist gelöst. Wenn wirklich dann kannst auch über die list nodes aktiv auslesen, aber ich finde das überflüssig, weil Batterien wenn die Warnschwelle überschritten ist, ja nicht gleich den Geist aufgeben. Zumindest wenn die Warnschwelle richtig gesetzt ist..
Enum kannst du aber unter node Red vergessen.
-
@mickym ok Danke!! dh. ich werde eine schedule triggern und dann die einzeln abfragen , so viele sind es ja nicht.
ich nehme an das meinst du mit2 iobroker in nodes und eine Switch Node und die Sache ist gelöstja einfacher so....genial und gleichzeitig kann man true false auch checken
welches plugin fuer Telegram soll man verwenden?
Das trifft sich gut , moechte auch meine security cameras die manchmal die Verbindung verlieren checken denke da gibt es einen active status irgendwo.
Hoffe der telgram adapter laesst sich je nachdem die message uebergeben.
Danke nochmal ...viel viel einfacher
-
@fred-freund Nein - wie gesagt ich würde die Geräte selbst triggern lassen - Du musst doch nichts aktiv abfragen - auch wenn es zum Testen erstmal schwerer fällt.
Wenn es exakt diese Geräte sind, würde ich nur iobrokerIN Nodes verwenden.
Größer 10% interessiert Dich ja nicht. Das topic musst halt mit einer ChangeNode in lesbare Geräte übersetzen -
alternativ kannst auch jetzt ein list Node verwenden und dann das Objekt mit dem Namen auslesen.
... nächsten Post für die Ausgabeseite.
-
Kommen wir nun zur Ausgabenseite - der Wert interessiert - des batterylevels würde mich ggf. nur am Rande interessieren - aber musst Du wissen - wichtig ist jedoch, dass nun in der msg.topic das Gerät mehr oder weniger im Klartext steht.
Muss aber vorausschicken, dass ich selbst kein telegram benutze.
Für die Telegram Ausgabe stehen Dir nun folgende Optionen zur Verfügung:
-
Wenn Du den telegram Adapter nicht bereits im Einsatz hast, würde ich mir überlegen, ob ich die telegram Ausgabe nicht weiter NodeRed überlassen würde.
https://flows.nodered.org/node/node-red-contrib-telegrambot -
Wenn Du den Telegram Adapter im iobroker bereits im Einsatz hast und ggf. auch anderweitig in Blocklies verwendest, dann hast nach Dokumentation des Adapters folgende Möglichkeit:
Um den Flow also für einfache Nachrichten weiterzuführen, würde ich mal bei dem Beispiel mit dem manuellen Übersetzen der Topic so verfahren:
Kompliziertere Optionen kann man über Node-Red wohl über ein JSON Objekt an an
telegram.0.communicate.responseJsonübergeben. Da kann man dann wohl auch formatieren etc. Vor dem Senden dann halt noch eine JSON Node machen.
- Option wenn man den iobroker Adapter nutzen will und die Möglichkeiten unter Punkt 2 nicht ausreichen. NodeRed kann nicht mit SendTo was an einen anderen Adapter schicken. Ich habe aber so eine kleines JS als Proxy geschrieben.
Dieser Thread enthält ein kleines JS Script, so dass man über Node-Red über einen Selbsterstellten Datenpunkt quasi als Proxy die SendTo Funktion nutzen kann.
Standardmässig hört das Script auf den Datenpunkt "0_userdata.0.NodeRed.sendTo" kann aber im Script natürlich geändert werden.
var exchangeWithNodeRed = "0_userdata.0.NodeRed.sendTo";In diesem Datenpunkt - kannst Du ein Objekt aus NodeRed mit anschließender JSON Node reinschreiben, wo Du die Parameter mitgeben kannst und ggf. einen eigenen Datenpunkt für eine Antwort - ansonsten wird der Datenpunkt mit dem Objekt auch als Rückgabe verwendet.
Wenn Du also via NodeRed - sowas über SendTo an den Adapter schicken wolltest:
Dann könntest Du zum Beispiel so ein Objekt konstruieren:
über JSONATA in der Change Node natürlich auch mit variablen aus dem Nachrichtenobjekt füttern. Das habe ich allerdings noch nie gemacht - da ich wie gesagt kein telegram Adapter bzw. telegram überhaupt benutze,
-
-
@fred-freund sagte in batterieliste werte vergleichen und mit telegram ausgeben:
@mickym ok Danke!! dh. ich werde eine schedule triggern und dann die einzeln abfragen , so viele sind es ja nicht.
ich nehme an das meinst du mitWie gesagt - pollen finde ich in der iot Welt - das Schlechteste was man tun kann. Auch wenn Du nicht immer sofort Ergebnisse hast dann warte halt bis sich die Geräte melden.
Es belastet die Systeme mit unnützen Abfragen. Wenn eine Batterie nach 2 Jahren einen zu niedrigen Level hat und dass vielleicht noch im Minutentakt - weil man die Batterie dann auch sofort innerhalb einer Minute auswechselt
, hat man 2 Jahre diesen Datenpunkt umsonst abgefragt - denkt einfach mal bissi "wirtschaftlich" wie man mit Systemressourcen umgeht. 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!!!! 
Was ich mache - ist, dass ich mit den letzten Status einfach in einem Datenpunkt in JSON abspeichere - so dass ich die immer parat habe.
{ "Präsenz Wohnzimmer": true, "Thermometer Gefrierfach": true, "Thermometer Küche": true, "Präsenz Schlafzimmer2": true, "Schlafzimmer Schrank Links": true, "Schlafzimmer Schrank Mitte": true, "Würfel Wohnzimmer": true, "Präsenz Küche": true, "Präsenz Büro": true, "Präsenz Diele": true, "Präsenz Flur": true, "Präsenz Schlafzimmer": true, "Würfel Büro": true, "Präsenz Bad": true, "Thermometer Kühlschrank": true, "Schlafzimmer Schrank Rechts": true, "Thermometer Bad": true, "Würfel Schlafzimmer": true, "Präsenz Wohnzimmer Essbereich": true }Das kann ich dann leicht bei Adapterstart einmal abfragen - so dass ich nicht warten muss und wird dann von den Geräten einzeln bei Bedarf aktualisisert.
-
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.
Man kann dann entweder über mqtt ausweichen - oder Leute dann fragt das halt besser nach.
Ich habe hierzu seit Oktober 2021 ein enhancement request aufgemacht: https://github.com/ioBroker/ioBroker.node-red/issues/224
Da gibts hier von der iobroker- community 0 response - keinen Daumen hoch oder sonst was.
Als Entwickler würde ich mir auch denken, warum soll ich da Aufwand reinstecken, wenn es eh keiner will.Die enum Datenpunkte sind leider für NodeRed nicht zugänglich. Insofern kann man auch nichts mit der list Node machen.
-
@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
