Neues MQTT Plugin

[kaiwerner]

...
- Bei Punkt Eins liegst Du falsch. Der Connect wird durch self.ConnectToBroker() in der __init__ Routine ausgeführt, also vor dem parsen. (sonst würde das Plugin keine messages abonnieren)

Ja Du hast recht! Erst __init__ da parse_item.

mhh...
Mir war aber beim Testen genau das passiert, also es wurden keine Messages abonniert.

Kann es sein das der Verbindungsaufbau etwas zu lange gedauert hat?

Verständnisfrage:
Warum fragst Du das "connected" beim parsen der items ab?

MfG

[felix86]

Hallo Zusammen,

ich versuche auch gerade das MQTT Plugin ans laufen zu bekommen, aber irgendwo hakt es :/

plugin.conf

[mqtt]
    class_name = Mqtt
    class_path = plugins.mqtt
    host = 192.168.178.2

item

[wlan_thermo]
        [[kanal1]]
                name = Kanal1
                type = num
                mqtt_topic_in = WLanThermo/NANO-82e3d9/status/temp1

        [[test]]
                name = Test
                type = foo
                mqtt_topic_in = test

Ich habe ein WLAN Thermometer welches per MQTT die Werte schicken kann. Dies funktioniert soweit auch:

mosquitto_sub -h localhost -t WLanThermo/NANO-82e3d9/status/temp1
24.5
24.4
24.5
24.4
24.4
24.5

Im Topic Test habe ich auch mal Nachrichten geschickt und mittels mosquitto_sub auch empfangen.

Im mosquitto Log kann ich auch erkennen, dass sich das Plugin verbindet.

Im SmarthomeNG Log steht bzgl. MQTT

2017-08-17  21:58:26 INFO     Main         MQTT: Connecting to broker. Starting mqtt client 'HAL9000'
2017-08-17  21:58:26 INFO     Main         MQTT: parsing item: wlan_thermo.kanal1
2017-08-17  21:58:26 INFO     Main         MQTT: parsing item: wlan_thermo.test
2017-08-17  21:58:26 INFO     Thread-15    MQTT: Connection returned result 'Connection Accepted.' 
2017-08-17  21:58:26 WARNING  Thread-15    MQTT: Connected to broker 'mosquitto version 1.4.8' at address 192.168.178.2:1883

SmarthomeNG ist selber gerade frisch auf Version 1.3

Hat vll jemand einen Tipp für mich?

[Msinn]

Hi,

bei Deinem Loglevel (Info) müsste eigentlich nach der Zeile

 
 2017-08-17  21:58:26 INFO     Main         MQTT: parsing item: wlan_thermo.kanal1

eine Zeile

 
 2017-08-17  21:58:26 INFO     Main         MQTT: Listening on topic 'WLanThermo/NANO-82e3d9/status/temp1' for item 'wlan_thermo.kanal1'  
 [FONT=Arial][/FONT]

stehen...

Ich habe eine Idee: Evtl. antwortet Dein mosquitto etwas langsam.

Das Plugin ist so geschrieben, dass es die Subscriptions beim parsen der Items absetzt. (Aber nur, wenn der Broker den Connect bereits bestätigt hat).

Kannst Du im Plugin (in der __init__.py) zum Test mal folgende Änderung vornehmen und mir schreiben was sich verändert:

Ändere Zeile 243

            if self._connected:

mal auf

            if self._connected or True:

[felix86]

Hi Msinn,

das sieht deutlich besser aus:

2017-08-18  08:30:29 INFO     Main         MQTT: Connecting to broker. Starting mqtt client 'HAL9000'
2017-08-18  08:30:29 INFO     Main         MQTT: parsing item: wlan_thermo.kanal1
2017-08-18  08:30:29 INFO     Main         MQTT: Listening on topic 'WLanThermo/NANO-82e3d9/status/temp1' for item 'wlan_thermo.kanal1'
2017-08-18  08:30:29 INFO     Main         MQTT: parsing item: wlan_thermo.test
2017-08-18  08:30:29 INFO     Main         MQTT: Listening on topic 'test' for item 'wlan_thermo.test'
2017-08-18  08:30:29 INFO     Thread-6     MQTT: Connection returned result 'Connection Accepted.' 
2017-08-18  08:30:29 WARNING  Thread-6     MQTT: Connected to broker 'mosquitto version 1.4.8' at address 192.168.178.2:1883
2017-08-18  08:30:58 INFO     Thread-6     MQTT: Received topic 'WLanThermo/NANO-82e3d9/status/temp1', payload '23.2' (type num), QoS '0', retain '0' for item 'wlan_thermo.kanal1'
2017-08-18  08:31:28 INFO     Thread-6     MQTT: Received topic 'WLanThermo/NANO-82e3d9/status/temp1', payload '23.2' (type num), QoS '0', retain '0' for item 'wlan_thermo.kanal1'
2017-08-18  08:31:58 INFO     Thread-6     MQTT: Received topic 'WLanThermo/NANO-82e3d9/status/temp1', payload '23.2' (type num), QoS '0', retain '0' for item 'wlan_thermo.kanal1'

