Hi Peter,
werden die Geräte dann auch als Offline angezeigt? Oder bleiben die Online?
paresy
Muss ich abwarten, Frau und Kinder laufen Amok weil der Raffstore nicht ging.
Edit: Habe vor dem Neustart die Queue von 500 auf 5000 erweitert, vielleicht hilft das ja…
Ok hilft nicht. Habe die Situation wieder, Raffstore Schlafzimmer geht nicht. Geht dann auf Offline.
Hi Harry.
Du hast also die Konfiguration angepasst und jetzt ist alles wieder gut?
paresy
Ich habe die beiden Parameter eingetragen und es sieht momentan ok aus.
Timeout 3600 und Queue Limit 500
Viele Grüße aus dem Unterallgäu
Harry
Moin.
jetzt habe ich auch ein ShellyEM welches sich nicht über IPS schalten lässt, und Offline anzeigt.
Alle Messwerte trudeln aber noch ein.
Ich vermute, wenn ich das Shelly neu starte (Reboot) wird alles wieder gehen, ich lasse das aber erst mal.
Nachtrag, im Server Socket war „Fehlermeldungen zu Verbindusabbrüchen unterdrücken“ aktiv.
Das hatte ich nicht eingeschaltet, sehr merkwürdig.
Habe es wieder inaktiv gesetzt, und sofort war das Shelly wieder Online.
Bei mir war die Einstellung nicht aktiv. Als ich versucht habe sie zu aktivieren, ist der Schalter gleich wieder auf inaktiv gesprungen - aber der Shelly war sofort online und das Skript geht wieder. Hier gibt es also definitiv einen Zusammenhang.
Apropos, das kann ich NICHT bestätigen. Neustart vom Shelly hilft nicht.
Ich habe soeben eine neue Version hochgeladen. Mögt ihr die einmal testen? Falls diese nicht hilft, habe ich auch ein paar neue Debug Meldungen eingebaut.
Was mir dann helfen würde: Debug vom Server Socket und MQTT Server „In Datei schicken“ aktivieren und sobald ein Gerät offline geht mir ein Bild vom Baum senden (wo ich den Zeitstempel sehen kann) und die IP-Adresse vom problematischem Gerät.
Vielen Dank an alle, die mir bisher Debug Logs geschickt haben!
paresy
Ich habe die Version gestern sofort installiert und meine Tasmota Probleme sind nicht mehr aufgetreten. Jedoch ist der Online Status scheinbar manchmal kurz offline. Das sehe ich am Last Change Time stamp und habe auch schon mal eine Variable „erwischt“. Ich aktiviere mal die Archivierung für so eine Online Variable.
Du kannst ja auch das Debug vom MQTT Server „offen“ lassen und nach CONNET filtern. Dann wirst du wahrscheinlich sehen, dass deine Geräte tatsächlich sich neu verbunden haben. Der Fehler, den ich gefixt hatte, trat dann also nur auf, wenn Geräte sich zwischendurch neu verbunden hatten. (Wenn Geräte eine zu 100% stabile Verbindung hatten, trat der Fehler nicht auf)
paresy
Also bei mir ist der Fehler jetzt scheinbar weg! 
Danke!!
Ich hatte bis dahin nur den einen Fehler, von daher beobachte ich weiter.
Bis jetzt läuft das aber rund.
Also ich habe meine Installation auf Docker Basis heute Vormittag auch auf stable aktualisiert, und mich gerade gewundert wieso einer der Gosund nicht per Zeitplan aus schaltet. Durch Zufall bin ich auf diesen Thread gekommen. Ich habe auch ein ganz komisches verhalten. Ab und an, kann ich einen Gosund schalten den ich neu einstecke, dann ist dieser nicht mehr erreichbar, auch nicht über die Tasmota WebGUI.
MQTT Server
Session Timeout war/ist bei mir auf 3600
Session Queue Limit 500
Gruss Marco
eben zurück auf symcon/symcon:5.5-78. Läuft bei mir seit 45 Minuten mit diversen Schalt-Tests stabil…
Gruss Marco
ich kann meine Beträge nicht editieren deshalb neuer Update via Antwort:
Docker symcon/symcon:5.5-78 nach wie vor eine Probleme (seit 8+ h)
Falls ich irgendwie helfen kann, einfach melden.
Gruss Marco
Hallo,
seit den Update auf Version 5.5 wird mein sync nur Homematic und zur Siemens Logo nicht mehr richtig ausgeführt und häufig kommt die Fehlermdlung: zu viele Gleichzeitige Scripte. Vorher lief es super stabil und immer synchron. Ich take das durch 3 Siemens Logos und der Homematic. Immer eine Minute true, eine Minute false zur Kontrolle bzw. als Lebensbit. Schaltvorgänge zur Siemnes muss man mehrmals machen, so dass es auch dort wirklich ankommt.
Woran kann das liegen???:mad:
Gruß Udo
Hi Udo,
magst du mal die Beta-Version ausprobieren, ob diese hilft? Wir hatten zur 5.5 an den Netzwerk-Bibliotheken updates durchgeführt, diese in der aktuellen Beta aber revidiert, um ggf. Probleme damit auszuschließen.
paresy
Hallo Paresy,
ja kann ich gerne machen. Zrück kommt man doch wieder falls die Probleme noch mehr werden?
Kommt daher auch evtl. die Meldung mit den zu vielen scripten? Ich habe schon alles deaktiviert was nicht unbedingt benötigt wird.
Gruß Udo
Du kannst in den PHP Informationen mal schauen, welcher deiner Skripte ggf. verzögern. Bisher haben wir nur sehr wenig Probleme mit den Sockets und noch nicht in der Kombination, dass Skripte „gedropped“ werden.
paresy
Hall Paresy,
in den PHP Informationen habe ich gesehen, dass wenn er die Simens Logo Variablen schreibt voll läuft und lange braucht, in der Zeit stockt das ganze System und Befehle werden nicht mehr richtig verarbeitet.
Fehlermeldung ist dann immer: Socket nicht verbunden.
Worann kann das liegen?
Gruß Udo
Setup:
[ul]
[li]RPi
[/li][li]Buster
[/li][li]
[/li][/ul]
Moin zusammen,
seit gefühlt einer Woche kommt beobachte ich, daS die PHP Script Engine immer wieder ins stocken kommt / hängen bleibt.
Was passiert ?
Ich sehe in der Visu keine Variablenupdates mehr und öffne die Win-Konsole. Dann gleich auf den Reiter >PHP Information<.
ALLE 25 slots sind leer. Sprich es werden keine Scripte ausgeführt.
Mittlerweile…
mach ich keinen symcon restart mehr, sondern lediglich ein F5 auf die Visu… damit scheint sich dann etwas ‚zu loesen‘… und die Script Execution engine zeigt ein wildes ROT auf allen 25 slots.
Danach normalisiert sich die Script Execution… aber immer noch mit einer heftigen Aufholjagd.
Beide Screenshots sind aus einem Screen Video von ca. 30MB… das kann ich dem symcon team zur Verfügung stellen.
Danach läuft es wieder rund… bis Symcon sich wieder verhakt… den Auslöser des Verhakens kann ich bisher nicht erkennen.
Abschliessend:
Die PHP Executer Auslastung ist bei meinem System typisch bei 30%. ich nutze 5 UDP Ports (Registervariablen) über die Payload von anderen Systemen an Symcon übergeben werden. Ansonsten eine Tonne von Scripts und In-Line PHP welche durch Variablenänderungen getriggered werden. Diese Mimik läuft seit Jahren sehr stabil.
Um jeden Tip dankbar - für Debug offen.
Gruss, homa
PS: sollte mein Beitrag nicht in diesen Thread reinpassen… bitte als neuen verschieben