Array mit Objekten in iOBroker anlegen
-
Also ich habs mal aus Deinem schlechten Input gemacht was ich konnte.
Hier zeig ich Dir wie man es aus dem Debug Fenster kopiert:
und dann hier in CodeTags einstellt:
[{"id":"109","name":"Kontakt","state":"closed"},{"id":"110","name":"BW","state":"closed"}]So ist das ein vernünftiger Ausgangspunkt um Dir mit einer Inject Node - Deine Nutzdaten zu simulieren.
-
Also bitte für die Zukunft beachten - ansonsten hier die kleine Sache:
und hier der Flow:
und hier zum Import:
Wichtig ist dass Du im Adapter das Erstellen von Fremdobjekten zulässt.
-
Hey, vielen vielen Dank. Genau so funktioniert das! Nächstes mal werd ich dann auch besser posten, muss man ja nur wissen
Aber eine Frage hab ich noch. In einigen Namen sind Punkte enthalten. Zb. als Abkürzung (BW Fen. R.). Kann man das so einstellen, dass er die Punkte mit übernimmt. Derzeit hängt er sich dabei auf und schreibt dann auch den State nicht mehr. Leerzeichen werden übernommen, nur halt der Punkt nicht.
"0_userdata.0.Alarm." & payload.id & "." & payload.nameUm den payload.name geht es.
-
@hackypaddy nein Punkte musst du eliminieren. Das sind im iobroker zwingend Pfadbestandteile. Das hat nichts mit Node-Red zu tun. Am besten Du machst in der Anweisung unten in JSONATA noch eine Replacefunktion um payload.name und ersetzt Punkt gegen Unterstrich.
Alternativ belässt du es wie es ist mit Name und State. Ich persönlich fände das viel besser, weil du State und Name immer gleich ansprechen kannst, das hat einen großen Vorteil da man dann mit wildcards arbeiten kann. Deswegen finde ich deine Idee nicht so prickelnd die schöne Objektstruktur kaputt zu machen. Grundsätzlich sollte man auch keine Sonderzeichen in Namen machen - das ist schon vom Ansatz her falsch. Als wenn man schon Bewegungsmelder Fenster Rechts machen will - dann halt gleich BM_FensterRechts oder so. Aber wie gesagt - falls Du auf Deinen Namen beharrst - wäre kommender Vorschlag noch eine Alternative mit einigen Vorteilen. Über die ID ist das Gerät ja bereits eindeutig identifiziert und der Name kann ja dann kosmetisch schön bleiben.
-
Den Namen kann ich leider nicht ändern. Der wurde damals durch die Errichterfirma vergeben und ich komme da nicht ran.
Ich habe das jetzt aber so gelöst, dass ich den Punkt in ein Leerzeichen ersetzen lasse. Damit kann ich gut leben und nun funktioniert auch alles tadellos!
Könntest Du mir vielleicht noch bei einer anderen Problemstellung helfen? Geht da um sequenzielles abarbeiten der Statusabfragen.
Bin nur gerade unterwegs und auf dem Handy ist das doof zu schreiben. Würde ich dann später zuhause machen.
-
@hackypaddy Wie gesagt lass mich Dir noch einen Alternativvorschlag machen - dann kannst Du mit Wildcards alle States aufeinmal abfragen.
-
Gern, ich bin für alles offen
-
So, hier noch mein anderes Problem.
Leider muss ich für jeden Bereich den Status einzelnd abrufen. Es gibt 4 Bereiche.Bisher habe ich das so gelöst, dass ein Timestamp alle 90 Sek. auslöst und die Bereiche abfragt. Von dem Baustein werden dann auch zeitgleich 4x die Anforderung an die Alarm geschickt und die kommt damit aus der Puste.
Jetzt habe ich mir folgendes überlegt:
Ich würde gerne die Abfrage nacheinander machen. D.h. erst Status Bereich 1, dann Status Bereich 2, usw. Wenn er unten angekommen ist, soll er wieder von vorne anfangen.
Die Node gibt mir bei erfolg den Status "OK" aus. Bei einem Fehler, den Status "Error".
Wie kann ich das so bauen, dass er bei einem OK, die nächste Abfrage startet und bei einem Error ein paar Sekunden wartet und die Anfrage wiederholt?
Hier ein Auszug aus dem Node-Baustein:
.then(function (response) { finalmsg = response.data; node.status({ fill: "green", shape: "dot", text: "OK" }); if (command == "state") { finalmsg = finalmsg.state; node.status({ fill: "green", shape: "dot", text: "Partition " + partition + " : " + finalmsg, }); } msg.payload = finalmsg; node.send(msg); }) .catch(function (error) { node.status({ fill: "red", shape: "dot", text: "Error" }); }); -
- Erst will ich Dir noch was zu meinem Alternativvorschlag sagen.
- Kannst Du mir den Link zu der Node schicken bzw. wie würdest Du es anstellen die Bereiche einzeln abzufragen.
Ist das keine fertige Node, sondern eine function Node?
-
Ich verwende die hier:
https://github.com/yreiser/node-red-contrib-secvestDie hat einmal den Baustein für die Statusabfrage der Bereiche und einmal ein Command-Baustein zum setzen von Zuständen.
Ich brauche aber nur die Statusabfrage.
Der Baustein holt sich die Daten über eine https abfrage bei der Anlage und gibt dann ein array aus, wie wir das ja schon "zerstückelt" haben. Problem ist nur, das muss für jeden Bereich einzelnd erfolgen. Die Anlage gibt es nicht her, dass man 4 Bereiche auf einmal abfragt.
-
Dann kannst Du doch über die payload die Abfrage der unterschiedlichen Partitionen damit steuern?
Aber ich glaube nicht, dass Du dauern pollen sollst. Diese Status Node liefert Dir doch, wenn sich was ändert. Ich bin ein grundsätzlicher Gegner - Geräte abzufragen, wenn das schon eine Status Node macht.
-
Ne, ich eigentlich auch nicht.
Aber! Die liefert mir die Änderungen halt nicht. Es muss jedes mal der Bereich neu abgefragt werden, damit ich Änderungen an den Zonen mitbekomme. -
@hackypaddy OK - aber wie ich verstehe Du kannst über eine payload - einzelne "Partitionen" abfragen und Du das kannst Du ggf. zeitlich verzögert machen.
Wenn eine Abfrage fehlschlägt, bekommst Du das über die payload mit, die aus der Node rauskommt oder warum willst Du unbedingt den Status der Node verwenden (das geht auch - ist aber eher umständlich).
Damit sollte es ja möglich sein die "Partitionen" einzeln abzufragen.
-
Ja genau. Den Status "OK" oder "Error" hätte ich gerne bei der Sequenz.
Sprich ist der Status "OK", dann mit der nächsten Statusabfrage beginnen, usw.Ist der Status "Error", dann ein paar Sekunden warten und die gleiche Abfrage nochmal wiederholen.
Ich weiß nur nicht genau, wie ich die Sequenz anlege, dass er nacheinander alle Statusmeldungen abruft.
Ich hab mit Sequenzen noch nicht gearbeitet, mir fehlt da gerade die Logik hinter, wenn Du verstehst, was ich meine.
-
@hackypaddy Nochmal das ist nicht das Problem - aber anstelle des Status abzufragen - kommt denn bei einem Fehler als Ausgabe anstelle des Arrays oder der Daten eine Fehlermeldung raus oder einfach gar nichts? Wie gesagt den Fehler in der Ausgabenachricht zu haben, macht das wesentlich einfacher, als den Status der Node abzufragen.
-
Doch bei einem Fehler kommt eine Ausgabe, genau das ist das Problem. Ich kann dann nicht sehen, ob die Ausgabe "vollständig" ist oder nicht. Es ist immer ein array als Ausgabe. Bei einem Error fehlen aber teilweise Daten.
Deshalb wollte ich das mit dem node.status machen. Da kann ich mir sicher gehen, wenn "OK", dann ist die Abfrage zu 100% erfolgreich durchgelaufen.
Bei einem Error halt nicht.
-
@hackypaddy sagte in Array mit Objekten in iOBroker anlegen:
Doch bei einem Fehler kommt eine Ausgabe
Ja aber erkennt man an der Ausgabe - dass ein Fehler vorliegt?
OK wenn nicht dann müssen wir den Status nehmen. Aber ist nur die 2. beste Lösung. Wie lauten die einzelnen payloads mit den Du die 4 Partitionen einzeln abfragen kannst?
-
Nein das kann man nicht erkennen. Mal fehlt eine Zone komplett, bei nächsten Mal fehlt ein Status. Das alles zu prüfen ist purer Wahnsinn, zumal müsste dann auch alles wieder angepasst werden, wenn neue Zonen in dem Bereich dazu kommen.
Jetzt willst Du die Payloads wissen, ich habs mir gedacht
Ja, wo finde ich die...?Vom dem Baustein gehts direkt auf deine Auswertung, die Du mir zu Anfang geschickt hast und die speichert die Zustände dann im ioBroker.
Wie gesagt, ich brauche noch viel Input was Node Red betrifft. Sry.
-
@hackypaddy Hast Du denn zu der Node keinen Beispielflow gefunden mit dem Du einzelne Partitionen abfragen kannst?
-
Nein, es gibt zwar ein Beispiel. Aber das hat nichts damit zu tun.
Hier der Beispiel-Flow vom Entwickler.[ { "id": "9c44cf3001e5d6f2", "type": "tab", "label": "Secvest", "disabled": false, "info": "", "env": [] }, { "id": "fb9b7833467bb649", "type": "inject", "z": "9c44cf3001e5d6f2", "name": "", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "unset", "payloadType": "str", "x": 110, "y": 280, "wires": [ [ "139564743bb8b131" ] ] }, { "id": "90e82662da299ce2", "type": "Secvest Status", "z": "9c44cf3001e5d6f2", "name": "", "server": "67c1d8818c300c5c", "partition": "2", "command": "state", "x": 320, "y": 140, "wires": [ [ "4619a3617e5b649b" ] ] }, { "id": "139564743bb8b131", "type": "Secvest Command", "z": "9c44cf3001e5d6f2", "name": "", "server": "67c1d8818c300c5c", "partition": "3", "command": "payload", "x": 290, "y": 280, "wires": [ [ "9d1e4f9edf40cbab" ] ] }, { "id": "4619a3617e5b649b", "type": "debug", "z": "9c44cf3001e5d6f2", "name": "debug 6", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "false", "statusVal": "", "statusType": "auto", "x": 520, "y": 140, "wires": [] }, { "id": "9d1e4f9edf40cbab", "type": "debug", "z": "9c44cf3001e5d6f2", "name": "debug 7", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "false", "statusVal": "", "statusType": "auto", "x": 500, "y": 280, "wires": [] }, { "id": "b23c678c622af7f7", "type": "inject", "z": "9c44cf3001e5d6f2", "name": "", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "", "payloadType": "date", "x": 120, "y": 360, "wires": [ [ "948e6cf133e3cab4" ] ] }, { "id": "948e6cf133e3cab4", "type": "Secvest Command", "z": "9c44cf3001e5d6f2", "name": "", "server": "67c1d8818c300c5c", "partition": "3", "command": "unset", "x": 310, "y": 360, "wires": [ [ "9b0f5d90ba26630f" ] ] }, { "id": "2e4ef7561e93f3a1", "type": "comment", "z": "9c44cf3001e5d6f2", "name": "Ex. : Get state of Partition 2", "info": "", "x": 180, "y": 80, "wires": [] }, { "id": "2e597cdec7162587", "type": "comment", "z": "9c44cf3001e5d6f2", "name": "Ex. : 2 ways to unset Partition 3", "info": "", "x": 190, "y": 220, "wires": [] }, { "id": "52237c57a097f979", "type": "inject", "z": "9c44cf3001e5d6f2", "name": "", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "", "payloadType": "date", "x": 120, "y": 140, "wires": [ [ "90e82662da299ce2" ] ] }, { "id": "9b0f5d90ba26630f", "type": "debug", "z": "9c44cf3001e5d6f2", "name": "debug 9", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "false", "statusVal": "", "statusType": "auto", "x": 500, "y": 360, "wires": [] }, { "id": "22acdbcecc7ddf20", "type": "comment", "z": "9c44cf3001e5d6f2", "name": "Ex. : partset Partition 1 via MQTT", "info": "", "x": 190, "y": 440, "wires": [] }, { "id": "441a1c2dbbc62730", "type": "mqtt in", "z": "9c44cf3001e5d6f2", "name": "", "topic": "/secvest/cmd/", "qos": "2", "datatype": "auto-detect", "broker": "", "nl": false, "rap": true, "rh": 0, "inputs": 0, "x": 210, "y": 560, "wires": [ [ "fe208e5ff91d6bd4" ] ] }, { "id": "fe208e5ff91d6bd4", "type": "Secvest Command", "z": "9c44cf3001e5d6f2", "name": "", "server": "67c1d8818c300c5c", "partition": "1", "command": "payload", "x": 430, "y": 560, "wires": [ [] ] }, { "id": "8894a1b6066e0132", "type": "mqtt out", "z": "9c44cf3001e5d6f2", "name": "", "topic": "/secvest/cmd", "qos": "", "retain": "", "respTopic": "", "contentType": "", "userProps": "", "correl": "", "expiry": "", "broker": "", "x": 340, "y": 500, "wires": [] }, { "id": "b0c6544ed8dc8152", "type": "inject", "z": "9c44cf3001e5d6f2", "name": "", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "partset", "payloadType": "str", "x": 110, "y": 500, "wires": [ [ "8894a1b6066e0132" ] ] }, { "id": "67c1d8818c300c5c", "type": "ABUS Secvest", "servername": "Secvest_Example", "host": "192.168.1.100", "port": "4433", "user": "Admin", "password": "1234" } ]
