Array mit Objekten in iOBroker anlegen
-
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" } ] -
Lassen wir das mit dem Error sonst erstmal weg. Würde dann folgendes funktionieren?:
Globale Variable = counter.secvest
Der Flow startet, die erste Abfrage wird über einen Timestamp initialisiert, dann läuft die Abfrage durch, dann zählt der Counter eins hoch. Bei der nächsten Abfrage wird geprüft, ob Counter bei 1, dann 2. Abfrage, wieder Counter einen hoch zählen. usw.
Bis alle 4 Bereiche durch sind und dann wieder bei 1 einfangen. und das immer in einer schleife.
Dann schenken wir uns das erstmal mit dem Error-Handling. Wäre zwar ein nice to have, aber wenn das so ausufert, dann ist das blödsinn.
-
Na ja in der Hilfe steht auch nichts - was hast Du bisher gemacht, wenn Du alle 4 Nodes einzeln abgefragt hast? und das nicht über die payload gemacht hast? Alle 4 Partitionen in die Node eingetragen und nun wolltest Du 4 Nodes machen und dann damit jede Partition einzeln abfragen?
Wenn ich die Beschreibung des Textes lese kann man das ja alles als payload schicken. Ich habe diese Node nicht, aber es sieht so aus, wenn Du den Status abfrägst, dass das Kommando "state" ist.
{ "id": "90e82662da299ce2", "type": "Secvest Status", "z": "9c44cf3001e5d6f2", "name": "", "server": "67c1d8818c300c5c", "partition": "2", "command": "state" .....Aus der Beschreibung der Node (s. Screenshot) steht.
You can also set the desired partition (1/2/3 or 4) as msg.payload.
Du könntest also einfach mal in der Inject Node eine payload schicken mit der partition und dies in der Node leer lassen.
Also:
hier zum Import:
[ { "id": "30a75b4cea8b0f90", "type": "inject", "z": "517cd16e4d7e6ae4", "name": "", "props": [ { "p": "payload" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "{\"partition\":\"3\"}", "payloadType": "json", "x": 360, "y": 1240, "wires": [ [] ] } ]
Wichtig ist, dass es als Objekt schickt (s. Pfeil)
Eventuell auch die 3 oder Anführungszeichen sondern als Zahl
-
@hackypaddy Nein wir müssen uns das nicht schenken - lass uns das erst mal eins nach dem anderen machen. Ich stelle Fragen und überlege mir was ich für die beste Lösung halte. Du kannst es dann ja immer noch ändern. Jetzt lass mich Dir erst mal den anderen Vorschlag machen und Dir die Vorteile erklären, wenn Du die Struktur beläst so wie sie rauskommt.
Und nochmal die Frage??? - hast Du alle 4 Partitionen bisher aufeinmal abgefragt und Du willst nur die fehlerhaften Aussortieren? Falls das so ist und Du nur die fehlerhaften wegschmeißen kannst, dann ist das easy. Wollen wir deshalb mit dem einfachsten anfangen?
-
@hackypaddy sagte in Array mit Objekten in iOBroker anlegen:
BW Fen. R.
So also erst nochmal zu meinem Alternativvorschlag und dann im nächsten Post welche Vorteile das hat - daneben dass Du auch die Originalnamen behalten kannst.
-
Ok.
Genau, bisher habe ich die 4 Partitionen gleichzeitig abgefragt. Damit kommt die Anlage aber nicht klar, dass ist zu viel auf einmal.
Deshalb sollen die Bereiche sequenziell nacheinander abgefragt werden. Als Auslöser der nächsten Abfrage würde ich mir den node.status "OK" wünschen.
Wenn ein Error ausgegeben wird, ist das nicht wichtig für mich. Bei der nächsten Anfrage wird er nicht mehr da sein. D.h. auch bei einem Error kann die Abfragesequenz fortgesetzt werden.
Ganz toll wäre es natürlich, wenn er bei einem Error die Abfrage nochmal macht. Aber das ist nicht zwingend notwendig.
-
@hackypaddy Lass Dir erst nochmal die Vorteile meiner Alternativstruktur erklären und dann auch nochmal die Frage, wenn Du alle 4 Partitionen auf einmal abfragst - kommt das nur manchmal vor, dass die Anlage nicht klar kommt und kannst Du dann ggf. auf diese Abfrage verzichten oder geht es grundsätzlich nicht?
Bei meiner Alternativstruktur kannst Du dann nämlich mit Wildcards (nachdem anfänglich erst mal alle Initialisiert wurde) - nur noch auf Änderungen reagieren und alle states auf einmal überwachen:
Da der Datenpunkt mit dem state immer gleich heißt - hast Du so immer den aktuellen Status - der Name wird eigentlich gar nicht gebraucht kannst ihn aber mit einer get-Node ggf. auslesen. Da hier der Name des Datenpunktes ebenfalls konstant ist, ist das hier natürlich von Vorteil
Wie gesagt den Originalnamen brauchst Du nicht. Im oberen Ast - hast Du im Topic ja den Pfad zur Originalquelle. Wenn Du unbedingt den Originalnamen als topic haben willst, dann holst Du ihn Dir via get Node.
Hier der Import
