Treppenlichtfunktion flexibel

[Cannon]

Ich habe einen neuen Aktor, der leider nicht die Möglichkeit hat die Zeit der Treppenlichtfunktion über den Bus zu senden. Für die Gartenbewässerung wäre das aber sinnvoll. Da aber die ganze Steuerung ohnehion mit SmartHomeNG läuft, möchte ich auch die Treppenlichtfunktion umsetzen. Ich kriegs aber nicht so hin, wie ich mir das vorstelle. Das heißt:

- es gibt ein Item schalten
- es gibt ein Item Dauer
- Dauer soll in Minuten sein
- wenn Dauer > 0, dann soll das Item schalten eingeschaltet werden und bei 0 abgeschaltet werden

- Dauer soll gleichzeitig die Restzeit beinhalten, wenn per Dauer eingeschaltet wurde
- wenn das Item schalten manuell eingeschaltet wird, dann wird Dauer ignoriert (oder mit einen Standardwert vorbelegt)

Im Prinzip funktioniert alles, bis auf die letzten beiden Punkte. Da weiß ich nicht mal ansatzweise, wie ich das lösen kann. Den Rest kann ich zwar berechnen, aber nicht im Item, welches die Dauer beinhaltet.

    schalten:
        type: bool
        autotimer: sh..Dauer.Sekunden() = 0
        visu_acl: rw
        database: yes
        on_update:
            - .wannAktiv = sh.now() if value else None
        # Beregnungsdauer in Minuten
        Dauer:
            type: num
            visu_acl: rw
            on_change:
                - .Sekunden = value * 60
                - .Rest = value
                - ..self = True if value > 0 else False
            Sekunden:
                type: num
                enforce_updates: yes
            Rest:
                type: num
                cycle: 60
                enforce_updates: yes
                visu_acl: rw
                eval: sh...self() - round(sh...self.update_age() / 60, 0) if sh...self() > 0 else 0

[bmx]

Wozu brauchst Du die Restzeit? Da müßtest Du das ja andauernd triggern damit sich das neu berechnet? Und wenn Du die ggf. in der SmartVISU anzeigen willst, dann ist das Websocket da permanent mit beschäftigt das anzuzeigen. Wir haben diese Diskussion schon mal irgendwo gehabt. Die Quintessenz war IMHO das man einmalig beim Schalten die Restzeit einem Item gibt und für die Visualisierung dann Item und Dauer in der SmartVISU verknüpfen müßte um das dort korrekt anzuzeigen.

Ich würde das Ganze mit einer Logik unterstützen und nicht nur mit einem Autotimer.

[Tom Bombadil]

Wir hatten schonmal eine ähnliche Problematik beim Thema "Stoßlüften" hier - sind aber nie zu einer finalen Lösung gekommen.

Steht somit noch auf meiner ToDo-Liste:
Allgemeingültige Itemstruktur austüfteln, die für Autotimer/Countdown (Treppenlicht, Stoßlüftung etc pp) verwendbar ist
(mit allen denkbaren Features drumherum wie z.B. Abbruch durch Taster/Visu).

Vielleicht helfen die Gedanken im verlinkten Thread ja trotzdem.

/tom

[Morg]

Eine praktikable Lösung wäre ggf, nicht den Rest, sondern den Einschaltzeitpunkt zu nutzen und an die Visu zu übermitteln.

Die Anzeige "jetzt - Aktivierung" könnte man über JS dauerhaft und mit wenig Aufwand aktuell halten.

Mit Deaktivierung wird der Startzeitpunkt zurückgesetzt und die Anzeige geht aus...

Kann ich mangels JS-Fähigkeiten nicht umsetzen, aber die Aktivierungszeit wäre über Item-Properties vom Schaltitem lesbar.

[wvhn]

Wenn der Schaltzeitpunkt und die gesetzte Einschaltdauer als items definiert werden, kann ich diese in smartVISU in einem Widget als Countdown anzeigen lassen - z.B. alle 5 oder 10 Sekunden, solange das Schaltitem eingeschaltet ist.

Gruß
Wolfram

[Onkelandy]

