Ankündigung

Einklappen
Keine Ankündigung bisher.

DateTime in einer Rule verursacht einen Fehler

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    DateTime in einer Rule verursacht einen Fehler

    Hallo,
    in einer Rule meines Müllkalenders laufe ich in einen Fehler
    Code:
    rule "Müllkalender"
    when
    Time cron "0 * * ? * *" //every 1 Minute
    // Time cron "0 15 17 * * ?" //once per Day 17:15
    //Item date_today changed
    then
    var String muelltonne_1
    muelltonne_1 = CalDAV_Muell_1.state.toString
    
    var String muelltonne_2
    muelltonne_2 = CalDAV_Muell_2.state.toString
    
    // Prüfung ob der Wert gefüllt ist (damit beim cast auf DateTimeType keine Fehlermeldung erscheint)
    if (muelltonne_1 != "UNDEF") {
    // Datum der Abholung wird mit dem aktuellen Datum verglichen
    // die erste Bedingung prüft, ob das aktuelle Datum vor dem Ablaufdatum + 24 Std. liegt
    // die zweite Bedingung prüft, ob das aktuelle Datum nach dem Datum der Abholung liegt
    if (now.isBefore(new DateTime((CalDAV_Muell_1_Date.state as DateTimeType).getCalendar().getTime()).plusHours(2 4)) &&
    now.isAfter(new DateTime((CalDAV_Muell_1_Date.state as DateTimeType).getCalendar().getTime()))) {
    
    // Benachrichtigung per Telegram an Bot senden
    if(muelltonne_2 == "UNDEF") {
    sendTelegram("xxx_bot", "Müllkalender: %s", muelltonne_1)
    logInfo("INFO","CalDAV.rules - Müllkalender: %s", muelltonne_1)
    } else {
    sendTelegram("xxx_bot", "Müllkalender: %s & %s", muelltonne_1, muelltonne_2)
    logInfo("INFO","CalDAV.rules - Müllkalender: %s & %s", muelltonne_1, muelltonne_2)
    }
    }
    }
    end
    Code:
    2020-04-12 19:35:24.258 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'muell.rules', using it anyway:
    The method getCalendar() from the type DateTimeType is deprecated
    The method getCalendar() from the type DateTimeType is deprecated
    2020-04-12 19:35:24.338 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'muell.rules'
    2020-04-12 19:35:39.476 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'miele.rules', using it anyway:
    The operator '!=' should be replaced by '!==' when null is one of the arguments.
    2020-04-12 19:37:12.153 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'Müllkalender': Could not cast NULL to org.eclipse.smarthome.core.library.types.DateTimeT ype; line 19, column 40, length 41
    Hätte jemand eine Idee was hier falsch läuft ?


    Gruß

    Frank

    #2
    Die ersten Meldungen haben ja nur informativen Charakter. getCalendar() ist veraltet und wird in zukünftigen OH-Versionen nicht mehr unterstützt. An dieser Stelle muss man aber auch ganz klar sagen, dass zukünftige Versionen von openHAB (OH3) die Rules DSL vermutlich gar nicht mehr unterstützen werden, da würde ich jetzt also keine Energie investieren.

    Der zweite Punkt ist ein syntaktischer in einer anderen Rule, != ist als Vergleich für null zwar zulässig, besser ist aber !==.

    Der Unterschied zwischen den beiden Vergleichen:
    != : Ist nicht gleich, Gegenteil von ==. a=5, b=5 -> a == b
    !== : Ist nicht identisch, Gegenteil von ===. a=5, b=5 -> a !== b, weil a auf eine andere Speicherzelle im RAM verweist als b. Im Unterschied dazu verweist jede auf null gesetzte Variable immer auf die selbe Speicherzelle, welche die Bedeutung null hat (es ist dabei unerheblich, welcher Wert nun konkret in dieser Speicherzelle steht)

    === vergleicht also die Zeiger, während == die Werte vergleicht.

    Der eigentliche Fehler (letzte Zeile im log) dürfte der Tatsache geschuldet sein, dass die Prüfung auf ungültige Werte nicht vollständig ist. Ein DateTime Item kann nicht nur ein gültiges Datum oder UNDEF enthalten, der Status kann auch NULL sein (wobei gilt: NULL != null), die Prüfung auf UNDEF ist also zwar notwendig aber nicht hinreichend.

    Noch kurz zu Deiner Verwendung von logInfo(): Der Befehl benötigt zwei Strings als Argumente. Dabei ist der erste String das Ende des Loggernamens, der zweite String ist die eigentliche Meldung. Der Befehl logInfo() erzeugt aber immer eine Zeile im Log, die den Teilstring [INFO ] enthält. Alle log-Befehle (logDebug(), logInfo(), logWarn() und logError()) nutzen als Logger-Pfad org.openhab.model.script. und hängen dann den ersten String an. Besser wäre also so eine Meldung:
    Code:
    logInfo("caldav","Müllkalender: {}", muelltonne_1)
    welche dann eine Logzeile der Form
    Code:
    2020-04-12 19:35:24.338 [INFO ] [     org.openhab.model.script.caldav] Müllkalender: Inhalt von muelltonne_1
    erzeugt. Ob die Leerzeichen vorne oder hinten aufgefüllt werden, hab ich jetzt grade nicht im Kopf
    Über die Karaf Konsole kannst Du anschließend exakt alle Meldungen des Loggers org.openhab.model.script.caldav auf bestimmte Level begrenzen, also z.B. alle logInfo() Meldungen unterdrücken, logWarn() würde aber weiter ausgegeben, ebenso die logInfo() Meldungen mit anderem Loggernamen.
    Zuletzt geändert von udo1toni; 13.04.2020, 05:17.

    Kommentar


      #3
      Vielen Dank für deine Hilfe, ich habe inzwischen geschafft meine Kalender abzufragen, jedoch läuft es nicht sehr zuverlässig. Ich bekomme manchmal einen Fehler:

      Code:
      2020-04-16 12:09:36.121 [WARN ] [caldav.internal.job.EventReloaderJob] - Sardine error while loading calendar entries: Unexpected response (401 - Unauthorized)
      com.github.sardine.impl.SardineException: Unexpected response
      at com.github.sardine.impl.handler.ValidatingResponse Handler.validateResponse(ValidatingResponseHandler .java:48) ~[221:org.openhab.io.caldav:1.13.0]
      at com.github.sardine.impl.handler.MultiStatusRespons eHandler.handleResponse(MultiStatusResponseHandler .java:40) ~[221:org.openhab.io.caldav:1.13.0]
      at com.github.sardine.impl.handler.MultiStatusRespons eHandler.handleResponse(MultiStatusResponseHandler .java:35) ~[221:org.openhab.io.caldav:1.13.0]
      at org.apache.http.impl.client.CloseableHttpClient.ex ecute(CloseableHttpClient.java:218) ~[221:org.openhab.io.caldav:1.13.0]
      at org.apache.http.impl.client.CloseableHttpClient.ex ecute(CloseableHttpClient.java:160) ~[221:org.openhab.io.caldav:1.13.0]
      at com.github.sardine.impl.SardineImpl.execute(Sardin eImpl.java:962) ~[221:org.openhab.io.caldav:1.13.0]
      at com.github.sardine.impl.SardineImpl.list(SardineIm pl.java:417) ~[221:org.openhab.io.caldav:1.13.0]
      at com.github.sardine.impl.SardineImpl.list(SardineIm pl.java:409) ~[221:org.openhab.io.caldav:1.13.0]
      at com.github.sardine.impl.SardineImpl.list(SardineIm pl.java:386) ~[221:org.openhab.io.caldav:1.13.0]
      at org.openhab.io.caldav.internal.job.EventReloaderJo b.loadEvents(EventReloaderJob.java:246) ~[221:org.openhab.io.caldav:1.13.0]
      at org.openhab.io.caldav.internal.job.EventReloaderJo b.execute(EventReloaderJob.java:137) [221:org.openhab.io.caldav:1.13.0]
      at org.quartz.core.JobRunShell.run(JobRunShell.java:2 02) [109:org.eclipse.smarthome.core.scheduler:0.10.0.oh240]
      at org.quartz.simpl.SimpleThreadPool$WorkerThread.run (SimpleThreadPool.java:573) [109:org.eclipse.smarthome.core.scheduler:0.10.0.oh240]
      Wenn ich hier im Forum nachlese scheint es aber an der Kombination caldav und google liegen. Giebt es jemanden bei dem es zuverlässig läuft ?

      Gruß

      Frank

      Kommentar

      Lädt...
      X