Plugin MQTT Delay

**Christian Fenzl** · 20.07.2020, 15:28

Die IP-Config am Miniserver schaut auch genauso aus?

Grundsätzlich wär's für die interne Funktionalität egal (würde man meinen) - verwendest du bewusst einen Public IP Range als Subnet für dein lokales Netz?

**Christian Fenzl** · 20.07.2020, 15:57

Und das gewählte Subnet ist auch jeder deiner Komponenten bekannt? Du bist sicher, dass da nicht irgendwer nach draußen routen will?

Einfacher Test wäre:
Einen MS auf 192.168.0.10
Einen LoxBerry auf 192.168.0.11
Dazwischen einen normalen Layer 2 Switch.
Nochmal probieren.

Es "riecht" irgendwie nach einem Knoten in deiner Netzwerkconfig außerhalb von MS und LB.

**eisenkarl** · 20.07.2020, 16:20

Hier das Netzwerk der beiden MS:

Ich bin ja für alles offen, auch für eure bedenken der Netzwerkkonfiguration, diese läuft aber schon seit Jahren genau so fehlerfrei...
http und udp an andere Geräte machen keine Probleme. Ich habe den/die Miniserver direkt in verdacht.
Im Monitor der Config ist auch einiges los, allerdings finde ich nichts verdächtiges

**svethi** · 20.07.2020, 18:25

Und im Netzwerkmonitor in der Config musst Du doch die ausgehenden Verbindungen sehen. Sind die da auch verzögert?
ich sehe gerade, dass bei Deinem Screenshot der Eintrag ein Zigbee Gerät ist und dass das der State ist. Sprich wir haben da noch ein Funkgerät dazwischen, was eventuell gar nicht den State direkt übermittelt, sondern nur gepollt wird? Du schickst Ein per MQTT. Wie geht es denn dann weiter? Es muss doch dann ein MQTT Client auf das Topic hören um es dann an Zigbee zu senden. Wenn dann die Lampe eingeschaltet wird, ändert sich der state und dies wird sicher von der Zigbeeseite wieder an MQTT übertragen. Das werden die Differenzen sein. Wenn die Uhren überhaupt alle genau gleich gehen. Nutzen alle den selben Zeitserver und sind auch aktuell?

Nimm mal wirklich nur den Testaufbau mit dem Shelly. Shelly hat aktuelle Firmware und die Verbindung zum MQTT wurde dort per IPv4 angegeben?! Das sollte den Shelly direkt Schalten. Wenn dem so ist, würde ich eher auf die Geschichte MQTT <> Zigbee tippen.

Wie genau sieht denn der Weg jetzt vom MS zur Zigbee Lampe mit allen Beteiligten aus?

**eisenkarl** · 20.07.2020, 19:22

Ich habe die Zigbee Lampe ja erst nach dem ich festgestellt habe, dass ich ein Delay habe mit dem Shelly, zum testen konfiguriert.
Zigbee2mqtt mit einem Raspberry (192.128.0.148)
Zeitserver ist für alle Geräte gleich. Die Zeiten stimmen auch...

Monitor teste ich jetzt noch mal

**eisenkarl** · 20.07.2020, 19:56

Hier die Monitor Daten

beim drücken des Schalters:

Code:

00007492 192.128.0.6 20:52:03.121 20:52:05.182 HTTP2 Webservice request jdev/sps/io/15b98e57-0032-ddd4-ffffcfdbe91f9071/off
00007493 192.128.0.6 20:52:03.121 20:52:05.182 'dev/sps/io/15b98e57-0032-ddd4-ffffcfdbe91f9071/off' '15b98e57-0032-ddd4-ffffcfdbe91f9071/off' 'dev/sps/io'
00007494 192.128.0.6 20:52:03.121 20:52:05.184 GW Send command to 192.128.0.7: gw/JVirtualInOut/157f773d-01cf-6684-ffff504f94000000/15b98e57-0032-ddd4-ffffcfdbe91f9071off/0
00007495 192.128.0.6 20:52:03.121 20:52:05.188 GW answer from 192.128.0.7 36
00007496 192.128.0.6 20:52:03.121 20:52:05.188 HTTP2 Webservice answer: {"LL": { "control": "dev/sps/io/15b98e57-0032-ddd4-ffffcfdbe91f9071/off", "value": "0", "Code": "200"}}
00007497 192.128.0.6 20:52:03.121 20:52:05.194 MS intercom rcv 1 external memory/IO (ARP 13/1/498 OK)
00007498 192.128.0.6 20:52:03.121 20:52:05.196 MS memory Testschalter (iobroker, Büro) 0.000/0

wenn der Shelly schaltet:

Code:

00007602 192.128.0.6 20:52:12.463 20:52:14.541 HTTP2 Webservice request keepalive
00007603 192.128.0.6 20:52:12.549 20:52:14.645 TCP 116 accept listen port 80 (from 192.128.0.148/52316)
00007604 192.128.0.6 20:52:12.549 20:52:14.647 HTTP Client HTTP6 connected, Socket 116 Port 52316
00007605 192.128.0.6 20:52:12.550 20:52:14.647 HTTP6 GET /dev/sps/io/shellies_shelly1-10E487_relay_0_command/0 HTTP/1.1
00007606 192.128.0.6 20:52:12.551 20:52:14.649 HTTP6 Line empty
00007607 192.128.0.6 20:52:12.551 20:52:14.649 HTTP No Keep-Alive
00007608 192.128.0.6 20:52:12.552 20:52:14.649 'dev/sps/io/shellies_shelly1-10E487_relay_0_command/0' 'shellies_shelly1-10E487_relay_0_command/0' 'dev/sps/io'
00007609 192.128.0.6 20:52:12.552 20:52:14.649 GW GetSlaveS AY_0_COMMAND missing
00007610 192.128.0.6 20:52:12.565 20:52:14.661 TCP 1 accept listen port 80 (from 192.128.0.148/52318)
00007611 192.128.0.6 20:52:12.569 20:52:14.663 HTTP Client HTTP3 connected, Socket 1 Port 52318
00007612 192.128.0.6 20:52:12.569 20:52:14.665 HTTP3 GET /dev/sps/io/shellies_shelly1-10E487_relay_0/0 HTTP/1.1
00007613 192.128.0.6 20:52:12.569 20:52:14.665 HTTP3 Line empty
00007614 192.128.0.6 20:52:12.569 20:52:14.665 HTTP No Keep-Alive
00007615 192.128.0.6 20:52:12.572 20:52:14.667 'dev/sps/io/shellies_shelly1-10E487_relay_0/0' 'shellies_shelly1-10E487_relay_0/0' 'dev/sps/io'
00007616 192.128.0.6 20:52:12.651 20:52:14.749 TCP remove socket 116 (1)
00007617 192.128.0.6 20:52:12.804 20:52:14.853 HTTP HTTP6 disconnected
00007618 192.128.0.6 20:52:12.804 20:52:14.853 TCP create socket 103 - free: 244
00007619 192.128.0.6 20:52:12.804 20:52:14.867 HTTP HTTP3 disconnected
00007620 192.128.0.6 20:52:12.804 20:52:14.867 TCP create socket 172 - free: 243
00007621 192.128.0.6 20:52:12.804 20:52:14.867 TCP remove socket 1 (7)

**svethi** · 20.07.2020, 20:36

Daran sieht man, dass das Plugin/MQTT sofort reagiert. Und ich lese da auch heraus, dass der Shelly bereits reagiert hat. Hast Du den Shelly denn bezüglich des Modus richtig konfiguriert?
Ich kann auch von Seiten des MS aus derzeit keine Verzögerung sehen.

**eisenkarl** · 20.07.2020, 21:08

Hm? Vom drücken bis zum schalten vergehen 9 Sekunden? Laut der Logdatei

**Christian Fenzl** · 20.07.2020, 23:07

Ich versteh das Log nicht. Irgendwas kommt von ioBroker auf .6 herein, dann wird irgendwas an .7 weitergesendet.
Paar Sekunden später geht der Shelly-Command von .6 ans MQTT Gateway, und 20ms später kommt der Status zurück.

Kannst du am .6 mal einen einfachen Schalter-Baustein machen, und damit den VO für den Shelly schalten. Das probierst du dann in der Loxone App.

Ich kann nicht deuten, was ioBroker da involviert ist, und die beiden MS.

**svethi** · 21.07.2020, 00:34

Das sehe ich jetzt erst. Wieso sind da 2 Zeitstempel drin? Aber wie auch immer, wo siehst Du da 9 Sekunden, die da vergehen?

**eisenkarl** · 28.07.2020, 17:01

Ich habe jetzt per Packetsender die Befehle an den Loxberry geschickt, gleiche Verzögerung wie vom Miniserver

**eisenkarl** · 28.07.2020, 17:10

Hier das Log vom Loxberry:

Code:

 [LEFT][SIZE=13px][COLOR=#000000][FONT=monospace]18:08:20.059 [/FONT][/COLOR][/SIZE][/LEFT]
  [LEFT][COLOR=green][FONT=monospace][SIZE=13px][B]OK:[/B][/SIZE][/FONT][/COLOR][/LEFT]
  [LEFT][SIZE=13px][COLOR=#000000][FONT=monospace]UDP IN: (192.128.0.73): shellies/shelly1-10E487/relay/0/command on[/FONT][/COLOR][/SIZE][/LEFT]

Abgeschickt am Rechner per Packetsender um 18:08:10 - 10 Sekunden delay am Loxberry

**Christian Fenzl** · 28.07.2020, 22:16

Also zusammengefasst:
UDP vom MS: langsam
UDP von .0.73: langsam
HTTP per Browser: schnell
HTTP vom MS: langsam

Was ist bei deinem Browser/PC anders als bei MS und .0.73?

Ist die .0.73 der Rechner, wo auch der Browser läuft?
Ein tracert und Ping geht zackig und ohne Hops?

Sonst mal Wireshark am Rechner, wo‘s langsam ist, laufen lassen, was der da alles so macht in den 10 Sekunden.

**Christian Fenzl** · 28.07.2020, 22:29

Wenn du nicht weiter kommst, können wir Mi. Abend eine Remote Session machen, dann schau ich mal drauf.
Wenn ok, schick mir deine WhatsApp/Signal Tel. per PM.
lg, Christian

**tpk** · 06.03.2022, 11:29

Hallo Zusammen,

habe mir gerade das Thema durchglesen weil ich (bis gerade eben) das selbe Problem hatte wie eisenkarl. Fing bei mir allerdings erst vor ein paar Tagen an als ich damit begonnen habe alle Loxone Komponenten in ein eigenes VLAN zu versetzen und Shelly & Co in ein eigenes IoT VLAN. Der Zugriff über den Webbrowser auf den Loxberry (rennt bei mir als HyperV VM) war ebenfalls langsam, hatte am Anfang schon das VLAN Tagging am HyperV bzw. den Switch in Verdacht..
Des Rätsels Lösung war das ich vergessen hatte auf der Firewall den DNS Service auch für die beiden neuen VLANs bereitzustellen, mag der Loxberry gar nicht

Vielleicht hilft es ja dem ein oder anderen mal

LG

Plugin MQTT Delay

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar