So sieht das aus…
Wie viele MQTT Server Instanzen hast du zur Zeit?
Wie viele Shellys hast du zur Zeit?
Grüße,
Kai
2 MQTT Instanzen (1x 6 Dimmer, 1x 24 Shellies).
Aber wenn ich die Instanzen deaktiviere, dann bleibt die CPU Auslastung bei 92-100%.
Ich könnte mal mit anydesk drauf schauen.
Ich sende dir per PM meine Daten.
Leute, ich habe den Fehler für die Verzögerungen ausfindig gemacht und nach unzähligen Tests kann ich es definitiv zu 100% eingrenzen.
Ich habe auch wieder alle Shellys in 1 MQTT Instanz. Das rennt jetzt wie am Schnürchen.
Und zwar liegt es am 5Ghz WLAN. Sobald ich dieses an der Fritzbox 7490 deaktiviere, läuft alles ohne jegliche Verzögerungen.
Sobald ich das 5Ghz WLAN wieder einschalte, habe ich nur Stress.
Und das obwohl das 2,4 und das 5Ghz WLAN unterschiedliche SSIDs haben…
Ich verstehe nur nicht wieso das erst seit IPS5.5 so ist und vorher mit der 5.4er nicht…
Also werde ich wohl oder übel die Fritzbox tauschen müssen? Da bleibt ja dann nur die Fritzbox 7590, es sei denn jmd hat was Besseres als Vorschlag.
Oder das 5Ghz WLAN streut in den Raspi rein, der steht nämlich direkt neben der Box. Aber vorstellen kann ich es mir nicht.
Oh Moment.
Das habe ich vorhin nicht gewusst, und nicht nach Wlan geschaut.
Ist auf dem Pi Wlan aktiv oder (und) Netzwerkkabel angeschlossen ?
Ob bei dem Raspi WLAN aktiv ist das weiß ich leider nicht. Zumindest ist es nie konfiguriert worden, der Raspi ist per LAN angeschlossen.
Von daher dürfte es eigentlich egal sein ob WLAN am Raspi aktiv ist oder nicht, da er ja eh keine Verbindung aufbauen kann und es nie konfiguriert war.
Au man, darauf muss man erstmal kommen… Da die Fritzbox 7490 sowieso etwas träge ist (da hängen inkl. der Shellies bestimmt knapp 50 Geräte per WLAN dran), muss wohl neue Hardware her…
Habe die 7490 gegen 7590 getauscht,
aber die ist auch lahm geworden.
Hat aber noch mehr Geräte im Wlan.
Abar hier ist 5 und 2.4 per Mesh mit einigen Repeatern am laufen.
Ich denke, wir sprechen noch mal Morgen, wenn du Zeit hast.
Übrigens konnte ich beim alsk1 IP-Symcon als Urasche ausschließen, da man in Wireshark sehen konnte, wie die Pakete korrekt abgesendet werden und dann bei der eigentlichen übertragung TCP Retransmission Errors aufgetreten sind.
Falls jemand sich den Spaß machen will, könnt ihr auf dem Pi Daten per TCP Dump einsammeln:
sudo tcpdump -s 65535 -w dump.tcp port 1883
(port 1883 könnt ihr anpassen, wenn es ein anderer Port sein soll :))
Die Datei dann kopieren und auf eurem Rechner diese per Wireshark öffnen und mit dem Debug von den Instanzen vergleichen 
paresy
Und es kann auch sein das ich noch ein ‚faules Ei‘ unter den Shellies habe.
Das ist natürlich schwer zu identifizieren aber mir ist aufgefallen das ich mehrfach in letzter Zeit den Fall hatte, das „Spiegelschrank Bad“ in Symcon auf true stand, das Licht aber aus war. Bei diesem Aktor handelt es sich um einen Shelly2.5 mit dem Deckenlicht und Spiegelschrank geschaltet werden (Kanal 1 Spiegelschrank, Kanal 2 Deckenlicht).
Wenn ich nun den Kanal1 mehrfach in Folge über das WebUI des Shelly schalte (ein, aus, ein, aus… ) dann funktioniert das zwar, aber plötzlich beim Ausschalten verschwindet kurz die Uhrzeit und der Button kreiselt endlos. Und das ist dann der Moment wo der Aktor zwar ausgeschaltet hat, in Symcon bleibt er aber auf ein stehen.
Kanal2 macht keine Probleme. Daher wird dieser Shelly2.5 heute mal getauscht.
Komischerweise habe ich diesen „paradoxen Zustand“ der Stati auch mit anderen Shelly Aktoren. Aber wer weiß was für Auswirkungen dieser besagte Shelly2.5 auf das ganze System hat… Man kann ja nur eingrenzen. Das ist echt recht müßig aber ich werde weiter berichten denn vielleicht kämpft irgendwann jemand anderes auch mit den Problemen.
Es wird immer spannender. Ich hatte im Badezimmer einen Shelly 2.5, welcher auf Kanal1 den Spiegelschrank (Röhre) und auf Kanal2 das Deckenlicht (Einbauspots) geschaltet hat.
Dann habe ich im Schlafzimmer einen Dimmer, welcher mit Latenzen zu kämpfen hatte, wenn man diesen über MQTT geschaltet hat. die Latenzen sind wie @paresy schon festgestellt hat, nicht auf den MQTT Broker zurückzuführen sondern liegen irgendwo in der Kommunikation am WLAN bzw. WLAN <-> Dimmer.
Nun hatte ich festgestellt das in den letzten Tagen laut IPS der Spiegelschrank an sein sollte, obwohl dieser aus war. Ich bin also hergegangen und habe sowohl über das WEBUI des Shelly2.5, als auch über das Webfront den Shelly2.5 mehrfach schnell hintereinander ein/ausgeschaltet (Kanal1 = Röhre) und dabei festgestellt das der Shelly dort (vor allem beim Ausschalten) plötzlich ins Stolpern gerät. Dieses konnte man daran sehen, das der Button im WEBUI des Shelly2.5 plötzlich am Dauerkreiseln war bzw. eine Bedienung über das Webfront überhaupt nicht mehr möglich.
Daraufhin habe ich den Shelly2.5 ausgebaut und einen Ersatz-Shelly2.5 eingebaut, da ich hier die Ursache vermutete. Habe dann den neuen Shelly2.5 eingerichtet, dann Kanal1 (Röhre) an, aus, an… plötzlich zischte es kurz und es gab ein „Plopp“, das war es dann. Der neue Shelly2.5 tot… sagt keinen Mucks mehr. Habe dann gelesen, das durch induktive Spannungen (Röhren mit KVG und Starter) wohl schon massig Shelly2.5 gestorben sind. So nun auch mein Ersatz-Shelly2.5…
Warum der erste Shelly2.5 solange gehalten hat, ist wohl ein Wunder.
Habe nun erstmal für das Badezimmer keinen Shelly mehr, werde erstmal auf eine LED Röhre umrüsten und das alte KVG überbrücken. Dann sollte es keine Probleme mehr geben.
Interessant ist jedoch folgendes: Mir ist dann eingefallen, das das Schlafzimmer und Badezimmer an einer Sicherung hängen. Habe dann das 5Ghz WLAN an der Fritzbox wieder eingeschaltet und seit dem der Shelly2.5 im Badezimmer nicht mehr existent ist, habe ich auch keine Schaltverzögerungen mehr beim Shelly-Dimmer im Schlafzimmer, obwohl das 5Ghz WLAN wieder aktiv ist (gestern erst noch hatte ich festgestellt, das durch das Abschalten des 5Ghz WLAN auch die Schaltverzögerungen des Dimmers weg sind, allerdings lebte da ja der Shelly2.5 im Badezimmer noch).
Jetzt frage ich mich natürlich ob es sein kann, das der Shelly2.5 mit dem KVG inkl. Starter auf dem Kanal1 irgendeinen Mist in das Stromnetz eingespeist hat, so das hiervon auch der Dimmer im Schlafzimmer (selbe Sicherung) betroffen war bzw. beeinflusst wurde. Anders kann ich es mir kaum erklären, das hier wirklich irgendein Mist reingestrahlt ist, sei es über WLAN, oder über das Stromnetz.
Ich bin auch am Überlegen, ob ich nicht auch an jeden Dimmer einen Einschaltstrombegrenzer setzen sollte. Denn ich dimme überwiegend LED Leuchten (welche alle als dimmbar deklariert sind) aber ich habe mal gelesen, das die LED Leuchten mitunter beim Einschalten ein Vielfaches an Strom ziehen, als die Nennangabe. Nicht das mir hier noch Shelly-Dimmer über den Jordan hüpfen.
Danke für die Info’s
Jetzt wird mir einiges klarer.Mit sochen Dingen hatte ich nicht gerechnet, in der kurzen Zeit,
Naja,so ganz schlüssig ist mir das alles immer noch nicht. Das der Shelly2.5 aufgrund induktiver Rückspannung die Grätsche macht/machen kann OK… Aber nicht der Rest, der damit anscheinend auch irgendwie zusammenhängt.
Also hier ist definitiv was faul mit der v5.5.
Ich habe heute den Update gemacht (von 5,4) und jetzt habe ich riesige Probleme mit den Shellys. Als Reachable wird bei allen „Offline“ angezeigt" obwohl diese erreichbar sind und auch schaltbar sind.
Ich habe ein Script das jede Minute überprüft, ob die Shellys noch leben (hatte ich bisher über den Update der State Variable geprüft). Das geht nicht mehr, weil sich bei verschiedenen Shellys nur noch manche oder gar keine Variablen ändern.
Beim Shelly 2.5 nur „Device Temperature“ und Overtemperatur"
Beim Shelly 1 nur „Input“ und „State“
Beim Shelly-Plug nur „Energy“ und „Power“
Beim Shelly Dimmer ändert sich gar nichts mehr.
Hier bitte dringend nachbessern oder mal bekanntgeben, was sich geändert hat, das dieses Verhalten auslöst. Ich muss sonst ein Haufen Logik in meinen Programmen ändern.:mad:
Nachtrag: Bei einem Schaltbefehl an den Shelly werden alle Variablen upgedated (bei allen Typen), aber nie die „Reachable“.
Das kann ich auch so bestätigen. Ist mir aber erst nach diesem Beitrag aufgefallen.
@KaiS ist es möglich beim RGBW2 den Input/Eingang hinzuzufügen? Beim Shelly 1 nutze ich den Eingang vom Ausgang getrennt schon länger. Danke
Mfg Daniel
@HMK: Was das angeht sollte sich zur 5.5 nichts geändert haben - zumindest nicht absichtlich.
Ich kann dies aber bei meinem Shelly’s auch nachstellen. Ich werde mal nachforschen, woran das liegt, dass diese Variablen fehlen.
paresy
Hallo Paresy,
Ich hatte das Problem schon mal hier beschrieben [Modul 5.1] Shelly - MQTT Server & MQTT Client - Seite 44 .
Zu der Zeit hatte ich das Problem, das irgendwann die Shellys nicht mehr reagiert haben. Gelöst habe ich das durch ein Script, das die Aktualisierung der Variablen (state) prüft. https://www.symcon.de/forum/threads/40057-Modul-5-1-Shelly-MQTT-Server-MQTT-Client?p=423102#post423102
Aktuell kann ich dieses Script nicht mehr laufen lassen und weiß demzufolge nicht, ob meine Shellys noch leben. Das erfahre ich erst, wenn ich einen Schaltbefehl ausführen will, und dann ist es vielleicht schon zu spät.
Das hat sich von 5.4 zu 5.5 definitiv verändert.
PS: alle Shellys haben die aktuelle Firmware und sind nach dem Update auf 5.5 nochmal neu gestartet worden. Auch das Shelly-Modul von Kai habe ich nochmal neu installiert.
Gerne kann ich auch Debugs oder Wireshark-Traces beisteuern.