Magst du mal in der Connect Instanz einfach die Verbindung deaktivieren, übernehmen und dann wieder aktivieren?
paresy
Super. Du hast mir den Tag gerettet. Genau das war es.
Wäre schön, wenn dies in der Dokumentation auch mit aufgenommen werden könnte.
Aktuell steht da zwar „Der Dienst muss neugestartet werden.“, aber ich hatte das auf den kompletten IP-Symcon Prozess und nicht nur den Connect-Dienst bezogen.
Moin Moin,
ich brauche eure Hilfe. 5.0 läuft nun von Anfang an erfolgreich im Docker auf meiner Synology DS916+.
Ich habe nun schon einige Versionen abgewartet um vielleicht Fehler in einzelnen Versionen auszuschließen, aber symcon frisst von Tag zu Tag CPU Ressourcen und gibt sie nicht mehr frei. Alle paar Tage müsste ich symcon neustarten damit meine DS auch mal wieder etwas Ressourcen für anderes frei hat.
Hier nach 10 Tage Laufzeit (müsste mal beobachten wie schnell das geht… gucke ja nicht jeden Tag in meine DS)
Wenn ich symcon beende ist alles wieder ruhig…
Symcon sieht nach 13 min noch gut aus
Haben andere hier das gleiche Phänomen ? Oder gibts hier ne Idee wo ich ansetzen könnte ?
Das sieht ja so aus, als wenn symcon einhundert mal gestartet ist. Gibt es irgendwelche Fehlermeldungen bei dir? Oder merkst du Abstürze?
paresy
Nein, keinerlei Abstürze… Symcon läuft 1a bis auf dieses Problem 
Die Anzahl an Prozessen scheint bei der Synology wohl Normalzustand zu sein, da alle anderen Prozesse auch so oft vorhanden sind. Die meisten schlafen nur.
In symcon habe ich keine besonderen Fehlermeldungen… (die roten sind bekannt aber nicht Ursache des Fehlers… hatte die Fehler schon mal testweise beseitigt)
Deshalb stehe ich ja auf dem Schlauch und hab mich an euch / Dich Paresy gewand. Habs lange beobachtet aber keine Fehlerquelle finden können.
Nach 2 Tagen sieht es schon wieder schlimmer aus… symcon frisst schon wieder fleissig CPU Transistoren ^^
Nach 3 Tagen… 
Nach 4 Tagen…
Kann das hier kein Docker User bestätigen ?
@paresy: Wenn das an irgendwelchen scrypten oder was auch immer in meinem symcon liegt, wie könnte ich dem auf die Spur kommen ? Hast du keine Idee ? Ich muss alle 1-2 Tage symcon neustarten…
Habe auch eine DS916+ und auch IPS5 @ Docker. Kann ich nicht bestätigen. Bei mir dümpelt IPS bei 3% rum. Gestern ist einmal IPS beim Aktualisieren der Module abgeschmiert. Und momentan kann ich die Module nicht aktualisieren, ansonsten läuft alles Stabil.
Beim Aufruf der Webconsole auf einem Mac über den Chrome Browser kommt es sporadisch zum Absturz des Containers.
Wie kann ich analysieren, weshalb das passiert. Ich kann es leider nicht nachstellen. Es passiert sporadisch.
Ich habe die aktuelle Stable Version: IP-Symcon 5.0, Alpine, 30.10.2018, abf566bf67c
Es läuft auf Docker einer Synology 218+.
Es ist gerade schon wieder passiert.
Was kann ich tun, damit der Fehler nicht so oft passiert?
Wie kann ich bei der Fehleranalyse tätig werden?
Ich bin an dem Problem noch dran - ich konnte das auch schon beobachten. Es liegt höchstwahrscheinlich am „Aktualisierungs“ Widget, welches die PHP-Module prüft und dabei scheint es abzustürzen.
paresy
Ich habe das selbe Problem allerdings mit Chrome Browser Version 70.0.3538.110 (Offizieller Build) (64-Bit) unter Windows.
Ich bin auf der aktuellen Docker Beta IP-Symcon 5.0, Alpine, 22.11.2018, 9c414bf914c
Gefühlt tritt der Fehler meist erst nach ein paar Tagen auf, also wenn IPS schon ein paar Tage läuft.
Der Container wird dann automatisch wieder gestartet, dies dauert sehr lange, weil er dann zuerst mal alle Variablen reaggregiert.
In der Zeit ist bei mir das Webfront und die Web Console nicht erreichbar.
Gibt es eine Möglichkeit der Sache auf den Grund zu kommen?
Ich wollte hier nur mal meine Erkenntnis mit der hohen CPU Last da lassen. Fehler konnte ich wohl beseitigen.
Mein Duty Cycle war viel zu hoch. Es hat eigentlich immer alles funktioniert, aber angehen wollte ich das Thema schon immer mal. Er hat täglich sogar die 100% erreicht. Und fiel nie unter 20%. Die ganzen Bewegungsmelder in jedem Raum sind schuld ^^
Also änderte ich bei allen Aktoren und Sensoren den Übertragungsmodus von „gesichert“ auf „Standard“ um die Pakete zu reduzieren. Tadaaaaa. Mein symcon läuft nun schon seit 3 Tagen bei 3% statt 45% CPU Last.
@paresy kannst du mir erklären warum ein zu hoher Duty Cycle symcon so sehr beeinflusst, dass die CPU Last so enorm in die Höhe schnellt ?
Am 02.Dezember hab ich die Anpassungen vorgenommen um den DC zu senken.
DutyCycle
Morgen,
einige meiner Instanzen die z.B. ein UDP Host sind, benötigen die Empfängerhost-IP Adresse.
Ich habe die Installation über Docker wie in der Dokumentation, bei Systemneustarts kann es aber vorkommen, dass die Docker Instanz eine andere IP Adresse bekommt.
Sämtliche dieser Instanzen einschließlich der HomeMatic CCU2 sind dann nicht mehr erreichbar und müssen erst mit der neuen HostIP-Adresse aktualisiert werden. Eigentlich kein Thema, aber bei vielen Instanzen nervig und wenn ich beim Reset mal nicht anwesend bin geht die Hälfte nicht mehr.
Wie in der Dokumentation habe ich auch Portainer am Laufen, die beiden wechseln sich wohl beim Hochfahren ständig mit den IP-Adressen durch…
Gibt es dazu bereits eine Lösung, wenn nein setz ich mich demnächst mal selbst ran?
Hallo, drdigital und ich haben uns da viele Gedanken gemacht und viele Tests angetan, weil uns das auch sehr gestört hat.
Sobald ein DSM Update oder ein Neustart der Synology gemacht wurde, konnte es sein, dass die Docker Container (symcon und portainer) unterschiedliche interne IP Adressen bekamen, als vorher. Und dann musste man eben die einzelnen Sachen in Symcon wieder anpassen, so wie Du auch schon erlebt hast.
Insofern, haben wir jetzt eine Lösung bzw. einen Workaround gefunden, welcher dieses Problem beseitigt.
Wir haben die beiden Docker Container in unterschiedliche Subnetze verteilt. So bekommt der Container für Symcon immer die erste freie Adresse des einen Subnetzes und der Container für Portainer immer die erste freie Adresse des anderen Subnetzes.
In meinem Fall ist das 172.17.0.2 für Portainer und 172.18.0.2 für Symcon.
Dazu legt man sich unter Docker/Netzwerk ein neues Subnetz durch das Klicken auf „Hinzufügen“ an.
Danach stoppt man den Symcon Containter und vergibt das neu angelegte Subnetz dem gestoppten Container und speichert. Es bietet sich an, einen Neustart von Docker zu machen, damit das neue Konstrukt greift.
Und danach Docker wieder entsprechend Starten.
Nun sollten Portainer und Docker unterschiedliche Subnetze haben.
Das geht natürlich auch bei mehreren Containern.
So sieht es in Portainer aus, wenn man fertig ist:
Die neue IP-Adresse muss man natürlich einmalig überall in Symcon einstellen, wo diese benötigt wird.
Das sollte dann aber auch das letzte Mal gewesen sein, wenn man den Symcon Container alleine im erstellten Subnetz belässt.
Seither sind DSM Updates und Neustarts bei mir kein Problem mehr.
Ich hoffe, das hilft hier im Forum all jenen, die das gleiche Thema bzw. Problem haben.
Cheers, Nico.
Guten Morgen,
vielen Dank für den Tip, ich habe es etwas einfacher gelöst.
Ich habe lediglich ein neues Netzwerk erstellt und dem Run Befehl dann neben diesem Netzwerk (in meinem Fall alice) auch eine fixe IP-Adresse mitgegeben:
docker network create --subnet=XXX.XXX.0.0/16 alice
docker run --name symcon \
--hostname symcon \
--net alice \
--ip XXX.XXX.0.5 \
-d \
-p 3777:3777 \
-p 5544:5544 \
-v /var/lib/symcon:/var/lib/symcon \
-v /var/log/symcon:/var/log/symcon \
-v /root:/root \
--restart always \
symcon/symcon:stable
Meinen ursprünglichen Blogbeitrag habe ich dahingehend aktualisiert:
https://mytec-home.de/smart-home/ip-symcon-update-5-0-auf-dem-openmediavault-debian-nas
LG & schöne Weihnachten
Hallo Paresy, frohes neues Jahr.
Wird an diesem Thema gearbeitet? Symcon stürzt mehrmals am Tag sporadisch ab, wenn ich die Webkonsole aufrufe.
Vielen Dank vorab für eine kurze Info.
Ja, wir haben den Fehler auf dem Schirm. Ich vermute, dass wir hier ein Problem/Inkompatibilität mit der Alpine Distribution (genau genommen musl) haben, welche wir im Hintergrund verwenden. Ich möchte zur 5.1 auf Ubuntu ändern, welches viel besser getestet ist und wir auch „normal“ ohne Docker anbieten und verwenden. Das sollte diese unerklärlichen Randprobleme lösen. Hab’ somit bitte noch etwas Geduld - Sobald wir die ersten Public Betas davon anbieten, werden wir auch das Docker Image wieder anbieten.
paresy
Hallo,
ich habe ein „Zeit“ Problem in symcon… aber irgendwie total strange.
Wenn ich das Terminal vom Container öffne, stimmt die Uhrzeit, aber in Symcon selbst läuft die Zeit auseinander, da in Symcon 1 Sekunde ca. 20-30 Sec. in Echtzeit bedeutet. Symcon lebt damit in der Vergangenheit. Die Meldungen laufen auch etwas langsamer ^^ Ich glaub ich hab das, seit dem ich Nall-chan/IPSMySQLArchiv installiert habe und dort ein paar mehr Variablen in die mysql Datenbank schreibe. Ist das so aufwändig ? Hab da auch Stromzähler, die sekündlich Werte erzeugen.
Der Container selbst langweilt sich aber…
PHP Informationen…hier rattert es normalerweise nur so durch. Still ruht der See… ab und an kommt hier mal wieder was rein… Was bedeuten hier eigentlich rote Zeilen ?
Krasses Phänomen…
Nach einem Neustart stimmt kurz die Urzeit und füngt dann sofort wieder auseinander zu laufen… 30 sec in Echtzeit entspricht 1 sec in Symcon.
[b]EDIT:
Es liegt am Modul „Nall-chan/IPSMySQLArchiv“ <— deaktiviert und alles rennt wieder. Schade…[/b]
Hallo zusammen,
ich hoffe mir kann einer von euch helfen. Ich habe heute IP Symcon auf die neuste Version geupdatet. Dabei bin ich genau nach der Anleitung von der Homepage vorgegangen mit Docker und Portainer. Theoretisch hat das auch alles gut funktioniert, wenn ich jetzt aber die IP Symcon Console starte ist das ganze wie eine Neuinstallation. Alle Geräte und Einstellungen sind weg. Im Ordner sind aber noch alle Dateien der vorherigen Version vorhanden. Die Pfadangaben im Container stimmen ebenfalls. Weiß jemand, wie das funktioniert, oder muss ich ein Backup zurückspielen?
Das klingt aber sehr danach, dass doch etwas bei den Pfaden nicht ganz stimmt. Magst du mal ein Bild machen?
paresy