Neues MQTT Plugin

[Asterix3]

Dankeschön!

Habe mal testweise die __init__.py bei mir durch dei "neue" develop ersetzt. Hat allerdings nach dem Neustart meines FHEM wieder nicht funktioniert. Muss wahrscheinlich das komplette Plugin ersetzen, oder?

[Msinn]

Am Plugin habe ich nichts getan. Wie ich schrieb, lag das Problem im mqtt Modul.

Falls Du das Modul gemeint hattest: Was steht denn bei Dir im Log?

Du schreibst, dass Du fhem neu gestartet hast. Implementiert fhem denn einen brocker, oder was ist Deine broker Software?

[Onkelandy]

Init reicht. Aber nicht plugin sondern Modul wie erwähnt

[Asterix3]

Also ich nutze im FHEM den integrierten MQTT broker. Wenn ich den FHEM neu starte verliert der smarthomeNG die Verbindung. Log müsste ich mal morgen aktivieren. und probieren.
Hab mich bei Plugin bzw Modul auch vertan, meinte das modul (/smarthome/modules/mqtt/*)
Wie gesagt, hatte das init File aus dem Dev genommen und meinen smarthomeNG neu gestartet. MQTT läuft dann mit dem neuen init File. Starte ich dann meinen Broker (FHEM) neu verliere ich trotzdem die Verbindung. Nach dem Neustart des smarthomeNG läuft alles wieder. Somit behebt das neue init File zumindest bei mir das Problem nicht.
Muss mir morgen mal die Log Geschichten anschauen, weiss nicht wie diese aktiviert werden. Mache dann mal Logs.

PS: Bewundere euch für die Arbeit die ihr macht. Smarthome ist einfach genial und absolut stabil.

[Msinn]

Das logging von SmartHomeNG musst Du nicht aktivieren. das läuft ständig. Ein Neustart des Brokers sieht da beimmir so aus:

2022-04-25 19:28:26 WARNING modules.mqtt Disconnected from broker with returncode '7'
2022-04-25 19:29:29 NOTICE  modules.mqtt Reconnected to broker

[Asterix3]

So, habe nochmal durchgetestet. Anscheinend hatte ich gestern noch irgendwas verbastelt. mit der neuen Version der init (aus dem Dev Bereich) macht er einen sauberen reconnect nach einem disconnect. Somit läuft das MQTT Plugin wieder wenn im Hintergrund der Broker neu gestartet wird.

2022-04-26 08:32:53 WARNING modules.mqtt Disconnected from broker with returncode '7'
2022-04-26 08:33:09 NOTICE modules.mqtt Reconnected to broker

Nochmals vielen Dank!

[henfri]

Hallo,

hat jemand eine Idee, wie ich dieses Problem eingrenzen kann?
Ich sende in SH ein Item auf MQTT. Laut log wird das durchgeführt:

2022-04-27 08:03:25 INFO modules.mqtt 'publish_topic()' - called from Plugin by 'publish_topic()'
2022-04-27 08:03:25 INFO modules.mqtt Plugin 'mqtt' is publishing topic '/KWL-PWM/cmd' with payload 'PWM,14,973' (qos=1, retain=False)
2022-04-27 08:03:25 DEBUG modules.mqtt cast_to_mqtt: data = 'PWM,14,973', type(data) = '<class 'str'>', bool_values ='None'
2022-04-27 08:03:25 INFO modules.mqtt Plugin 'mqtt' has published topic '/KWL-PWM/cmd' with payload 'PWM,14,973'

bei mosquitto scheint aber nix anzukommen:

mosquitto_sub -h localhost -t "#" -v -u henfri -P xxx |grep -i kwl
/KWL-PWM/status KWL-PWM_Online
/KWL-PWM/status/LWT Connected

(und mehr kommt da nicht)

Gruß,
Hendrik

[Msinn]

Du sendest einen anderen Topic (/KWL-PWM/cmd) als Du mit der Mosquitto Client Software mosquitto_sub empfangen möchtest (/KWL-PWM/status)

Generell gilt übrigens: Ob ein Client (hier mosquitto_sub) etwas empfängt, sagt nichts darüber aus, ob der mosquitto Broker die Daten empfangen hat.

[henfri]

Hallo,

Du sendest einen anderen Topic (/KWL-PWM/cmd) als Du mit der Mosquitto Client Software mosquitto_sub empfangen möchtest (/KWL-PWM/status)

Nein, empfangen tue ich "#", also alles. Nur das grep filtert nach KWL und angezeigt wird nur etwas mit status - weil nix anderes ankommt.

Generell gilt übrigens: Ob ein Client (hier mosquitto_sub) etwas empfängt, sagt nichts darüber aus, ob der mosquitto Broker die Daten empfangen hat.

Und wo müsste man gucken, um zu prüfen, ob der Broker das erhalten hat? Im Log vom Broker?

Wie auch immer:
Es funktioniert wieder. Ich hatte den Rechner neu gestartet -- > hat nix gebracht.
Danach habe ich smarthome neu gestartet (hatte ich vorher natürlich auch schon) - jetzt geht es erstmal wieder...

Gruß,
Hendrik

[Msinn]

Ja, Um wirklich zu sehen was der Broker empfängt, musst Du im Log des Brokers nachschauen. Dazu musst Du evtl. Das Logging des Brokers hochdrehen.

[Msinn]

Hattest Du evtl. den Broker neu gestartet bevor das Problem auftrat?
In v1.9.1 gibt es ein Problem beim Reconnect von SmartHomeNG an den Broker, nachdem die Verbindung abgebrochen war.
Das ist im kommenden Release 1.9.2 gefixt.

[henfri]

Hallo,

nee, den Broker habe ich nicht neu gestartet.
Das ist komisch - aber jetzt läuft es wieder.
Edit: was ich geändert habe -aber ich weiß nicht, ob es damit zusammenhängt: Ich habe das tasmota-plugin deaktiviert. Das lief aber vorher schon länger.


Gruß,
Hendrik

[Onkelandy]

Ich versuche gerade mit dem Roborock Staubsauger via MQTT zu kommunizieren, was großteils auch prima klappt. Bekomme aber folgenden Fehler. Ne Idee, wie das zu lösen wäre?

Aug 16 21:21:32 CEST DEBUG    modules.mqtt      modules.mqtt.paho_client _on_log: Received SUBACK  --  (__init__.py:_on_mqtt_log:597)
Aug 16 21:21:32 CEST DEBUG    modules.mqtt      modules.mqtt.paho_client _on_log: Received PUBLISH (d0, q1, r1, m28), 'valetudo/roborock_eg/MapData/map-data', ...  (461 bytes)  --  (__init__.py:_on_mqtt_log:597)
Aug 16 21:21:32 CEST DEBUG    modules.mqtt      modules.mqtt.paho_client _on_mqtt_message: RECEIVED topic 'valetudo/roborock_eg/MapData/map-data', payload 'b'x\x9c\x8d\x93M\x8b\xdb0\x10\x86\xff\xcb\x9c\x15\x90l}\xd8\xbe\xb6=\x14ZX(\xf4RB\x90m\x91\x15\xd8\x96\xb1\xb5\xdbM\x83\xff{G\xe3\x8f\xee\xe6\xd4\x83\xcc\xc3;\xe3w\xdeq\x94;\\.Mg\xe7\x19*\xf8i;\x17_\xda\xf0\xdd\x8e\xc0\xa0w\xd1~\xb6\xd1Bu\x87W7\xb4aB\xfdk\x0b\x95\xd0"g(M\xb3\x0f\x03T\x19\x83!\x0c\x8dC\x03Wf\x8d\xe1\xb58\x15\xae\xe0\'\xa9\xeb\xfadmS\x9f\xb2\\\x1a\xaeZ\xe1\x94\xe1\xb00\x98\xfd\x1f\x97l\xdf\xa0R"\xe3\x0cn+`i\xf4o\xae\xfbAu\xc5\xa0\xb37\x1c\x03\xd5\xaf\xfb\xbb\x98\x18\xe3[\xd2\x1f2\xda\xc9\xd9\x14N%\x9bx\x1bS\xa0\xdf\xb6\xeb`3M6g\x06\xad\xef\xdd\x90\x92\xcf[\x82;\xf4\x1e\xd7\x90\x06\xe7\xf5\x96"\x15H\x1e7\x95\xa5a`_\xaf\xa8q\xb5P\xcc\xbd\xbb\x14G\xb7\xd9\xba\x15\x97G\xb7\xd9W\xf9\x14^\x86\x08\x95\xd6(4\xa1\x1f\'7\xcf\xae}\xda\x03\xc9R\xb1\xe4%\xf0\xa9\xf1d\x07\xe5\x89\x8a\x1cI\x12\xa9\x83\x0cQ\xaa\x98]#RH\x8a\x8b\x8389e[\xd5\x10\x15t\xf67J\xea+YJ\x9e(\xc3\xa3\x0e\xd2\x89\xc4?\x92D8\x17\xbf\x14n\xb8M\xdbH\xac\x94#i\xa2l\xeb+\xb6,\x89\xd0\x0b\xbf\xd6{\x8d\x12\x90\xb6\x12\xbe+\xf8\x9e\x00=\xd3\xf4\x9cR\xecU"\xd2r\xd2\x8a\x9dH\x93\x87&\x0f\x8d6\x12+\xe9M\xd3\xe4\\\x10i\xda\x9fR\x9c\x17\xbc!n\x88>z\xf7x\xed\x9e\x82\x1f"\xde\xbd/\xa9|\xfbx\xf9\xd2\xaf\x9d\xca\xe9\x9dL\x19\xdcTi~>\xaea\xf3l\xa7\xab\x9b.]hlL\x7f\x9a\x85\xfd\xaf3\xd8\xe1\xda\xa1G\xc9?\xce\xd0\xfca\xc6\x14\xea\x10/c\x98\xfd:\xe1\xbc\xfc\x05d`\x06y', QoS '1', retain '1'  --  (__init__.py:_on_mqtt_message:533)
Aug 16 21:21:32 CEST DEBUG    modules.mqtt      modules.mqtt.paho_client _on_mqtt_message: subscription 'mqtt-116': {'subscriber_type': 'plugin', 'callback': <bound method MqttPlugin._on_mqtt_message of <plugins.mqtt.Mqtt2 object at 0xa7a1e7a8>>, 'payload_type': 'str', 'bool_values': None}  --  (__init__.py:_on_mqtt_message:560)
Aug 16 21:21:32 CEST ERROR    modules.mqtt      modules.mqtt.paho_client _on_log: Caught exception in on_message: 'utf-8' codec can't decode byte 0x9c in position 1: invalid start byte  --  (__init__.py:_on_mqtt_log:595)

[Msinn]

Kurze Frage: Welche MQTT Protokoll Version nutzt der Staubsauger?

Was ich aus den Zeilen lese ist, dass das Item, welches die Daten empfängt anscheinend als String definiert ist, dass aber die Payload, welche vom Staubsauger kommt, sich nicht in einen String wandeln lässt.

In MQTT v3.x ist die Payload einfach ein Array of Byte, über dessen Interpretation sich Sender und Empfänger einig sein müssen.

[Onkelandy]

Hm, ich tippe mal auf MQTT 3.1.1 - das einzige was ich finden konnte ist dieser Satz:
Valetudo will not receive any feedback from the broker if publishing fails due to ACL restrictions as such feedback simply isn't part of the MQTT v3.1.1 spec. MQTT v5 fixes this issue but isn't widely available just yet.

Soll ich das Item mal auf dict stellen?