Betatester für neues Modul AutoShuttersControl gesucht!

[Beta-User]

Mei, geht das voran, eben dachte ich noch, dass es doch schön wäre, die Timer nicht nur im list zu sehen, und schon isses so ...

Super Sache!

Was mir noch aufgefallen ist, nachdem ich jetzt dann das eine oder andere an Spielereien mal angehen wollte:
Eben fand ich es unnötig kompliziert, für die Temperatur Sensor und Reading getrennt setzen zu müssen; "MYSENSOR_97:temperature2" in einem einzigen Attribut finde ich persönlich übersichtlicher.

Das Device für Brightness wird im Moduldevice vergeben.

Das habe ich eben auch nicht gefunden; auch hier würe mir die Schreibweise "Device:reading" (oder "device reading") entgegenkommen.

Generell wollte ich nochmal nachfragen, ob es angedacht ist, default-Werte für die Attribute aus dem Moduldevice zu nehmen; insbesondere dann wäre es für die Übersichtlichtḱeit besser, die Menge der Attribute auch dort einzugrenzen.

Schönen Abend jedenfalls,

Beta-User

[Papaloewe]

Hallo Leon,

in der aktuellen Version des Rollo-Moduls heißt das Kommando zum Fahren des Rolladen, bzw. der Jalousie jetzt auch "pct" und nicht mehr "position".

[CoolTux]

Hallo Leon,

in der aktuellen Version des Rollo-Moduls heißt das Kommando zum Fahren des Rolladen, bzw. der Jalousie jetzt auch "pct" und nicht mehr "position".

Alles klar. Das macht nichts. Ich schaue nur wegen der Anleitung ob ich da einen Verweis habe. Ansonsten einfach bei AutoShuttersControl die 2 mit angeben.

[CoolTux]

Mei, geht das voran, eben dachte ich noch, dass es doch schön wäre, die Timer nicht nur im list zu sehen, und schon isses so ...

Super Sache!

Was mir noch aufgefallen ist, nachdem ich jetzt dann das eine oder andere an Spielereien mal angehen wollte:
Eben fand ich es unnötig kompliziert, für die Temperatur Sensor und Reading getrennt setzen zu müssen; "MYSENSOR_97:temperature2" in einem einzigen Attribut finde ich persönlich übersichtlicher.

Für mich ist das einfacher so wie es ist. So habe ich weniger Aufwand beim Code

Das habe ich eben auch nicht gefunden; auch hier würe mir die Schreibweise "Device:reading" (oder "device reading") entgegenkommen.

Stimmt, das ist auch im Rolladenmodul. Ist aber auch noch nicht aktiv. Alles was aktiv ist findet man in der commandref zum Modul.

Generell wollte ich nochmal nachfragen, ob es angedacht ist, default-Werte für die Attribute aus dem Moduldevice zu nehmen; insbesondere dann wäre es für die Übersichtlichtḱeit besser, die Menge der Attribute auch dort einzugrenzen.

Wie meinst das mit den default Werten? Die Werte müssen ja dahin wo das Attribut ist und das ist im Rolladen.

Ich wünsche auch einen schönen Abend.
Und schreibt mal was zur generellen Betrieb. Wie ist es beim Fenster auf oder gekippt. Wie wenn Sonnenauf oder Untergang ist. Klappt bei Euch alles?

[CoolTux]

Ich würde in einer nächsten Version gern

RolloKuecheLinks_nextAstroEvent

austauschen gegen

RolloKuecheLinks_nextAstroTimeEvent

da es ja auch feste Zeiten sein können, also kein Astro. Wäre das ok? Dann müsstet Ihr das alte Reading bitte von Hand löschen.

[Prof. Dr. Peter Henning]

Das Löschen von veralteten Readings von Hand ist fehleranfällig. Bau doch temporären Code ins Modul, der das automatisch macht.

LG

pah

[CoolTux]

Das Löschen von veralteten Readings von Hand ist fehleranfällig. Bau doch temporären Code ins Modul, der das automatisch macht.

LG

pah

Ich wollte es mir sparen 
Aber hast ja Recht, so kann ich wenigstens sicher sein.

[Beta-User]

Für mich ist das einfacher so wie es ist. So habe ich weniger Aufwand beim Code

Hätte vermutet, dass zwei AttrVal() Funktionen drin sind, um zwei Variablen zu füllen. Wenn es so wäre, wäre doch  ein split auf ein AttrVal fast dasselbe (mal abgesehen von dem einmaligen Aufwand, den bestehenden Code zu ändern; aber dafür waren ja die Rückmeldungen da, um rauszufinden, was user denken, oder?).

Wie meinst das mit den default Werten? Die Werte müssen ja dahin wo das Attribut ist und das ist im Rolladen.

Hatte ich neulich schon geschrieben, versuche das mal etwas zu konkretisieren:Heute holst du vermutlich den Wert für den einzelnen Rolladen schlicht aus dem Attribut (AttrVal()).
Dafür ist es zwingend, dass jeder Rolläden die ganzen Attribute nicht nur optional erhält, sondern diese mit Werten gesetzt sind.

Mein Vorschlag wäre, eine Funktion einzubauen, die nach einer gewissen Priorität mehrere Speichermöglichkeiten absucht. Nennen wir sie "readShutterSetting($$)", die man mit dem Namen des Rolladen sowie dem (heutigen) Attributnamen füttert. Die Speichermöglichkeiten sollten dann nacheinander gelesen werden, und beim ersten Treffer, der nicht undef ist, den Inhalt zurückliefern. Also in folgender Priorität:
- AttrVal() am Rolladen
- Attrval() am AutosShutterControl-Device (das war der default, den ich meinte)
- zuletzt könnte man noch ein paar Defaults in ein Array mit "Attributname1 => "Defaultwert1, usw." packen, dann könnte man auf das Ausrollen der vielen Attribute verzichten (natürlich müssen die userattr an die Rolläden, aber man müßte erst mal keine Werte setzen).

Unausgedacht: Eventuell könnte man auch ReadingsVal() (mind. am Device?) _zusätzlich_ nutzen, aber da bin ich mir nicht so klar, ob das nicht des guten zu viel ist. Jedenfalls ergäbe das sehr flexible Möglichkeiten für versierte Nutzer, auch zur Laufzeit manches zu beeinflussen (den Einwand, dass du nicht in fremde Devices schreiben magst, habe ich wahrgenommen; hier wäre dann die Frage, ob man das Reading-Set pro Rolladen am zentralen Steuerungs-Device pflegen kann).

Hoffentlich habe ich das jetzt einigermaßen nachvollziehbar erklärt...

Und schreibt mal was zur generellen Betrieb. Wie ist es beim Fenster auf oder gekippt. Wie wenn Sonnenauf oder Untergang ist. Klappt bei Euch alles?

Auf und zu scheint zu klappen, auch abhängig vom Roommate-Status, ansonsten habe ich noch nicht alles ausprobiert. Aber du darfst sicher sein, dass du was hörst, wenn was nicht funktioniert ...
Gruß, Beta-User

[CoolTux]

Hätte vermutet, dass zwei AttrVal() Funktionen drin sind, um zwei Variablen zu füllen. Wenn es so wäre, wäre doch  ein split auf ein AttrVal fast dasselbe (mal abgesehen von dem einmaligen Aufwand, den bestehenden Code zu ändern; aber dafür waren ja die Rückmeldungen da, um rauszufinden, was user denken, oder?).

Ich kann es mir gerne noch mal anschauen.

Hatte ich neulich schon geschrieben, versuche das mal etwas zu konkretisieren:Heute holst du vermutlich den Wert für den einzelnen Rolladen schlicht aus dem Attribut (AttrVal()).
Dafür ist es zwingend, dass jeder Rolläden die ganzen Attribute nicht nur optional erhält, sondern diese mit Werten gesetzt sind.

Nein nicht zwingend. Wenn die Funktion AttrVal kein Attribut auslesen kann kommt als Rückgabe der beim Funktionsaufruf übergebene 3 Parameter als default zurück.

Mein Vorschlag wäre, eine Funktion einzubauen, die nach einer gewissen Priorität mehrere Speichermöglichkeiten absucht. Nennen wir sie "readShutterSetting($$)", die man mit dem Namen des Rolladen sowie dem (heutigen) Attributnamen füttert. Die Speichermöglichkeiten sollten dann nacheinander gelesen werden, und beim ersten Treffer, der nicht undef ist, den Inhalt zurückliefern. Also in folgender Priorität:
- AttrVal() am Rolladen
- Attrval() am AutosShutterControl-Device (das war der default, den ich meinte)
- zuletzt könnte man noch ein paar Defaults in ein Array mit "Attributname1 => "Defaultwert1, usw." packen, dann könnte man auf das Ausrollen der vielen Attribute verzichten (natürlich müssen die userattr an die Rolläden, aber man müßte erst mal keine Werte setzen).

Wir können das gerne für einen späteren Zeitpunkt festhalten. Das Abfragen wäre nicht die Sache, aber dann würden auch doppelte Attributnamen im Rollo und Moduldevice sein. Weil man entweder im Rollo sucht oder im Moduldevice.




Grüße

[Beta-User]

Nein nicht zwingend. Wenn die Funktion AttrVal kein Attribut auslesen kann kommt als Rückgabe der beim Funktionsaufruf übergebene 3 Parameter als default zurück.

Ah, daran hatte ich gar nicht mehr gedacht... jetzt wird mir aber klar, warum du den Hinweis auf "default" bisher für unsinnig gehalten haben mußt - auf diese Art die defaults über den ganzen Code zu verteilen, wäre natürlich Murks...

Ich kann es mir gerne noch mal anschauen.

Danke, ist aber wirklich nur eine Nebensache.

Wir können das gerne für einen späteren Zeitpunkt festhalten. Das Abfragen wäre nicht die Sache, aber dann würden auch doppelte Attributnamen im Rollo und Moduldevice sein. Weil man entweder im Rollo sucht oder im Moduldevice.

Ja, wobei man natürlich auch im Modul selbst ein anderes Präfix verwenden könnte, z.B. "default_Time_Up_Early" - wäre evtl. für die User einfacher zu durchschauen, und die Funktion könne man trotzdem generalisieren, weil man ja eigentlich nur den hinteren Teil ("Time_Up_Early") an die Funktion übergeben könnte und den Rest im Funktionscode ergänzen.

Und ja, muß nicht gleich sein, reicht auch später noch; bei diesem Punkt geht ja nicht um Funktionalität an sich, sondern Useability bzw. Einfachheit beim Einrichten (was mit der ReadingsGroup natürlich auch zu machen ist, aber je weniger man "drumrum" noch machen muß (nicht: kann), desto besser. .

Apropos ReadingsGroup: Muss es bei den Time-Angaben bei HH:MM:SS bleiben oder ginge auch HH:MM (ich hab's bisher nicht ausprobiert und auch den Code nicht untersucht). Schön wäre es, wenn das Modul (mittelfristig) beides nehmen würde (analog at).

Gruß, Beta-User

[CoolTux]

Apropos ReadingsGroup: Muss es bei den Time-Angaben bei HH:MM:SS bleiben oder ginge auch HH:MM (ich hab's bisher nicht ausprobiert und auch den Code nicht untersucht). Schön wäre es, wenn das Modul (mittelfristig) beides nehmen würde (analog at).

Gruß, Beta-User

Zeiten setzen sollte jetzt schon ohne Sekunde gehen. Muss ich mal testen.

[Beta-User]

Thx für die Info zu Zeiten, hab's eben getest: scheint zu funktionieren, DANKE!

ABER: Habe dazu das "set ... renew..." genutzt. Damit werden dann auch nachmittags die Timer für morgens gesetzt. Ist unschön, denn heute abend werden die Rolläden dann nicht fahren.
Wäre das auch bei einem Restart von FHEM so?

Einleuchtender fände ich es, wenn dann die aktuelle Soll-Position (aus dem letzten abgelaufenen Timer bzw. der Shading-Funktion) angefahren würde und zusätzlich (bzw. mind.) der nächste effektiv anstehende Timer gesetzt. Also Nachmittags dann die Schließ-Timer.



Habe eben noch etwas mit den Fensterkontakten gespielt; da ist mir manches nicht klar:

- Bei den in NOTIFYDEV genannten Fensterkontakten fehlen meine beiden den Jalousien zugeordneten Kontakte?
- Fährt man manuell zu, solange der FK open oder tilted meldet, passiert erstmal nichts.
OK, also verhindert das Modul nicht das manuelle Schließen. Verstanden, kommt dem WAF vermutlich sehr entgegen, Useraktionen haben Vorrang. Also: Wie ist das mit dem Aussperren an den Terrassentüren? Da ich die Terrassentür im Moment nicht prüfen kann (da ist eine Jalousie und der FK wird daher nicht überwacht), habe ich also das lock-out-Attribut bei einem der Fenster/Rolläden geändert auf "on". Scheint aber keine Auswirkung zu haben? Also Zustand open oder tilted iVm. Rolladen unten ist zulässig? Da stimmt m.E. was nicht (Kommt das von der "2-er" Logik, also 100=open?).

- Die Lüftungsposition wird bei threestates nur angefahren, wenn "tilted", oder? (Weiß noch nicht, ob ich das gut finde, oder die Option als Wunsch nennen, auch eine "offen"-Position anzugeben).

(- Überhaupt ist die Einrichterei der Fensterkontakte umständlich, aber das macht man ja auch nur ein Mal).

Wieder mal nur Eindrücke und spontane Gedanken .

[CoolTux]

Thx für die Info zu Zeiten, hab's eben getest: scheint zu funktionieren, DANKE!

ABER: Habe dazu das "set ... renew..." genutzt. Damit werden dann auch nachmittags die Timer für morgens gesetzt. Ist unschön, denn heute abend werden die Rolläden dann nicht fahren.
Wäre das auch bei einem Restart von FHEM so?

Einleuchtender fände ich es, wenn dann die aktuelle Soll-Position (aus dem letzten abgelaufenen Timer bzw. der Shading-Funktion) angefahren würde und zusätzlich (bzw. mind.) der nächste effektiv anstehende Timer gesetzt. Also Nachmittags dann die Schließ-Timer.



Habe eben noch etwas mit den Fensterkontakten gespielt; da ist mir manches nicht klar:

- Bei den in NOTIFYDEV genannten Fensterkontakten fehlen meine beiden den Jalousien zugeordneten Kontakte?
- Fährt man manuell zu, solange der FK open oder tilted meldet, passiert erstmal nichts.
OK, also verhindert das Modul nicht das manuelle Schließen. Verstanden, kommt dem WAF vermutlich sehr entgegen, Useraktionen haben Vorrang. Also: Wie ist das mit dem Aussperren an den Terrassentüren? Da ich die Terrassentür im Moment nicht prüfen kann (da ist eine Jalousie und der FK wird daher nicht überwacht), habe ich also das lock-out-Attribut bei einem der Fenster/Rolläden geändert auf "on". Scheint aber keine Auswirkung zu haben? Also Zustand open oder tilted iVm. Rolladen unten ist zulässig? Da stimmt m.E. was nicht (Kommt das von der "2-er" Logik, also 100=open?).

- Die Lüftungsposition wird bei threestates nur angefahren, wenn "tilted", oder? (Weiß noch nicht, ob ich das gut finde, oder die Option als Wunsch nennen, auch eine "offen"-Position anzugeben).

(- Überhaupt ist die Einrichterei der Fensterkontakte umständlich, aber das macht man ja auch nur ein Mal).

Wieder mal nur Eindrücke und spontane Gedanken .

Gerade unterwegs daher kurz.
Sind die Jalousien mit im Moduldevice und und die Fenster nicht im NOTIFYDEV dann bitte einmal die Fensterdevice Attribute löschen und neu anlegen.

[CoolTux]

- Fährt man manuell zu, solange der FK open oder tilted meldet, passiert erstmal nichts.
OK, also verhindert das Modul nicht das manuelle Schließen. Verstanden, kommt dem WAF vermutlich sehr entgegen, Useraktionen haben Vorrang. Also: Wie ist das mit dem Aussperren an den Terrassentüren? Da ich die Terrassentür im Moment nicht prüfen kann (da ist eine Jalousie und der FK wird daher nicht überwacht), habe ich also das lock-out-Attribut bei einem der Fenster/Rolläden geändert auf "on". Scheint aber keine Auswirkung zu haben? Also Zustand open oder tilted iVm. Rolladen unten ist zulässig? Da stimmt m.E. was nicht (Kommt das von der "2-er" Logik, also 100=open?).

Ein manuelles fahren wird derzeit nicht verhindert. Lediglich Fahrbefehle welche über das Modul kommen richten sich nach dem Fensterkontakt.
Und natürlich wenn das Rollo unterhalb von Lüften Wert steht fährt das Modul beim kippen oder öffnen (twostate) das Rollo auf Lüften und schließt es beim schlieen wieder sofern immer noch die Lüftenposition vorhanden ist.

- Die Lüftungsposition wird bei threestates nur angefahren, wenn "tilted", oder? (Weiß noch nicht, ob ich das gut finde, oder die Option als Wunsch nennen, auch eine "offen"-Position anzugeben).

ja genau. Macht sonst kein Sinn denke ich.



Grüße

[CoolTux]

Man kann wohl einige Rolladenaktoren Hardwaremäßig sperren.
set DEVICE inhibit on

oder

set DEVICE blocked

Kann mir jemand verraten ob es dazu auch Readings gibt. Finde dazu nichts.
Dann baue ich das so das wenn AutoShuttersControl_lock-out auf yes gesetzt ist ich das blockiere