Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[MartinP]

Ich nutze Radicale für unsere Familienkalender. Läuft in einem Docker Container wiederum in einem LXC-Container auf meinem Proxmox System.

Manchmal stützt Radicale ab, und man muss etwas nachhelfen, dass der Container wieder gestartet wird. Da bin ich noch bei der Ursachenforschung ...

In iobroker nutze ich den ical-Adapter, und der bietet über sein Logging einen Ansatzpunkt, den Docker-Container zu überwachen, und sich Mails bzgl des Zustandes schicken zu lassen ...
Um da nicht im Poll-Intervall des Kalenders gespammt zu werden, natürlich nur eine Mail beim Betreten des Fehlerzustandes und eine Mail beim Verlassen....

Trigger auf diese Log-Messages

Radicale läuft nicht:

ical.0
	2024-01-22 02:30:04.404	warn	Error reading from URL "http://192.168.2.146:5232/martin/e4c584bc-2ea6-bae6-1d4e-debe6a702f21/"

Radicale läuft wieder:

cal.0
	2024-01-22 02:30:06.373	info	processing URL: Martin_docker http://192.168.2.146:5232/martin/e4c584bc-2ea6-bae6-1d4e-debe6a702f21/

Und hier der Code, um diese beiden Messages auszufiltern:

var bWarnReceived = false;

onLog('info', data => {
    // console.log('Following warn message: ' + data.message + "from: " + data.from);
    if((bWarnReceived == true) && (data.from == 'ical.0') && (data.message.includes('processing'))) {
      // Auswertung von data.message
      bWarnReceived = false;
      sendTo("email", "send", {
         text: (['ical Adapter funktioniert wieder ', data.message].join('')),
         to: 'xxxxxxxx@xxxxxxxxx.de',
         subject: 'Ical OK'
      });
    }
    else if((bWarnReceived == false) && (data.from == 'ical.0') && (data.severity != 'info')) {
      // Auswertung von data.message
      bWarnReceived = true;
      sendTo("email", "send", {
         text: (['ical Adapter meldet probleme ', data.message].join('')),
         to: 'xxx@xxx.de',
         subject: 'Ical-Alarm!'
      });
   }
});

Ist es sinnvoll, diese längliche Version EINES on(...) Blocks zu verwenden, oder ist es egal, wie viele on(...) Registrierungen man macht, und ich könnte den Fehlerfall, und den ok-Fall in separate on(...) Blöcke bearbeien lassen?

[MartinP]

Nun funktioniert das doch nicht,

Leider habe ich nicht genau genug geschaut ... Im Fehlerfall sieht das Logging so aus:

ical.0
	2024-01-22 10:00:04.532	warn	Error reading from URL "http://192.168.2.146:5232/martin/e4c584bc-2ea6-bae6-1d4e-debe6a702f21/"
ical.0
	2024-01-22 10:00:04.537	info	Use cached File content for "http://192.168.2.146:5232/martin/e4c584bc-2ea6-bae6-1d4e-debe6a702f21/" from Mon Jan 22 2024 09:00:04 GMT+0100 (Central European Standard Time)
ical.0
	2024-01-22 10:00:06.281	info	processing URL: Martin_docker http://192.168.2.146:5232/martin/e4c584bc-2ea6-bae6-1d4e-debe6a702f21/

Also wird der Fehlerfall zwei Sekunden später wieder aufgehoben ... da muss ich ggfs. doch mit Timeouts o. Ä. arbeiten ...

[MartinP]

So, das ist nun meine Lösung...

var LastLogMessageReceived = (new Date().getTime());

onLog('warn', data => {
    // console.log('Following warn message: ' + data.message + "from: " + data.from);
    if((data.from == 'ical.0') && (data.severity == 'warn')) {
      let myActTime = new Date().getTime();
      // Auswertung von data.message
      if ((myActTime - LastLogMessageReceived)> 2700000) {  // 2 700 000 ms = 45 min (check ical settings for fitting timeout limit, 30 min ical interval -> 45 min timeout)
        sendTo("email", "send", {
          text: (['ical Adapter meldet Warnung ', data.message].join('')),
          to: 'xxxxxxxxxxxxxxxxx,
         subject: 'Ical-Alarm!'
        });
      }
      LastLogMessageReceived = myActTime;
      
   }
});

Schickt zwar keine OK-Mail, wenn wieder alles funktioniert, aber das ist erstmal nicht so wichtig denke ich ...