Sind die abstürze durch die streams eigentlich behoben?
Nutze diese zur Zeit nicht, hab aber in release notes dazu noch nichts gelesen?
Noch nicht zu 100%. Aber ohne dem ProxyWatch Spezialschalter sollten die eher selten auftreten.
paresy
War bei mir bisher nicht der Fall…
Dann warte ich lieber noch etwas.
Nabend,
bei mir steht unten in Videobild, „Per Relay verbunden“ Egal ob per App am Tablet oder per Webview übers Laptop.
Verbunden bin ich bei beiden direkt mit der IP von Symcon, nicht über den Connect Dienst.
Was heißt das genau?
mfg
Wo läuft denn dein Symcon Server? Evtl. im Docker?
paresy
Nein, läuft auf einem kleinen Industrie PC auf dem Ubuntu 22.04 LTS läuft.
Dieser hat 4 Ethernet Ports, davon sind nur zwei in Betrieb, einer fürs Hausnetz und einer für die Verbindung zum physikalisch komplett getrennten Netzt für die Siemens SPSen.
Magst du mal in den Spezialschaltern das ProxyInterface setzen auf die IP-Adresse von deinem Hausnetz? Also von dem du auch auf die Visu zugreifst?
paresy
Habe ich gemacht, es steht leider immer noch, per Relay verbunden da.
Was heißt das denn genau? Warum macht er das ?
mfg
Warum auch immer kann er keine Direktverbindung herstellen. D.h. er ist der Meinung, dass zwischen dem Browser und IP-Symcon keine direkte Verbindung (per UDP) hergestellt werden kann. Grund kann sein ein NAT, welches dazwischen ist oder ein anderes VLAN oder eine Firewall die sehr restriktiv alles dicht hält. (Oder irgendein Fehler 
)
paresy
Komisch das ganze.
Es passiert ja auch nicht immer aber schon sehr oft.
Habe ein komplettes Unifi Netz mit Security Gateway Pro 4 und ein paar Unifi Switche und AP.
Ein NAT sollte da keine Probleme machen und die Firewall filtert intern nichts.
Auch auf dem Ubunut habe ich keine Firewall zusätzlich konfiguriert.
Welche Ports per UDP sollten denn offen sein? Vielleicht kann ich da nochmal genauer gucken.
An und für sich ist es ja auch kein Problem., es funktioniert ja alles. Aber komisch ist es schon
Sollten damit nun die Abstürze behoben sein? Oder muss ich da weiter aufpassen?
Zumindest die beim Beenden. Kannst du welche zur Laufzeit nachstellen/provozieren?
paresy
Hi,
Also bei mir stürzt symcon immer noch beim beenden ab sobald ich einmal einen stream aufgerufen habe.
Viele grüsse
Vor dem Update heute hatte ich zumindest noch eins…
Bin da etwas vorsichtig geworden da symcon bei mir alles steuert, Licht, Heizung usw…
Kann aber noch Mal etwas testen.
Moin, hab gestern Abend nun mal wieder ein Absturz gehabt.
Habe kurz am Handy Licht eingeschaltet, in der Kategorie ist unten auch eine Kachel mit Stream eingebaut, dann direkt Handy gesperrt und weg gelegt.
5Min Später wollte ich Licht wieder ausschalten und App fragte nach „Neu Verbinden“. Da war der Dienst dann abgestürzt.
Im Normalen Logfile stehen nur ein Haufen Änderungen von Variablen/Skripten aber nichts was auf einen Fehler hinweist.
11.10.2023 19:45:39 | 19348 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:39 | 41811 | DEBUG | ScriptEngine | Skript ausgeführt - Ereignis: 41811 ~ Absender: Variable ~ Dauer: 1 ms
11.10.2023 19:45:39 | 53635 | DEBUG | VariableManager | [System\Strom\Trockner\Energie] = 120.7826000000
11.10.2023 19:45:39 | 19348 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
11.10.2023 19:45:39 | 19348 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:39 | 44393 | DEBUG | VariableManager | [System\Strom\Trockner\Status] = true
11.10.2023 19:45:39 | 19348 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
11.10.2023 19:45:39 | 19348 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:39 | 55099 | MESSAGE | VariableManager | [System\Strom\Trockner\Temperatur] = 32.1500000000
11.10.2023 19:45:39 | 19348 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
11.10.2023 19:45:39 | 19348 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:39 | 19348 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
11.10.2023 19:45:39 | 19348 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:39 | 36937 | DEBUG | VariableManager | [System\Strom\Trockner\Übertemperatur] = false
11.10.2023 19:45:39 | 19348 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
11.10.2023 19:45:40 | 57131 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: Timer: GetSystemStatus
11.10.2023 19:45:40 | 52493 | DEBUG | ScriptEngine | Skriptausführung - Ereignis: 31035 ~ Absender: TimerEvent
11.10.2023 19:45:40 | 55852 | DEBUG | VariableManager | [System\Unifi\Access\MotionID] = 6525072a00658503e400723b
11.10.2023 19:45:40 | 28618 | DEBUG | VariableManager | [System\Unifi\Access\LastMotionStart] = 10.10.2023 10:11:22
11.10.2023 19:45:40 | 26847 | DEBUG | VariableManager | [System\Unifi\Access\LoginAktiv] = true
11.10.2023 19:45:40 | 40690 | DEBUG | VariableManager | [System\Unifi\Access\LastMotionEnd] =
11.10.2023 19:45:40 | 23880 | DEBUG | VariableManager | [System\Unifi\Access\MotionType] = access
11.10.2023 19:45:40 | 41284 | DEBUG | VariableManager | [System\Unifi\Access\UserID] = xxxxxxxxxxxxxxxxxxxxxx
11.10.2023 19:45:40 | 52493 | DEBUG | ScriptEngine | Skript ausgeführt - Ereignis: 31035 ~ Absender: TimerEvent ~ Dauer: 80 ms
11.10.2023 19:45:40 | 24966 | DEBUG | VariableManager | [GeCoS_IO Haus\Server Status] = true
11.10.2023 19:45:40 | 57131 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: Timer: GetSystemStatus ~ Dauer: 317 ms
11.10.2023 19:45:40 | 57131 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: Timer: RTC_Data
11.10.2023 19:45:40 | 57131 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: Timer: RTC_Data ~ Dauer: 2 ms
11.10.2023 19:45:40 | 57131 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:40 | 51240 | MESSAGE | VariableManager | [GeCoS_IO Haus\RTC Zeitstempel] = 1697046346
11.10.2023 19:45:40 | 19595 | DEBUG | VariableManager | [GeCoS_IO Haus\RTC Temperatur] = 30.7500000000
11.10.2023 19:45:40 | 55293 | MESSAGE | VariableManager | [GeCoS_IO Haus\Letztes Keep Alive] = 1697046340
11.10.2023 19:45:40 | 57131 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 2 ms
11.10.2023 19:45:41 | 48133 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:41 | 57673 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: Timer: GetSystemStatus
11.10.2023 19:45:41 | 48133 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 2 ms
11.10.2023 19:45:42 | 48133 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:42 | 48133 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
11.10.2023 19:45:42 | 48133 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:42 | 48133 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
11.10.2023 19:45:42 | 48133 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:42 | 48133 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 4 ms
11.10.2023 19:45:42 | 48133 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:42 | 48133 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
11.10.2023 19:45:42 | 48133 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:42 | 48133 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 3 ms
11.10.2023 19:45:42 | 48133 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:42 | 48133 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 2 ms
11.10.2023 19:45:42 | 27050 | DEBUG | VariableManager | [GeCoS_IO Garage\Server Status] = true
11.10.2023 19:45:42 | 57673 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: Timer: GetSystemStatus ~ Dauer: 1080 ms
11.10.2023 19:45:42 | 57673 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: Timer: RTC_Data
11.10.2023 19:45:42 | 57673 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: Timer: RTC_Data ~ Dauer: 1 ms
11.10.2023 19:45:42 | 57673 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
11.10.2023 19:45:42 | 37386 | MESSAGE | VariableManager | [GeCoS_IO Garage\RTC Zeitstempel] = 949387147
Version:
IP-Symcon 7.0, Raspberry Pi (arm64), 09.10.2023, d7b3cd53dd6d
Das kann ich bestätigen. Beim Neuverbinden stürzt der Dienst auch bei mir ab.
Dazu an euch die frage, könnt ihr den symcon dienst neustarten? Ich habe das problem das ich den dienst unter linux killen muss. Ein neustart funktioniert nicht.
bei mir reicht ein „sudo /etc/init.d/symcon start“…
Ich dachte bisher, das neu verbinden erscheint durch den Absturz, nicht das dadurch der Absturz ausgelöst wird, beobachte ich mal…
Edit: also nur warten bis die App ein „Neu Verbinden“ anfragt, führt bei mir nicht direkt zum Absturz.
Mir geht es eher darum, das wenn sich der streamingserver bei mir erst mal verabschiedet hat, ich den symcon dienst nicht klassisch neustarten kann.
Ich habe dazu im beta bereich ein debug erstellt, der aber scheinbar nicht beachtet wurde. Ich vermute das es damit zusammenhängen könnte
Wie meinst du kannst den nicht beenden? Normalerweise sollte der beim Beenden eher Abstürzen, wenn es Probleme mit den Streams gab (so meine Erfahrung) - aber was bedeutet es für dich, dass der StreamingServer sich abschiedet? Wie kann ich das nachstellen?
paresy