UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[stefan22]

@mickym Ok also ist die msg.topic ein weiteres Nachrichtenobjekt. Die msg.topic kann ich quasi immer überall durch Festlegen erzeugen.Und dieses Nachrichtenobjekt wird von manchen Nodes vorausgesetzt.

[mickym]

@stefan22 Nein es ist kein weiteres Nachrichtenobjekt - sondern gehört zu dem gleichen Nachrichtenobjekt, dass auch die payload enthält,

das Object ist also so definiert:

var msg = {topic:"Dies ist ein Topic", payload:"Dies ist die payload"};

und zugreifen tust Du über msg.topic oder msg.payload.

Es sind Bestandteile eines Nachrichtenobjektes und keines zweiten.

[stefan22]

@mickym ahhhhh jetzt. Sprich die variable msg ist das ganze und beinhaltet die Topic und die Payload. Diese kann ich aber unterschiedlich oder getrennt von einander für Inhalte nutzen.

[mickym]

@stefan22 Genau. :D Der Kandidat hat 100 Punkte.

Ich hab Dir mal die Steckdose 1 Debug Node in dem Flow als Objekt ausgeben lassen und Du siehst dass das Topic Nr.1 noch weiter enthalten ist:

In dem obigen Beispiel siehst Du auch dass die split node noch weitere Objekte dem msg Objekt hat zukommen lassen, nämlich msg.parts - dieses dienen zum Beispiel einer JOIN Node die Nachrichten wieder zusammenzufügen - brauchen wir aber nicht.

Ein weiterer Bestandteil eines msg Objektes ist die interne _msg.id - die nutzt aber nodeRed intern um eine Nachricht genau zu identifizieren.

Wie gesagt Du kannst jederzeit - ein Nachrichtenobjekt mit beliebigen weiteren Objekten/Parametern ergänzen und die werden auch in der Regel alle weitergegeben ausser ein node - erstellt ein komplett neues Nachrichtenobjekt.

[mickym]

@stefan22 said in Node-Red Hilfe:

@mickym ahhhhh jetzt. Sprich die variable msg ist das ganze und beinhaltet die Topic und die Payload. Diese kann ich aber unterschiedlich oder getrennt von einander für Inhalte nutzen.

und ja auch wenn Du die unterschiedlich nutzen kannst - so sind halt diese beiden in Ihrer Funktion vordefiniert - sprich die meisten Nodes gehen davon aus, dass das Topic die Sache / Herkunft der Nachricht beschreibt, die mit dem Nachrichtenobjekt einhergeht und die payload den Wert den die Sache hat.

In unserem Fall ist das Topic also die Steckdose Nr. X und die payload der Zustand oder Wert ob die Steckdose ein oder ausgeschaltet ist.

Bei einem Sensor wie einem Thermometer wird das Topic beschreiben, welches Thermometer es ist und die Payload die aktuelle Temperatur.

Deine UDP node wird als topic wahrscheinlich die IP Adresse enthalten und als payload eben diesen String. usw,

[stefan22]

@mickym Moin. Soooo ich hab es auch mal wieder hier her geschafft. Jetzt dachte ich ich schaumal ob ich das mit dem nächsten Projekt alleine hinbekomme , aber ich hab da noch meine Probleme, irgendwie steh ich auf dem Kriegsfuß mit json.
Anbei mal ein Bild. Wie bekomme ich da die einzelne Werte raus, damit ich mit diesen Arbeiten kann ?????
Wann nehm ich ne Json Node , wann ne Split-Node ???
Und kann es sein das gewisse Sachen bei manchen Browsern nicht gehen, sprich beim Programmieren der Node ?

Gruss Stefan

[mickym]

@stefan22 Mit dieser Abfrage bekommst Du doch nur einen Wert (Value) innerhalb eines Objektes raus. BSH.Common.EnumType. PowerState.On - also On
Wenn Du das alleine haben willst einfach: einen change node - Festlegen msg.payload auf msg.payload.value. Dann kannst auch noch übersetzten mit Change Node Ändern BSH.Common.EnumType. PowerState.On

JSON ist erst mal einen String und was Du siehst - ist da ein Objekt und kein String (siehst Du ja msg.payload.Object). Darauf greifst Du dann einfach zu mit msg.payload.<Eigenschaft des Objektes> also zum Beispiel: value.

Und Du brauchst doch nur 1 Nachricht weder was zum aufteilen noch zusammenzufassen.

[stefan22]

@mickym Hm Ok für blöde. Ich könnte auch rein theoretisch die msg.payload auf msg.payload key festlegen, auch wenn es käse wäre. Erklär mir mal bitte die Grundlage von dem Objekt . In den Anführungsstrichen ist der String. Was ist dann das key , value , level . Gruss

[mickym]

@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.

[stefan22]

@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

[mickym]

@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.

[stefan22]

@mickym :blush: Denkanstösse . Ich probiere gleich mal und dann weiter Fliesen gehen. Gruss

[mickym]

@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.

[stefan22]

@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

[mickym]

@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?

[stefan22]

@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

[mickym]

@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.

[stefan22]

@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.

[mickym]

@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.