Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[mickym]

@dos1973 Du kannst direkt unter allen shellies nochmal einen Datenpunkt command anlegen oder bei den einzelnen shellies. Dort kann man dann mit announce die shellies zwingen ihren status im info Datenpunkt abzulegen oder bei Bedarf kann man das nutzen um die Firmware zu aktualisieren.

siehe: https://shelly-api-docs.shelly.cloud/gen1/#common-mqtt-commands

Im Info-Datenpunkt findest in der Regel fast alle Infos zu dem Shelly in einem JSON zusammengefasst. So auch ob es ein FW Update gibt, welche FW Version etc.

Mit announce in dem command Punkte - entweder beim Einzelgerät oder für alle werden die info DP aktualisiert, mit update die normalen states, mit update_fw kannst Du Firmwareupdates anstossen.

Aus dem Link siehst, dass die announce Datenpunkte eher alt sind und bis zur FW. 1.6.x genutzt wurden, ab Version 1.8.x wird Info genutzt. Aktuell siehst ja an meinem Screenshot sind wir bei einer FW Version 1.11.x

Und wenn Du mit NodeRed arbeiten würdest könntest ja meinen Flow nutzen der daraus einzelne Datenpunkte unter userdata macht - (Wenn derzeit auch mit Nacharbeit wegen Admin5). Zeig es Dir mal an einem Beispiel. Theoretisch könnte Dir so ein Flow auch selbst den Info DP unter mqtt aufdröseln.

[mickym]

@mickym sagte in Mqqt best practice:

Und wenn Du mit NodeRed arbeiten würdest könntest ja meinen Flow nutzen der daraus einzelne Datenpunkte unter userdata macht - (Wenn derzeit auch mit Nacharbeit wegen Admin5). Zeig es Dir mal an einem Beispiel. Theoretisch könnte Dir so ein Flow auch selbst den Info DP unter mqtt aufdröseln.

Mit diesem kleinen Flow - könntest Du dann alle states aus dem Info Datenpunkt aufdröseln:

Dann muss man halt wieder das javascript drüber jagen - dieses Mal über userdata - damit einmalig die fehlenden Objekte angelegt werden. NodeRed kann im Moment nur states und keine Objekte anlegen.

Fehlende Stiftsymbole !!!

Das Skript macht dann aus allen fehlenden Objekten - Folderobjekte:

Ist das aber einmal erledigt, dann werden diese Datenpunkte mit Aktualisieren des Info Datenpunktes automatisch aktualisiert.

Ich habe deshalb niemals verstanden, warum man Adapter nutzt, die kaum was anderes machen, als kompakte JSON-String Datenpunkte in einzelne Datenpunkte zerlegt. OK man muss keine Datenpunkte selbst anlegen, wenn man Kommandos verschickt. :) - Punkt gegen mqtt. ;)
Bei Bedarf kann man sich ja auch nur einzelne Datenpunkte aus dem JSON rausholen und in einem Alias beispielsweise abspeichern (habe ich ja vorher schon mal gezeigt, wie das geht).

[mickym]

In diesem Info Datenpunkt bekommt man in meinen Augen mind. soviel Infos wie in dem Adapter:

So siehst Du zum Beispiel, ob der Shelly gerade mit einem FW Update beschäftigt ist oder auch RAM Belegung ,die Güte des WLAN Signals, Uhrzeit des Shellies usw.

Uptime ist hier die Zeit in Sekunden (nicht Millisekunden ;) ), seitdem das Gerät neu gebootet hat- also 548006 Sekunden sind in diesem Fall ca. 152 Stunden oder vor gut 6 Tagen.

[mickym]

@dos1973
Falls Du übrigens mal den Shelly über Deine VIS und nicht das WEB-Interface konfigurieren willst und Du feststellst es geht nicht über MQTT, dann bleibt Dir immer noch die HTTP Schnittstelle, mit der kannst quasi alles machen.

Um zum Beispiel den Zeitserver zu ändern stehen Dir ja die unter settings beschriebenen Parameter zur Verfügung:
https://shelly-api-docs.shelly.cloud/gen1/#settings

Ich hab das sowohl mit GET und POST Requests getestet und funktioniert wunderbar:

Die Get-Requests funktionieren zum Testen auch im Browser wunderbar:

Mit

kannst also zum Beispiel den SNTP Server setzen:

So nun hab ich aber glaube genug Möglichkeiten der Steuerung ohne Adapter aufgezeigt. ;)

Ergänzend sei noch hinzugefügt: Natürlich kannst Du solche HTTP Requests auch über Blockly machen - aber ich bin da kein Fan von, deswegen habe ich hier nur begrenztes Wissen, aber dafür gibts ja dann andere hier an Board.

[dos1973]

@mickym sagte in Mqqt best practice:

So nun hab ich aber glaube genug Möglichkeiten der Steuerung ohne Adapter aufgezeigt

eindeutiges JA.
eigentlich war/ ist genau das mein Ziel.
Da ich inzwischen Zuviele von den kleinen Dingern habe, möchte ich nicht Abhängig vom Adapter und der Entwicklung sein.

kann der node-red "Status Teil exportiert werden. Das sehen ja bestimmt noch Sachen drin welche im Screenshot nicht ersichtlich sind.

[mickym]

@dos1973 sagte in Mqqt best practice:

@mickym sagte in Mqqt best practice:

So nun hab ich aber glaube genug Möglichkeiten der Steuerung ohne Adapter aufgezeigt

eindeutiges JA.
eigentlich war/ ist genau das mein Ziel.
Da ich inzwischen Zuviele von den kleinen Dingern habe, möchte ich nicht Abhängig vom Adapter und der Entwicklung sein.

kann der node-red "Status Teil exportiert werden. Das sehen ja bestimmt noch Sachen drin welche im Screenshot nicht ersichtlich sind.

Der Subflow-Node ist hier in meinem Thread genau beschrieben (z. Bsp muss man im NodeRed Adapter die Erstellung von Fremdobjekten zulassen und die Stringkonvertierung ausschalten):
Beides hier nochmal als Screenshot (Projektfunktion brauchst Du nicht):

https://forum.iobroker.net/topic/43856/json-string-oder-java-object-in-iobroker-struktur
https://forum.iobroker.net/topic/43856/json-string-oder-java-object-in-iobroker-struktur/9

Ich hab Dir mal nur den Teil exportiert ohne die mqtt-In Node - das kannst ggf. selbst machen oder alternativ eine iobroker-in Node vorne dran hängen:

Hier der Flow zum Import - enthält dann automatisch die Subflow Node mit Beschreibung:

