[callidomus] Zustandsautomat und dynamische Uhrzeitangaben

[trollvottel]

Hallo zusammen!

Ich versuche mich gerade an einer SM für 'Nacht' (Tag/Nacht-Umschaltung in Abhängigkeit der Uhrzeit und Sonnenauf-/Untergang).

Ich scheitere aber daran, dass in den Eingangsbedingungen keine dynamischen Uhrzeitangaben (z.B. 'sunrise' oder 'sunset') angegeben werden dürfen. Im Log steht dann z.B. 'time:2355 < sunrise => EXCEPTION: unorderable types: int() < str()'.

Das wäre aber sehr nützlich wenn das funktionieren würde, auch mit Offset. Mir fehlen hier in der Doku auch die Angaben zu den möglichen Werten bzw. wie deren Format auszusehen hat.

Oder fahre ich hier den komplett falschen Ansatz?

[heckmannju]

Hi,
probiers doch mal mit dem Sonnenstand(Höhe). Das sollte doch eigentlich gehen.

Tag ist es wenn Sonnenstand > 0 und Nacht ist wenn nicht Tag ist. (hab aber noch das Jahr>0 bei nacht gebraucht)

Viele Grüsse
Jürgen

[trollvottel]

heckmannju Danke für den Input. Für rein Tag/Nacht ohne Offset funktioniert das so weit (ausprobiert).

Hintergedanke meines Ansatzes war jedoch auch, noch weitere Zustände (z.B. 'Dämmerung') hinzufügen zu können. Da müsste ich dann schon mit relativen Zeitangaben arbeiten können, oder?

[heckmannju]

Hi, Zeiten wären schöner. Das finde ich auch.

Es geht aber doch bestimmt auch wenn du Sonnenaufgang >-6 ist Dämmerung definiert. So ist glaube ich auch die "Bürgerliche Dämmerung" definiert.

Markus rechnet das halt in den Zeitschaltuhren noch um in Minuten. Ist wahrscheinlich nicht ganz das selbe wen man das in Minuten angibt aber vielleicht ist es das was man eigentlich haben will.

VG
Jürgen

[trollvottel]

Entgegen der Onlinedoku funktioniert es auch mit Pythoncode nicht. Wenn ich z.B. als Uhrzeit-Vergleichswert 'cd.location.today.sunset()' hernehme, hagelt es folgende Exception:

time:1146 >= cd.location.today.sunset():2016-12-20 16:32:34+01:00 => EXCEPTION: unorderable types: int() >= datetime.datetime()

Offenbar wird für die Uhrzeit einfach ein int() angenommen, das is IMO bisl doof an der Stelle.

callidomus ?

[mumpf]

Hi,

wie Jürgen schon sagte, sun_altitude ist die Antwort. Du gibst dort ja direkt den Winkel an, den Du erwartest. Dämmerung fängt bei 6° an, wenn ich mich richtig erinnere (das kann man ja nachlesen), also ist

• Nacht bei sun_altitude < 0
• Dämmerung bei sun_altitude [0,6]
• Tag bei sun_altitude > 6

An den Werten kannst Du rumspielen, bis es Dir genehm ist. Code würde ich vermeiden (außer es geht nicht anders), denn der Vorteil einer SM ist es ja gerade, ohne code auszukommen, mit rein logischen Ausdrücken.

Gruß, Waldemar

[trollvottel]

Ich erwarte eigentlich keinen Winkel, sondern die Eingabe eines zeitlichen Offsets. Das lässt sich mit einem Winkel ja nicht kombinieren.

Bin überzeugt, die Eingabemöglichkeit dynamischer Uhrzeiten ist auch für andere Dinge noch praktisch... Bei den Items geht das ja.

[heckmannju]

Hi Mario,

ja aber der winkel ist ja sowas wie der Zeitliche Offset nur das du ihn halt jetzt noch nicht so definieren kannst.

Für die Sache an sich zur Erkennung der Dämmerung halte ich den Winkel eigenlich für die bessere Wahl da ja die Dämmerungsphasen im Winter länger sind als im Sommer.

Aber ich vermute mal das du halt irgendwas schalten oder mache willst 1h vor Sonnenaufgang oder so ähnlich richtig?

Viele Grüsse
Jürgen

[trollvottel]

Aber ich vermute mal das du halt irgendwas schalten oder mache willst 1h vor Sonnenaufgang oder so ähnlich richtig?

Richtig. Für bsp. eine Anwesenheitssimulation hätte ich da sogar ganz gerne noch etwas Zufall drin im Offset. Finde schon, dass das Sinn ergibt.

Aber ich sehe natürlich ein, dass das so nun einfach noch nicht implementiert ist - Als Feature wäre es IMO allerdings wünschenswert.

Gerade für Einsteiger liegt die Eingabe des Winkels hierfür auch nicht gerade auf der Hand...

[heckmannju]

An den Werten kannst Du rumspielen, bis es Dir genehm ist. Code würde ich vermeiden (außer es geht nicht anders), denn der Vorteil einer SM ist es ja gerade, ohne code auszukommen, mit rein logischen Ausdrücken.

Kann man den überhaupt auch einen Codeblock als Bedingung machen?

[trollvottel]

Kann man den überhaupt auch einen Codeblock als Bedingung machen?

Ja, man kann Code als Vergleichswert schreiben. Steht auch so in der Onlinehilfe. Aber nützt halt nix, wenn sich das Ergebnis des Ausdrucks an der Stelle nicht vergleichen lässt.

[mumpf]

Hi Mario,

Leider nur vom Handy, deswegen nicht getestet...

Nutze die Möglichkeiten der SM:
Mach einen Zustand "Daemmerung" und dann einen weiteren, der auf
Zustand == "Daemmerung"
Maschine age >= 3600
abfragt. Dieser Zustand wird 1 Stunde nach dem Zustand "Daemmerung" betreten.

Gruß Waldemar

[heckmannju]

Hi Waldemar,
was ist den die Bedeutung von Maschine age?
VG
Jürgen

[mumpf]

Hi,

Mit age spricht man das Alter eines Items an (also wie lange hat es diesen Wert). Und mit machine ist das Item gemeint, dem sie SM zugeordnet ist. Da das die Zustände hält, kann man so messen, wie lange die SM in einem Zustand ist.
Gruß Waldemar

[callidomus]

Hallo trollvottel,

Entgegen der Onlinedoku funktioniert es auch mit Pythoncode nicht.

doch. Gib mal

Birnen

bei dem Wert an.

Ernsthaft, der Wert sollte schon zum Vergleichen passen.

cd.location.today.sunset().time()

Ok, dass wird zwar momentan auch nicht funktionieren, das könnte ich aber einrichten.

Gerade für Einsteiger liegt die Eingabe des Winkels hierfür auch nicht gerade auf der Hand...

Du meinst bei Sonnenstand (Azimut) und Sonnenstand (Höhe) ist die Angabe von Zeit-Minuten oder Zeit-Sekunden offensichtlicher? Wirklich?

Aber zurück zu dem eigentlichen Problem. Die Höhe, mit einem Offset in Grad, ist wahrscheinlich passend. Ein Offset in Minuten ist nicht so gut, da zwischen Sommer und Winter enorme Unterschiede bestehen - was die Helligkeit angeht bei sagen wir einmal 30 Minuten vor Sonnenaufgang.

Was möchtest Du denn genau erreichen? Als was schalten?

Bis bald

Marcus