[73_AutoShuttersControl.pm] Jalousie Lamellen Steuerung - Ideensammlung

[CoolTux]

Je mehr Leute hier beschreiben wir ihre "Lamellen Funktion" geht um so mehr komme ich an den Punkt nicht zu wissen wie ich sowas umsetzen soll im aktuellen kompletten Code 

[gestein]

Mein Problem ist ja, dass ich - wenn jemand Zuhause ist - die Beschattung auf 100% (oder etwas weniger, weil 100% ja reserviert ist, also z.B. 91%).
Wenn alle außer Haus sind (Residents-Device merkt das) dann sollen nach einiger Zeit die Rollos auf 200% (199% wären auch ok) fahren.

Wenn aber jemand nach Hause kommt, sollten in relativ kurzer Zeit die Rollos wieder auf 91% gehen.
Ansonsten steht man komplett im Dunkeln.

lg, Gerhard

[CoolTux]

Mein Problem ist ja, dass ich - wenn jemand Zuhause ist - die Beschattung auf 100% (oder etwas weniger, weil 100% ja reserviert ist, also z.B. 91%).
Wenn alle außer Haus sind (Residents-Device merkt das) dann sollen nach einiger Zeit die Rollos auf 200% (199% wären auch ok) fahren.

Wenn aber jemand nach Hause kommt, sollten in relativ kurzer Zeit die Rollos wieder auf 91% gehen.
Ansonsten steht man komplett im Dunkeln.

lg, Gerhard

Das kannst Du mittels Perlcode machen. Das sollte meiner Meinung nach gehen.
Wenn nicht. Mach mal bitte einen eigenen Thread zum Thema hier im Board Automatisierung auf.

[Beta-User]

@derstinker:
Gibt es auch die Option, beides getrennt zu setzen, oder ist der gemeinsame Fahrbefehl ein "muß"?


@daelch:
Da ist nach meinem Eindruck bereits sehr viel "customizing" drin. Mein Bauchgefühl sagt mir, dass wir möglichst auf zu viel customizing verzichten sollten, sondern lieber, möglichst mit den Basisfunktionen das passende Ergebnis hinzubekommen. Erfahrungsgemäß ist es umso weniger "rückfrageanfällig", je mehr ASC "von sich aus" weiß (=> z.B. aus dem TYPE ableitet) und je weniger der user sich um die Konfiguration kümmern muß. Gerade bei vergleichsweise verbreiteten Typen wie HMCCUDEV sollte ASC "wissen", was zu tun ist.


@CoolTux
Früher war es so, dass alle Fahrbefehle durch eine zentrale Routine gegangen sind. Wenn das noch so ist (_SetCmdFn ?):

Entweder dort eine Unterscheidung einbauen, ob es ein "normaler" Rollladen ist, oder was, das auch Lamellen drehen soll. Dann könnte man zumindest eine "einfache" Variante bauen, die einem bestimmten Zielwert eine Drehung zuordnet. Ginge mit einem einfachen target-pos=>lamella-value-hash (zu entnehmen aus einem Attribut, das zugleich die Unterscheidung markiert), und das sollte man als Minimum m.E. immer einbauen.

Dazu würde nur die weitere Angabe benötigt, welcher weitere set-Befehl erforderlich ist (device+reading), _wenn_ alle Varianten zwei getrennte Befehle akzeptieren, ob das gewollt ist, kann man leicht ablesen, wenn es einen Treffer im hash gibt.

Oder (besser: Und):
Der Aufruf findet sich an 4 Stellen. Was spricht dagegen, %h ggf. um ein Element zu erweitern, um den Fahranlass mitzugeben?
Dann kann der User statt/zusätzlich zu den Zahlenwerten Anlaß=<lamella-value>-Paare angeben. Logik wäre dann: gibt es einen solchen Treffer, diesen verwenden, dann hilfsweise nachsehen, ob es einen Zahlentreffer gibt.

That's all...

(Du hast den Code ja schön modular gebaut ).

[CoolTux]

@derstinker:
Gibt es auch die Option, beides getrennt zu setzen, oder ist der gemeinsame Fahrbefehl ein "muß"?


@daelch:
Da ist nach meinem Eindruck bereits sehr viel "customizing" drin. Mein Bauchgefühl sagt mir, dass wir möglichst auf zu viel customizing verzichten sollten, sondern lieber, möglichst mit den Basisfunktionen das passende Ergebnis hinzubekommen. Erfahrungsgemäß ist es umso weniger "rückfrageanfällig", je mehr ASC "von sich aus" weiß (=> z.B. aus dem TYPE ableitet) und je weniger der user sich um die Konfiguration kümmern muß. Gerade bei vergleichsweise verbreiteten Typen wie HMCCUDEV sollte ASC "wissen", was zu tun ist.


@CoolTux
Früher war es so, dass alle Fahrbefehle durch eine zentrale Routine gegangen sind. Wenn das noch so ist (_SetCmdFn ?):

Entweder dort eine Unterscheidung einbauen, ob es ein "normaler" Rollladen ist, oder was, das auch Lamellen drehen soll. Dann könnte man zumindest eine "einfache" Variante bauen, die einem bestimmten Zielwert eine Drehung zuordnet. Ginge mit einem einfachen target-pos=>lamella-value-hash (zu entnehmen aus einem Attribut, das zugleich die Unterscheidung markiert), und das sollte man als Minimum m.E. immer einbauen.

Dazu würde nur die weitere Angabe benötigt, welcher weitere set-Befehl erforderlich ist (device+reading), _wenn_ alle Varianten zwei getrennte Befehle akzeptieren, ob das gewollt ist, kann man leicht ablesen, wenn es einen Treffer im hash gibt.

Oder (besser: Und):
Der Aufruf findet sich an 4 Stellen. Was spricht dagegen, %h ggf. um ein Element zu erweitern, um den Fahranlass mitzugeben?
Dann kann der User statt/zusätzlich zu den Zahlenwerten Anlaß=<lamella-value>-Paare angeben. Logik wäre dann: gibt es einen solchen Treffer, diesen verwenden, dann hilfsweise nachsehen, ob es einen Zahlentreffer gibt.

That's all...

(Du hast den Code ja schön modular gebaut ).

Ich danke Dir für Deine Ansicht. Ich denke ich muss einfach nur mal Ruhe finden (mir selber geben) um das ganze in einer richtigen Übersicht zu sehen.
Thema "anderer Blickwinkel"


Danke



Grüße

[derstinker]

@derstinker:
Gibt es auch die Option, beides getrennt zu setzen, oder ist der gemeinsame Fahrbefehl ein "muß"?

Nein, geht auch einzeln und ist kein muss. So habe ich es auch bisher genutzt für hoch/runter über ASC, Lammelen hab ich dann händisch nach geregelt. bzw. über szenen.

set dim / setClosure: hoch/runter
setOrientation: Orientierung

100 unten / geschlossen

[Beta-User]

  Dann ginge das wohl auch mit "meinem" Vorschlag, und auch die bisherige Vorgehensweise scheint recht nah an dem zu sein.

Ich denke ich muss einfach nur mal Ruhe finden (mir selber geben) um das ganze in einer richtigen Übersicht zu sehen.
Thema "anderer Blickwinkel"

Klar, take your time!

Vielleicht noch einen Nachtrag zu den dusseligen "normalen" CUL_HM-HM (HM-LC-BL1PBU-FM): Da hatte ich zu meiner Anfangszeit mal ein notify für gebastelt, das dann bei Erreichen von bestimmten Zielpositionen (z.B. 99.5, 55.5) reagiert hat und dann (erforderlichenfalls) eine Fahrt in die Gegenrichtung veranlaßt hat. Sowas wäre wohl indirekt möglich, wenn man eine User-Funktion aufrufen könnte, die dann aber in diesem Fall "exklusiv" wäre und sich um alles beide kümmern müßte, dafür aber einen vollen Parametersatz bekommt.

Beispiel:
Es soll auf 50% Beschattung gefahren werden, Lamellen sollen 30% geöffnet sein.

Funktion bekommt folgende Info, "50%", "Beschattung", "30%".

ASC tut dann gar nichts mehr, es erwartet schlicht, dass das Teil am Ende auf 50% steht.

Kommt man jetzt von oben, muß die Funktion selbst sicherstellen, dass das passiert.
Sie kann ermitteln, wo die Jalousie jetzt steht (hier z.B. oben).

