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

[mickym]

@dos1973 sagte in Shellys ("Alt und Plus") über MQTT Adapter:

@mickym
Du … bist ja von flows umschwungen
Bei dir sieht das immer so easy und logisch aus.

Na Du musst Dir doch nur vorstellen, wie ein Nachrichtenobjekt durch die Kabel flutscht und Dir dann jede Node betrachtest, was diese mit dem Nachrichtenobjekt anstellt. - Das schöne ist - Du kannst über Inject Nodes - Zwischenergebnisse in Deinen Flow injizieren, über debug Nodes Dich versichern, dass die Nachrichtenobjekte noch so aussehen, wie Du es erwartest. Mal ein Kabel kappen, um die Hardware nicht unnötig zu belasten und wie gesagt es gibt auch Nodes, die ganze Adapter ersetzen, wenn die mal nicht so wollen, wie man sich das vorstellt.

Du musst nur etwas Vorstellungskraft entwickeln - so ein Nachrichtenobjekt zu sein und durch die Kabel zu fließen.

[hotspot_2]

@mickym

Diese Variante:

Ist mir sehr sympatisch.

Würde ich damit auch so eine Folge hinbekommen:

True - 2 Sekunken Pause - False - 2 Sekunden Pause - True 2 Sekundnen Pause- False

Also quasi 2 mal klingeln mit Pause dazwischen? Im Moment wird ja wieder direkt nach false true geschickt.

[mickym]

@hotspot_2 dann nimm doch lieber die letzte Variante mit dem Array, da kommst auch ohne Variable und Flow Kontext aus. Das Array definierst einfach in einer Change-Node. Damit steuerst Du über ein Array einfach die Nachrichtenfolge und begrenzt die Nachrichtenrate über die delay Node.

Spoiler