Wenn wir da grad dabei sind bezüglich Countdown. Das wäre uU noch ein nettes Feature für das stateengine Widget. Dort ist die Dauer in einem Item definiert. Und bis dato die Endzeit als String. Letzteres wird vermutlich nicht viel bringen - aber es wäre sicher easy, beim entsprechenden Schaltzeitpunkt ein Item mit der aktuellen Uhrzeit zu befüllen. In welchem Format/Type müsste das dann vorliegen?

[wvhn]

Ich würde von Formaten ausgehen, die SV und shNG schon beherrschen. Das sind die Zeitstempel, die z.B. vom database-Plugin gesendet werden und die duration-Formate, die bei den Plots üblich sind. Beispiel: 1h 5i 3s sind 1 Stunde, 5 Minuten und 3 Sekunden.
Also Anfangszeit -> Zeitstempel und gesetzte Dauer -> duration.

Was wäre denn eine sinnvolle countdown-Frequenz? Ich kann die einstellbar machen. Dann kann jeder selbst festlegen, wie sehr er sein System mit Zählen beschäftigen will. Ich würde folgendes abhängig von der Dauer als Default vorschlagen:

• über 10 Minuten: 1 x pro Minute
• über 1 Minute: alle 10 Sekunden
• unter 1 Minute: alle 5 Sekunden

Ich würde das Feature clock.countdown(id, Schaltitem, Startzeit, Dauer, [Freuenz]) nennen und die Ausgabe per javaScript in ein html-Element schreiben.

Passt das so?

Gruß
Wolfram

[Cannon]

Wozu brauchst Du die Restzeit? Da müßtest Du das ja andauernd triggern damit sich das neu berechnet? Und wenn Du die ggf. in der SmartVISU anzeigen willst, dann ist das Websocket da permanent mit beschäftigt das anzuzeigen. Wir haben diese Diskussion schon mal irgendwo gehabt. Die Quintessenz war IMHO das man einmalig beim Schalten die Restzeit einem Item gibt und für die Visualisierung dann Item und Dauer in der SmartVISU verknüpfen müßte um das dort korrekt anzuzeigen.

Was heißt denn andauernd? Die Welt geht nicht unter, wenn es einmal pro Minute aktualisiert wird. Ich will einfach auf der VISU sehen, wie lange die Bewässserung noch laufen wird. Ich könnte alternativ allerdings noch die Endzeit berechnen und dann hinschreiben. Dann habe ich zwar keine Restzeitanzeige, aber die Uhrzeit, wie lange das noch läuft.

Wir hatten schonmal eine ähnliche Problematik beim Thema "Stoßlüften" hier - sind aber nie zu einer finalen Lösung gekommen.

Der Ansatz ist die USZU. Ich kriege die bei mir gar nicht zum Laufen. SmartHomeNG lässt sich dann nicht starten, wenn das plugin aktiviert ist. Dennoch interessanter Ansatz ich schau mal rein.

Was wäre denn eine sinnvolle countdown-Frequenz? Ich kann die einstellbar machen. Dann kann jeder selbst festlegen, wie sehr er sein System mit Zählen beschäftigen will. Ich würde folgendes abhängig von der Dauer als Default vorschlagen:

Klingt interessant. Nutzen und reinlesen müsste ich mich dazu aber in das stateengine-plugin?

[Onkelandy]

Ne, das hat mit dem stateengine nix zu tun - wollte nur Interesse bekunden, dass es ein Countdown in dem Zusammenhang auch interessant wäre.
Fürs UZSU gibt es einen Supportthread. zu 99% liegt es an der fehlenden Scipy Installation. Am Raspi auch noch lib-atlas. Steht aber in der Doku und im Supportthread.

[Tom Bombadil]

Der Ansatz ist die USZU. Ich kriege die bei mir gar nicht zum Laufen. SmartHomeNG lässt sich dann nicht starten, wenn das plugin aktiviert ist. Dennoch interessanter Ansatz ich schau mal rein.

Nein, weiter hinten im Thread geht es um eine allgemeine Zeitschaltuhr, die z.B. durch einen Taster ausgelöst wird ("Stoßlüftung"). Weiterhin eine Rückkehrfunktion auf den vorher eingestellten Wert (=Lüftungsstufe vor Stoßlüftung) sowie Abbruchmöglichkeit (=Stop, Rückkehr auf alten Wert) und Restzeitanzeige. Geht alles ohne UZSU. Stefan und Wolfram haben damals ja auch viele gute Ideen dazu gehabt.

