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

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

[hotspot_2]

@hotspot_2 Ich hätte nochmal eine Frage zur Get Node. Das einlesen des Wertes funktioniert einwandfrei aber sie überschreibt mir msg.topic mit dem Namen des ioBroker Objekts. Ich brauche aber msg.topic zur Übergabe an die Pushover Node später.

Kann man das irgendwie lösen?

[mickym]

@hotspot_2 dann musst du vor der get Node die msg.topic in eine andere Nachrichteigenschaft wegsichern (verschieben oder setzen) und nach der get node wieder das topic restaurieren. Also Change Node davor und danach.

[hotspot_2]

@mickym Hallo, ich würde gerne checken ob für die Shellys (das Beispiel hier ist der Shelly Plus 1 und dann eine Meldung auslösen.

{
  "mac": "A8032ABD5E90",
  "restart_required": false,
  "time": "17:29",
  "unixtime": 1687879763,
  "uptime": 3888016,
  "ram_size": 234760,
  "ram_free": 160548,
  "fs_size": 458752,
  "fs_free": 106496,
  "cfg_rev": 16,
  "kvs_rev": 2,
  "schedule_rev": 0,
  "webhook_rev": 0,
  "available_updates": {
    "beta": {
      "version": "1.0.0-beta5"
    }
  }
}

So so sieht das JSON aus das der Shelyl liefert über MQTT. Kannst Du mir einen Tipp geben wie ich auswerten könnte das in "avalaible_updates" : "beta" oder "stable" da ist und auch die Version dann auslesen kann?

Ich würde dann für jeden Shelly Typ (Plus 1, Smoke, Plug usw.) einfach ein Node anlegen und mir dann z.B. eine Mail schicken wenn es Updates gibt, so der Plan ;-).

[mickym]

@hotspot_2 Meines Erachtens brauchst Du das nicht.

Du solltest eigentlich in jedem Shelly einen INFO Datenpunkt haben. Dort gibts eine Eigenschaft: has_update. Der steht auf true wenn es ein Update gibt.

[hotspot_2]

@mickym Ja, den gibt es. Aber es sieht für mich so aus das der nur bei den Gen1 Devices vorhanden ist.

{
  "wifi_sta": {
    "connected": true,
    "ssid": "FFHomeNet24",
    "ip": "192.168.3.56",
    "rssi": -54
  },
  "cloud": {
    "enabled": false,
    "connected": false
  },
  "mqtt": {
    "connected": true
  },
  "time": "19:13",
  "unixtime": 1687885996,
  "serial": 1,
  "has_update": false,
  "mac": "C8C9A388F8FA",
  "cfg_changed_cnt": 0,
  "actions_stats": {
    "skipped": 0
  },
  "relays": [
    {
      "ison": false,
      "has_timer": false,
      "timer_started": 0,
      "timer_duration": 0,
      "timer_remaining": 0,
      "overpower": false,
      "source": "mqtt"
    }
  ],
  "meters": [
    {
      "power": 0,
      "overpower": 0,
      "is_valid": true,
      "timestamp": 1687893196,
      "counters": [
        0,
        0,
        0
      ],
      "total": 10074
    }
  ],
  "temperature": 33.46,
  "overtemperature": false,
  "tmp": {
    "tC": 33.46,
    "tF": 92.23,
    "is_valid": true
  },
  "update": {
    "status": "idle",
    "has_update": false,
    "new_version": "20230503-101129/v1.13.0-g9aed950",
    "old_version": "20230503-101129/v1.13.0-g9aed950"
  },
  "ram_total": 52056,
  "ram_free": 39664,
  "fs_size": 233681,
  "fs_free": 166664,
  "uptime": 1540988
}