[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

[CoolTux]

Ä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!)

Liegt an meiner Denkweise min:max und das min ja für Abends ist. Aber da wir ja eh da in Sonnenauf und Untergang denken wollen hast Du Recht.

[Beta-User]

Mahlzeit!

Nachdem ich grade ein wenig zum Thema objektorientierte Programmierung hier rumgelesen habe: http://learnperl.scratchcomputing.com/tutorials/objects/, versuche ich zu verstehen, welche Schlüsse ich daraus in Bezug auf eine mögliche zukünftige Datenstruktur ziehen soll, die für ASC zukünftig evtl. Sinn macht.
Vorläufige Idee: Neben dem ASC-Zentraldevice (Master) dann zukünftig nicht alles an den Rollläden verwalten, sondern für jeden ein entsprechendes Client-Device bauen?

Dann wären wir flexibler, was das Ausrollen von notwendigen neuen/geänderten Attributen angeht, die Anzeige von Internals, den Rückgriff auf defaults usw.... Das wäre vermutlich viel transparenter für die User, wie wenn wir irgendeine interne Unterstruktur unterhalb eines Einheits-ASC-Devices basteln würden. Attribute wären nur sichtbar, wenn gesetzt, es gäbe (als Möglichkeit) eigene Setter für jeden Teil der Logik an jedem Rolladen und wir könnten fast 1:1 direkt auf die vorhandene Logik "lies dieses oder jenes Attribut" aus der heutigen ASC-Logik aufbauen.

Du hast ja schon einige Erfahrung mit objektorientiertem Programmieren unter Perl, ich kenne das etwas von MySensors her (habe dabei aber eher ein vermutlich lückenhaftes intuitives Verständnis dazu entwickelt). Daher die Frage: Wäre das ein praktikabler Ansatz?

Ansonsten: hast du gesehen, dass Leute jetzt plötzlich Interesse an "Samstagen" haben...?!?
Es ist wie verhext: Kaum denkt man etwas halblaut, gibt's jemanden, der es hört, selbst wenn er Meilen entfernt ist

[CoolTux]

Du meinst so eine Art Channel-Device wir bei HM? Ich weiß nicht. Dann haben wir ja wieder doppelte Devices. Also einmal das original Rolllodevice und ein Abbild als Channeldevice vom ASC Device.

[Beta-User]

Der Vergleich mit einem Chanel-Device paßt ganz gut, ich hatte ursprünglich ROLLO im Hinterkopf, aber das mit dem HM-Channel trifft es deutlich besser.

Letztlich ist halt die Frage, wie wir eine halbwegs transparente und effektive Struktur hinbekommen, die an den richtigen Stellen für Nutzereingriffe offen ist, ohne einen gleich zu erschlagen.
Im Moment würde ich eher dazu neigen, dass eine "Doppelung" der Devices mit einem zusätzlichen  ASC-Kanal das "kleinere" Übel ist; aber ich bin da auch nur Anfänger und wollte das einfach mal angesprochen haben; vielleicht kann/will da auch jemand was zu sagen, der da mehr Erfahrung hat? Das eilt ja alles nicht, man sollte es dieses Mal nur "richtig" anpacken, auch wenn es immer viele Wege gibt, "irgendwas" umzusetzen...

Aber der Gedanke, jeweils _einen_ ASC-Kanal pro Rollladen zu haben, klingt schon allein deswegen nicht schlecht, weil ich bei den HM-Devices schon jetzt erst mal lange scrollen muß, bis ich bei den Einstell-Optionen für ASC bin . Und das einzige, was wirklich doppelt wäre, wäre ggf. der derzeitige pct-Stand, alles andere ist sowieso entweder im HM-Hauptdevice oder ASC-spezifisch...

Dafür könnten wir z.B ein Internal halten für die Anzahl der blockierenden Infos (wind, Anwesenheit, Fensterkontakt offen, manual ....) und bei der Ausgabe von Infos das leichter zusammenformatieren.

[CoolTux]

Mmmhhh klingt interessant. Also das mit den __ASC__ Kanal pro Rollladen. Müsste man sich mal anschauen wie man das am besten um setzt.

Aber ich schlage vor wir machen erstmal die derzeitige Entwicklerversion fertig und dann schauen wir einmal.

[Beta-User]

Aber ich schlage vor wir machen erstmal die derzeitige Entwicklerversion fertig und dann schauen wir einmal.

Da bin ich völlig bei dir!

Mmmhhh klingt interessant. Also das mit den __ASC__ Kanal pro Rollladen. Müsste man sich mal anschauen wie man das am besten um setzt.

Vorläufige Idee:

Code Auswählen Erweitern