Wie schon geschrieben, steht eine für derlei Dinge einsetzbare, allgemeingültige Itemstruktur mit den dafür notwendigen Hilfsitems noch auf meiner ToDo-Liste. Ich nehm aber auch gern 'fertigen' Input von anderer Seite.

/tom

[wvhn]

Die Restzeit in shNG zu berechnen ist IMHO Ressourcenverschwendung. Da gebe ich bmx recht. Das kann die Visu viel schlanker. Zudem läuft sie auf dem Client und führt das Ganze auch nur dann aus, wenn die entsprechende Seite angewählt ist.

Ich mache mich also in den nächsten Tagen mal an die Countdown-Funktion, wie oben beschrieben. Nach der Diskussion hier würde ich die Anzeige allerdings bei jeder Änderung des Schaltitems abbrechen, also nicht nur, wenn es 0 (aus) ist. Vermutlich ist es sinnvoll, wenn shNG das item für den Startzeitpunkt auf 0 setzt, wenn der Autotimer abgelaufen oder der Vorgang abgebrochen ist.

Gruß
Wolfram

[wvhn]

Jetzt hat es doch ne Weile gedauert, bis ich mich dransetzen konnte. Im Anhang nun die erste Version mit Bitte um ausführliches Testen.
Das widget clock.countdown benötigt

• ein item, das im Backend mit timer geschaltet wird
• ein item für die Startzeit (Unix Zeitstempel)
• ein item für die Schaltdauer (Format y m d h i s, e.g. "2i 30s"). y, m und d werden vom widget in Stunden umgerechnet und angezeigt.
• eine optionale Angabe für das Zählintervall (default: 10s)

Der Countdown wird gestartet, wenn Startzeit und Dauer gesetzt sind und die Summe größer als die aktuelle Zeit ist.
Abgebrochen wird der Countdown, wenn das Schaltitem geändert wird, aber die Startzeit gleich bleibt. Wenn das item im Backend nach Ablauf des Timers nicht verändert wird, läuft der Countdown einfach weiter.
Startzeit und Dauer können vom Backend verändert werden, während der Countdown läuft. Die Anzeige wird entsprechend angepasst.

Dateien einschl. Docu-Seite anbei. Einfach entsprechend der Ordnerstruktur entpacken. Viel Spaß!

Gruß
Wolfram

P.S.: neue Dateien hochgeladen nach Korrektur der Anzeige negativer Werte und Verbesserung der Triggerung des Countdowns

P.P.S: übrigens ist das Widget auch in github auf smartvisu-newstuff

[wvhn]

Musste nochmal was korrigieren und habe die Dateien ausgetauscht. Siehe #12

[Onkelandy]

Danke für das coole Widget! Jetzt gibts mal prinzipiell keinen Fehler mehr Komisch ist aber, dass auf der Dokuseite ca. 5 Sekunden vergehen, bis der Countdown angezeigt wird. Zudem erscheint eine Sekunde lang ein sehr hoher Minusbetrag, ehe der Wert korrigiert wird.

Für Stateengine scheint das Widget leider nicht tauglich. Dort wird nämlich immer das Suspend Item auf falsch und sofort auf wahr gesetzt - und somit wohl der Countdown sofort gestoppt, ehe er begonnen hat, denke ich..? Muss ich nochmals durchgucken.

Ich generiere den Timestamp in shng via: sh.tools.dt2ts(shtime.now())
Muss das dann halt * 1000 nehmen, damit es klappt. Allerdings wäre es natürlich schön, das Widget würde das selber kapieren, ob die Angabe in s oder ms ist..?

[wvhn]

Es ist immer wieder erstaunlich, was trotz intensivem Testen alles passieren kann. Vor allem der Browser-Cache spielt eine nicht unerhebliche Rolle
Bei mir stoppt der Countdown auf dem PC mit lokalem Apache und Firefox seit heute morgen beim ersten Mal sofort wieder. Mit Apache auf dem Raspberry läuft er sauber an, startet dann aber nach dem Abbruch immer wieder neu.

Wartet mal mit dem Testen. Ich stelle nochmal eine neue Version bereit.

Gruß
Wolfram