Symcon Connect Neustart via Skript

IP-Symcon
1

Hallo,

innerhalb von 2 Tagen das 2. Mal „Heim nicht erreichbar“. D.h. der Symcon Connect Dienst läuft nicht mehr. Gestern hat stoppen / starten geholfen. Bin gerade unterwegs, kann es also nicht wieder aktivieren.

Änderung am System hat in den letzten zwei Tagen nicht stattgefunden, welche dies erklären würde.

Daher würde ich gern eine Art „Watchdog“ für den Dienst einrichten. Wie lauten die Befehle für das prüfen, stoppen und starten des Dienstes?

Danke
Eric

PS: Oder liegt es am Erreichen des Datenlimits beim Connect Dienst? Habe seit 5 Tagen eine Abfrage meines Husqvarna Mähroboters via Modul im Shop (allerdings laufe ich noch auf Symcon 6.1), also eine ältere Version.

2

Hi,
gestern schwächelte Connect ein wenig. Normal verbindet er sich automatisch wieder. Ich überwache Connect mit einem Event. Hier könnte man z.B. einen Timer einbauen der Connect so lange deaktiviert und reaktiviert bis der Status wieder 102 ist.

Ich habe als fallback eine DDNS-Adresse mit der ich auf die Console komme.

Edit: Im Logfile kannst Du sehen warum es nicht mehr geht. Bei Überschreitung des Limits steht es eindeutig im Log und es kommt auch der Hinweis das man es durch Neustart von IPS beheben muss.

Ralf

3

Oh, das ging ja schnell. Vielen Dank für die Antwort.

Kannst Du Deine Überwachung etwas genauer beschreiben?

Welchen Trigger nutzt Du?
Welche php-Befehle zum Stoppen und Neustarten?

Danke

Eric

4

Hi,
in etwa so in Event Control bei Änderung von Connect dieses Script ausführen:

