[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

[CoolTux]

Wenn ich Dich jetzt richtig verstanden habe, dann konntest Du bei WindParameters folgendes nicht machen

50:20

oder nur

50


Ist das korrekt? In meinem kleinen Codesnippet Test geht es. Ich teste es jetzt noch im Ganzen.

[Beta-User]

Wind:
Doch, ging beides, zwingend war nur die Angabe der Zielposition (was ich nicht vertieft getestet habe: ob die Hyserese-Berechnung sauber läuft).

Zum $we-Thema noch:

Das ist  irgendwie nicht ganz stringent (imo), dass da auf Value() zugegriffen wird und nicht auf den Inhalt des Readings state...

Diese ganze $we-Geschichte sollte m.E. insgesamt anders laufen.
Der Teil gehört für mich in eine eigene sub in fhem.pl (so wie in ASC), die man dann aus jedem Modul aufrufen kann. Ruft man das ohne Parameter oder mit "today" auf, wird auf state zugegiffen, nicht auf STATE, ruft man es mit "tomorrow" oder "1" auf, wird morgen geliefert.

Dann könnte man Calendar noch um ein cal2holiday-Attribut erweitern, das Readings am Calendar (z.B. "today" und "tomorrow") füllt, wenn man dort "Schlüsselwort" oder "Schlüsselwort:Kalender-Element" (mehrere: Leerzeichen dazwischen, Element ist z.B. Description, um unterschiedliche Urlaubsarten auseinanderzuhalten, zuhause oder nicht etc.) eingibt. So könnte man auch Calendar-Devices direkt via holiday2we viel einfacher einbinden...

Deine Meinung?

[CoolTux]

Die Temperatur Übernahme scheint auch so weit zu gehen.

Kannst Du mir noch eine kurze Übersicht geben wo jetzt was nicht ganz so passt in Deinen Augen mit der neuen Attributssyntax.

Was sagst Du zu

Code Auswählen Erweitern

ASC_brightnessDriveDownUp

für die Brightness Angaben im ASC Device

ASC_brightnessDriveDownUp - WERT-ABENDS:WERT-MORGENS, Werte bei dem Schaltbedingungen für Sunset und Sunrise geprüft werden sollen. Diese globale Einstellung kann durch die WERT-ABENDS:WERT-MORGENS Einstellung von ASC_BrightnessSensor im Rollladen selbst überschrieben werden.

[CoolTux]

Wind:
Doch, ging beides, zwingend war nur die Angabe der Zielposition (was ich nicht vertieft getestet habe: ob die Hyserese-Berechnung sauber läuft).

Also eigentlich nicht. Zwingend ist immer nur der aller erste Wert. Im Fall von WindParameters wäre es das Max der Rest kann entfallen.

Zum $we-Thema noch:

Das ist  irgendwie nicht ganz stringent (imo), dass da auf Value() zugegriffen wird und nicht auf den Inhalt des Readings state...

Diese ganze $we-Geschichte sollte m.E. insgesamt anders laufen.
Der Teil gehört für mich in eine eigene sub in fhem.pl (so wie in ASC), die man dann aus jedem Modul aufrufen kann. Ruft man das ohne Parameter oder mit "today" auf, wird auf state zugegiffen, nicht auf STATE, ruft man es mit "tomorrow" oder "1" auf, wird morgen geliefert.

Dann könnte man Calendar noch um ein cal2holiday-Attribut erweitern, das Readings am Calendar (z.B. "today" und "tomorrow") füllt, wenn man dort "Schlüsselwort" oder "Schlüsselwort:Kalender-Element" (mehrere: Leerzeichen dazwischen, Element ist z.B. Description, um unterschiedliche Urlaubsarten auseinanderzuhalten, zuhause oder nicht etc.) eingibt. So könnte man auch Calendar-Devices direkt via holiday2we viel einfacher einbinden...

Deine Meinung?

Finde ich gut. Gerade die Sache mit cal2holiday.

[Beta-User]

Also eigentlich nicht. Zwingend ist immer nur der aller erste Wert. Im Fall von WindParameters wäre es das Max der Rest kann entfallen.

Nope, wie geschrieben: Der Rolladen geht auf 50%, wenn ich den Level weglasse (HM-Type, also ASC=2)

[CoolTux]

Nope, wie geschrieben: Der Rolladen geht auf 50%, wenn ich den Level weglasse (HM-Type, also ASC=2)

Mussverständniss
So ist es ja auch eingestellt als default für Position. Er sollte auf 50% fahren. Habe nun die 0 als default Wert genommen. Er sollte also nach dem nächsten Update wenn Du nichts weiter ein gibst auf 0 fahren.

[Beta-User]

Mussverständniss
So ist es ja auch eingestellt als default für Position. Er sollte auf 50% fahren. Habe nun die 0 als default Wert genommen. Er sollte also nach dem nächsten Update wenn Du nichts weiter ein gibst auf 0 fahren.

Hmm, wo nimmst du die "0" her? Das klingt wie ein fester Wert.

Wunsch wäre: Offen-Position, wie sie sich aus dem ASC-Typ ergibt, also HM = 100, ROLLO=0

Auf die Spitze getrieben: Rückgriff auf den Typ erst "hinter" einem optionalen Attribut-Wert für alle Rollläden am ASC-Device.

[CoolTux]

Hast auch wieder Recht. Besser sauber als offen setzen. Sollte man bei Wind lieber offen haben?

[Beta-User]

Hast auch wieder Recht. Besser sauber als offen setzen. Sollte man bei Wind lieber offen haben?

Ich verwende das alte notify bisher nur bei meinen Jalousien, und da ist offen zwingend. Ob das andere genauso sehen, kann ich nicht beurteilen.

Daher hatte ich das geschrieben:

Auf die Spitze getrieben: Rückgriff auf den Typ erst "hinter" einem optionalen Attribut-Wert für alle Rollläden am ASC-Device.

Ergo: Wer mit "unserer" Denke (oder dem was der Entwickler am Ende entscheidet) nicht einig ist, was diese Grundsatzentscheidung angeht, _könnte_ am Ende da eine 0, 50, 27 oder 100 reinschreiben. (Nur) wer es noch genauer braucht, muß (und kann!) den einzelnen Rollläden anfassen .

[CoolTux]

Fällt Dir noch irgendwas ein was wir anders machen sollten. Also was ich jetzt in der neuen Entwicklung vielleicht falsch angefasst habe? Oder ist die derzeitige Syntax bei den Attributen ok? Also bei denen die ich geändert habe.

[Beta-User]

Hmm, das ist eine sehr tiefgreifende Frage, die ich so nicht abschließend beantworten kann.

Bis dahin habe ich mir angesehen:
- Wind
Da finde ich es super, wenn es kommt wie vorhin skizziert, also
-- Mindestangabe ist eine Windgeschwindigkeit beim Rollladen, dann "geht" eigentlich alles weitere automatisch, insbesondere der Rollladen geht auf die jeweils passende "offen"-Position
-- Maximalkonfiguration: geht über das einzelne Rolladenattribut "as is", auch ok so.
-- Offen/Wünschenswert vielleicht noch: Attribut für das ASC (windDefaults?); da könnte man dann eine globale Grenzgeschwindigkeit festlegen (limit:value), den default Offen-Wert (position:value) und den default Hysterese-Wert (hystersis:value) (alles optional). Geht aber erst mal auch so; die "Prüfungskette" ggf. zu verlängern, wäre ja kein großes Problem (jedenfalls, wenn wir beim Start einmalig prüfen und an einen festen Ort schreiben, welcher konkrete Wert denn jeweils für die Einzelangabe gilt und dann später unmittelbar darauf zugreifen).

- Brightness
Da hatte ich schon dazu ausgeführt, warum mir das _nicht_ gefällt
Dazu könnte ich noch anmerken, dass du beim Übertragen der alten Werte in neue optionale weitere Werte statt der defaults dann besser nichts angibst (bei min/max stand da -1/-1); das Übertragen macht m.E. nur da Sinn, wo es wirkliche User-Angaben gab.

Viel mehr konnte ich bis dato nicht ansehen (bis auf dieses unselige $we-Thema...), ansonsten hatte ich auch nicht den Eindruck, dass da viele weitere Attribute betroffen waren.

Gibt es noch ein konkretes, zu dem ich was sagen kann bzw. dass ich mir ansehen sollte?

[Beta-User]

Zu dem Brightness-Thema ist mir grade noch was eingefallen:

"Angeschaltet" wird der brightness-Mode ja an jedem Rolladen, getrennt für morgens und abends (ASC_Up und ...Down). Da wäre der jeweilige Schwellwert als optionale individuelle Angabe doch gut aufgehoben, oder? Also auch überhaut nur auszuwerten, wenn vorne brightness steht.

Dann die Schwellwerte als optionales Vorgabe-Attribut beim ASC-Device (Gimmick: Wenn der brightness-Sensor angegeben ist, kennen wir den Typ; z.B. bei meinem HM-(außen-Bewegungsmelder zum Selberlöten) war das ein Wert Mitte/Ausgang der 60, 67, wenn ich das richtig im Kopf habe)

[CoolTux]

Ich hatte alle Attribute im ASC Device entsprechend umgesetzt. So zum Beispiel Residents noch.

Meinst also man könnte dann ASC_Up brightness:500:700 machen?
Die Idee finde ich cool. Leider kann man dann nicht mehr so schön zur Auswahl greifen (machen)
Also Auswahl von ASC_Up Astro,Brightness,Time

[Beta-User]

Die Idee finde ich cool.

Danke.

Meinst also man könnte dann ASC_Up brightness:500:700 machen?

In die Richtung, aber...
(Du vermutest Probleme wegen der Doppelpunkte, oder?)

Der Reihe nach... Heute steht da:

Code Auswählen Erweitern

'ASC_Up:time,astro,brightness' Vielleicht ginge:

Code Auswählen Erweitern

'ASC_Up:time,astro,brightness 500:700'
oder:

Code Auswählen Erweitern

'ASC_Up:time,astro,"brightness  500:700"' ABER:
"An sich" würde man die optionalen Werte doch gar nicht benötigen, oder ? => schlicht weglassen (setzt aber voraus, dass wir irgendwo anders einen default definiert haben).
Sobald der User was eingetragen hat, ist eh' egal, FHEM "kann" dann die Attr-Inhalte schon auslesen.

Dann ginge auch wieder völlig stressfrei:

Leider kann man dann nicht mehr so schön zur Auswahl greifen (machen)
Also Auswahl von ASC_Up Astro,Brightness,Time

"Anders" wird es erst, wenn man pro Rollladen wirklich eine andere Einstellung haben will als den (globalen) default dazu (zukünftig kommend vom ASC-Device?). Keine Ahnung, wie groß der Anteil "brightness"-User unter den "ASC'lern" ist, aber ich würde annehmen, dass von denen auch nur ein Bruchteil unterschiedliche Werte an vielen Rollläden verwenden . Da macht man ggf. auch Gruppen von Devices.

Ergänzend:
- Was die Frage Doppelpunkt oder Leerzeichen angeht, müßten wir irgendeine Logik entwickeln, die der user bei ähnlichen Fragen dann auch immer anwenden kann. Ausgehend von Wind => Device:Reading ist klar, danach kam Bedingung: Hysterese, dann Zielwert.
Brightness würde ich wahlweise unter "Bedingung" oder "Device" einsortieren, daher das Leerzeichen oben.
- 500:700 stand für sunset:sunrise (oder umgekehrt). Würde auch hier wieder vorschlagen, den 2. Wert optional zu machen, also sunset[:sunrise], und dann sunrise mit sunset zu belegen, wenn nicht angegeben. (Kosmetik, zugegeben...)

Resident hatte ich bisher im ASC-Device nicht genutzt, nur an den Rollläden. Mal schauen, wie weit ich da komme, da fehlt mir noch etwas das "Gefühl", welche Auswirkungen das jeweils hat.

Aber so langsam habe ich das Gefühl, dass wir nach und nach ein gemeinsames Verständnis dafür bekommen, wie die useability einfacher gemacht werden kann, ohne ggf. für Experten die Freiheiten zu beschränken?

[Beta-User]

Was sagst Du zu

Code Auswählen Erweitern

ASC_brightnessDriveDownUp
für die Brightness Angaben im ASC Device

Ähm sorry, den hatte ich vorher übersehen. Kurzer Kommentar noch dazu: Wenn es direkt im ASC_Up usw. geht, fände ich das noch besser (da eingespart...), aber an sich spricht nichts gegen ein solches Attribut (und da stand auch, dass es das Zentral ja schon gibt! Auch gut, und noch mehr ein Argument, das für die einzelnen Rolläden gleich einzusparen.).

Die Benennung finde ich sperrig, aber mir fällt grade auch nichts besseres ein. Gedanklich stolpere ich immer über die Reihenfolge DownUp, irgendwie liegt mir der "normale" Tagesablauf näher, also sunrise[:sunset], aber ich bin da leidenschaftslos; gehört zu den Dingen, die ich ggf. mal teste, wenn sich sonst keiner findet... (Bin mit Astro sehr zufrieden!)