define <name> ASC masterdefine <name> ASC <Name Rollladendevice> <Rollladentyp>
Beim Schlüsselwort "master" prüfen wir, ob wir "alleine" sind (es darf keinen zweiten geben), die andere Variante würde das "Kanal-Device" definieren. Der Rollladen würde dann nicht mehr über das globale ASC-Attribut identifiziert, sondern samt der "Grundrichtung" mit in der Definition stehen. Das einzige, was man dann noch direkt am Rollladendevice machen würde: das associatedWith-Reading setzen bzw. erweitern.
Man könnte auch am Master ein "set" vorsehen, in dem man indirekt das define aufruft ("set ASC addShutter <Name Rollladendevice> <Rollladentyp>", das wäre vermutlich für den User intuitiver.


[OT]
Zur Info: in der aktuellen 10_MYSENSORS_DEVICE.pm sind 410 Treffer für "->" drin, die 00_MYSENSORS.pm hat nochmals 151 hits und in die restlichen zugehörigen pm's habe ich nicht mehr geschaut . ASC ist damit scheinbar nicht der Vorreiter, was objektoritentierte Programmierung bei FHEM-Modulen angeht, und vermutlich sind die alten MQTT-pm's ähnlich, die stammen nämlich ursprünglich vom gleichen Autor.
[/OT]

[CoolTux]

[OT]
Zur Info: in der aktuellen 10_MYSENSORS_DEVICE.pm sind 410 Treffer für "->" drin, die 00_MYSENSORS.pm hat nochmals 151 hits und in die restlichen zugehörigen pm's habe ich nicht mehr geschaut . ASC ist damit scheinbar nicht der Vorreiter, was objektoritentierte Programmierung bei FHEM-Modulen angeht, und vermutlich sind die alten MQTT-pm's ähnlich, die stammen nämlich ursprünglich vom gleichen Autor.
[/OT]

Ich habe jetzt nicht wirklich geschaut. Aber -> ist ja in erster Linie eine Referenz auf irgendwas. Das kann ein Objekt sein, dann muß es entsprechend erstellt worden sein. Oder aber auch eine Referenz auf ein Hash, Scalar, Array was auch immer.

Ob eine Objekt verwendet wird erkennst Du am new, in den meisten Fällen dient dies zur Erstellung eines neuen Objektes. 


Grüße

[Beta-User]

...dann war der Einwand unberechtigt, jedenfalls in der 10_...er. Oder der "new"-Befehl heißt halt anders.
Scheinen dort eher "normale" Referenzierungen zu sein. Ist aber auch OT...

[CoolTux]

Ich habe soeben eine neue Version hoch geladen.
Ich habe mir eine komplette Entwicklerumgebung mit aktuellem FHEM und configDB Konfiguration eingerichtet.
Ich habe damit den wechsel von der derzeitig ausgerollten stabilen Version auf die aktuelle Entwicklerversion mit allen geänderten Einstellungen getestet. Es wurden bei mir alle Werte korrekt übernommen und in die neuen Attribute gesetzt.

[Beta-User]

Moin,

habe eben die 0.4.0.11beta37 eingespielt und auf die Schnelle keine Probleme bemerken können.

Hast du das mit dem wind-Attribut schon umgestellt auf default aus dem Rollladentyp? Sonst würde ich erst mal die "Vollversion" drin lassen (mit Ziellevel)...

[CoolTux]

Ich habe das so umgestellt das er per default die open Position des Shutters nimmt.

[Beta-User]

Danke für die Rückmeldung, dann werde ich das an den Jalousien mal entsprechend ändern auf nur eine Angabe.
Für die "offen=weniger offen als maximal-offen"-Rollläden ist wind eh' nicht das Thema. Geschrieben und festgestellt: Falscher Ansatz... Wenn halboffen, ist das ab gewissen (hohen) Geschwindigkeiten durchaus ein Thema, das aber im Moment nicht so eilt. Ergo: alle Rollläden bekommen den Windschutz, aber eben mit unterschiedlichen Geschwindigkeiten und die "speziellen" bekommen eben eine spezielle Einstellung .

DANKE!

[CoolTux]

Danke für die Rückmeldung, dann werde ich das an den Jalousien mal entsprechend ändern auf nur eine Angabe.
Für die "offen=weniger offen als maximal-offen"-Rollläden ist wind eh' nicht das Thema. Geschrieben und festgestellt: Falscher Ansatz... Wenn halboffen, ist das ab gewissen (hohen) Geschwindigkeiten durchaus ein Thema, das aber im Moment nicht so eilt. Ergo: alle Rollläden bekommen den Windschutz, aber eben mit unterschiedlichen Geschwindigkeiten und die "speziellen" bekommen eben eine spezielle Einstellung .

DANKE!

Meintest Du jetzt damit das man Rolläden aus der Windroutine ausschließen kann?
Das wollte ich glaube noch einbauen, stimmt's 

[Beta-User]

Meintest Du jetzt damit das man Rolläden aus der Windroutine ausschließen kann?
Das wollte ich glaube noch einbauen, stimmt's 

Ausschließen geht doch mit "-1", oder?

Nee, mir ging es um meine Sichtuschutz-Rollläden im Schlafzimmer, die eine open-Position festgelegt haben, die deutlich unter dem maximal möglichen Öffnungsgrad liegt. => m.E. no action required

[CoolTux]

Ach stimmt auch wieder. Hatte ja -1 gesetzt. Denke ich zu mindestens. Lach. Ich schaue nachher lieber noch mal.

Gestern und Vorgestern klappte das Beschatten und Endschatten super bei mir.