<?php
$instance = IPS_GetInstance(20756);
$status = $instance['InstanceStatus'];
if ($status >= 200){
    $mailInhalt = "Connect Dienst nicht verfügbar";
    IPS_SetProperty(ConnectID, "Active", false);
    IPS_ApplyChanges(ConnectID
   IPS_Sleep(1000);
    IPS_SetProperty(ConnectID, "Active", true);
    IPS_ApplyChanges(ConnectID);
}
if ($status == 102){
    $mailInhalt = "Connect Dienst wieder verfügbar";
}
?>

Deaktivieren/Reaktivieren müsste in eine Schleife. Wie gesagt es geht automatisch und in einem anderen Thread wurde erklärt warum es gestern hakte.

Ralf

5

Finger weg davon, weil dann erreichst du sehr wahrscheinlich das Reconnect Limit und dann geht gar nix mehr für 24 Stunden.
Zumindest wenn du es automatisch ausführen lässt.
Michael

6

Hallo Michael,

ich verstehe Deine Bedenken.

Am Ende würde mich die Ursache interessieren.

Die Dauer-Lösung liegt sicher nicht im Watchdog-Reconnect. Das ist eher ein Back-Up, damit das System von sich aus die Verbindung herstellen kann. Ohne bin ich ja komplett ausgesperrt. Und was nützen mir am Ende 24 „unbenutzte“ Reconnects am Abend, wenn ich dafür tagsüber, wo ich die Verbindung benötige, nicht darauf zugreifen kann aus der Ferne? Bin nun mal nur 3 Stunden „wach“ daheim und 14Stunden außer haus „wach“.

Mfg

Eric

7

Vielen Dank, das verstehe ich und damit kann ich was anfangen. Die max. 25 Reconnects kann durch den Code ja mittels entsprechender Erweiterung des selbigen abfangen.

8

Ich kann das verstehen, lieber 15x reconnect als keine Verbindung. Wenn symcon das Problem intern gelöst hat wird die Funktion hinfällig. Aber wann das kommt weis man ja nicht.

Wenn du ne Funktion gebaut hast hätte ich auch Interesse dran, komme aus Zeitmangel nicht dazu bin in Urlaub.

9

Hallo nochmal,

habe eben das Logfile durchsucht.

Die meiste Zeit hat das System im Minutentakt folgende Eintragung hinterlassen:
Wiederverbinden [Connect] übersprungen. Nächster Versuch: xxxxxxx (Uhrzeit + 1 Minute).

Wieso überspringt das System das Wiederverbinden?

Ab und zu sah es etwas hoffnungsvoller aus:

Feld10 Feld1 Feld2 Feld3 Feld4 Feld5 Feld6 Feld7 Feld8
Wiederverbinden [Connect] übersprungen. Nächster Versuch: 11.09.2023 07:55:29 11.09.2023 07:54:29 48233 DEBUG
Einstellungen gespeichert 11.09.2023 07:55:29 48233 MESSAGE
Verbinde… 11.09.2023 07:55:30 48233 MESSAGE
Initialisiert 11.09.2023 07:55:30 48233 MESSAGE
Wiederverbinden [Connect] fehlgeschlagen = Verbinden fehlgeschlagen 11.09.2023 07:55:30 48233 ERROR

Und nach vielen Stunden dann von selbst:

Feld10 Feld1 Feld2 Feld3 Feld4 Feld5 Feld6 Feld7 Feld8
Einstellungen gespeichert 11.09.2023 16:27:31 48233 MESSAGE
Verbinde… 11.09.2023 16:27:31 48233 MESSAGE
Initialisiert 11.09.2023 16:27:31 48233 MESSAGE
Verbunden 11.09.2023 16:27:32 48233 MESSAGE
Fingerabdruck überprüft 11.09.2023 16:27:32 48233 MESSAGE
Authentifizierung war erfolgreich 11.09.2023 16:27:33 48233 MESSAGE
Verbindung hergestellt 11.09.2023 16:27:33 48233 NOTIFY
Wiederverbinden [Connect] erfolgreich 11.09.2023 16:27:33 48233 MESSAGE

Komisch…

10

Das ist der Abstand hier:

Da steht auch das hier wohl noch Veränderungen kommen.

So ein automatisches Wiederverbinden Script gab es schon in den Anfangszeiten des Connect Dienst. Damit würde dann der Dienst zugespammt.
Daraufhin ist dann das 24 Reconnect Limit gekommen.
Darum auch meine Aussage; macht das nicht selber.
Wartet da auf eine Lösung von Symcon.
Michael

11

Da das Problem echt doof ist, wird es spätestens noch zur 7.0 eine Lösung gehen. Wir sind da dran.

paresy

1 „Gefällt mir“
12

Hallo Jungs,

vielen Dank für Eure Bemühungen. Ich muss mich erstmal zu einem Update auf 6.2/6.3/6.4 durchringen… Dazu muss der Raspi auf Bullseye. Nach meinem neulichen Fehlschlag habe ich dazu gerade keine Lust…

Was der Grund für den Fehler war, weiß ich nun auch.

Mein Spam-Skript kann ich also im Keller lassen?

Gruß
Eric

13

Ja.
Denke es lohnt sich auch auf 7.0 zu gehen, auch wenn das mit Raspi vlt. nicht so einfach ist.
Da ich für so „Faxen“ leider keine Zeit hab, bin ich ein Fan der Symbox. Auch weil ich auf Linux echt kein Held bin und bei einem Kunden nicht mit einem Raspi basteln mag.
Für einen selbst natürlich eine coole Sache.
Cheers Seppm

14

Wenn nur Symcon drauf ist… Backup machen, aktuelles raspberry pi os installieren, Symcon installieren und Backup einspielen…

Am einfachsten mit einer neuen SD Karte, wenn was falsch läuft kannst einfach die alte wieder rein stecken…

1 „Gefällt mir“
15

Die Vorgehensweise ist mir bewußt, wäre ja nicht das erste mal.

Hatte vor Kurzem mal 4 Tage Terror, als ich auf Bullseye wollte. Habe eine SSD und aus einem mir nicht bekannten Grund war die Bootpartition nur 47MB groß (das meiste im Normalbetrieb in Nutzung). Natürlich waren die reichlich vorhandenen Backups der zweiten Partition alle auf diesen „Umstand“ ausgerichtet. Beim Update rächte sich die „Kleine“ (ist das das Gegenteil von Größe?) der Boot mit einem Abbruch des Updates wegen Speichermangel und das System hat danach auch nicht mehr gebootet. Dummerweise habe ich vom Bootsektor nie ein Backup gemacht. Dann kamen 4 Tage „Lernphase“ und dank Kumpel war es am 4 Tag dann wieder (fast) so wie zuvor. Jetzt genieße ich erstmal die Ruhe…