Kommt man von oben, muß man ermitteln, wie weit man (in pct...) wieder hochfahren muß, um in etwa die 30% zu bekommen (ausgehend von 100%, da wir nach unten fahren). Das ist in meinem Fall ca. 1%.

Ergo: verändere ich via Funktion den Fahrbefehl auf 49% (da 0% = geschlossen), warte (z.b. mit einem einmaligen at, oder mit zwei "eigenen" Readings an einem generalisierten notify) darauf, dass diese Position angefahren ist, und setze dann aus dem at bzw. notify heraus die Gegenbewegung in Gang, indem 50% als Folgeanweisung gefeuert werden.

Könnte man vermutlich auch innerhalb ASC machen, ist aber sehr kompliziert.

[daelch]

Kommt man von oben, muß man ermitteln, wie weit man (in pct...) wieder hochfahren muß, um in etwa die 30% zu bekommen (ausgehend von 100%, da wir nach unten fahren). Das ist in meinem Fall ca. 1%.

Ich fürchte das wird bei vielen nicht funktionieren und zwar dann, wenn man unterschiedlich lange Jalousien im Haus hat. Bestes Beispiel Terrassentür und Fenster.
Wenn bei geschlossenen Behang die Lamellen um sagen wir 50% hochklappen (mit dem dafür vorgesehen Befehl des Aktors), steht bei der Terrassentür ein pct von 1% und beim Fenster 2%.
Als Workaround für einen Nicht-Jalousieaktor mag das sicher eine clevere Lösung sein. Für einen Jalousieaktor wird es dann für den User mühsam, wenn er für jede Jalousielänge erstmal den richtigen pct-Wert ermitteln muss.

Viele Grüße

[Beta-User]

Sorry, doppeltes Mißverständnis:

1. Echte Jalousieaktoren sollten direkt "abgefackelt" werden können. Das war Gegenstand meines Vorschlags hier https://forum.fhem.de/index.php/topic,109424.msg1035283.html#msg1035283 bzw. hier: https://forum.fhem.de/index.php/topic,109424.msg1034220.html#msg1034220.
Also: Ein Attribut (Name z.B. "ASC_VenetianSettings"), darin sagt man z.B. "Shading=30 100=100 0=0". That's all.
Dann weiß ASC: Aha, das ist eine Jalousie, denn das Attribut ist gesetzt. Wenn ich auf Beschattung fahren soll, soll der Drehwinkel 30% sein, schließe ich (pct 0), dann sollen auch die Lamellen auf 0 fahren (bei einem CUL_HM mit dem Jal-Aktor sollte dann klar sein, dass Zielaktor der 2. Anweisung dasselbe FHEM-Gerät ist und der Drehbefehl sich auf slatLevel (?) bezieht, denn das ist bei diesem subType immer so...).
Für meinen ZWave-Aktor dann erweitert auf: "Shading=30 99=99 0=0 DEVICE=ZWave_SWITCH_MULTILEVEL_8.02 READING=dim".
Auch damit wüßte ASC, wohin welcher zusätzliche Befehl soll.

2. Nur solche "Krücken" wie die "falschen" CUL_HM-Bl-Teile würde man ggf. mit einem Perl-AddOn aus meinem letzten Post hier versuchen können zu bändigen. Das könnte dann so aussehen:

Code Auswählen Erweitern

attr DEVICE ASC_VenetianSettings PERL=myVeryFancySlatsCode()
Das könnte dann ein eval auf

Code Auswählen Erweitern

myVeryFancySlatsCode($name,$targetPos,$reason) aufrufen, womit der Job aus ASC-Sicht getan wäre.
myVeryFancySlatsCode() dann mit Leben zu füllen wäre Aufgabe des einzelnen Users, der dann aber auch die Kontrolle über die Position übernehmen müßte...
Da kann man dann auch berücksichtigen, welche Jalousie ggf. wie schnell dreht usw.. Aber das ist und bleibt eine Krücke - aber eben besser wie nichts...

[daelch]

Danke für die ausführliche Erklärung. Ja, so ergibt es durchaus Sinn. Sorry, da hatte ich Dich missverstanden.