Neues MQTT Plugin

[henfri]

Hallo,

@sisamiwe
Das kommt davon, wenn man die Dokumentation liest. Da steht On und Off. Dabei kann sie auch 1 und 0
klab und zwar auch ohne die zwei Kommandos!
Danke für den Hinweis.

Dennoch bleibe ich dabei, dass mein Vorschlag sinnvoll ist...

Bisher ist da noch gar nichts rumgekommen. Ich habe einige Punkte für das MQTT Plugin. Ich wollte das mit der Anpassung des Plugins für MQTT 5.0 machen. Allerdings zieht sich das Release des v5.0 kompatiblen paho-mqtt Packages.

und doch ganz unabhängig von MQTT 5.0...

Gruß,
Hendrik

[klab]

Hallo,
folgendes in der Konsole von tasmota und die Steckdose nutzt 1 / 0 statt ON / OFF.
Dann kannst Du das Hilfsitem sparen. :-)

StateText1 0
StateText2 1

siehe

https://github.com/arendst/Tasmota/wiki/Commands#how-to-use-commands

Gruß
kla.b

[Sisamiwe]

Ich will gerade eine SonOff Steckdose per MQTT einbinden
Sie braucht statt 1 und 0 per MQTT ON und OFF

Hallo,
ich habe auch diverse SONOFF eingebunden und nutze die Tasmota FW und MQTT. Ich mach das ohne Hilfitems so:

sonoff:
    sonoff_b1:
        type: str
        mqtt_topic_in: SONOFF_B1/tele/LWT
        telegram_message: 'sonoff_b1: [VALUE]!'
        switch:
            type: bool
            mqtt_topic_out: SONOFF_B1/cmnd/POWER
        switch_num:
            name: 0-off, 1-on, 2-toggle
            type: num
            mqtt_topic_out: SONOFF_B1/cmnd/POWER
            uzsu:
                type: dict
                uzsu_item: ..
                cache: yes
                trigger:
                    type: bool
                    on_update: "... = value if (sh....uzsu.planned()['value'] != value) and (sh....uzsu.activate() == True) else None"

        power:
            type: str
            mqtt_topic_in: SONOFF_B1/stat/POWER
            cache: yes
            on_update: sonoff.sonoff_b1.switch = value == "ON"
        sensor:
            type: dict
            mqtt_topic_in: SONOFF_B1/tele/SENSOR
            cache: yes
            #{"time":"2018-08-18t16:51:02","ds18b20":{"temperature":26.1},"tempunit":"C"}
            temp:
                type: num
                eval: sh...()['DS18B20']['Temperature']
                eval_trigger: ..
            unit:
                type: str
                eval: sh...()['TempUnit']
                eval_trigger: ..
        status:
            type: dict
            mqtt_topic_in: SONOFF_B1/tele/STATE
            cache: yes
            #SONOFF_B1/tele/STATE = {"Time":"2019-08-05T21:25:48","Uptime":"3T01:20:20","Heap":16,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"ON","Wifi":{"AP":1,"SSId":"WLAN-Access","BSSId":"CC:CE:1E:C4:EF:11","Channel":1,"RSSI":72,"LinkCount":2,"Downtime":"0T00:00:09"}}
            loadave:
                type: num
                eval: sh...()['LoadAvg']
                eval_trigger: ..
            power:
                type: str
                eval: sh...()['POWER']
                eval_trigger: ..
                on_change:
                  - sonoff.sonoff_b1.switch = value == "ON"
            ssid:
                type: str
                eval: sh...()['Wifi']['SSId']
                eval_trigger: ..
            valid:
                type: bool
                name: SONOFF sendet noch
                eval: (value != '$$!!%%')
                eval_trigger: ..
                autotimer: 600 = $$!!%%

Du musst glaube ich die englische FW nutzen, mit der deutschen geht es glaube ich nicht so.

Michael

[Msinn]

Bisher ist da noch gar nichts rumgekommen. Ich habe einige Punkte für das MQTT Plugin. Ich wollte das mit der Anpassung des Plugins für MQTT 5.0 machen. Allerdings zieht sich das Release des v5.0 kompatiblen paho-mqtt Packages.

[henfri]

Moin,

Da denke ich noch drauf rum.

Was ist hierbei rumgekommen?

Ich will gerade eine SonOff Steckdose per MQTT einbinden
Sie braucht statt 1 und 0 per MQTT ON und OFF

Ich habe keine Lust auf Hilfsitem-Spielereien und hatte weiter oben ja schon funktionierenden Code und die Bereitschaft für einen PR gezeigt.
Was sagst du?

Gruß,
Hendrik

[GHild]

Vielen Dank für die beiden Vorschläge.

Ich habe mich für den ersten entschieden, da mir das Pushen für diesen Anwendungsfall sinnvoller erschien.

Zur Dokumentation noch meine neue Item-Definition:

