Neues MQTT Plugin

[Sisamiwe]

Ich könnte höchstens darüber nachdenken zwei weitere Item Attribute einzuführen (sowas wie mqtt_bool_false und mqtt_bool_true). Die müssten dann aber bei jedem Item von Typ bool angegeben werden, die boolsche Werte versenden, die nicht als True/False gesendet werden sollen.

Das wäre eine Überlegung wert.
Liese sich ggf in dem bool Item mit eval: aus true/false eine 1/0 machen?

Noch ne Frage: Lässt sich Pub und Sub auf einem Item vereinigen, so wie bei knx_send und knx_listen?
Ich meine, dass Senden und Hören auf ein Item läuft?

Danke,
Michael


Update:
Mein MQTT-Geräte (SONOFF mit Tasmota FW) versteht doch true/false. Man muss nur die englisch-sprachige FW nutzen. Ich habe bislang die deutsche verwendet und die erwartet wahr / falsch.

[ratzi82]

Code:

ERROR Main plugin 'mqtt' version differs between Python code (1.3c.4) and metadata (1.4.4)
Sagt mir, dass eine Datei es nicht ins Release geschafft hat.

Nicht unbedingt, ich hatte in meiner Dev-Umgebung zuerst das gleiche Problem.

Einfach mal versuchen den Ordner:

smarthome/plugins/mqtt/[B]__pycache__[/B]

zu löschen.

Gruß,
Henning

[Msinn]

Ich könnte höchstens darüber nachdenken zwei weitere Item Attribute einzuführen (sowas wie mqtt_bool_false und mqtt_bool_true). Die müssten dann aber bei jedem Item von Typ bool angegeben werden, die boolsche Werte versenden, die nicht als True/False gesendet werden sollen.

[Sisamiwe]

Ok, danke.
Nun habe ich es verstanden.

Noch ne frage: Lässt sich Pub und Sub auf einem Item vereinigen, so wie bei knx_send und knx_listen?

[Msinn]

Warum? Wer sagt, dass das andere Ende 0/1 als boolsche Werte erwartet und nicht true/false, yes/no, etc.

Da es im MQTT keine Datentypsvereinbarungen gibt, muss Du an dieser Stelle schon selber (über ein Hilfs-Items) den aufbereiteten String erzeugen.

[Sisamiwe]

Da habe ich mich wohl missverständlich ausgedrückt. Es ging mir um die Senderichtung, als shNG als Publisher.
Wann man das SendeItem als bool definiert, wir true/false an den Broker gesendet. Hier müsste eine 0/1 gesendet werden.

[Msinn]

Was ist da abzufangen?
Das Plugin nimmt jegliches casting vor. Dum musst Dein Item nur entsprechend definieren. Um z.B. Json zu empfangen, einfach das Item als type dict definieren. Das einzige was das Plugin nicht sinnvoll kann ist einen evtl. bool Wert auf ein Item vom Typ num zu mappen.

Wenn Du in ein Item vom Typ Bool empfängst, wird sehr umfassend gecastet. Es ist ja nicht gesagt, dass das mqtt Telegram true/false enthält. Es könnte auch True/False oder yes/no oder on/off oder 1/0, t/f, y/n, etc. sein. Das wird alles korrekt umgewandelt.

[Sisamiwe]

Ok, verstanden.
Könnte man das im Plugin nicht abfangen und aus true/false eine 1/0 machen?

[Msinn]

MQTT selber kennt keine Datentypen. Da geht immer nur ein Array of char über den Draht. Wenn Du ein Item als bool definierst, wird ein 'true' oder 'false' übertragen.

[Sisamiwe]

Damit geht es.

Was sagst zum Senden von Bool Items?

[Msinn]

Nimm sonst erstmal die Plugin Version aus dem Develop Branch.

[Msinn]

 
 ERROR    Main         plugin 'mqtt' version differs between Python code (1.3c.4) and metadata (1.4.4)

Sagt mir, dass eine Datei es nicht ins Release geschafft hat.

Dadurch wird auch die Warnung ausgegeben, die eigentlich als Info unter dem normalen Radar bleiben sollte.

[Sisamiwe]

Hallo,

im habe im Log (auch nach dem Update auf 1.4.2) folgende Fehlermeldungen:

ERROR    Main         plugin 'mqtt' version differs between Python code (1.3c.4) and metadata (1.4.4)

Was sagt mir das?

Den folgenden Eintrag im Log sehe ich als Info, dass dem Item das dict zugewiesen wurde. Warum wird das als Warnung gekennzeichnet?

WARNING  paho_mqtt    Received topic 'tele/sonoff_s20/STATUS', payload '{'VCC': 3.448, 'Laufzeit': 2, 'WLAN': {'AP': 1, 'SSID': 'WLAN-Access', 'RSSI': 64, 'APMac': 'C0:25:06:15:95:57'}, 'Zeit': '2018.01.02 17:11:30', 'POWER': 'OFF'}' (type dict), QoS '0', retain '0' for item 'Sonoff.S20_1.Status_dict'

Dann ist mir aufgefallen, bei einer boolschen Item-Definition etwas nicht funktioniert. Es wird "true" und "false" gesendet und nicht "1" und "0". Kann man das konfigurieren?

Sonoff:
    wz_Tasmota:
        schalten_bool:
            type: bool
            mqtt_topic_out: cmnd/sonoff_1/POWER

Danke für die Rückmeldung.

[Onkelandy]

***BREAKING NEWS***

Die Fehlerquelle ist gefunden, allerdings wohl ziemlich absurd. Sobald auf dem Raspi3 mehr als 5500 Items in SmarthomeNG deklariert sind (das sind es bei mir wegen der Autoblind Statemachine), funktioniert das Plugin nicht mehr. Bei genau 5499 wird die Verbindung immer hergestellt, bei 5001 nie. Ich habe das nun in einem Docker Container auf der Synology getestet, dort spielt die Anzahl Items keinerlei Rolle. An der Ressourcenauslastung kann es aber nicht liegen. RAM und CPU sind großteils bei maximal 25%.

Was keine Rolle spielt:
* Art der Items.. ich kann ganz unterschiedliche hernehmen, es zählt offenbar nur die Anzahl.
* andere Plugins: habe die auf ein Minimum reduziert. Bei 5499 Items kein Problem, darüber schon.
* IP des Brokers: habe auch eine Verbindung auf einen Broker auf einem anderen System getestet, selbes Spiel

Ich vermute mal, du hast auch keine Idee, wie das gelöst werden könnte, Msinn ?

Vielleicht kannst du in dem Zusammenhang aber beim Logging noch ein paar Anpassungen machen?

Initialized plugin 'mqtt' from from section 'mqtt' -> ein from weg

Connection returned result 'Connection Accepted.' -> Ich war immer der Meinung, dass das schon die Verbindung zum Broker bestätigt. Tut es aber nicht. Wenn danach nicht ein Connected to broker kommt, funktioniert das Plugin nicht. Insofern wäre hier eine andere Formulierung gut. Sowas wie "Authorization attempt returned.. Trying to connect."

Obiges Problem, wenn keine Verbindung zum Broker hergestellt werden kann...

Beim Empfangen oder Senden eines Topics sollte doch das Log Level Info sein, oder nicht? Eine Warnung wäre doch nur, wenn etwas nicht so funktioniert wie es soll?