Das Item wird nun immer mit der aktuellen Temperatur geschrieben. Danke!

[Msinn]

Ok, ich habe einen Hotfix eingecheckt. Die v.1.3.4 des MQTT Plugins st jetzt auf Develop.

[bytesmith]

Hi Zusammen,

das Problem mit dem connecting and nicht subscriben habe ich auch local da der connect async ist und oft erst kurz nach dem parse items ausgelöst wird. Dadurch subscribed das Plugin bei mir nie, es sei denn ich workarounde den code wie zum Biespiel hier beschrieben. Was aber immer noch eine Race Condition ist und damit nicht wirklich eine Lösung sondern immer noch Glücksache.

Insgesamt würde ich aber das Plugin umschreiben und ein subscriben auch erst nach dem connect machen. Dann wäre auch eine wiederanlauf Fähigkeit gegeben falls der Broker zwischendrin mal weg war. Im Moment wird zwar reconnected aber nicht noch mal subscribed. Also eher nutzlos.

Wie wäre es also eine zentrale subscribing methode welche jeweils erst beim erfolgreichen connect/Reconnect aufgerufen wird ? Re-Connect wäre gelöst und auch langsameres connecting auf den Broker wäre kein Problem mehr ! Das gleiche gilt hier übrigens auch für das logic handling.

[Sisamiwe]

Hallo,

ich habe das Plugin wie im Wiki beschrieben eingebunden.
Trotzdem erscheint im Log die Fehlermeldung:

2017-12-17 16:25:11 ERROR Main Plugin mqtt exception: 'LogRecord' object has no attribute 'message'
Traceback (most recent call last):
File "/usr/local/smarthome/plugins/mqtt/__init__.py", line 371, in ConnectToBroker
self._client.connect(self.broker_ip, self.broker_port, 60)
File "/usr/local/lib/python3.5/dist-packages/paho/mqtt/client.py", line 768, in connect
return self.reconnect()
File "/usr/local/lib/python3.5/dist-packages/paho/mqtt/client.py", line 895, in reconnect
sock = socket.create_connection((self._host, self._port), source_address=(self._bind_address, 0))
File "/usr/lib/python3.5/socket.py", line 712, in create_connection
raise err
File "/usr/lib/python3.5/socket.py", line 703, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Verbindungsaufbau abgelehnt

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/smarthome/lib/plugin.py", line 90, in __init__
plugin_thread = PluginWrapper(smarthome, plugin, classname, classpath, args, instance)
File "/usr/local/smarthome/lib/plugin.py", line 144, in __init__
exec("self.plugin.__init__(smarthome{0}{1})".forma t("," if len(arglist) else "", argstring))
File "<string>", line 1, in <module>
File "/usr/local/smarthome/plugins/mqtt/__init__.py", line 171, in __init__
self.ConnectToBroker()
File "/usr/local/smarthome/plugins/mqtt/__init__.py", line 373, in ConnectToBroker
self.logger.error('Connection error:', e)
File "/usr/lib/python3.5/logging/__init__.py", line 1309, in error
self._log(ERROR, msg, args, **kwargs)
File "/usr/lib/python3.5/logging/__init__.py", line 1416, in _log
self.handle(record)
File "/usr/lib/python3.5/logging/__init__.py", line 1426, in handle
self.callHandlers(record)
File "/usr/lib/python3.5/logging/__init__.py", line 1488, in callHandlers
hdlr.handle(record)
File "/usr/lib/python3.5/logging/__init__.py", line 856, in handle
self.emit(record)
File "/usr/local/smarthome/bin/smarthome.py", line 120, in emit
self._log.add([timestamp, record.threadName, record.levelname, record.message])
AttributeError: 'LogRecord' object has no attribute 'message'

smarthomeNG 1.3 Hotfix2
MTTQ Plugin 1.3.3 mit den eingebauten Änderungen zu 1.3.4

Kann jemand helfen?

[Msinn]

Aus der Fehlermeldung kann ich leider nichts schließen, da sie ziemlich grundsätzliche Fehler schmeisst, die nicht unbedingt etwas mit dem MQTT Plugin zu tun haben.

Evtl. liegt der eigentlich auslösende Fehler schon davor. Was für Meldungen hast Du im Log zwischen Start und dieser Fehlermeldung?

Du müsstest auch schon genau beschreiben was Du getan hast:
- Wie sieht Deine plugin.yaml aus?
- Wie ist der MQTT Broker konfiguriert?
- Auf welchs Wiki Beschreibung referenzierst Du?
- Wie hast Du die Änderungen eingebaut (und welche genau)?