EG:
    HWR:
        LaserJet:
            name: EG_HWR_LaserJet
            type: bool
            on_change: mqtt.hplaserjet_out = '{ "state":"on"}' if sh.EG.HWR.LaserJet() else '{"state":"off"}'
            enforce_updates: 'true'
            visu_acl: rw

Funktioniert ebenso, ist aber viel schlanker. Prima.

[Msinn]

Du könntest auf die Logik verzichten und im HWR.LaserJet mit on_change direkt die gewünschten Werte in hplaserjet_out setzen.

Alternativ könntest Du mit einem eval in hplaserjet_out den String in Abhängigkeit von HWR.LaserJet berechnen.

[GHild]

Tatsächlich, das war's, es funktioniert wie gedacht. Wie oft habe ich darauf geschaut, ob ich mich vertippt habe.

Vielen Dank für den Hinweis!

Nun noch die Frage, ob es einen einfacheren Weg gibt?

[knxms]

Hallo!
Ist da ein Tippfehler in „watch_item:...“ ...?
EG.HWR.LaserLet <—>. EG.HWR.LaserJet

[GHild]

Hallo,

zum Schalten meiner neuen Osram Zigbee Steckdose nutze ich zigbee2mqtt, mosquitto und das mqtt Plugin der shNG (V1.6).

Vielleicht ist es ein allgemeineres Problem, da es sich aber auf Post #106 bezieht, poste ich es hier.

Zur Kommunikation mit dem mqtt Broker verwende ich das Item:

mqtt:
  hplaserjet_out:
    name: hplaserjet_out
    type: str
    visu_acl: rw
    enforce_uptdates: true
    mqtt_topic_out: 'zigbee2mqtt/osramdose1/set'

das durch die folgende Logik switch_osramdose1.py gesetzt wird:

#!/usr/bin/env python3

logger.info("GEH LOGIK {0}".format( logic.filename))

if sh.EG.HWR.LaserJet():
    sh.mqtt.hplaserjet_out( '{"state": "on"}' )
else:
    sh.mqtt.hplaserjet_out( '{"state": "off"}' )

Zum Schalten habe ich ein weiteres Item definiert, auf das ich über die smartVISU zugreifen möchte:

EG:
   HWR:
        name: EG_HWR
        SV_page: room
       
        LaserJet:
            name: EG_HWR_LaserJet
            type: bool
            enforce_updates: 'true'
            visu_acl: rw

Dieses Item soll dann meine Logik triggern (in logics.yaml):

HpLaserJet:
    filename: switch_osramdose1.py
    watch_item: EG.HWR.LaserLet

Im Log-File sieht alles gut aus, im Backend auch. Allerdings wird beim Umschalten des Items EG.HWR.LaserJet die Logik nicht getriggert. Ich habe im backend den Wert geändert und auch im interaktiven Modus, ohne Erfolg. Führe ich im Backend die Logik manuell aus, schaltet die Steckdose. Die Kommunikation mit dem broker scheint zu funktionieren. Es sieht so aus, also ob das watch_item die Logik nicht triggert. Woran könnte das liegen?

Gibt es einen einfacheren Weg als über 2 Items und eine Logik zu gehen?

Danke & Grüße
Gerd

[msteffel]

Hallo Martin.

WOW. Das war einfach - und hat (fast) auf Anhieb geklappt.
Jetzt kann ich sogar per MQTT die Lüftungsstufe der Anlage schneller / langsamer stellen.
Temperaturen auslesen geht auch.
Vielen lieben Dank!
Wie lange ich mich damit geplagt hab, und dabei habe ich immer zu kompliziert gedacht.
Nochmals vielen Dank und viele Grüße

Martin.

[Msinn]

Eine Möglichkeit die Werte zu senden ist, in jedem Item ein mqtt_topic bzw. mqtt_topic_out zu definieren. Ich habe das beispielhaft für die ersten 3 Items mal getan:

ventilation:
   rs485:
       _fanspeed:
           name: 'Aktuelle Lüftungsstufe (EC300Pro: 1..8)'
           type: num
           helios_var: fanspeed
           visu_acl: rw
           sqlite: 'yes'
           mqtt_topic_out: 'lueftung_stufe'
# hier kommt noch viel Zeug, was ich nicht übertragen möchte
#...
# folgendes dann doch wieder:
   # Summer bypass
   bypass:
       # '============================================================================================ #'
       is_on:
           name: Summer bypass on --> 1
           type: num
           eval: 1 if (sh.ventilation.rs485._bypass_disabled()==0) else 0
           eval_trigger: ventilation.rs485._bypass_disabled
           mqtt_topic_out: 'lueftung_bypass'
       _outside_temp:
           name: 'DIN/EN: Außenluft, outdoor air / ODA, grün; Luft von draussen'
           type: num
           helios_var: outside_temp
           visu_acl: r
           sqlite: 'yes'
           mqtt_topic_out: 'temp_aussen'

         ...