P.S.: Was mir noch aufgefallen ist, dass in den Logmeldungen im format die Variablen oft in strings umgewandelt werden. Dafür ist meines Wissens das format selbst zuständig, könnte man also weglassen. z.B .format( message.topic, str(payload)..

[Sisamiwe]

Msinn

Das Plugin funktioniert prima. Leider zickt mosquitto bei einigen Geräten mit ESP8266 rum. Davon ist in den Foren etc haufenweise zu lesen und es schein keine Lösung zu geben. So geht es mir auch. Ich habe 2 Sonoff Basic gekauft und mit Tasmota FW geflashed. Beide verbinden sich mit WIFI, aber danach nur einer mit mosquitto. Der andere verbindet sich nicht.
Die Webconsole der Sonoff-FW sagt:

00:00:00 Project sonoff_wz Sonoff_wz (Topic sonoff_wz, Fallback sonoff_test1, GroupTopic sonoffs) Version 5.10.0
00:00:00 WIF: Connecting to AP1 WLAN-Access in mode 11N as sonoff_wz-7273...
00:00:07 WIF: Connected
00:00:14 DNS: Initialized
00:00:21 HTP: Web server active on sonoff_wz-7273.local with IP address 192.168.2.127
00:00:29 MQT: Attempting connection...
00:00:43 MQT: Connect failed to 192.168.2.12:1883, rc -2. Retry in 10 sec
00:01:01 MQT: Attempting connection...
00:01:27 MQT: Connect failed to 192.168.2.12:1883, rc -4. Retry in 10 sec
00:01:55 MQT: Attempting connection...
00:02:07 MQT: Connect failed to 192.168.2.12:1883, rc -2. Retry in 10 sec<

Das mosquitto Log sagt:

1513544715: New connection from 192.168.2.127 on port 1883.
1513544715: New client connected from 192.168.2.127 as sonoff_test1 (c1, k120, u'test').
1513544735: Socket error on client sonoff_test1, disconnecting.
1513544809: New connection from 192.168.2.127 on port 1883.
1513544809: New client connected from 192.168.2.127 as sonoff_test1 (c1, k120, u'test').
1513544829: Socket error on client sonoff_test1, disconnecting.<

Interessant ist auch, dass beide sich mit einem testweise augesetzten MQTT Broker auf einem Tablett verbinden und sich steuern lassen. Es scheint also ein Problem von mosquitto. Auch andere FW etc habe ich versucht.

Lange Rede kurzer Sinn. Auf der Suche nach einer mosquitto Alternative bin ich hierauf gestoßen: hbmqtt
Das ist ein MQTT broker und client in python.
Ließe sich das noch in das Plugin inegrieren, so dass das Plugin nicht nur Client ist, sondern auch den Broker "stellt"?
Danke für Deine Meinung.

Update
______________________

Das Problem scheint doch woanders zu liegen.
Den Problem-Sonoff kann ich vom PC aus per Ping erreichen. Vom RPI aus, auf dem auch der Broker läuft, kann ich den Problem-Sonoff per Ping zuerst nicht erreichen. Scheint somit nicht richtig im Netzwerk zu sein. dann irgendwann geht es dann. Ping#31 ging durch und ab Ping #376 alle.

[root@SmartHomeNGTEST ~]# ping 192.168.2.127
PING 192.168.2.127 (192.168.2.127) 56(84) bytes of data.
64 bytes from 192.168.2.127: icmp_seq=31 ttl=128 time=18.6 ms
64 bytes from 192.168.2.127: icmp_seq=376 ttl=128 time=2.41 ms
64 bytes from 192.168.2.127: icmp_seq=377 ttl=128 time=3.12 ms
64 bytes from 192.168.2.127: icmp_seq=378 ttl=128 time=2.18 ms
64 bytes from 192.168.2.127: icmp_seq=379 ttl=128 time=2.55 ms
64 bytes from 192.168.2.127: icmp_seq=380 ttl=128 time=2.43 ms
64 bytes from 192.168.2.127: icmp_seq=381 ttl=128 time=2.21 ms
64 bytes from 192.168.2.127: icmp_seq=382 ttl=128 time=2.88 ms
64 bytes from 192.168.2.127: icmp_seq=383 ttl=128 time=2.37 ms
64 bytes from 192.168.2.127: icmp_seq=384 ttl=128 time=3.08 ms
64 bytes from 192.168.2.127: icmp_seq=385 ttl=128 time=2.50 ms
64 bytes from 192.168.2.127: icmp_seq=386 ttl=128 time=2.51 ms

Hier bin ich mit meinem Latein zum Thema "Netzwerk" am Ende.
Wie könnte man hier weiter forschen?