[
   {
       "id": "c8b50d3d51d90b9c",
       "type": "inject",
       "z": "2e7d4cac81c671e3",
       "name": "Es klingelt",
       "props": [
           {
               "p": "payload"
           }
       ],
       "repeat": "",
       "crontab": "",
       "once": false,
       "onceDelay": 0.1,
       "topic": "",
       "payload": "true",
       "payloadType": "bool",
       "x": 520,
       "y": 4360,
       "wires": [
           [
               "79bf8d45a373fc13"
           ]
       ]
   },
   {
       "id": "79bf8d45a373fc13",
       "type": "change",
       "z": "2e7d4cac81c671e3",
       "name": "",
       "rules": [
           {
               "t": "set",
               "p": "payload",
               "pt": "msg",
               "to": "[true,false,true,false]",
               "tot": "json"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 710,
       "y": 4360,
       "wires": [
           [
               "32dd43edf0eaf0dd"
           ]
       ]
   },
   {
       "id": "32dd43edf0eaf0dd",
       "type": "split",
       "z": "2e7d4cac81c671e3",
       "name": "",
       "splt": "\\n",
       "spltType": "str",
       "arraySplt": 1,
       "arraySpltType": "len",
       "stream": false,
       "addname": "",
       "x": 890,
       "y": 4360,
       "wires": [
           [
               "d7b7548fa616ba39"
           ]
       ]
   },
   {
       "id": "5384ef4e3a1e8116",
       "type": "debug",
       "z": "2e7d4cac81c671e3",
       "name": "Klingel",
       "active": true,
       "tosidebar": true,
       "console": false,
       "tostatus": false,
       "complete": "payload",
       "targetType": "msg",
       "statusVal": "",
       "statusType": "auto",
       "x": 1270,
       "y": 4360,
       "wires": []
   },
   {
       "id": "d7b7548fa616ba39",
       "type": "delay",
       "z": "2e7d4cac81c671e3",
       "name": "",
       "pauseType": "rate",
       "timeout": "5",
       "timeoutUnits": "seconds",
       "rate": "1",
       "nbRateUnits": "2",
       "rateUnits": "second",
       "randomFirst": "1",
       "randomLast": "5",
       "randomUnits": "seconds",
       "drop": false,
       "allowrate": false,
       "outputs": 1,
       "x": 1080,
       "y": 4360,
       "wires": [
           [
               "5384ef4e3a1e8116"
           ]
       ]
   }
]

Du siehst an den Zeitstempeln alle 2 s eine Nachricht. Außerdem siehst du an der Delay Node im Status gleich, wieviele Nachrichten noch kommen.

Bei der Variante unten von dir müsstest Du noch eine delay Node mit 2s in die Schleife einfügen, da finde ich das ohne Flowkontext viel einfacher und intuitiver.

[hotspot_2]

@mickym Funktioniert perfekt!

Hast Du mir noch einen Tipp wie ich den Eingang entprellen kann (Klingeltaster). So dass z.B. alle 2 Sekunden nur eine Meldung durchgeht?

[mickym]

@hotspot_2 Ja mit der tollen Trigger Node

oder ebenfalls mit der Delay Node und Begrenzung der Nachrichtenrate

hier dann halt die Zwischennachrichten löschen.

Bei der Delay Node kommt in jedem Fall eine Nachricht durch nach 2s. Bei der Trigger Node kannst Du entscheiden, ob nach 2 Sekunden eine Nachricht kommt (also Haken bei Verzögerung verlängern deaktivieren) oder ob Du den Dauerklingler solange ignorierst, bis er den Finger für 2s von der Klingel nimmt ;). (also Haken bei Verzögerung verlängern aktivieren)

[hotspot_2]

@mickym Hallo!

Ich habe noch mal eine Verständnisfrage zu dem hier:

Wenn in dem obigen Flow jetzt der Bewegsungsmelder keller und nicht der wk auslöst dann wird der Wert für den aktuellen Lux-Wert in der Waschküche nicht ermittelt und d.h. das vermutlich das Licht nicht angeht bzw. dem Zufall überlassen ist am Ende des Flows da vergleiche ja dann lux_wk wert mit einem Limit und wenn größer dann geht das Licht nicht an.

Wie wäre es denn machbar den Lux wert von WK immer abzrufen? Zum Beispiel auch wenn es noch mehr Bewegungsmelder sind.

Danek für einen TIpp dazu.

[mickym]

@hotspot_2 Dann nimm halt über eine iobroker-Get Node direkt den Wert aus dem mqtt-Adapter.

[hotspot_2]

@mickym Danke, da bin ich jetzt irgendwie nicht darauf gekommen.

[mickym]

@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:

@mickym Danke, da bin ich jetzt irgendwie nicht darauf gekommen.

Kann aber sein, dass Du keinen Gewinn davon hast, da der BWM oft nur lux aktualisiert bei BEwegung oder vielleicht im Stundenrhythmus. Da das aber in einem Objekt ist - hast Du trotzdem wahrscheinlich den aktuellsten Wert.

[hotspot_2]

@mickym Hallo mivkym, oder andere ;-),

Ich habe mal wieder eine kleine Verständnisfrage da ich den Eindruck habe das was nicht ganz so abläuft wie ich mir das gedacht habe.

Ich habe bei zwei Lichtsteuerungen quasi das gleiche gemacht:

Nummer 1:

Nummer 2:

Ich habe den Eindruck das es nicht funktioniert und der eingestellte Wert vom ioBroker Objekt nicht eingelesen wird wenn der Trigger über MQTT kommt.

Kann das sein? Müsste ich den iobroker in in den Flow einbinden damit es korrekt funktioniert?

Danke für eine Rückinfo dazu.

[mickym]

@hotspot_2 Ich verstehe die Frage nicht. Laut status werden doch die iobroker-In Nodes eingelesen. Was hast Du in msg.delay - ist Dir klar dass der Wert in ms angegeben wird?

[hotspot_2]

@mickym Ja, das ist mir klar. Vielleicht liegt es auch an meiner Denkweise.

Wird der Wert in Trigger überhaupt aktuell angezogen wenn der eigentliche Trigger für die Schaltung von einem anderen Strang / Zweig kommt? Das ist eigentlich meine Frage. Ich denke mir im Moment das dadurch das der Trigger nicht vom iobroker in kommt beim Schaltvorgang der Werte nicht aktuell eingelesen wird durch den oberen Strang oder unteren im zweiten Flow.