Spoiler

 [
    {
        "id": "c3403a60.92fbb8",
        "type": "subflow",
        "name": "JSON or Obj to IOBroker",
        "info": "# Creates an IOBroker tree\n\nThis node creates an IOBroker tree out of an Java-Object or JSON String.\n\nThe object tree will be created under 0_userdata.0\nIn addition to the JSON-String or Java Object as `msg.payload` it is necessary to specify a `msg.top` properity in addition to the msg-Object.\n\nThe object tree will be created under 0_userdata.0\n\nExisting `msg.topic` entries will be deleted.\nAn iobroker-out node has to be appended to this subflow node. It is not part of the subflow itself. No topic should be specified in the iobroker out node.\n\nIs no `msg.top` property is defined, then you will get an error in the following iobroker-out node (key or topic does not exist) - if you append a debug node to the subflow node you will get the message: \n> Please define msg.top as root for the object structure \n\n# Erstellt einen Objektbaum im ioBroker\n\nDiese Node erstellt einen Objektbaum im ioBroker aus einem JAVA Objekt bzw. einem JSON String. \n\nDer Baum wird in jedem Fall unter 0_userdata.0 erstellt und zwar unter dem Topic der in` msg.top` mitgegeben wurde. In der `msg.payload` befindet sich dann der JSON String oder das entsprechende Objekt.\n\nExistierende `msg.topic `Einträge werden gelöscht.\nEin entsprechende iobroker-out Node muss an den Flow angehängt werden. Sie ist nicht Bestandteil des Subflows. In dieser iobroker-out Node darf kein Topic angegeben werden. \n\nFalls in keine Angabe in msg.top definiert wurde, wird man in der darauffolgenden iobroker-out node den Fehler erhalten, dass kein key oder topic definiert ist. Falls eine debug Node an den Subflow angehängt wirde erhält man folgende Ausgabe:\n> Please define msg.top as root for the object structure ",
        "category": "parser",
        "in": [
            {
                "x": 60,
                "y": 160,
                "wires": [
                    {
                        "id": "94876630.f71748"
                    }
                ]
            }
        ],
        "out": [
            {
                "x": 2280,
                "y": 260,
                "wires": [
                    {
                        "id": "74b0b536.02371c",
                        "port": 0
                    },
                    {
                        "id": "ab9b1e85.eea2a",
                        "port": 0
                    }
                ]
            }
        ],
        "env": [],
        "meta": {},
        "color": "#E2D96E",
        "icon": "node-red/batch.svg"
    },
    {
        "id": "eea737e7.7e8fb8",
        "type": "split",
        "z": "c3403a60.92fbb8",
        "name": "split object",
        "splt": "\\n",
        "spltType": "str",
        "arraySplt": 1,
        "arraySpltType": "len",
        "stream": false,
        "addname": "key",
        "x": 1170,
        "y": 160,
        "wires": [
            [
                "dc473616.c2b508"
            ]
        ]
    },
    {
        "id": "dc473616.c2b508",
        "type": "change",
        "z": "c3403a60.92fbb8",
        "name": "add key to topic",
        "rules": [
            {
                "t": "set",
                "p": "stateName",
                "pt": "msg",
                "to": "key",
                "tot": "msg"
            },
            {
                "t": "set",
                "p": "topic",
                "pt": "msg",
                "to": "topic  & '.' & key",
                "tot": "jsonata"
            },
            {
                "t": "change",
                "p": "topic",
                "pt": "msg",
                "from": " ",
                "fromt": "str",
                "to": "_",
                "tot": "str"
            }
        ],
        "action": "",
        "property": "",
        "from": "",
        "to": "",
        "reg": false,
        "x": 1360,
        "y": 160,
        "wires": [
            [
                "78697695.9a72c8"
            ]
        ]
    },
    {
        "id": "78697695.9a72c8",
        "type": "switch",
        "z": "c3403a60.92fbb8",
        "name": "is type?",
        "property": "payload",
        "propertyType": "msg",
        "rules": [
            {
                "t": "istype",
                "v": "array",
                "vt": "array"
            },
            {
                "t": "istype",
                "v": "object",
                "vt": "object"
            },
            {
                "t": "else"
            }
        ],
        "checkall": "true",
        "repair": false,
        "outputs": 3,
        "x": 1540,
        "y": 160,
        "wires": [
            [
                "d839cef8.577f1"
            ],
            [
                "eea737e7.7e8fb8"
            ],
            [
                "bdfdae99.f4d9d"
            ]
        ]
    },
    {
        "id": "d839cef8.577f1",
        "type": "split",
        "z": "c3403a60.92fbb8",
        "name": "split array",
        "splt": "\\n",
        "spltType": "str",
        "arraySplt": 1,
        "arraySpltType": "len",
        "stream": false,
        "addname": "",
        "x": 580,
        "y": 280,
        "wires": [
            [
                "36327f2d.8efc3"
            ]
        ]
    },
    {
        "id": "36327f2d.8efc3",
        "type": "change",
        "z": "c3403a60.92fbb8",
        "name": "add index to topic",
        "rules": [
            {
                "t": "set",
                "p": "topic",
                "pt": "msg",
                "to": "topic  & '.' & parts.index",
                "tot": "jsonata"
            }
        ],
        "action": "",
        "property": "",
        "from": "",
        "to": "",
        "reg": false,
        "x": 770,
        "y": 280,
        "wires": [
            [
                "d8f58d9b.b6a1"
            ]
        ]
    },
    {
        "id": "74b0b536.02371c",
        "type": "change",
        "z": "c3403a60.92fbb8",
        "name": "finalize msg.topic",
        "rules": [
            {
                "t": "set",
                "p": "top",
                "pt": "msg",
                "to": "'0_userdata.0.' & top",
                "tot": "jsonata"
            },
            {
                "t": "set",
                "p": "topic",
                "pt": "msg",
                "to": "top & topic",
                "tot": "jsonata"
            }
        ],
        "action": "",
        "property": "",
        "from": "",
        "to": "",
        "reg": false,
        "x": 1970,
        "y": 240,
        "wires": [
            []
        ]
    },
    {
        "id": "4cdee7cb.910c38",
        "type": "switch",
        "z": "c3403a60.92fbb8",
        "name": "is type?",
        "property": "payload",
        "propertyType": "msg",
        "rules": [
            {
                "t": "istype",
                "v": "json",
                "vt": "json"
            },
            {
                "t": "istype",
                "v": "object",
                "vt": "object"
            },
            {
                "t": "istype",
                "v": "array",
                "vt": "array"
            },
            {
                "t": "else"
            }
        ],
        "checkall": "true",
        "repair": false,
        "outputs": 4,
        "x": 400,
        "y": 160,
        "wires": [
            [
                "c1c41535.17d3b8"
            ],
            [
                "eea737e7.7e8fb8"
            ],
            [
                "d839cef8.577f1"
            ],
            [
                "d8f58d9b.b6a1"
            ]
        ]
    },
    {
        "id": "c1c41535.17d3b8",
        "type": "json",
        "z": "c3403a60.92fbb8",
        "name": "",
        "property": "payload",
        "action": "",
        "pretty": false,
        "x": 570,
        "y": 120,
        "wires": [
            [
                "3ccd67db.375058"
            ]
        ]
    },
    {
        "id": "bdfdae99.f4d9d",
        "type": "switch",
        "z": "c3403a60.92fbb8",
        "name": "is msg.top != null",
        "property": "top",
        "propertyType": "msg",
        "rules": [
            {
                "t": "nnull"
            },
            {
                "t": "null"
            }
        ],
        "checkall": "true",
        "repair": false,
        "outputs": 2,
        "x": 1750,
        "y": 280,
        "wires": [
            [
                "74b0b536.02371c"
            ],
            [
                "7ba7dc21.fdb214"
            ]
        ]
    },
    {
        "id": "7ba7dc21.fdb214",
        "type": "change",
        "z": "c3403a60.92fbb8",
        "name": "payload = warning",
        "rules": [
            {
                "t": "set",
                "p": "payload",
                "pt": "msg",
                "to": "Please define msg.top as root for the object structure",
                "tot": "str"
            },
            {
                "t": "delete",
                "p": "topic",
                "pt": "msg"
            }
        ],
        "action": "",
        "property": "",
        "from": "",
        "to": "",
        "reg": false,
        "x": 1970,
        "y": 300,
        "wires": [
            [
                "ab9b1e85.eea2a"
            ]
        ]
    },
    {
        "id": "ab9b1e85.eea2a",
        "type": "rbe",
        "z": "c3403a60.92fbb8",
        "name": "",
        "func": "rbe",
        "gap": "",
        "start": "",
        "inout": "out",
        "septopics": true,
        "property": "payload",
        "x": 2130,
        "y": 300,
        "wires": [
            []
        ]
    },
    {
        "id": "94876630.f71748",
        "type": "change",
        "z": "c3403a60.92fbb8",
        "name": "",
        "rules": [
            {
                "t": "delete",
                "p": "topic",
                "pt": "msg"
            }
        ],
        "action": "",
        "property": "",
        "from": "",
        "to": "",
        "reg": false,
        "x": 210,
        "y": 160,
        "wires": [
            [
                "4cdee7cb.910c38"
            ]
        ]
    },
    {
        "id": "3ccd67db.375058",
        "type": "switch",
        "z": "c3403a60.92fbb8",
        "name": "is array?",
        "property": "payload",
        "propertyType": "msg",
        "rules": [
            {
                "t": "istype",
                "v": "array",
                "vt": "array"
            },
            {
                "t": "else"
            }
        ],
        "checkall": "true",
        "repair": false,
        "outputs": 2,
        "x": 700,
        "y": 120,
        "wires": [
            [
                "d839cef8.577f1"
            ],
            [
                "eea737e7.7e8fb8"
            ]
        ]
    },
    {
        "id": "80dde279.c28ec",
        "type": "comment",
        "z": "c3403a60.92fbb8",
        "name": "Array",
        "info": "",
        "x": 400,
        "y": 280,
        "wires": []
    },
    {
        "id": "95ee816e.68a16",
        "type": "comment",
        "z": "c3403a60.92fbb8",
        "name": "object",
        "info": "",
        "x": 1140,
        "y": 100,
        "wires": []
    },
    {
        "id": "d8f58d9b.b6a1",
        "type": "switch",
        "z": "c3403a60.92fbb8",
        "name": "is type?",
        "property": "payload",
        "propertyType": "msg",
        "rules": [
            {
                "t": "istype",
                "v": "object",
                "vt": "object"
            },
            {
                "t": "istype",
                "v": "array",
                "vt": "array"
            },
            {
                "t": "else"
            }
        ],
        "checkall": "true",
        "repair": false,
        "outputs": 3,
        "x": 960,
        "y": 280,
        "wires": [
            [
                "eea737e7.7e8fb8"
            ],
            [
                "d839cef8.577f1"
            ],
            [
                "bdfdae99.f4d9d"
            ]
        ]
    },
    {
        "id": "61325de1.acf564",
        "type": "json",
        "z": "169f5b00.a13415",
        "name": "",
        "property": "payload",
        "action": "",
        "pretty": false,
        "x": 480,
        "y": 220,
        "wires": [
            [
                "cf5f91d.7edbb7"
            ]
        ]
    },
    {
        "id": "cf5f91d.7edbb7",
        "type": "change",
        "z": "169f5b00.a13415",
        "name": "",
        "rules": [
            {
                "t": "set",
                "p": "top",
                "pt": "msg",
                "to": "shellies.kueche.spuelmaschine",
                "tot": "str"
            }
        ],
        "action": "",
        "property": "",
        "from": "",
        "to": "",
        "reg": false,
        "x": 670,
        "y": 220,
        "wires": [
            [
                "f873a8e3.a764f8"
            ]
        ]
    },
    {
        "id": "f873a8e3.a764f8",
        "type": "subflow:c3403a60.92fbb8",
        "z": "169f5b00.a13415",
        "name": "",
        "x": 910,
        "y": 220,
        "wires": [
            [
                "a85e782b.a06c68"
            ]
        ]
    },
    {
        "id": "a85e782b.a06c68",
        "type": "ioBroker out",
        "z": "169f5b00.a13415",
        "name": "",
        "topic": "",
        "ack": "true",
        "autoCreate": "true",
        "stateName": "",
        "role": "",
        "payloadType": "",
        "readonly": "false",
        "stateUnit": "",
        "stateMin": "",
        "stateMax": "",
        "x": 1140,
        "y": 220,
        "wires": []
    }
]

Standardmässig werden die Datenpunkte nur als Read-Only Datenpunkte angelegt - macht eigentlich auch Sinn, da man damit ja nichts steuert, sondern Informationen liest. Willst Du das alle Datenpunkte, die von dem Flow angelegt werden beschreibbar sind, musst Du das in der iobroker-out Node angeben:

Ausserdem bekommt man glaub sogar Warnungen im LOG wenn man ReadOnly Felder beschreiben will. Ganz blicke ich das auch nicht - alles Admin5 Änderungen.
EDIT2: Na anscheinend kann man die Datenpunkte doch ReadOnly lassen und sie werden es gibt keine Fehlermeldungen wenn der Adapter die Datenpunkte beschreibt. Vielleicht wurde da was geändert im Admin5.

Und wie gesagt in der Hilfe zu der Subflow Node habe ich die Funktionsweise nochmals kurz beschrieben:

Die Bäume werden also als msg.top Datenpunkte ALLE unter 0_userdata.0 angelegt. Wenn Du diese selbst wieder als mqtt topics über die mqtt-out Nodes beschreiben willst, musst halt über eine Change Node die topics wieder anpassen!

Wenn Du nun natürlich mehrere Geräte unter userdata.0 aufgesplittet haben willst brauchst nur den vorderen Teil zu ändern, der hintere kann gleich bleiben.

Zur Veranschaulichung habe ich mal die zugehörigen Nodes gruppiert und beschriftet:

Man kann aber auch alle 5 Nodes gruppieren und pro Device machen - macht wahrscheinlich keinen Unterschied.

EDIT: Sorry hatte die Code-Tags beim Flow vergessen, habe ich nun nachgetragen, damit man das leichter kopieren kann. Ich hasse das selbst, wenn man da ewig scrollen muss anstelle "Select All" und dann kopieren. ;)

[mickym]

@dos1973 Ach und ändere doch mal die Überschrift vom "Mqqt" in "Mqtt" - ansonsten findet das niemand und schaut grauslig aus. ;)

[dos1973]

@mickym sagte in Mqtt best practice:

@dos1973 Ach und ändere doch mal die Überschrift vom "Mqqt" in "Mqtt" - ansonsten findet das niemand und schaut grauslig aus.

habe ich gemacht.

und ich habe auch die ganzen Infos reinbekommen. Schon toll, wie schnell und einfach.

ok, gebe zu, dass ich momentan noch nicht alles verstehe - sondern nur nachbaue. Aber beeindruckt mich.

aber ich muss den DP (mqtt.0.shellies.command) aktiv triggern über ein cronjob z.b alle 30 Sekunden damit die Werte aktualisiert werden?

