Neues MQTT Plugin

[TCr82]

Hi,

es läuft nun, aber was es genau war weiss ich nicht, da ich dummerweise zwei Sachen auf einmal geändert habe.

1. Habe ich den mosquitto von 1.4.15 (distributions-standard) auf 2.0.4 aktualisiert
2. Dann ist mir aufgefallen, dass die enforce_updates: yes die ich rein Gebaut habe, falsch eingerückt waren und deswegen gar keine Items mehr geladen waren. Also hab ich das noch korrigiert und dann lief es. Ich vermute aber, dass es daran lag - das enforce_updates kümmert sich ja darum, dass die Daten über die Plugins gesendet werden, auch ohne Änderung der Werte.

Trotzdem danke für die Unterstütung und den denkanstoß

[Msinn]

Was passiert denn, wenn Du dem Item Daten zuweist, die weniger komplex sind? Siehst Du dann im MQTT Explorer ein Telegramm? Was passiert wenn Du retain auf False setzt?

[TCr82]

Dass gar keins ankommt und somit der Eintrag Heizung/WW/Schaltzeiten gar nicht auftaucht. Dafür spricht ja auch dass debug log, denn dort kommt der Eintrag (in Bezug auf dass mqtt) trotz Definition gar nicht zu Gespräch

[Msinn]

Hab ich hier schon geschrieben

Das in den vielen langen Posts hier im Thread untergegangen. Ich habe es zumindest über die Browser Suche nicht (wieder)-gefunden.

Mit dem Tool MQTT Explorer sieht man auch, dass das Item einfach nicht geschrieben wird (es fehlt ganz schlicht).

Was meinst Du damit? Items werden in Richtung MQTT nicht geschrieben der MQTT Explorer sieht nur Telegramme.

Meinst Du dass dort ein Telegramm mit leerer Payload ankommt oder dass gar kein Telegramm ankommt?

[TCr82]

TCr82 wie sind die Items denn definiert?

Hab ich hier schon geschrieben
https://knx-user-forum.de/forum/supp...91#post1591991

EDIT:

Die Definition sieht man auch auch nochmal bei "(parsing result): item.conf '{'viess_timer': 'Timer_Warmwasser',....." in dem Debug-Log was ich gepostet habe.

Und ich habe eben auch mal ein enforce_updates: yes mit dazu gebaut, aber das hat leider auch nichts geändert.

[element]

Danke
es klappt

[Msinn]

Ich glaube die Bildung eines neuen items ist nicht normal, im item mqtt_out ist die Zeile eval leer, die Zeile eval_trigger ist mit dem richtigen trigger gefüllt.

Das stimmt, Du kannst das in YAML nicht so definieren. Deine Definition

                   mqtt_out:
                        type: dict
                        mqtt_topic_out: "sepia/smart-devices/wohnen/licht/decke/dimmen"
                        eval_trigger: eg.wohnen.licht.decke.dimmen
                        eval: {"state" : sh.eg.wohnen.licht.decke.dimmen()}

wird beim Einlesen verändert, da geschweifte Klammern YAML Sytnax sind, den Du statt Einrückung verwenden kannst. Das sieht dann so aus:

                   mqtt_out:
                        type: dict
                        mqtt_topic_out: "sepia/smart-devices/wohnen/licht/decke/dimmen"
                        eval_trigger: eg.wohnen.licht.decke.dimmen
                        eval:
                            state: sh.eg.wohnen.licht.decke.dimmen()

eval ist leer wird Dir im Item-Tree als Item dargestellt, dass ein Attribut state hat.

eval muss einen String enthalten.

Du müsstest den Ausdruck in Anführungszeichen setzen:

eval: '{"state" : sh.eg.wohnen.licht.decke.dimmen()}'

oder

eval: "{'state' : sh.eg.wohnen.licht.decke.dimmen()}"

[Msinn]

Wobei es aber eigentlich erstmal nur um das Item technik.heizung.WW.Schaltzeiten bzw dem Topic
Heizung/WW/Schaltzeiten geht

TCr82 wie sind die Items denn definiert?

[element]

Danke für die Hilfe, es ist nicht das erste Mal das ich Probleme mit Zeichen und Klammern habe.
Das item wird aber nicht getriggert. Ich hänge mal die yaml und das was smarthome daraus macht an.

eg:
    wohnen:
        licht:
            decke:
                schalten:
                    type: bool
                    visu_acl: rw
                    knx_dpt: 1
                    knx_init: 1/1/173
                    knx_listen: 1/1/173
                    knx_send: 1/1/170
                    webservices_set: 'doorpi'
                    webservices_data: 'val'

                nacht:
                    type: bool
                    knx_dpt: 1
                    knx_init: 1/1/179
                    knx_listen: 1/1/179
                    nachdimm_wert: 1

                    helligkeit:
                        type: num
                        visu_acl: rw
                        knx_dpt: 5
                        knx_cache: 1/1/172
                        enforce_updates: 'yes'
                        knx_send: 1/1/172

                dimmen:
                    type: num
                    visu_acl: rw
                    knx_dpt: '5'
                    knx_init: 1/1/174
                    knx_listen: 1/1/174
                    knx_send: 1/1/172
                    webservices_set: 'doorpi'
                    webservices_data: 'full'

                    mqtt_in:
                        type: dict
                        mqtt_topic_in: "sepia/smart-devices/wohnen/licht/decke/dimmen"
                        on_change:
                          - eg.wohnen.licht.decke.dimmen = value['state']

                    mqtt_out:
                        type: dict
                        mqtt_topic_out: "sepia/smart-devices/wohnen/licht/decke/dimmen"
                        eval_trigger: eg.wohnen.licht.decke.dimmen
                        eval: {"state" : sh.eg.wohnen.licht.decke.dimmen()}

Ich glaube die Bildung eines neuen items ist nicht normal, im item mqtt_out ist die Zeile eval leer, die Zeile eval_trigger ist mit dem richtigen trigger gefüllt.
Ich habe im yaml file die Zeilen getauscht, das eval_trigger vor eval steht, das bringt aber nichts.
Ich kann den Wert {"state":6} im mqtt_out eingeben und aktualisieren-> der Wert wird gesendet und in der sepia Sprachsteuerung auch verstanden.
Im mqtt_out.eval steht unter
Plugin spezifische Konfiguration
state mit dem Wert sh.eg.wohnen.licht.decke.dimmen()

stelle ich das item mqtt_out auf type num ein passiert dasselbe. Ich hatte das dicht im Verdacht das zu verursachen.
Jetzt vermute ich, das der Doppelpunkt im {"state": sh.eg.wohnen.licht.decke.dimmen()} das neue item erzeugt.
Stehe wieder auf dem Schlauch und brauche noch einen Rat.

[TCr82]

Sieht fast so aus, als wenn das mqtt plugin das Item einfach ignoriert, da es nicht im Logfile auftaucht mit dem grep Filter

[TCr82]

root@heizung:~# grep Schaltzeiten /usr/local/smarthome/var/log/smarthome-develop.log |  grep -v -e Betriebsart -e Heizen
2021-01-04 15:49:10 INFO     __init__          Main         Loaded Application Timer {'Timer_Warmwasser': {'item': Item: technik.heizung.WW.Schaltzeiten, 'commandcodes': ['2100', '2108', '2110', '2118', '2120', '2128', '2130']}}  --  (__init__.py:parse_item:216)
2021-01-04 15:49:10 INFO     __init__          Main         Loaded Application Timer {'Timer_Warmwasser': {'item': Item: technik.heizung.WW.Schaltzeiten, 'commandcodes': ['2100', '2108', '2110', '2118', '2120', '2128', '2130']}, 'Timer_A1M1': {'item': Item: technik.heizung.HK1.Schaltzeiten, 'commandcodes': ['2000', '2008', '2010', '2018', '2020', '2028', '2030']}}  --  (__init__.py:parse_item:216)
2021-01-04 15:49:10 INFO     __init__          Main         Loaded Application Timer {'Timer_Warmwasser': {'item': Item: technik.heizung.WW.Schaltzeiten, 'commandcodes': ['2100', '2108', '2110', '2118', '2120', '2128', '2130']}, 'Timer_A1M1': {'item': Item: technik.heizung.HK1.Schaltzeiten, 'commandcodes': ['2000', '2008', '2010', '2018', '2020', '2028', '2030']}, 'Timer_M2': {'item': Item: technik.heizung.HK2.Schaltzeiten, 'commandcodes': ['3000', '3008', '3010', '3018', '3020', '3028', '3030']}}  --  (__init__.py:parse_item:216)
2021-01-04 15:56:26 DEBUG    __init__          Main         parsing item: technik.heizung.WW.Schaltzeiten  --  (__init__.py:parse_item:143)
2021-01-04 15:56:26 DEBUG    __init__          Main         (parsing result): item.conf '{'viess_timer': 'Timer_Warmwasser', 'viess_init': True, 'mqtt_topic_init': 'Heizung/WW/Schaltzeiten', 'mqtt_retain': 'True', 'mqtt_topic_out': 'Heizung/WW/Schaltzeiten'}'  --  (__init__.py:parse_item:170)
2021-01-04 15:56:26 DEBUG    __init__          Main         parsing item: technik.heizung.HK1.Schaltzeiten  --  (__init__.py:parse_item:143)
2021-01-04 15:56:26 DEBUG    __init__          Main         (parsing result): item.conf '{'viess_timer': 'Timer_A1M1', 'viess_init': True, 'mqtt_topic_init': 'Heizung/HK1/Schaltzeiten', 'mqtt_retain': 'True', 'mqtt_topic_out': 'Heizung/HK1/Schaltzeiten'}'  --  (__init__.py:parse_item:170)
2021-01-04 15:56:26 DEBUG    __init__          Main         parsing item: technik.heizung.HK2.Schaltzeiten  --  (__init__.py:parse_item:143)
2021-01-04 15:56:26 DEBUG    __init__          Main         (parsing result): item.conf '{'viess_timer': 'Timer_M2', 'viess_init': True, 'mqtt_topic': 'Heizung/HK2/Schaltzeiten', 'mqtt_retain': 'True', 'mqtt_topic_in': 'Heizung/HK2/Schaltzeiten', 'mqtt_topic_out': 'Heizung/HK2/Schaltzeiten'}'  --  (__init__.py:parse_item:170)
2021-01-04 15:56:26 INFO     __init__          Main         Publishing topic 'Heizung/HK2/Schaltzeiten' (when needed) for item 'technik.heizung.HK2.Schaltzeiten'  --  (__init__.py:parse_item:186)
2021-01-04 15:56:27 INFO     mqttplugin        mqtt         _start_subscription: Subscribing to topic Heizung/HK2/Schaltzeiten, payload_type 'dict' for item technik.heizung.HK2.Schaltzeiten (callback=<bound method MqttPlugin._on_mqtt_message of <plugins.mqtt.Mqtt2 object at 0xa680d190>>)  --  (mqttplugin.py:_start_subscription:109)
2021-01-04 15:56:27 INFO     __init__          mqtt         subscribe_topic: Adding topic 'Heizung/HK2/Schaltzeiten'  --  (__init__.py:subscribe_topic:412)
2021-01-04 15:56:27 INFO     __init__          mqtt         _add_subscription_definition: Plugin 'mqtt-5' is subscribing to topic 'Heizung/HK2/Schaltzeiten'  --  (__init__.py:_add_subscription_definition:367)
2021-01-04 15:56:27 INFO     __init__          mqtt         subscribe_topic: mqtt module is subscribing to topic 'Heizung/HK2/Schaltzeiten' with qos=1 at broker (result=0, mid=18)  --  (__init__.py:subscribe_topic:427)

Wobei es aber eigentlich erstmal nur um das Item technik.heizung.WW.Schaltzeiten bzw dem Topic
Heizung/WW/Schaltzeiten geht

[TCr82]

Kann sein, dass die Meldung jedesmal kommt, wenn ich shNG neu gestartet habe und das Plugin den Wert in das Item geschrieben hat.

Ich habe das eben nochmal direkt getestet. Und zwar kommt die Meldung wohl, wenn ich shNG neu startet, aber denke beim beenden, nicht nach dem starten.

Das zeigt dass Logfile:

1609771731: Socket error on client heizung.MQTT-module, disconnecting.
1609771742: New connection from 192.168.99.30 on port 1883.

Ist dann wohl eher zu vernachlässigen.

Ich erstelle gleich mal noch ein Debug Log, wenn ich das konfiguriert bekomme.

[TCr82]

Wie hast Du das Websocket Modul konfiguriert?

Da du Modul sagtest und dort websocket mit drin ist, hänge ich einfach mal meine module.yaml an:

root@heizung:/usr/local/smarthome# cat etc/module.yaml
%YAML 1.1
---
# etc/module.yaml
# support for web server
http:
    module_name: http
    starturl: admin

# support for graphical admin interface
admin:
    module_name: admin

#enable, if mqtt protocol is going to be used
mqtt:
    module_name: mqtt
    broker_monitoring: true
    broker_host: zentrale.fritz.box
    last_will_topic: devices/shng-module/$online
    last_will_payload: 'False'
    birth_topic: devices/shng-module/$online
    birth_payload: 'True'

websocket:
    module_name: websocket

[TCr82]

Wie schreibst Du die Daten denn in das Item?

Das Viessmann Plugin auf dem heizungs-RaspberryPi schreibt das Item.

Was zeigt die Admin GUI als aktuellen Wert?

Wenn ich über das Admin-Interface mir den Wert des Items ansehe ist dieser wie folgt:

{'lastvalue': '0', 'sunset': '16:37', 'list': [{'time': '04:00', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '1', 'active': True}, {'time': '04:30', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '0', 'active': True}, {'time': '07:30', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '1', 'active': True}, {'time': '09:00', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '0', 'active': True}, {'time': '14:30', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '1', 'active': True}, {'time': '15:00', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '0', 'active': True}, {'time': '17:00', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '1', 'active': True}, {'time': '22:00', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '0', 'active': True}], 'active': True, 'interpolation': {'initage': '', 'initialized': True, 'itemtype': 'bool', 'interval': '', 'type': 'none'}, 'sunrise': '08:23'}

Zur Meldung im Broker Log: Wie häufig erscheint denn der Log Eintrag?

wenn man das Log betrachet, das sind wohl Timestamps, sieht wohl ziemlich unregelmäßig aus....
1609504860 = 1. January 2021 12:41:00
1609506138 = 1. January 2021 13:02:18
1609507133 = 1. January 2021 13:18:53
1609514825 = 1. January 2021 15:27:05
1609516643 = 1. January 2021 15:57:23
1609516865 = 1. January 2021 16:01:05
1609516982 = 1. January 2021 16:03:02
1609517040 = 1. January 2021 16:04:00

Kann sein, dass die Meldung jedesmal kommt, wenn ich shNG neu gestartet habe und das Plugin den Wert in das Item geschrieben hat.

Wie hast Du das Websocket Modul konfiguriert?

Du meinst das Plugin visu_websocket oder was?

Gruß

[Msinn]

Wie schreibst Du die Daten denn in das Item? Was zeigt die Admin GUI als aktuellen Wert?

Zur Meldung im Broker Log: Wie häufig erscheint denn der Log Eintrag? Wie hast Du das Websocket Modul konfiguriert?