Eine andere Möglichkeit wäre, ein Hilfseitem anzulegen und dort die Werte so aufzubereiten, wie der empfangende Client sie benötigt (z.B. einen Json String zu senden).

[msteffel]

Guten Abend,

Hier die Definitionen der Items, die ich übertragen möchte, aus der helios.yaml

ventilation:
    rs485:
        _fanspeed:
            name: 'Aktuelle Lüftungsstufe (EC300Pro: 1..8)'
            type: num
            helios_var: fanspeed
            visu_acl: rw
            sqlite: 'yes'
# hier kommt noch viel Zeug, was ich nicht übertragen möchte
#...
# folgendes dann doch wieder:
    # Summer bypass
    bypass:

        # '============================================================================================ #'
        is_on:
            name: Summer bypass on --> 1
            type: num
            eval: 1 if (sh.ventilation.rs485._bypass_disabled()==0) else 0
            eval_trigger: ventilation.rs485._bypass_disabled
        _outside_temp:
            name: 'DIN/EN: Außenluft, outdoor air / ODA, grün; Luft von draussen'
            type: num
            helios_var: outside_temp
            visu_acl: r
            sqlite: 'yes'

        # rrd: yes
        # rrd_min: yes
        # rrd_max: yes
        # Achtung: Bei starkem Frost wird der Zuluftventilator automatisch gestoppt.
        # In diesem Fall weicht die 'outside_temp' von der tatsächlichen Außentemperatur
        # stark ab, da keine Frischluft mehr in die Anlage geführt wird.
        # (Erwärmung des WT Anlage durch die Raumtemperatur sowie durch die ggf. gerade
        # abkühlende Vorheizung verfälschen dann die Werte)
        _incoming_temp:
            name: 'DIN/EN: Zuluft, supply air / SUP, blau; Luft in die Räume'
            type: num
            helios_var: incoming_temp
            visu_acl: r
            sqlite: 'yes'

        # rrd: yes
        # rrd_min: yes
        # rrd_max: yes
        _inside_temp:
            name: 'DIN/EN: Abluft, extract air / ETA, gelb; Luft aus den Räumen'
            type: num
            cache: true    # schmeisst sonst beim Start Fehler div/0 bei Berechnungen
            helios_var: inside_temp
            visu_acl: r
            sqlite: 'yes'

        # rrd: yes
        # rrd_min: yes
        # rrd_max: yes
        _exhaust_temp:
            name: 'DIN/EN: Fortluft, exhaust air, braun; Luft nach draussen'
            type: num
            helios_var: exhaust_temp
            visu_acl: r
            sqlite: 'yes'

die MQTT-Topics sind noch frei definierbar. Folgende Topics kann ich mir für die entsprechenden items (in []) vorstellen:

lueftung/stufe                 [ventilation:rs485:fanspeed]
lueftung/bypass              [ventilation:bypass:_ison]
lueftung/temp_aussen    [ventilation:bypass:_outside_temp]
lueftung/temp_zuluft       [ventilation:bypass:_incoming_temp]
lueftung/temp_raumluft   [ventilation:bypass:_inside_temp]
lueftung/temp_fortluft      [ventilation:bypass:_exhaust_temp]

Die Items [ventilation:rs485:fanspeed] und [ventilation:bypass:_ison] würde ich gerne per MQTT schreiben können, also den Bypass aktivieren / deaktivieren und die Lüftungsstufe steuern.
Es gibt noch einige Items mit dem Namen booster - das könnte eine interessante Funktion für später sein, aber ich will es ja nicht gleich übertreiben.
Ich hoffe, das ist verständlich geschrieben - falls nicht liefere ich nach Kräften nach!

Danke sehr und gute Nacht.

[Msinn]

Poste doch mal die Definitionen der Items die Du übertragen möchtest und die Namen der MQTT Topics unter denen das passieren soll.

[msteffel]

Guten Morgen Martin,

das ist genau richtig. Ich möchte die Werte, die das helios Plugin auf dem Raspberry von der Lüftungsanlage empfängt per MQTT weitersenden - und auch Werte per MQTT an den Raspberry schicken, die dieser dann per helios Plugin an die Lüftung weitergibt.

Bei mir läuft ein Mosquitto MQTT Broker und ein Openhab System, das die Werte empfangen soll - ggf. sollen einzelne von da aus noch auf den KNX-Bus gesendet werden. Aber da bin ich noch sehr weit weg.

Ziel 1 ist, Werte von der Helios Lüftung auf den Openhab zu bekommen (logische, numerische und evtl. gibt es noch weitere). In Openhab bin ich ein wenig fitter und traue mir zu, die Werte ins benötigte Format zu konvertieren (aber manchmal ist mein Mut auch größer als mein Programmier-Talent).

Danke für Deine Unterstüzugn

viele Grüße
Martin