Beiträge von supernova1963

    Every minute the shelly pro 3EM publish the sum of act energy and act returned energy to the emdata topic:

    Bedenkt bitte, dass der Passwortschutz des Shelly, wenn er denn per http://name:password@<shelly-ip> z.B. von einem anderen Shelly geschaltet wird, im Fall der Fälle, rein gar nichts mehr wert ist.

    Das Thema Sicherheit und Schalten per http passen einfach nicht zusammen. Das alte Feature sollte meiner Ansicht nach nicht auf Basis der Argumentation "Sicherheit" gefordert werden.

    Das Reduzieren der "geloggten" Werte hat helmi55 im FHEM Forum gepostet. Als Bespiel alle Readings-Änderungen höchstens alle 60 Sekunden, und, damit relay, input und online bei jeder Änderung ein event erzeugen:

    Code
    attr <fhem devicename> event-min-interval .*:60
    attr <fhem devicename> event-on-change-reading state,input0,online

    [script][/script]

    [script]event-min-interval [/script]

    [script]Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings:minInterval" Paare. readings kann ein regexp sein. Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind. Falls event-on-change-reading auch spezifiziert ist, dann werden sie mit ODER kombiniert, d.h. wenn einer der beiden Bedingungen wahr ist. [/script]

    [script][/script]

    Ich bezweifle zwar, dass das erstellen mehreren FHEM devices Ressourcen schonend ist, aber möglich ist alles.

    Könnte das ein mögliches Ergebnis der von der.fpg gewünschten ersten 3 Schritte?

    Achtung im "raw Format":

    Ich versuche es 'mal "in ganz groben" Zügen mit extremen Vereinfachungen zu beschreiben (ersetzt keinesfalls das Lesen und Verstehen der Dokumentationen zu FHEM: commandRef und Wiki's zu diesem Thema, sowie von MQTT selbst) :

    Vorab

    Es gibt mehrere Wege ein MQTT sendendes / empfangendes Gerät in FHEM einzubinden.

    Entweder man bindet einen externen Broker mit dem das Gerät kommuniziert über ein FHEM IO Device vom Typ MQTT_SERVER ein und definiert dann manuell die gewünschten FHEM devices vom Typ MQTT_DEVICE, oder, man definiert ein FHEM Device vom Typ MQTT2_SERVER als IO device, das sich "nach außen" genau wie ein "echter" MQTT Broker verhält. Dann kann man die Vorteile der automatischen Anlage von FHEM devices vom Typ MQTT2_DEVICE und der automatisierten Pflege des readingsList Attributes nutzen.

    MQTT2_SERVER und MQTT2_DEVICE (Empfehlung, macht den Einstieg leichter):

    Das definierte MQTT2_SERVER device verhält sich gegenüber externen Geräten wie ein MQTT-Broker und empfängt MQTT Messages oder sendet MQTT messages an Subscriber (kann also einen Broker wie z.B. mosquitto weitgehend ersetzen)!

    Ist das "autocreate" Attribut des MQTT2_SERVER device nicht explizit ausgeschaltet, legt dieser automatisch für alle eingehenden MQTT Nachrichten dieses Gerätes (MQTT ClientID) ein entsprechendes FHEM-device vom Typ MQTT2_DEVICE mit dem entsprechenden readingsList Attribut an.

    Die Elemente (Zeilen) des readingsList Attributs des FHEM-devices vom Typ MQTT2_DEVICE entsprechen den MQTT subscriptions. Sie werden auf Basis der in jeder Zeile definierten Regeln in readings zu diesem FHEM-device ausgegeben.

    Ist das Attribut "autocreate" des FHEM-devices von Typ MQTT2_DEVICE nicht explizit deaktiviert, wird jede eingehende MQTT Nachricht, die von diesem sendenden Gerätes (die Identifikation erfolgt über die ClientID dieses Gerätes) automatisch im readingsList Attribut ergänzt.

    Dabei wird der gesendete Inhalt (MQTT: payload) analysiert und, im Fall eines einzelnen Wertes String, Boolean, number, einem einzelnen reading zugeordnet, oder, im Fall von gültigem json in mehrere readings ausgegeben (json2namevalue(...)).

    Im Attribut "setList" des FHEM-devices können möglich MQTT publish commands zu diesem Gerät eingetragen werden.

    Verwendest man den MQTT2_SERVER werden viele notwendigen Schritte zu möglichen "subscriptions" in FHEM weitgehend automatisiert angelegt.

    Spezielle Aufbereitungen z.B. zur Darstellung, Interpretation/Aufbereitung von payloads und der möglicherweise geeigneten MQTT publish Commands (setList) werden für viele bekannte Geräte (u.A. auch shelly3em) als attrTemplate als mögliche Vorlage zur Definitionsanpassung des FHEM-devices vom Typ MQTT2_DEVICE angeboten.

    Schritte zum Kopieren in Kommandozeile bzw. in Multiline Command :

    1. MQTT2_SERVER anlegen (= MQTT Broker):

    Code
    define mqtt MQTT2_SERVER 1883 global

    2. [optional] basicAuth für mqtt anlegen

    (Hinweis: Ist in den MQTT Eingaben am Gerät als username und password zu erfassen):

    Code
    define allowed_mqtt allowed 
    attr allowed_mqtt validFor mqtt 
    set allowed_mqtt basicAuth  <username> <password> 

    3. Anschliessend am Shelly 3 EM unter Internet & Security - ADVANCED - DEVELOPER SETTINGS unter:

    • X Enable MQTT
    • Username: <username>
    • Password: <password>
    • Server: <ip vom FHEM Server>:1883
    • Custom MQTT prefix:
    • X Use custom MQTT prefix
    • <shelly3em_01>
    • Min reconnect timeout 2
    • Max reconnect timeout: 60
    • Keep alive: 60
    • O Clean Session
    • X Retain
    • Max QoS 0

    mit Save speichern. Anschließend bootet der shelly neu und sendet nachdem hochfahren die ersten Daten an dem MQTT Broker (hier: FHEM)

    Aufgrund des aktiven "autocreate" wir in FHEM im Raum MQTT2_DEVICE ein neues Device (wahrscheinlich: MQTT2_<shelly3em_01> angelegt.

    Automatisch werden alle eingehenden MQTT Nachrichten, die mit der ClientID an den MQTT Broker (hier: FHEM) in dem readingsList Attribut eingetragen und die entsprechenden readings angelegt bzw. aktualisiert.

    4. Jetzt kann man ggf. mit dem FHEM-Befehl:

    Code
    set MQTT2_<shelly3em_01> attrTemplate shelly3em

    ein Template zu diesem Shelly 3 EM Gerät ausführen.

    Danach sollten weitgehend nachvollziehbare attribute an diesem FHEM-device gesetzt worden sein und die FHEM-web Darstellung sinnvoll aufbereitet werden.

    Diese Vorlagen sind jedoch nur Vorschläge/Möglichkeiten zur FHEM-Device Definition, damit unerfahrene Benutzer einfacher geeignete Ergebnisse erhalten.

    5. Logging

    Das FHEM-FileLog ist das, was Du irrtümlich als MQTT Messaging interpretiert hast. FHEM devices vom Typ FileLog erstellen Text Datei(en) im Filesystem aus allen FHEM Ereignissen, die durch eine geeignete Regex gefiltert wurden. In den von Dir herangezogenen Beiträgen des "Sammelthreads" geht es darum, ob bei allen oder nur ausgewählten Änderungen ein Ereignis (Event) erzeugt werden soll, das in dann zur Summen-/Differenzermittlung in userReadings verwendet werden und je nach FileLog Definition auch zu einem Eintrag im FileLog führt. (siehe Beispiel von helmi55)

    Im Übrigen wird ein Standard FileLog Device (FileLog_MQTT2_...) automatisch bei dem Ereignis der ersten MQTT Message eines neuen Gerätes (mit neuer ClientID) angelegt. Dieses FileLog ist häufig die Basis für die grafisch Darstellung.

    Weitere Hilfe gerne in einem neuen Thema im fhem Forum unter MQTT ...

    Das heißt das überall wo in deinem Haus Stromleitungen liegen hochfrequente Wellen abgegeben werden. Ich weiß nicht wie stark das heutzutage ist aber damals als die Dinger auf den Markt kamen haben wir mit einem Spektrumanalyser die Dinger getestet und es war grauenhaft.

    Gibt es zu "grauenhaft" konkrete Informationen? Ich muß meine "Bessere Hälfte" davon überzeugen, noch 2 x UAP Flex HD an Stelle des DLAN's aufzustellen!

    Danke,

    Gernot

    Hey schaddudel ,

    ich möchte Dich auf einige, vielleicht nicht ganz zu vernachlässigenden Punkte, aufmerksam machen (ohne zu belehren):

    • Shellies beherrschen nur einen bereits jetzt alten WLAN Standard,
    • Funk ist nicht so sicher, wie Kabel,
    • Eine zentrale Steuerung hat auch Vorteile
    • Es gibt auch Shellies für die UV oder entsprechende Halter

    Das geniale an den Shellies ist imo die Möglichkeit nachzurüsten ohne Kabel zu verlegen.

    Für einen Neubau empfehle ich Kabel und/oder Leerrohre.