Ankündigung

**Onkelandy** · 18.12.2017, 10:07

Hm, komisch... Ich hab es erst mit dem neuesten Release getestet, da ich nun das network plugin auf mqtt umstellen will, was den Austausch an Item-Werten zwischen zwei SmarthomeNG Instanzen anlangt.

Problem ist wie gesagt, dass die Werte zwar bei beiden Instanzen gepublisht werden, aber beim Subscriber nicht upgedatet. Es kommt nichts ins Log und der Wert ändert sich dort nicht. Bei mosquitto selbst habe ich keine Änderungen an der Config vorgenommen. Sonderbar. Ich boote jetzt beide Geräte nochmals neu und melde mich dann nochmals.

An der oben beschriebenen Config kannst du aber auch keinen Fehler erkennen, ja?

**Msinn** · 18.12.2017, 10:32

Bist Du Dir sicher, dass nicht auf einem der PIs noch das Plugin in der Version 1.3.3 läuft?

**Onkelandy** · 18.12.2017, 12:39

Ist bei beiden PLUGIN_VERSION = "1.3c.4"
Auch nach dem Reboot kein Receiving

**Onkelandy** · 19.12.2017, 15:16

Hab jetzt für das neue Image alles neu aufgesetzt und siehe da. es klappt. *uff*

Wenn keine Verbindung aufgebaut werden kann, kommt allerdings folgender Fehlerschwall:

Code:

2017-12-19  15:08:06 INFO     Main         Loading '/usr/local/smarthome/plugins/mqtt/plugin.yaml' to 'OrderedDict'
2017-12-19  15:08:06 INFO     Main         plugin 'mqtt': Metadata paramlist = '['host', 'port', 'qos', 'last_will_topic', 'last_will_payload', 'birth_topic', 'birth_payload', 'publish_items', 'items_topic_prefix', 'user', 'password', 'acl']'
2017-12-19  15:08:06 INFO     Main         plugin 'mqtt': value not found in plugin configuration file for parameter 'port' -> using default value '1883' instead
2017-12-19  15:08:06 INFO     Main         plugin 'mqtt': value not found in plugin configuration file for parameter 'qos' -> using default value '1' instead
2017-12-19  15:08:06 INFO     Main         plugin 'mqtt': value not found in plugin configuration file for parameter 'last_will_topic' -> using default value '' instead
2017-12-19  15:08:06 INFO     Main         plugin 'mqtt': value not found in plugin configuration file for parameter 'last_will_payload' -> using default value '' instead
2017-12-19  15:08:06 INFO     Main         plugin 'mqtt': value not found in plugin configuration file for parameter 'birth_topic' -> using default value '' instead
2017-12-19  15:08:06 INFO     Main         plugin 'mqtt': value not found in plugin configuration file for parameter 'birth_payload' -> using default value '' instead
2017-12-19  15:08:06 INFO     Main         plugin 'mqtt': value not found in plugin configuration file for parameter 'publish_items' -> using default value 'False' instead
2017-12-19  15:08:06 INFO     Main         plugin 'mqtt': value not found in plugin configuration file for parameter 'items_topic_prefix' -> using default value 'devices/shng' instead
2017-12-19  15:08:06 INFO     Main         plugin 'mqtt': value not found in plugin configuration file for parameter 'user' -> using default value '' instead
2017-12-19  15:08:06 INFO     Main         plugin 'mqtt': value not found in plugin configuration file for parameter 'password' -> using default value '' instead
2017-12-19  15:08:06 INFO     Main         plugin 'mqtt': value not found in plugin configuration file for parameter 'acl' -> using default value 'none' instead
2017-12-19  15:08:06 INFO     Main         Connecting to broker. Starting mqtt client 'SmartHomeNG'
2017-12-19  15:08:06 ERROR    Main         Plugin 'mqtt' from section 'mqtt' exception: 'LogRecord' object has no attribute 'message'
Traceback (most recent call last):
  File "/usr/local/smarthome/plugins/mqtt/__init__.py", line 382, 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 111, in __init__
    plugin_thread = PluginWrapper(smarthome, plugin, classname, classpath, args, instance, self.meta)
  File "/usr/local/smarthome/lib/plugin.py", line 413, in __init__
    exec("self.plugin.__init__(smarthome{0}{1})".format("," if len(arglist) else "", argstring))
  File "<string>", line 1, in <module>
  File "/usr/local/smarthome/plugins/mqtt/__init__.py", line 176, in __init__
    self.ConnectToBroker()
  File "/usr/local/smarthome/plugins/mqtt/__init__.py", line 384, in ConnectToBroker
    self.logger.error(self.get_loginstance()+'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 113, in emit
    self._log.add([timestamp, record.threadName, record.levelname, record.message])
AttributeError: 'LogRecord' object has no attribute 'message'

**Sisamiwe** · 20.12.2017, 20:34

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?

**Onkelandy** · 23.12.2017, 11:55

***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** · 02.01.2018, 17:15

Hallo,

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

Code:

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?

Code:

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?

Code:

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

Danke für die Rückmeldung.

**Msinn** · 02.01.2018, 17:42

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.

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

**Msinn** · 02.01.2018, 17:47

Nimm sonst erstmal die Plugin Version aus dem Develop Branch.

**Sisamiwe** · 02.01.2018, 17:56

Damit geht es.

Was sagst zum Senden von Bool Items?

**Msinn** · 02.01.2018, 18:07

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** · 02.01.2018, 18:10

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

**Msinn** · 02.01.2018, 18:22

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** · 02.01.2018, 18:25

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** · 02.01.2018, 18:27

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.

Ankündigung

Neues MQTT Plugin

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar