[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.6.x

[Loredo]

Kommt denn was bei Debug Ausgaben?

"Glücklicherweise" lasse ich derzeit ca. 50 MB Logfiles pro Tag für ASC schreiben - ja da wird was dabei sein. Hab ich dir per Slack geschickt.
Ich selbst blicke da nicht wirklich durch, was da wie geloggt wird.

[no_Legend]

Ich habe wieder etwas gebaut

Ich muss ehrlich gestehen, dass ich nicht mehr in der Lage bin dem Thread zu folgen.
Man muss immer alles mitverfolgen um überhaupt die chance zu haben zu verstehen was gerade passiert.
Die Entwicklung ist echt rasant, so kann bei manchen neuen Funktionen nicht mal beim testing helfen.

Gruß Robert


Gesendet von iPhone mit Tapatalk Pro

[Loredo]

Ich habe wieder etwas gebaut

Hm. Mir gefällt es irgendwie nicht, dass in ASC so viele Dinge drin sind, die man aber auch in anderen Steuerungen braucht. Ich finde es nicht so gut, dass ASC das hier so autark macht, daher ja mein Vorschlag da nochmal die Köpfe in Sachen HOMESTATE und vor allem ROOMSTATE zusammenzustecken.

[eurofinder]

@CoolTux:
Das sieht vielversprechend aus. Jetzt fhelt mir vorerst nur noch eine Lösung zum "Range-Problem", aber das bist du ja auch schon gedanklich dran:-)

Mal eine ganz andere Frage. Es existiert zwar beim Shading die Möglichkeit über einen Außentemperatursensor die Temperatur zu berücksichtigen; mir würde es aber viel mehr helfen, wenn ich pro Rollladen alternativ einen Innentemperatursensor mit zu berücksichtigender Temperatur einbinden könnte - z.B. in der Form ASC_Shading_Min_InsideTemperature= Devicename:Reading 25.
Gerade unter dem Dach heizen sich die Räume (je nach Ausrichtung zur Sonne) sehr unterschiedlich auf.

Würde mich freuen, wenn das berücksichtigt werden könnte.

Gruß
eurofinder

[CoolTux]

Hm. Mir gefällt es irgendwie nicht, dass in ASC so viele Dinge drin sind, die man aber auch in anderen Steuerungen braucht. Ich finde es nicht so gut, dass ASC das hier so autark macht, daher ja mein Vorschlag da nochmal die Köpfe in Sachen HOMESTATE und vor allem ROOMSTATE zusammenzustecken.

Wieso in anderen Steuerungen. Geht doch nur darum das man nun entweder ASC komplett disablen kann oder halt nur einzelne Rolllos aus der Steuerung rausnehmen kann. Und zwar per set Befehl. Jetzt kann man dann flexibler die Steuerung für einige Zeit deaktivieren.
Wo wäre da ein Zusammenhang zu HOMESTATE oder ROOMSTATE? Oder anders kann HOMESTATE oder ROOMSTATE nicht einfach dann die set Befehle aus führen? Es wäre ja quasi wie eine API zum aktivieren/deaktivieren.

[Beta-User]

Hm. Mir gefällt es irgendwie nicht, dass in ASC so viele Dinge drin sind, die man aber auch in anderen Steuerungen braucht. Ich finde es nicht so gut, dass ASC das hier so autark macht, daher ja mein Vorschlag da nochmal die Köpfe in Sachen HOMESTATE und vor allem ROOMSTATE zusammenzustecken.

Grundsätzlich finde ich das einen guten Gedanken, die Dinge mehr oder weniger automatisiert "auf dem gleichen Stand zu halten", aber:

Bitte berücksichtigt ggf. auch, dass es Leute gibt, die das nicht nutzen; da sollte es trotzdem auch funktionieren.

[OT]
Wenn man das (oder Teile von ASC) dann ggf. von den anderen Modulen abhängig macht: Jedenfalls mir fehlt noch ein richtiger gedanklicher Einstieg in das ganze Thema, das ist (gefühlt) ein ähnlich unüberschaubares Thema wie ASC in der Vollversion.
Vielleicht habe ich nur den richtigen Teil der Doku nicht gefunden, aber an sich sollte es - ähnlich wie es bei ASC jetzt ist - recht einfach sein, erst mal ein paar wenige Basiseinstellungen zu machen, und das dann bei Bedarf/Wunsch auszubauen.
Frage daher: Gibt es einen ähnlichen "Einrichtungsleitfaden" wie bei ASC (wo es leider schon wieder veraltet ist)?
Wir können das gerne dann woander weiter diskutieren...
[/OT]


@Cooltux:
Das Thema von eurofinder hast du noch auf dem Zettel, oder?
(Fände ich nach wie vor gut!)

[CoolTux]

@Cooltux:
Das Thema von eurofinder hast du noch auf dem Zettel, oder?
(Fände ich nach wie vor gut!)

Du meinst die Toleranz Sache bezügich Position des Rolllos? Ja die habe ich noch auf dem Schirm.

[Beta-User]

Du meinst die Toleranz Sache bezügich Position des Rolllos? Ja die habe ich noch auf dem Schirm.

Auch gut, aber ich meinte das Beschatten abhängig von der jeweiligen INNEN-Temperatur .

[CoolTux]

Auch gut, aber ich meinte das Beschatten abhängig von der jeweiligen INNEN-Temperatur .

Ah, nee das hatte ich nicht mehr auf den Schirm. Als Ersatz für Brightness oder als Zusatz?

[Beta-User]

Ah, nee das hatte ich nicht mehr auf den Schirm. Als Ersatz für Brightness oder als Zusatz?

Boahhh, das ist so eine Frage...

Also bezogen auf meine Gedankenwelt: Ich nutze ausschließlich Astro, und die Beschattung soll dann auch Außentemperatur-gesteuert ausgelegt werden. Da würde ich gerne mit den grundsätzlichen Schwellentemperaturen "weiter runter", wegen der großen Südfenster + Sonnenertrag. Aber ab einer gewissen Innentemperatur wäre dann eben doch Beschattung angesagt. Brightness interessiert mich dabei vermutlich nie.

Hoffe, das ist verständlich erläutert, aber ggf. sehen das Brightness-Fans anders.

(Loredo hatte neulich einen guten Satz dazu geschrieben: Es macht evtl. Sinn, erst mal nur einen Zweig vollends "durchzuchecken" und dann andere nachzuziehen. Man sollte dabei nur beachten, dass es andere Varianten/Denkweisen geben kann, die dann noch möglich sein sollten; ihr könnt auch gerne mit dem Brightness-Zweig beginnen...).

[eurofinder]

@CoolTux:

Du meinst die Toleranz Sache bezügich Position des Rolllos? Ja die habe ich noch auf dem Schirm.

Ja, die meinte ich.

Ah, nee das hatte ich nicht mehr auf den Schirm. Als Ersatz für Brightness oder als Zusatz?

Meine Anforderung wäre zusätzlich zur jetzigen Implementierung von Brightness, wobei ich mir noch nicht ganz sicher bin, wie dann die Bedingungen aussehen müssten:-)

Gruß
eurofinder

[CoolTux]

@CoolTux:Ja, die meinte ich.
Meine Anforderung wäre zusätzlich zur jetzigen Implementierung von Brightness, wobei ich mir noch nicht ganz sicher bin, wie dann die Bedingungen aussehen müssten:-)

Gruß
eurofinder

Ja da sehe ich auch noch eine Herausforderung.

[volschin]

Bedeutet was genau?
Bei der Beschattung wird immer gefahren mit einer Ausnahme, das Fenster ist eine Terrassentür und sie ist offen (open)