[mickym]

@hotspot_2 Wenn Du über die rosa mqtt-Nodes gehst gehst Du nicht über den iobroker, wenn Du über die iobroker Node gehst schon. Ich weiss gerade nicht ob du mosquitto als Broker nutzt oder den mqtt-Adapter.

[hotspot_2]

@mickym

Wenn jetzt über die rosa Mqtt-Nodes ein Event kommt und der Flow startet. Wird dann zu dem Zeitpunkt auch der dann im iobroker objekt stehende Wert ausgelesen?

[mickym]

@hotspot_2 Nein!! - Dieser Wert wird nur ausgelesen wenn Du den änderst. Wenn Du innerhalb eines Flows einen Wert auslesen willst dann musst Du die GET Node verwenden. Achte aber darauf, dass Du Dir die payload nicht überschreibst. Also müsstest Du die delay Nachrichteneigenschaft bereits in der Get Node setzen:

Also mit einer GetNode die Verzögerung holen und in den Flow einbauen, in dem Du es hiner die mqtt-In Node schaltest:

Spoiler

[
   {
       "id": "5b4783f0af523133",
       "type": "ioBroker get",
       "z": "c7454c976ad86c7e",
       "name": "delay",
       "topic": "0_userdata.0.Test.statelessSwitch",
       "attrname": "delay",
       "payloadType": "value",
       "errOnInvalidState": "nothing",
       "x": 1350,
       "y": 1380,
       "wires": [
           [
               "44344967c59de2e8"
           ]
       ]
   },
   {
       "id": "44344967c59de2e8",
       "type": "change",
       "z": "c7454c976ad86c7e",
       "name": "",
       "rules": [
           {
               "t": "set",
               "p": "delay",
               "pt": "msg",
               "to": "delay * 1000",
               "tot": "jsonata"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 1540,
       "y": 1380,
       "wires": [
           [
               "4bbd3b3548a2168e"
           ]
       ]
   }
]

[hotspot_2]

@mickym Ich habe mir jetzt ein iobroker get node eingebaut, aber irgendwie klappt das einlesen des Wertes nicht so wie ich mir das vorstelle:

Die Payload sieht nicht so aus wie gedacht. Ich habe mir gedacht ich kann dann danach auf den eingelesen Wert so zugreifen:

Was mache ich denn da falsch?

[mickym]

@hotspot_2 die Eigenschaft, die du in deiner Switch Node untersuchst ist keine Eigenschaft von payload, sondern direkt des msg Objektes. Die get-node kann auch kein tieferes Level setzen.

Deshalb musst du in deiner Switch Node nicht auf
„msg.payload.meldung_an_weitere_1“ untersuchen, sondern „msg.meldung_an_weitere_1“.

Wenn du meine beiden Nodes importiert hättest- dann müsstest du das sehen. Wenn du eine debug-Node hinter die iobroker get-Node hängst und Dir das komplette Nachrichtenobjekt und nicht nur die payload ausgeben läßt, dann siehst du das.

[hotspot_2]

@mickym Ok, verstanden. Das teste ich mal aus.

Warum wird mir aber im Debug nicht angezeigt ob der Werte dann true oder false ist?

[mickym]

@hotspot_2 habe ich dir gerade erklärt, weil du dir in der Debug Node nur die Nachrichteneigenschaft payload und nicht das komplette Nachrichtenobjekt ausgeben läßt. Das musst du halt in der debug node umstellen. In der payload stehen ja die Werte aus der mqtt Node.

Steht doch auch im Debugfenster, was Du Dir ausgeben läßt:

msg.payload: number

Also die Nachrichteneigenschaft payload des Nachrichtenobjektes mit Datentyp:number. Jedenfalls enthält die payload ja einen Datum, woher auch immer.

[hotspot_2]

@mickym

Jetzt passt es! Das Debug Node angepasst und schon sehe ich alles ;-).

Super, jetzt kann ich weitermachen.