Öffne einfach mal die Instanz, verändere etwas da drin und setz es wieder auf den eingestellten Wert zurück, danach kannst du speichern. 
Grüße,
Kai
Das hört sich dann aber eher nach einem Firmware Problem an.
Mit Verzögerungen über MQTT hatte ich auch eine Zeit lang zu kämpfen, ich habe aber einfach zu viele Geräte, die über MQTT kommunizieren und teilweise auch viele Werte schicken.
Der MQTT Server verarbeitet alles nacheinander, daher kann es zu Verzögerungen kommen. Ich habe einfach eine zweite MQTT Server Instanz mit einem anderen Port erstellt und darüber weitere Geräte angebunden.
Grüße,
Kai
Hallo alsk1,
ich habe wirklich viele Wlangeräte im Einsatz, und meistens läuft es rund, aber einen Fall habe ich auch der da was ausbremmst.
Ein ShellyEM mit der Leistungsmessung hängt ein deier MiniPV (Leitung Zelle und Zuleitung zur Garage). Wenn die PV morgens startet, flattern die Werte (hohe Datenlast) und bremsen MQTT aus.
Da habe ich einfach mal einen zweiten MQTT Server in IPS eingerichtet (mit anderm Port) und dort das ShellyEM drangehängt, seitdem ist alles OK.
Kai war schneller…
Hallo KaiS…anbei die Dump Datei…ich habe nur Kanal 1 per Webfront Button eingeschalten und dann wieder ausgeschalten.
dump (2).txt (31.5 KB)
Gruß
richimaint
Hallo Kai,
die Shelly 1 haben doch gar keine (Über-)temperatur-Attribute. Insofern kann er die da ja nicht finden…
Vielen Dank für die Info! Ich habe allerdings keine mir bewusst übermäßig schreienden Geräte über MQTT.
Ich habe derzeit 24 Shellies, davon 6 Dimmer1, 4x Shelly2.5, 1x ShellyPlug, 13x Shelly1 (v3).
Ob das schon ausreicht? Komischerweise tritt eine spürbare Verzögerung auf, wenn ich einen Dimmer mehrfach kurz hintereinander schalte. Ab und an aber auch, wenn ich Z.B. einen Shelly1 schalte.
Es muss ein Problem mit dem Broker geben.
Die „Erreichbar“ Variable im Shelly Modul wird selbst nach einem Neustart des Shelly nicht mehr aktualisiert. Dieses funktionierte unter IPS 5.4 einwandfrei, jetzt unter IPS 5.5 nicht mehr.
Wird der Shelly Aktor neu gebootet, so bleibt die „Erreichbar“ Variable unverändert.
Stellt man die „Erreichbar“ Variable manuell auf TRUE und geht dann in die WebUI des Shelly in die Advanced Develepor Settings und speichert dort (ohne etwas zu verändern), wird die „Erreichbar“ Variable wieder auf FALSE gesetzt.
Irgendwas passt hier überhaupt nicht.
Die Dimmer senden extrem viele Daten. Das kann schon so sein.
Erstelle mal einen zweiten MQTT Server und teste es.
Grüße,
Kai
Gesendet von iPhone mit Tapatalk
Habe vorhin mal das neueste Update des Modul installiert (ohne zu wissen was dort geändert wurde) aber die ‚Erreichbar‘ Variable wird nach einem Reboot immer noch nicht aktualisiert und verbleibt stumpf auf dem Wert wo sie steht.
Kann das jmd verifizieren? Oder senden die Shellies ihren Status gar nicht mehr? Dann könnte man die Variable ja komplett entfernen…?
Wenn ich eine zweite MQTT Instanz anlege, sollte ich dann hier alle Dimmer reinpacken? Welchen Port nehme ich dann vorzugsweise für die 2.Instanz? Die jetzige Instanz nutzt den 1883. Nehme ich dann die 1884?
Ich habe für meine Tasmota Geräte den Port 1883 und für die Shellys 1884.
richimaint
Gesendet von iPhone XS mit Tapatalk
Danke!
Wie viele und welche Shelly Geräte setzt Du denn über den Port 1884 ein wenn ich fragen darf?
Tasmota Geräte habe ich glaub 20 und Shellys erst 3
Gesendet von iPhone XS mit Tapatalk
Hol dir mal einen MQTT Explorer, dann siehst du was deine Shellys senden. Zumindest ich sehe nichts was Richtung „Status“ deutet.
Moin,
Shelly sendet nach einem Reboot :
27.09.2020, 10:01:46 | JSON | {"DataID":"{7F7632D9-FA40-4F38-8DEA-C83CD4325A32}","PacketType":3,"QualityOfService":0,"Retain":false,"Topic":"shellies/büro/test/online","Payload":"false"}
Somit wird Online auf false gesetzt.
Also die Variable im Modul wird nicht mehr aktualisiert. Ich glaube entweder seit der Shelly FW 1.8.4 oder seit IPS 5.5…
Das war alles recht zeitgleich.
Irgendwie passt da was nicht mehr mit dem Modul in Bezug auf den Online Status. Zumindest nicht was einen Reboot des Shelly betrifft.
https://shelly-api-docs.shelly.cloud/#mqtt-configuration
Ich versuche mal was zu finden.
Sieht nach einem Bug in der Shelly Firmware aus, oder die Doku passt nicht.
Also den Status Online/Offline erst mal ignorieren.
Hallo Leute,
ich habe eben nochmals mit mehreren Shellys bei mir im Hause den Online/Offline Status getestet.
Nach stromlos schalten der Shellies dauert es ca. 1 Minute und die Variable -Erreichbar- in IPS wechselt auf Offline.
Erhält der Shelly wieder Spannung ist die Variable nach weniger als 5 Sekunden wieder auf Online.
Dieses Verhalten funktioniert jedes mal, da kann doch kein Firmenwareproblem vorliegen.
Allerdings verwende ich als Broker den Mosquitto. Stelle ich einen Shelly auf den internen Brocker um bekomme ich auch unter IPS 5.4 die Probleme mit dem Online/Offline verhalten.
Bei mir laufen auch zwei Shelly Dimmer am Mosquitto und ich stelle keine Probleme mit den Shellies und auch den Tasmota Geräten fest die am Mosquitto hängen. Habe keinerlei Schaltverzögerungen, an keinem Gerät (26 Tasmota-Geräte und 23 Shellies an einem Mosquitto).
Ich habe lange den internen versucht zu nutzen, aber leider war 99,9% zuverlässiges schalten nicht wirklich möglich.
Oft verzögert, teils auch überhaupt nicht. Die kann ich in meinem produktiv System nicht wirklich gebrauchen.
Ich bin Kai unendlich dankbar, das er den MQTT-Client wieder angebunden hat an die 5’er Module.
Selbst eine MQTT Anbindung zu bauen wäre 3-4 Stufen oberhalb meines Fähigkeiten.
Toll ist, das man jetzt leicht zwischen beiden Brokern hin und her stellen kann um zu Testen.
Gruß
Achim
Ich habe den internen MQTT immer noch installiert und teste regelmäßig nach Updates von IPS ob der interne jetzt genauso sauber läuft wie der Mosquitto, leider ist dies bis jetzt nicht der Fall.
Aber wie heißt es so schön, >Gut Ding will Weile haben<.
Hallo,
ich habe die Online-Variable rausgeworfen und eine eigene integriert. Die schaltet jeweils bei Aktualisierung der Statusvariable auf Online und das funktioniert auch ganz gut so. Bevor ich ein RequestAction versende, stelle ich sie explizit auf OFFLINE und wenn der Request im Shelly ankommt, meldet er sich zurück und sie ist wieder Online. Damit habe ich auch gleich visualisiert, ob mein Request angekommen ist. Tatsache ist ja, dass die Original-Variable ja bei einem Strom- oder WLAN-Ausfall ja sowieso kein OFFLINE zurückmeldet (wie auch ?). Wenn man es noch genauer haben möchte, kann man ja auch das Aktualisierungs-Intervall auswerten und wenn man feststellt, dass er sich 30 Sekunden lang nicht gemeldet hat, ist er wohl OFFLINE.
Dazu habe ich noch ein Shelly-Alive-Request per HTTP geschaltet, da es öfters vorkommt, dass die Shellies per MQTT (interner Broker) nicht erreichbar sind und nach dem Absetzen des HTTP-Befehls wieder da sind. Ich gehe nachwievor davon aus, dass dies ein Problem des internen Brokers ist, denn die Shellies senden ja ständig ein Signal, dass zwar im MQTT-Server-Debug zu sehen ist, aber der Server ignoriert das und das fängt sich erst nach dem HTTP wieder 
.
Auch bei einem WLAN Ausfall müsste die Variable auf Offline gehen, da eine solche Variable zyklisch vom Aktor gesendet werden müsste bzw der Aktor müsste zyklisch sein Alive Senden, damit die Variable auf Online bleibt. Kommt kein Alive mehr, so müsste sie auf Offline schalten (durch den Broker).