mit dem Wert "update" und "announce"

richtig?

[mickym]

@dos1973 Nein das würde ich auf keinen Fall machen. Die wichtigsten Werte wie Schaltzustände und Verbräuche und Temperaturen werden zeitnah aktualisiert.

Das ist sinnloser Netzverkehr und belastet den ioBroker und die Shellies unnötig.

Ich würde das announce Kommando allenfalls als eine Art Refresh Button ansehen, das man mal auf Bedarf drückt. Alles wichtige aktualisiert sich on demand und selbstständig. Die Intervalle kannst Du über die mqtt Parameter im Shelly einstellen.

Im Prinzip gibt es neben den Schaltzuständen also relays, lights, noch den Stromverbrauch zu überprüfen und den announce Datenpunkt (enthält Benachrichtigung über FW Updates). Damit ist eigentlich das wichtigste abgedeckt.

Ansonsten würde ich den Info DP eben nur auf Bedarf holen oder wenn Du unbedingt willst, in wesentlich längeren Zeitabständen (alle Stunde oder so).

[mickym]

@dos1973
Noch eine Anmerkung meinerseits. Ich persönlich nutze die Aufspaltung des JSON strings in einzelne Objekte nicht, da weder der Informationsgehalt steigt und Du nun aus 1 Objekt 50 Objekte machst. Gut es wird übersichtlicher dargestellt aber auch der Zugriff auf Eigenschaften eines JavaScript Objekts ist keine Hexerei und spart Ressourcen.

[dos1973]

@mickym

ja, ich hab auch recht schnell gemerkt, ich brauch die Infos eigentlich nicht.
Ich hätte gerne einezelne Werte daraus, IP, WLAN, RSSI etc. ein paar ausgewählte.

ich habe eben den Shelly Motion eingebunden, bei dem muss ich den Node-Red Ansatz fahren...

der bietet nur diese DP an.

im Status sind dann die Werte die ich für die Logik brauche, insbesondere "motion" um die Beleuchtung ein/ auszuschalten.

was mir aber heute extrem auffällt, diverse Adapter starten immer wieder neu, Zigbee, Harmony... auch der Shelly Adapter. Kann das daran liegen dass dort noch hinreferenziert wird, aber eben zT noch fehlerhaft...?

[mickym]

@dos1973 Grundsätzlich kannst Du die Parameter auch direkt abgreifen.

Wenn Du aus dem status was brauchst - dann bekommst mit der json Node ein Javascript objekt und kannst dann über payload.eigenschaft direkt darauf zugreifen. Aber egal - ich hab den Flow ja gebastelt, wenn man das in einzelnen Datenpunkten haben will.

Shelly Adapter kenn ich nicht, Harmony oder Zigbee kommunizieren ja gar nicht über mqtt - das hat meines Erachtens überhaupt nichts mit Deinen Umstellungen zu tun.

Wenn Du einzelne Werte brauchst kannst ja die Objekte selbst rauslösen bevor Du sie in die Subflow Node speist.

Aber wie gesagt auf einzelne Werte greifst einfach nach dem json Node direkt zugreifen

[dos1973]

@mickym

ich dachte ...ich änder mal "schnell" auf Mosquitto ;-)
das ganze ist ganz schön in Arbeit ausgeartet... und ich bin noch nicht fertig.

Aber ich bin damit echt zufrieden.:+1:

[dos1973]

@mickym

jetzt habe ich doch ein mittelschwere Problem in meiner VIS.

Ich benutze den DP zum schalten

mqtt.0.shellies.Küche_Lichtschalter.relay.0.command

aber die Werte Syncen sich nicht zueinander