[Sisamiwe]

Msinn
Danke für die schnelle Rückmeldung.

Ich glaube, dass meine mosquitto Installation irgendeinen Fehler hat. Ich arbeite mit Debian Stretch auf einen RPI3.
Hier kam es bei der Installation von Mosquitto zu einigen Schwierigkeiten. Der Broker Service läuft

[root@SmartHomeNGTEST ~]# sudo systemctl status mosquitto.service
● mosquitto.service - LSB: mosquitto MQTT v3.1 message broker
Loaded: loaded (/etc/init.d/mosquitto; generated; vendor preset: enabled)
Active: active (exited) since Sun 2017-12-17 17:57:35 CET; 3min 26s ago
Docs: man:systemd-sysv-generator(8)
Process: 2271 ExecStop=/etc/init.d/mosquitto stop (code=exited, status=0/SUCCESS)
Process: 2281 ExecStart=/etc/init.d/mosquitto start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/mosquitto.service

Dez 17 17:57:35 SmartHomeNGTEST systemd[1]: Starting LSB: mosquitto MQTT v3.1 message broker...
Dez 17 17:57:35 SmartHomeNGTEST mosquitto[2281]: Starting network daemon:: mosquitto.
Dez 17 17:57:35 SmartHomeNGTEST systemd[1]: Started LSB: mosquitto MQTT v3.1 message broker.

aber irgendwie, wenn ich testen will kommt:

[root@SmartHomeNGTEST ~]# mosquitto_sub -h localhost -v -t test
Ungültiger Maschinenbefehl

Hast Du eine Idee?

[Msinn]

Welche Version von mosquito hast Du denn laufen? Ich habe mich damals etwas schwer getan, da die von mir genutzte Distribution für den Pi nur eine relativ alte Version enthielt.

[Sisamiwe]

Genau so geht es mir auch.
Ich habe zwar viel gesucht, aber keine echte Lösung gefunden.
Ich glaube, dass bei Stretch standardmäßig mosquitto 1.4.10 dabei ist. Aktuell ist 1.4.12 mit Websockets und 1.4.14 ohne Websockets.
Werden die Websockets benötigt?

[Msinn]

Ich habe bei mir die 1.4.14 laufen.

[Msinn]

Sisamiwe Du solltest vieleicht auf SmartHomeNG v1.4 weitertesten

[Onkelandy]

Ich habe mit der neuen Version 1.4 auf 2 Raspis leider das gleiche Problem wie oben beschrieben..das subscriben funktioniert nicht.
Mosquitto Version 1.4.10
MQTT Plugin: 1.3c.4
SmarthomeNG: 1.4 master bzw. 1.4a.ebcf3d29.develop

Empfänger/Subscriber-Raspi:
Item:

            Aussen:
                name: Temperatur aussen
                visu_acl: ro
                type: num
                database@nas: 'init'
                influxdb: 'yes'
                mqtt_topic_in: WP/Status/Temperatur/Aussen

Log:

2017-12-18  00:23:50 INFO     plugins.mqtt Connecting to broker. Starting mqtt client 'SmartHome'
2017-12-18  00:23:50 INFO     lib.plugin   Initialized plugin 'mqtt' from from section 'mqtt'
2017-12-18  00:26:02 INFO     plugins.mqtt Listening on topic 'WP/Status/Temperatur/Aussen' for item 'WP.Status.Temperatur.Aussen'
2017-12-18  00:27:11 INFO     plugins.mqtt Connection returned result 'Connection Accepted.'

Sender-Raspi:
Item:

            Aussen:
                name: Temperatur aussen
                visu_acl: r
                type: num
                database@nas: init
                DuW_WP_register: 202
                #nw: 'yes'
                #send_nw: 10.0.0.150
                mqtt_topic_init: WP/Status/Temperatur/Aussen
                mqtt_retain: 'True'

Log beim Ändern eines Werts:

2017-12-18  00:30:09 INFO     plugins.mqtt Item 'WP.Status.Temperatur.Aussen': Publishing topic 'WP/Status/Temperatur/Aussen', payload '0.3', QoS '1', retain 'True'

Keinerlei Reaktion vom Empfänger. Mittels mosquitto-client aber schon:

mosquitto_sub -h localhost -t WP/Status/Temperatur/Aussen
0.3

Gleiches Spiel in die andere Richtung. mosquitto_sub funktioniert, SmarthomeNG bekommt aber nichts mit, obwohl subscribed. Ob out oder init scheint dabei egal zu sein...

[Msinn]

Das subscriben (wie als Problem oben beschriebenk ist gefixt. Das haben User bereits bestätigt. Kannst Du Dein Problem genauer beschreiben?

Da sich mit dem Release nichts gegenüber dem develop geändert hat: Hattest Du das Problem auch schon auf Develop bemerkt?