Ankündigung

Einklappen
Keine Ankündigung bisher.

- √ - Fehler bei Verwendung von sh.env.core.start() bei Neustart

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

    - √ - Fehler bei Verwendung von sh.env.core.start() bei Neustart

    Hallo zusammen,

    zur Vermeidung von Fehlmeldungen meiner Emaillogiken direkt nach dem Neustart des smarthome.py services hatte ich vor eine Art Karenzzeit nach dem Servicestart einzubauen unter Verwendung von sh.env.core.start().

    Hintergrund: Die Logiken werden beim Servicestart ja einmalig getriggert und so wurden kiloweise Mails generiert wenn das überwachte Item bspw. schon wahr war.

    Zum Abfangen wollte ich folgenden Code verwenden, welcher auch zur normalen Laufzeit einwandfrei funktioniert:
    Code:
    ....
    DelayAfterSystemstart = sh.env.core.start() + dateutil.relativedelta.relativedelta(seconds=300)
    if sh.now() > DelayAfterSystemstart:
    .....
    Bei einem echten Serviceneustart wirft es allerdings einen Fehler in der Zeile für die Def. von DelayAfterSystemstart:
    Code:
    File: /usr/smarthome/lib/3rd/dateutil/relativedelta.py, Line: 246, Method: __radd__, Exception: unsupported type for add operation
    Die Logik wird via watch_item = xxx angesprochen und funktioniert wie gesagt nach dem Systemstart später einwandfrei.

    Ist das ein Timingproblem?
    Gibt es eine andere Methode die initialen Logiktriggerungen zu vermeiden bzw. eine Art "Delay after Servicestart" in einer Logik zu implementieren?

    Bin wie immer für alle Hints und Tipps dankbar!

    Cheers,
    Oliver

    #2
    Hi, ich hab mir für so etwas ein Pattern überlegt, das ohne Timer auskommt:
    Das Item, zu dem die Logik implementiert ist, bekommt ein Attribut ignore_first_call = true.
    In der Logik frage ich als erstes dieses Attribut ab und setze es auf false und überspringe den Rest.
    So hab ich nach dem Systemstart alles so wie gewünscht.

    Gruß Waldemar

    Kommentar


      #3
      Hi Waldemar,

      erst mal wieder Danke für Deine Hilfe, ich glaub ich buche Dich nun mal als meinen Dauersupporter.

      Klingt in der Tat nach einer simplen Lösung. Ich muß mir das nochmal heute Abend in Ruhe durchlesen und dann mal einen Versuch bei mir starten; ich denke ich habe die Lösung verstanden, notfalls würde ich aber nochmal auf Dich zukommen.

      DANKE!

      Cheers,
      Oliver

      Kommentar


        #4
        Hi,

        jetzt bin ich auch zu Hause und kann Dir ein Beispiel geben (nur die relevanten Coding-Teile). Meine Logik führt dazu, dass ein kurzer Tastendruck auf stop bei stehendem Rolladen dazu führt, dass der Rolladen weiterfährt. Hat aber dazu geführt, dass bei Start von smarthome alle Rolläden losgefahren sind. Mit diesem Pattern hab ich das verhindert. Falls jemand eine bessere Lösung dafür hat, immer her damit!

        logic.conf
        Code:
        [rolloWeiterfahren]
        	filename = RolloWeiterfahren.py
        	watch_item = *.stop:ignore_first_call
        Rollo.conf
        Code:
        ...
            [[[rollo]]]
            ...
                [[[[stop]]]]
                type = bool
                visu_acl = rw
                ignore_first_call = true
                ...
        ...
        RolloWeiterfahren.py
        Code:
        ...
        	lItem = trigger['source']
        	lParent = sh.return_item(lItem).return_parent()
        	if lParent.stop.conf['ignore_first_call']:
        		lParent.stop.conf['ignore_first_call'] = false
        	elif ...
        ...
        Gruß, Waldemar

        Kommentar


          #5
          Hallo Oliver,

          Zitat von Sandman60 Beitrag anzeigen
          Hintergrund: Die Logiken werden beim Servicestart ja einmalig getriggert und so wurden kiloweise Mails generiert wenn das überwachte Item bspw. schon wahr war.
          das stimmt so erst einmal nicht. Die Logiken werden getriggert wenn sich Items ändern die mit watch_items beobachtet werden. Mit cache = yes oder sqlite = init als Attribute wird der letzte Wert des Items wiederhergestellt und die Logik wird nicht getriggert.

          Bis bald

          Marcus

          Kommentar


            #6
            Jetzt läufts...

            Hallo Waldemar, hallo Marcus,

            erst mal vielen Dank für Eure Hilfe. Habe mich nun nochmals intensiver damit befasst und nun klappt es.

            @Waldemar: Das mit dem "Zwischenschritt" war eine sehr gute Idee, habe das nun abgewandelt über eine weitere Logik geregelt, welche ein Item als letzte auszuführende Logik dann beschreibt und in der jeweiligen Logik mit einer if-Abfrage überspringt.

            @Marcus: Mit cache = yes klappt es wie Du es geschrieben hattest. Mich hat das ehrlich gesagt am Ende etwas irritiert, da ich in der items.conf einen knx_cache gesetzt hatte, welcher dann allerdings alleine nicht ausreichend war. Wieder was dazugelernt, es wird beides benötigt.

            Cheers,
            Oliver

            Kommentar

            Lädt...
            X