mqtt.0.shellies.Küche_Lichtschalter.relay.0

d.h, wenn jemand das Licht am Schalter ausmacht, wird mein State nicht aktualisiert... das wäre für mich ein NoGo.

irgendeine Idee?

[mickym]

@dos1973 Wie gesagt, dass kann nicht der gleiche Datenpunkt sein.

Wenn Du den Status UND das Kommando in einem Datenpunkt behandeln willst musst Du das über einen selbst erstellten Datenpunkt machen. Das hat aber mit mqtt-Adapter nichts zu tun, sondern da hättest Du immer ein Problem. Wichtig ist, dass der Status auch bei dem Schalter immer den Status des relays wiedergibt. Ich hab es mit dem Flow sauber mit dem ACK Flag gemacht. Man kann auch nur die Änderungen filtern, aber dann läuft die Schleife logisch 2 mal durch

Der aktuelle State steht immer (also egal ob Du den Shelly am Schalter oder logisch schaltest) in

mqtt.0.shellies.Küche_Lichtschalter.relay.0

das commando ist was anderes und ist nur zum Setzen eines Kommandos da.

Sprich wenn Du einen eigen Datenpunkt erstellst, dann kannst Du es in einem eigenen Datenpunkt machen und mit dem ACK-Flag arbeiten.

VIS schickt immer ohne ACK Flag und nur auf das darfst Du dann reagieren:

Diesen DP bindest Du in Deine VIS ein.

Wenn Du mit NodeRed arbeitest kannst Du dann folgenden Flow nutzen:

Spoiler

[
   {
       "id": "3e9c2889.5dd6e8",
       "type": "ioBroker in",
       "z": "169f5b00.a13415",
       "name": "",
       "topic": "0_userdata.0.Lichtschalter",
       "payloadType": "value",
       "onlyack": "",
       "func": "rbe",
       "gap": "",
       "fireOnStart": "false",
       "x": 280,
       "y": 480,
       "wires": [
           [
               "39d2398d.c05576"
           ]
       ]
   },
   {
       "id": "39d2398d.c05576",
       "type": "switch",
       "z": "169f5b00.a13415",
       "name": "Nur ACK = False",
       "property": "acknowledged",
       "propertyType": "msg",
       "rules": [
           {
               "t": "false"
           }
       ],
       "checkall": "true",
       "repair": false,
       "outputs": 1,
       "x": 550,
       "y": 480,
       "wires": [
           [
               "68e40785.91af98",
               "f19094f3.f5a0a8"
           ]
       ]
   },
   {
       "id": "68e40785.91af98",
       "type": "ioBroker out",
       "z": "169f5b00.a13415",
       "name": "",
       "topic": "mqtt.0.shellies.Küche_Lichtschalter.relay.0.command",
       "ack": "false",
       "autoCreate": "false",
       "stateName": "",
       "role": "",
       "payloadType": "",
       "readonly": "",
       "stateUnit": "",
       "stateMin": "",
       "stateMax": "",
       "x": 910,
       "y": 480,
       "wires": []
   },
   {
       "id": "8c63547a.3b2288",
       "type": "ioBroker in",
       "z": "169f5b00.a13415",
       "name": "",
       "topic": "mqtt.0.shellies.Küche_Lichtschalter.relay.0",
       "payloadType": "value",
       "onlyack": "",
       "func": "all",
       "gap": "",
       "fireOnStart": "false",
       "x": 320,
       "y": 580,
       "wires": [
           [
               "6587948d.dc03bc"
           ]
       ]
   },
   {
       "id": "6587948d.dc03bc",
       "type": "ioBroker out",
       "z": "169f5b00.a13415",
       "name": "",
       "topic": "0_userdata.0.Lichtschalter",
       "ack": "true",
       "autoCreate": "false",
       "stateName": "",
       "role": "",
       "payloadType": "",
       "readonly": "",
       "stateUnit": "",
       "stateMin": "",
       "stateMax": "",
       "x": 720,
       "y": 580,
       "wires": []
   },
   {
       "id": "f19094f3.f5a0a8",
       "type": "debug",
       "z": "169f5b00.a13415",
       "name": "",
       "active": true,
       "tosidebar": true,
       "console": false,
       "tostatus": false,
       "complete": "false",
       "statusVal": "",
       "statusType": "auto",
       "x": 790,
       "y": 440,
       "wires": []
   },
   {
       "id": "9c870f79.6d6f5",
       "type": "inject",
       "z": "169f5b00.a13415",
       "name": "",
       "props": [
           {
               "p": "payload"
           }
       ],
       "repeat": "",
       "crontab": "",
       "once": false,
       "onceDelay": 0.1,
       "topic": "",
       "payload": "off",
       "payloadType": "str",
       "x": 430,
       "y": 620,
       "wires": [
           [
               "6587948d.dc03bc"
           ]
       ]
   },
   {
       "id": "56ee62e6.5a107c",
       "type": "comment",
       "z": "169f5b00.a13415",
       "name": "Aktualisierung durch VIS - wenn ACK false",
       "info": "",
       "x": 340,
       "y": 420,
       "wires": []
   },
   {
       "id": "b137c5d6.0ccff8",
       "type": "comment",
       "z": "169f5b00.a13415",
       "name": "Aktualisierung durch den Shelly",
       "info": "",
       "x": 310,
       "y": 540,
       "wires": []
   }
]

Die Visualisierung sollte also von der eigentlichen Steuerung getrennt werden. Beim Shelly Adapter hat der Adapter einen Datenpunkt nutzen können, weil er selbst über das ACK Flag gearbeitet hat. Sprich das ACK Flag von VIS wurde nicht gesetzt und der Adapter wusste, er musste schalten.
Wenn der Shelly hingegen gemeldet hat, dass er geschaltet hat, hat er das mit ACK Flag gesetzt und somit konnte er selbst eine Endlosschleife verhindern. Du baust nun diese Logik mach.

Das ist grundsätzlich so. Auch wenn Du mit Tasmota arbeitest sind die Kommandodatenpunkte und die Zustandsdatenpunkte immer verschieden, sonst würdest Du immer in einer Endlosschleife landen.

In der iobroker-out Node setzt Du das ACK Flag durch den Type:

Type value = ACK gesetzt also Wert bestätigt

Type command = ACK nicht gesetzt. also Wert unbestätigt

In diesem Fall ist es halt deshalb nötig über einen eigenen Datenpunkt zu arbeiten, weil Du 2 verschiedene Möglichkeiten zum Schalten hast. Würdest Du nur über die VIS schalten, wäre der Status ja in der Regel immer mit der Schalterstellung identisch.
Ich schalte sogar über 3 Möglichkeiten

• über meine Visualisierung (Dashboard)
• über den physischen Schalter
• über Siri - bzw. Yahka Adapter (oder Alexa etc.)

Insofern nimmt der Adapter schon einiges an Arbeit ab, aber es sind keine unüberwindlichen Hindernisse. :innocent: :grin:

[dos1973]

@mickym

ich stehe eben auf dem Schlauch.
ich habe dein Flow importiert, habe einen DP "0_userdata.0.Wohnung.Status.Shellys.Küche" angelegt und die Flows verbunden.

der DP aktualisiert sich wie der Shelly On/off , aber ich kann darüber nicht schalten?

Das mit dem ACK - wo finde ich diese Einstellung?

[mickym]

Du schickst über Deine VIS kein on/off sondern true/false

ich hab es Dir markiert.

[mickym]

@dos1973 sagte in Mqtt best practice:

Das mit dem ACK - wo finde ich diese Einstellung?

Habe ich Dir doch lange beschrieben. In der iobroker out Node - value (ACK =true) - command (ACK = false).

VIS schickt nie ein ACK=true sondern immer ACK=false.

[dos1973]

@mickym
sorry, ich verstehe momentan gar nicht, was du mir versuchst zu erklären.

ich hatte gedacht verstanden zu haben, dass ich aus der userdata DP die Schaltung mittels true/ falls machen kann. Das klappt nicht, der DP aktualisiert, aber das hilft mir ja nicht für mein VIS

[mickym]

@dos1973 Ich verstehe Dich nicht:

Du schaltest doch mit on und off hier? Du musst nur als Object ID den 0_userdata DP eintragen.

Ansonsten wenn vis nur mit true und false umgehen kann, was ich aber nicht glaube - dann kannst natürlich übersetzen - aber eigentlich dachte ich, dass Du über die VIS direkt on und off schickst.