Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Wie ist das. Wie es aussieht funktioniert beides für die Ausführung von Aktionen. Liege ich da richtig?
In der Doku ist eigentlich nur (noch) se_action_ beschrieben. In paar Beispielen finde ich aber auch noch se_set (unter "Pluginspezifische Templates").
Ist se_set "deprecated" oder wie ist der Status?
Eigentlich finde ich ja die Syntax von se_set gegenüber se_action smarter:
se_set ist insofern deprecated als dass ich es mit den ganzen neuen Features nie getestet habe - aber generell sollte es problemlos parallel zum se_action funktionieren.
Historie: se_set ist tatsächlich simpel. Aber eben simpel. se_action ist deutlich flexibler, weil man da noch eine Menge andere Parameter angeben kann, die teilweise wichtig sein könnten.
Bei deinen beiden Beispielen sollte exakt das gleiche Resultat rauskommen.
da ich mit dem plugin über 30 Fenster beschatte, würde ich gerne verschiedene stateengines (z.B. je Stockwerk) versetzt triggern. Da ich die KNX-Buslast unmittelbar nach dem Triggern reduzieren möchte..
Wie kann ich erreichen, dass der Trigger jede 5 Minuten abläuft, jedoch in den verschiedenen Stockwerken jeweils um 1 Minute versetzt:
Code:
#items/item.yaml
dg:
trigger:
raffstore:
type: bool
name: Gemeinsamer Trigger für alle Raffstores im Dachgeschoss
enforce_updates: yes
cycle: 300 = 1
Du hast also pro Stockwerk einen eigenen Trigger und die sollen verzögert triggern..? Probier's doch mal mit einer Logik, die sich bei "init" aktiviert und die einzelnen Trigger per Timer ansteuert. Also dg.trigger.raffstore.timer(5,1) usw. Die Frage ist, nach was sich der Cycle richtet. Startup oder was auch immer. Wäre ein eigener Thread denk ich, vielleicht kann da wer helfen.
ivande Könntest du mir vielleicht schnell alle drei Stockwerke posten? Dann werde ich das verzögerte Triggern in nem Blogeintrag o.ä. gerne verewigen. Danke!
Ticker: #aendert alle 150 Sekunden / 2,5Minuten den Zustand
type: bool
enforce_updates: True
cycle: 150
eval: not sh..()
DelayEg: # Einschaltverzoegerung Erdgeschoss 2Minuten
type: num
autotimer: 120 = 2 = latest
eval: sh...() if value == 2 else 0
eval_trigger: ..
DelayOg: # Einschaltverzoegerung Obergeschoss 1Minute
type: num
autotimer: 60 = 2 = latest
eval: sh...() if value == 2 else 0
eval_trigger: ..
Eg:
Trigger: # Triggert alle 5 Minuten / jeweils um DelayEg (2min) verzögert
type: bool
enforce_updates: True
eval: True if sh.Ticker.DelayEg() == 1 else None
eval_trigger: Ticker.DelayEg
Og:
Trigger: # Triggert alle 5 Minuten / jeweils um DelayOg (1min) verzögert
type: bool
enforce_updates: True
eval: True if sh.Ticker.DelayOg() == 1 else None
eval_trigger: Ticker.DelayOg
Dg:
Trigger: # Triggert alle 5 Minuten ohne Verzögerung
type: bool
enforce_updates: True
eval: True if sh.Ticker() == 1 else None
eval_trigger: Ticker
hat ein bisschen gedauert..
Wieso werden hier im Forum (zumindest bei mir) beim Einfügen des Codes (STRG-V) die Einrückungen (Leerzeichen) nicht mit übernommen - die muss ich immer von Hand dazumachen?
Wieso werden hier im Forum (zumindest bei mir) beim Einfügen des Codes (STRG-V) die Einrückungen (Leerzeichen) nicht mit übernommen - die muss ich immer von Hand dazumachen?
Die Vorgehensweise ist in diesemBeitrag hier beschrieben...
Hi an alle, die das Stateengine Plugin nutzen. Mir sind letztens einige ganz grobe Probleme mit dem Manuell Item aufgefallen. Und da wundere ich mich grad, warum das nie aufgefallen ist - weder mir noch sonst wem.
Folgende Probleme:
- Beim Manuell Item wurde der Original Caller (für manual_exclude/include) anhand des letzten Changes statt Updates eruiert. Ich habe bei meinem manual_exclude ein "Init:*" dabei, damit nicht versehentlich beim Neustart ein Item in den suspend Modus geht. Das ist dann sinnvoll, wenn zB ein Item zwar enforce_updates (rauf/runter Jalousie), aber kein cache: True Attribut hat. Führt aber auch dazu, dass man beim manuellen Hinauffahren der Jalousie (Item Value = false) nicht in den Suspendmodus kommt.
- Oftmals wird die Evaluierung des Suspend Items auch durch das Stateengine Plugin getriggert. Wenn das nun nicht im manual_exclude ist, kann es durchaus sein, dass man versehentlich im Suspendmodus landet.
Beide Situationen kamen bei mir primär bei shng Neustarts vor. Im laufenden Betrieb gab es keine wirklichen Probleme, sporadisch aber wohl schon.
Kann die Probleme vielleicht jemand bestätigen bzw. mal mit dem develop Branch entsprechende Tests machen? Danke!
Ich bin gerade dabei, die bei mir laufende Version zu aktualisieren: (git pull und Umstellung nach struct. Ich hatte noch eine alte Version, in der ich nur die Notwendigen Sachen von Autoblind auf Stateengine umgestellt hatte.)
Dabei ist mir aufgefallen und trotz lesen des BlogEintrages und diverser Sachen im Forum, bin ich nicht weiter gekommen:
In der Anleitung kommen in der Definition des Default-struct die Regeln für beide Hausseiten vor.
Diese gelten doch dann auch gleichzeitig, wenn ich das dann als default einbinde, oder?
Dann gibt es die Infos von eib@home (von der vorigen Seite), der eine ähnliche Lösung anstrebt.
Ich habe jetzt schon seit 3 Tagen versucht aus diesen Informationen eine laufende Version zu basteln. Irgendwie habe ich mich da verrannt.
Kann mal jemand ein Muster schicken, wie man das Struct und verschiedene Hausseiten nutzen kann, oder muss ich 4 komplette Templates schreiben, und dann jeweils das passende auswählen? Mein Wunsch wäre ein Template mit den allgemeinen Sachen und dann nur noch
# - die Sonnenhöhe mindestens 1° ist
se_min_sun_altitude: 1
# - die Sonne aus Richtung 90° bis 270° kommt
se_min_sun_azimut: 90
se_max_sun_azimut: 270
diese Werte über ein Weiteres Struct (Ost, Süd, West, Nord) hinzuzufügen.
Ich bekomme es aber nicht hin, bzw finde kein entsprechendes Beispiel, was ich umschreiben kann.
Wer kann ein Muster posten?
Ich glaube ich habe es: Ich muss ein Item Nachführen definieren und dort via as_use das entsprechende Seitenobjekt referenzierten.
Ist das richtig gedacht?
Achtung - se_use nicht as_use. Allerdings brauchst du das eigentlich auch gar nicht, wenn du eh mit structs arbeitest. Im aktuellen develop Branch der plugins sollte das mit den beiden Hausseiten in der Doku nun auch verständlicher sein.
Hier mal ein Beispiel etc/struct.yaml:
Code:
beschattung_se_state_suntrack:
status:
suntrack:
osten:
bool_helligkeit:
type: bool
visu_acl: ro
cache: True
eval: 1 if sh......settings.suntrack.min_helligkeit() <= sh.wetterstation.helligkeit.osten() else 0
eval_trigger:
- wetterstation.helligkeit.osten
- .....settings.suntrack.min_helligkeit
settings:
suntrack:
himmelsrichtung:
type: str
visu_acl: rw
cache: True
eval: >-
"suedosten" if ("sueden_stiegenhaus" in sh..self.property.path) else
"osten" if ("osten" in sh..self.property.path) else
"sueden" if ("sueden" in sh..self.property.path) else
"sueden" if ("markise" in sh..self.property.path) else
"westen" if ("westen" in sh..self.property.path) else "unknown"
enforce_updates: True
crontab: init = "unknown"
min_helligkeit:
type: num
visu_acl: rw
cache: True
min_altitude:
type: num
visu_acl: rw
cache: True
max_altitude:
type: num
visu_acl: rw
cache: True
min_azimut:
type: num
visu_acl: rw
cache: True
max_azimut:
type: num
visu_acl: rw
cache: True
hysterese_dauer:
type: num
visu_acl: rw
cache: True
rules:
se_eval_bool_helligkeit: se_eval.get_relative_item('..status.suntrack.{}.bool_helligkeit'.format(se_eval.get_relative_itemvalue('..settings.suntrack.himmelsrichtung')))
se_template_bool_age: eval:sh...settings.suntrack.hysterese_dauer() * 60 * sh...settings.suntrack.helligkeit_enter_faktor() / 100
suntrack:
enter_helligkeit:
se_agemin_bool_helligkeit: template:bool_age
se_value_bool_helligkeit: True
se_min_sun_azimut: item:..settings.suntrack.min_azimut
se_max_sun_azimut: item:..settings.suntrack.max_azimut
se_min_sun_altitude: item:..settings.suntrack.min_altitude
se_max_sun_altitude: item:..settings.suntrack.max_altitude
Der Trick liegt eigentlich im "se_eval". Achtung: In meinem Beispiel haben tatsächlich ALLE Items ihre eigenen Settings von azimut, etc.
Du kannst aber natürlich auch auf deine "gloablen" Settings referenzieren anstatt die relativen Itempfade in den rules zu nutzen. Dann hättest du ein globales Settings-Item oder Struct, wo du min_altitude, etc. in ein Unteritem "osten", "sueden", etc. stopfst.
Du könntest dann sogar substruct nutzen, die es seit dem letzten Release gibt:
etc/struct.yaml
Code:
suntrack_settings_substruct:
min_altitude:
type: num
visu_acl: rw
cache: True
max_altitude:
type: num
visu_acl: rw
cache: True
min_azimut:
type: num
visu_acl: rw
cache: True
max_azimut:
type: num
visu_acl: rw
cache: True
min_temperatur:
type: num
visu_acl: rw
cache: True
hysterese_temperatur:
type: num
visu_acl: rw
cache: True
force_temperatur:
type: num
visu_acl: rw
cache: True
min_helligkeit:
type: num
visu_acl: rw
suntrack_settings:
osten:
struct: suntrack_settings_substruct
sueden:
struct: suntrack_settings_substruct
westen:
struct: suntrack_settings_substruct
Dann referenzierst du auf die entsprechende Angabe z.B. so - unter der Annahme dass jedes deiner Items die Himmelsrichtung in einem Item settings.suntrack.himmelsrichtung deklariert hat:
Hi an alle, die das Stateengine Plugin nutzen. Mir sind letztens einige ganz grobe Probleme mit dem Manuell Item aufgefallen. Und da wundere ich mich grad, warum das nie aufgefallen ist - weder mir noch sonst wem.
...
Hi,
also ich habe auch große Probleme mit dem Suspend und hatte auch schon mal versucht, das zu beschreiben. Siehe #36. Ich muss aber dazu sagen, dass ich vollkommen den Durchblick durch die Struktur der State-Engine verloren habe. Ihr seid da tief drin, aber wenn man sich nur ab und an damit beschäftigt, ist es echt schwer, diese sehr komplexen Konfigurationsmöglichkeiten und Wechselwirkungen im Blick zu haben. Letztendlich brauche ich eine Steuerung meiner Rollladen und teilweise Lampen, die an einigen Bedingungen hängt. Ich überlege schon, mit einfach ein paar Logiken zu schreiben, um wieder Herr des Verfahrens zu werden. Das alles ist keine Kritik, mir ist schon klar, dass die Komplexität der State-Enginge zustande gekommen ist, weil diese Anforderungen bei einigen oder vielen bestehen. Und ich bin ohnehin dankbar für alles, was ihr macht. Nur da ich vollkommen den Überblick verloren habe, muss ich mir wohl einen anderen Weg suchen.
Jedenfalls habe ich das Problem, dass nach Ablauf der Suspend-Time oftmals derselbe Befehl, der das Suspend ausgelöst hat, erneut registriert wird. Ohne dass ihn jemand ausgelöst hat. Das passiert aber auch nicht immer. Wenn ich teste, läuft oft alles so, wie es sein soll. Wenn ich dann in den Betrieb gehe, bleibt dann und wann irgendwo ein Rollladen im Dauer-Suspend.
Dann habe ich auch noch das Problem, dass ich einen Rollladen manuell öffne und wenn während der Öffnung (Rollladen läuft noch) der reguläre Trigger eine Neuberechnung auslöst, dann fährt der Rollladen wieder zurück. Also die normale Konfiguration wäre z.B. zu der Zeit "Rollladen geschlossen" und ich öffne ihn aber manuell. Dann kommt per Trigger in dem Moment eine Neuberechnung und er stoppt die Aufwärtsfahrt und fährt wieder nach unten. So, als ob der Suspend-Zustand nicht mehr rechtzeitig angekommen wäre...
Ich poste mal alle meine Konfigurationen. Vielleicht (oder ganz bestimmt) mache ich auch was Grundlegendes falsch.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar