Beiträge von 87insane

    Hallo zusammen,

    da es immer wieder Verständnis-Probleme im Zusammenhang mit MQTT gibt, wollte ich hier mal ein FAQ starten.

    Stellt fleißig Eure Fragen. Bitte ggf. auch Fragen, die hier irgendwo in den Tiefen des Forums begraben sind / alte Fragen. Am Ende profitieren wir alle davon. Jeder der nur mal kurz die Erinnerung auffrischen will oder aber jeder Neuling, kann dann hier auf die Schnelle nachsehen.

    Ich werde mich bemühen, alles so gut und detailliert, wie nur möglich, zu beantworten.

    Wie immer gilt: Das ganze lebt von und mit uns/Euch :)

    Danke!

    Erklärung zu den MQTT Einstellungen in einem Shelly:

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.


    Fragen & Antworten:

    1. Woher kommt der Online-State vom Shelly, bzw. wovon ist dieser abhängig? Beitrag #3

    2. Wie kann ich mir bequem die MQTT-Topics und Werte anzeigen lassen? Wie kann ich Eingaben testen? Beitrag #9

    3. Gibt es eigentlich eine Übersicht, welche Topics der Shelly publicht oder subscribt? Klick mich

    ...

    4. Hier könnte deine Frage stehen.... ;)

    Also mit dem normalen Sonos Play 1 (ohne Alexa, das wäre Play One) geht das gut. Du hast aber immer eine Cloud am Ende stehen. Bei den Sonos kannst du diese nach Einrichtung aber aus machen. Leider kostet gutes Spielzeug mehr ;)

    Hab das selber mit Sonos gemacht und finde es super.

    "Es hat vorne / hinten geklingelt"

    "Die Waschmaschine / Der Trockner ist fertig" usw...

    Moin nochmal...

    ich weiß nicht genau welches Template du genutzt hast. Vermutlich ist deine attrtemplate Datei nicht aktuell.

    Geh mal in den zweiten Channel und füge folgendes in die readingsList ein:

    Code
    shellies/shellyswitch-32C160/relay/1:.* state
    shellies/shellyswitch-32C160/relay/power:.* power
    shellies/shellyswitch-32C160/relay/energy:.* energy
    shellies/shellyswitch-32C160/input/1:.* input_1
    shellies/shellyswitch-32C160/online:.* online
    shellies/shellyswitch-32C160/announce:.* { json2nameValue($EVENT) }
    shellies/announce:.* { $EVENT =~ m,..id...shellyswitch-32C160...mac.*, ? json2nameValue($EVENT) : undef }

    Alles andere dort drin, bitte löschen.

    Danach einfach den Shelly neu starten. Die Optik ist dann, wie beim ersten Channel und der kleine Kreis = grün :)

    In deinem Channel 1 könnte man noch die ganzen shellyswitch_32C160: in der readingsList entfernen. Das hat aber nur optische Gründe. Kannst du auch lassen.

    Als Beispiel:

    shellyswitch_32C160:shellies/shellyswitch-32C160/relay/power:.* power

    so sieht es bei dir aus. Aber so sollte es korrekter Weise aussehen:

    shellies/shellyswitch-32C160/relay/power:.* power

    Die Funktion bleibt aber wie gehabt.

    Kurz erklärt:

    Die Shelly senden einen online/offline Satus. Dieser ist beim Shelly 2/2.5 natürlich bei beiden Channeln, der gleiche Zustand.

    Die Energie Messung ist bei dem 2er (entgegen dem 2.5er) leider echt nur über beide Kanäle. Bei dem 2.5er hat man pro Kanal eine separate Messung.

    das ist korrekt...aber die die das Thema hatten, hatten das entweder a) direkt in der Antenne oder b) genau da wo das Bild das zeigt.

    Hatte davon zum Glück keinen.

    Mach mal deine 2.5er auf. Da sollte kein Abdruck zu sehen sein.

    Würde aber einfach tauschen lassen. Wenn du bei Shelly direkt bestellt hast, ist das kein Problem (so lange du das Backup der original fw hast).

    1. davon ging ich aus...

    2. ja klar, die werte sind die gleichen. Nur das über mqtt eben andere Ereignisse kommen. Zb fehlt in der mqtt Implementation bei den shellys auch einiges noch. Der WLAN Name usw wird ja auch nicht mit gesendet. Aber via http GET schon. Dafür ist natürlich der mqtt connnect Status in dem Protokoll separat. Last will....macht an der stelle ja auch Sinn.

    Warum man bei den shellys einmalig announcen muss, ist für mich auch komisch. Da aber in den updates auch immer wieder mqtt erweitert wird, denke ich, wird das auch nicht mehr lange so sein. Ist auch ein Grund warum das nie mit in den Templates war. Aber wurde vor ein paar Tagen mit eingebaut. Tut ja auch nicht weh einen announce mehr zu haben, wenn er dann doch in der Firmware kommen sollte.

    Alles richtig verstanden. Wie aber schon gesagt...super hinweis. Nehme das mit auf. Die Namen der readings selber, sind aber in fhem Manier. Kann man bei Bedarf aber auch in der readingslist einfach anpassen.

    Glaube auch das die mqtt Einstellungen von den meisten so gelassen werden wie sie sind. Außer ggf. User/pw und IP. Werde mich die Tage mal an den pc setzen und mit dem gewonnen Infos, ein Bild und ne Anleitung fertig machen.

    kein Edit, damit es auch als Info auf ploppt.

    Habe gerade mal rein gesehen. Ich werde das mal in den FAQ Bereich mit aufnehmen und die einzelnen Bestandteile von mqtt auf Schlüsseln. Wusste nicht das die so unbekannt sind. Aber genau das ist gut, dass du das so fragst. Guter Hinweis.

    In deinem ersten Post, sieht man relativ gut das du davon ausgehst, das die Daten, die fhem bekommt, diese sind, die bei http://ip/status erscheinen.

    Das ist aber nicht so. Das ist http GET. Da du aber mqtt nutzt sieht die payload ein wenig anders aus.

    Hast du aufgrund der Erkenntnisse ggf weitere fragen? Gehe davon aus, dass vermutlich kaum einer das alles überhaupt weiß. Habe ich aber noch nie drüber nach gedacht, da ich relativ viel mit mqtt arbeite. Um so mehr fragen, um so besser kann ich das mit aufnehmen. Sicher wäre das für viele User sehr, seht gut!

    Danke! Danke!

    das ist ganz einfach :)

    Du vertauscht einfach die Funktionen von http get und mqtt. Mqtt liefert die payload.

    availability message on shellies/<shellymodel>-<deviceid>/online with payload true

    Bei mqtt ist das immer so....

    Gerät verbindet sich mit Server und meldet sich an (online)

    Danach kann das gerät erst Daten senden. Sollte das Gerät zb Strom verlieren zählt der Last will (LW). Der wird nach dem anmeldet mit gesendet. In diesem steht drin was passieren soll wenn der shelly sich in dem eingestellten Zeit Bereich nicht mehr meldet. In dem Moment nachdem das Gerät sich am mqtt Server angemeldet hat, sendet das Gerät von nun an zum einen im Intervall aber auch bei Änderungen seinen Status. Kannst du alles in deinen mqtt settings in deinem shelly sehen.

    Habe zb ein paar Skripte auf meinem pc, diese müssen sich auch am fhem mqtt anmelden und sendet dann eben was ich will. Da habe ich zb keinen Last will drin, da es dort keinen sinn machen würde.

    Hatte das auch irgendwo hier mal komplett aufgeschlüsselt.

    Bin mir sicher das du das in meinem FAQ unter Anleitungen findest ;)

    ach ja und das mit der power Messung ... Der Shelly 2.5 liefert einen gesamt wert, einen für Channel 1 und einen für Channel 2.

    Der rote Punkt hat auch nix mit der cloud zu tun. Das ist der tatsächliche mqtt Verbindungs Status.

    Nochmal Edit: der Split mehrkanaliger Geräte hat einen Vorteil. Solange man die config nicht groß manuell anpassen will, kann man so, die Geräte direkt auch via alexa fhem steuern. Die shellys haben entgegen dessen wie man das von tasmota kennt, keine direkte Emulation und müssen also über alexa fhem eingebunden werden. Mir falles noch mehr Sachen ein aber ich denke das ist hier OT.

    bei Google einfach mal Shelly API eingeben. Da hast du schon mal alle Infos an sich. Wie du dann am sinnvollsten die Abfrage Schleife laufen lässt, wüsste ich aus dem stehgreif nicht. Ist sicher auch ne Versuchs Reihe. Am besten ist vermutlich aber ein mqtt Server auf zu setzen und diesen dann ab zu fragen. Dann kommen die Werte von alleine und du muss diese nicht abfragen.

    Die werte könntest du dann weg schreiben oder eben direkt verwerten.

    Ist zwar kein code aber ggf hilft die Idee.

    Ps: JAP das ist ne gute Begründung :)

    PPS: HTML ist kein programmieren. Das ist nur formatieren :-P

    Auf qnap und auch synology kannste auch fhem u Co nutzen. Alles was du da "manuell" machst kann fhem. Hab selber synology in Betrieb mit x Anpassungen, für x Anwendungen. Ich liebe das kleine Teil für zuhause.

    Hattest deine Abneigung gegenüber fhem bzw andere ja schon erwähnt. Mich würde interessieren, warum? Bevor ich mir x Skripte baue, für eine sache die bereits existiert und sicher auch runder läuft. Ich Skripte selber gern aber da fehlt mir vermutlich dein Gedanken Strom :)

    Lese gerade die ganzen Beiträge. Kann verstehen das man ggf nicht alles direkt findet aber so versteckt sind die Beiträge nicht.

    Die Admins haben die sogar extra gepinnt.

    FHEM - FAQ / Fragen von Nutzern für Nutzer


    Wie in dem anderen Thread schon gesagt.. Tippt eure Fragen gerne einfach mal runter. Ich beantworte diese alle, so schnell es geht. Dafür ist das Forum ja da :)

    Edit: Anbei auch mal die REST API Doku und Mqtt...

    Bitte am Ende noch sagen ob dich das so weiter gebracht hat...setze das dann mit in die FAQ.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Ach ja...noch ein Hinweis... Web Status / GET ist nicht gleich MQTT payload.

    Hallo zusammen,

    leider habe ich das jetzt erst gesehen. Habe im fhem Bereich weitreichende Erklärungen zu allem möglichem verfasst.

    Die templates kommen von Beta-User und mir aus dem fhem Forum. Der rote Punkt nach der Einrichtung kommt, weil kein automatisches announce gesendet wird nach Template Wahl. Zwei Möglichkeiten hast du da. 1. shelly einfach neu starten. 2. set x_mqttcom announce. Danach ist der Punkt grün und verhält sich wie gewünscht.

    Welche "gemischten Gefühle" hast du/ihr bei den Templates? Welche Fragen sind offen? Helfe gerne...einfach melden ;)

    Anbei mal wie es sein sollte nach Templates. Die Templates sind natürlich nur Inspiration von dem, was so geht. Auch mqtt fragen sollte ich alle beantworten können. Am besten einfach mal alle offenen fragen runter tippen, bitte.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.