Ist nur blöd, wenn das Rollo ein Innenrollo ist, das knallt dann auf das geöffnete Fenster und verheddert sich. Wir brauchen also doch mehr Typen, wie hier bereits jemand festgestellt hatte.

Um es nochmal konkreter zu machen, das Rollo darf dann nur zur Comfort Open Position fahren. Ich habe nämlich mehrflügelige Altbaufenster und die Oberlichter dürften gern beschattet werden.

Weiterhin inkonsistent: ein shading out findet anschließend nicht statt, anscheinend, da das Fenster ja offen ist. [emoji848]

[CoolTux]

Ist nur blöd, wenn das Rollo ein Innenrollo ist, das knallt dann auf das geöffnete Fenster und verheddert sich. Wir brauchen also doch mehr Typen, wie hier bereits jemand festgestellt hatte.

Um es nochmal konkreter zu machen, das Rollo darf dann nur zur Comfort Open Position fahren. Ich habe nämlich mehrflügelige Altbaufenster und die Oberlichter dürften gern beschattet werden.

Weiterhin inkonsistent: ein shading out findet anschließend nicht statt, anscheinend, da das Fenster ja offen ist. [emoji848]

So viele Typen können wir gar nicht unterscheiden. Ich habe nämlich auch Innenrollos die aber am Fenster Fran sind.
Wie sieht es bei Dir aus, wenn Dein Fenster geklappt ist darf auch nicht gefahren werden? Wenn doch kannst ja einfach als Terrassentür zu ordnen.
Ich kann mir aber mal Gedanken machen wegen Innen und Aussenrollo. Wüsste aber nicht was man da beachten muss. Ich habe zum Beispiel gar keine Fensterbeachtung drin bei mir.

[Loredo]

Wieso in anderen Steuerungen. Geht doch nur darum das man nun entweder ASC komplett disablen kann oder halt nur einzelne Rolllos aus der Steuerung rausnehmen kann. Und zwar per set Befehl. Jetzt kann man dann flexibler die Steuerung für einige Zeit deaktivieren.
Wo wäre da ein Zusammenhang zu HOMESTATE oder ROOMSTATE? Oder anders kann HOMESTATE oder ROOMSTATE nicht einfach dann die set Befehle aus führen? Es wäre ja quasi wie eine API zum aktivieren/deaktivieren.

Es geht darum, dass ASC überhaupt keine Ahnung von physischen Räumen hat und es auch keinen Sinn macht ASC dahingehend zu erweitern.


Diese Information über einen Raum und dessen Status (=ROOMSTATE) braucht man auch für andere Automationen. Daraus leitet sich dann ab, dass man für den Gesamtstatus ebenfalls einen HOMESTATE benötigt, bei dem die Status hochaggregiert werden oder global definiert sind.


Beispiel 1:
Ich möchte die Beschattung nur in einem bestimmten Raum abschalten, nicht aber überall. Dafür möchte ich nicht in jedes Rollo des Raums gehen, sondern sagen "Raum, keine Beschattung - du weißt schon welche Rollos gemeint sind". Das gleiche für Zonen (=ZONESTATE) bzw. Stockwerke.


Beispiel 2:
Ich möchte aufgrund des Schwellenwertes für das Tageslicht weitere Steuerungen unternehmen, diesen Schwellenwert und den Sensor dafür jedoch genau ein einziges Mal definieren. ASC denkt nur für Rollos, aber eine Beleuchtung oder Sicherheitsschaltung hängt von ähnlichen Faktoren ab. Deshalb macht in meinen Augen der generelle Status "jetzt beleuchten" oder "jetzt beschatten" oder "jetzt absichern" in einem separaten Device für den physischen Raum mehr Sinn. Wenn ASC das alleine macht und man für den Rest wieder separate Module und Quellen hat, dann ist die Gefahr von inkonsistentem Verhalten zwischen den verschiedenen Gewerken Licht, Beschattung, Anwesenheit, etc. viel größer.