Node-Red Hilfe
-
@stefan22 Genau ein Objekt hat Eigenschaften - zum Beispiel value oder key und mit Syntax Objekt.key greifst Du darauf zu, In Anführungszeichen ist der Wert der Eigenschaft - also von value, key etc.
-
@mickym So jetzt weiss ich warum ich verwirrt bin war das falsche Foto. Kann ich auch Value und Key gleichzeitig in die msg.payload nehmen oder würde ich in dem Fall die Key in das Topic laden und den Wert in die msg.payload.value
Da ja ein anderes event auch ein true als value bringen könnte
-
@stefan22 Genau den Key machst zum topic und den value nimmst als payload. Im Prinzip ist es egal - Du kannst auch alles lassen - das Objekt nimmst doch komplett mit. key = topic und value = payload- ist halt das wie Du das Objekt quasi standardisierst, aber ist nicht nötig.
-
@mickym
Denkanstösse . Ich probiere gleich mal und dann weiter Fliesen gehen. Gruss -
@stefan22 Ach und was das level ist weiß ich nicht .Du oder jeder Hersteller kann doch Eigenschaften (Keys) für ein Objekt festlegen, wie er lustig ist. Du könntest auch mit msg.payload.neu - Deinem msg-Objekt eine neue Eigenschafthinzufügen. Den Wert setzt Du dann über den Change Node: Festlegen. msg.payload.neu Neuwert.
Du kannst auch ein eigene Eigenschaft ausserhalb der payload festlegen. Also nur msg.neu usw. Lass Dir immer mit dem Debug Node anzeigen, wie das dann dargestellt wird. -
@mickym So jetzt hab ich aber immer noch das Problem wenn ich msg.payload auf msg.payload value mache das ich nicht nur das true oder false bekomme, sonder dadurch das ja durch die Eventnode auch noch andere Sachen ankommen auch den z.b value: "BSH.Common.EnumeType.PowerState.On" . Sprich es kommen lauter events mit der selben Maske rein Timestamp , handling, uri, key, value, level nur halt mit anderem Inhalt bei value
-
@stefan22 Ja das hört sich doch alles gut an. Du setzt einen Request mit den benötigten Infos ab und bekommst diese je nachdem was Du abfragst? - Mit der URI steuerst Du doch, was Dich interessiert? Du musst doch auch nur das abfragen, was Dich interessiert. Was möchtest Du denn machen - dann musst schon genauer werden.
Node-Red ist zum Bearbeiten und Verarbeiten von Informationen da - nicht um diese zu speichern. Dann solltest Dich doch noch mit iobroker auseinandersetzen, wenn Du da grafisch einen Überblick haben willst. Du kannst zwar alles in Variablen zwischen speichern - aber das macht alles keinen Sinn. NodeRed dient arbeitet so:
Du fragst Info ab, bearbeitest diese und steuerst dann eine Aktion. Diese Zyklus läuft mehrfach und parallel und Du musst aus Deinem Kopf alles streichen, was mit Speichern zu tun hat. Dann nutze lieber noch mqtt - als Speichermedium für Zustände, wenn Du iobroker etwas zuviel Overhead hat.Selbst wenn DU keine verschiedenen URI's zur Steuerung der Ausgabe hast - so kannst Du selbst bei einer - ja über den KEy verscheidene Zweige aufmachen, um unterschiedliche Flows zum jeweiligen Zweck zu starten.
Hauptfrage: Durch was triggerst Du Deine HTTP Abfragen?
-
@mickym na ich möchte genau nur den Wert true bekommen sprich key: "BSH.Common.Status.RemoteControlStartAllowed" value: true (oder false)
wenn ich aber die msg.payload auf msg.payload.value setze bekomme ich auch z.b als value: das die Tür auf noch auf ist; oder value: das das Gerät noch 3000 Sekunden braucht. Lach nö nix mit Speichern.
Ich bekomme durch die Eventnode jedes aktuelle Event von der Maschine rein.
Ich brauche aber nur das Event true vom Fernstart.
Diese True und das True von meiner PV Anlage geben dann den Fernstart frei.
Lach du schreibst wesentlich schneller als ich
Im Endeffekt möchte ich den Value: true oder false vom key: "BSH.Common.Status.RemoteControlStart Allowed haben und nicht noch den Value von, x, y, z
Lach ich mach eindeutig zuviele Sachen gleichzeitig -
@stefan22 Da steht ich auf dem Schlauch, wenn Du eine HTTP Abfrage mit
... dieser URI machst dann bedeutet doch das true oder valse nur das Ergbenis dieser Abfrage und nichts anders (also nichts mit Tür oder sonst was - das sind doch sicher andere URIs die Du da verwendest?
Am Besten Du machst wieder einen Screenshot von Deinem Flow und/oder exportierst den.
Ach so ich glaube ich verstehe - Du hast irgendeinen Eventnode - der die HTTP Abfragen für Dich macht.
Nun dann ist einfach. Hänge einfach eine Switch Node ran, der filtert Dir alles nach den Keys die Du brauchst. -
@mickym Richtig aber über diese Event-Node kommen auch noch nacheinander die anderen Befehle rein.
Wenn jetzt noch die Maschine läuft würde quasi noch als drittes die Restzeit in Sekunden auftauchen. -
@stefan22 Wie gesagt hänge eine Switch Node dazwischen - da filterst Du gant easy aus.
Den Switch Node - lässt Du nach msg.payload.key filtern.Hier den Node zum importieren:
[ { "id": "f04957b3.470838", "type": "switch", "z": "6e170384.60c96c", "name": "", "property": "payload.key", "propertyType": "msg", "rules": [ { "t": "eq", "v": "BSH.Common.Status.RemoteControlStartAllowed", "vt": "str" }, { "t": "eq", "v": "BSH.Common.EnumType.PowerState", "vt": "str" } ], "checkall": "true", "repair": false, "outputs": 2, "x": 1040, "y": 2700, "wires": [ [ "8a3f9133.acf6f" ], [] ] }, { "id": "8a3f9133.acf6f", "type": "change", "z": "6e170384.60c96c", "name": "", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "payload.value", "tot": "msg" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 1260, "y": 2680, "wires": [ [] ] } ]Wenn Du nur den 1. Ausgang brauchst - dann löschen den 2. Ausgang wieder.
Ich habs Dir nun für den 1. Ausgang so gemacht, dass Du dort wie gewünscht nur noch true oder false für "BSH.Common.Status.RemoteControlStartAllowed" value: true (oder false) bekommst. wenn Du beide Nodes hinter Deine blaue Node-Red Node klemmst.
Ich kenne jetzt zwar Deinen Change NOde nicht, aber wenn Du dort msg.topic auf msg.payload.key gesetzt hast und msg.payload schon auf msg.payload.value - dann brauchst ja nur noch den switch dahinter machen und auf msg.topic filtern. Diese Variante ist sogar noch geschickter. - Ich ändere mal den Flow.
[ { "id": "aa0c95d9.989e58", "type": "change", "z": "6e170384.60c96c", "name": "", "rules": [ { "t": "set", "p": "topic", "pt": "msg", "to": "payload.key", "tot": "msg" }, { "t": "set", "p": "payload", "pt": "msg", "to": "payload.value", "tot": "msg" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 2140, "y": 2900, "wires": [ [ "15068b83.ecbbf4" ] ] }, { "id": "15068b83.ecbbf4", "type": "switch", "z": "6e170384.60c96c", "name": "", "property": "topic", "propertyType": "msg", "rules": [ { "t": "eq", "v": "BSH.Common.Status.RemoteControlStartAllowed", "vt": "str" }, { "t": "eq", "v": "BSH.Common.EnumType.PowerState", "vt": "str" } ], "checkall": "true", "repair": false, "outputs": 2, "x": 2340, "y": 2900, "wires": [ [], [] ] } ]
Warum ist das geschickter? - Nun weil man dann die Festlegung msg.payload = msg.payload.value nur einmal festlegen muss und nicht in jedem Ast nach dem Switch.
