Hallo zusammen,
die aktuelle ASC Version kann noch keine Lamellenansteuerung. Dementsprechend habe ich folgendes Workaround getestet, um auch Lamellen steuerbar zu machen:
1.) Für jede Jalousie lege ich einen zusätzlichen Rolladendummy an. Diesen Rolladendummy setze ich auf attr ASC 2. Die richtigen Jalousien bekommen keine ASC Attribute.
2.) Der Dummy bekommt in ASC die Wert zugeteilt:
... state 100 (Offen)
... state 20 (Shading)
... state 10 (Privacy)
... state 0 (Geschlossen)
3.) Über ein DOIF setze ich in Abhängigkeit des Dummies die Behanghöhe und die Lamellenstellung der richtigen Jalousie
... DUMMY_Rolladen_Wohnzimmer state 100 Offen >>> Jalousie_Wohnzimmer pct 100 / Lamelle 100 Offen
... DUMMY_Rolladen_Wohnzimmer state 20 Shading >>> Jalousie_Wohnzimmer pct 0 / Lamelle 100 Shading
... DUMMY_Rolladen_Wohnzimmer state 10 Privacy >>> Jalousie_Wohnzimmer pct 0 / Lamelle 40 Privacy
... DUMMY_Rolladen_Wohnzimmer state 0 Geschlossen >>> Jalousie_Wohnzimmer pct 0 / Lamelle 0 Geschlossen
4.) Ändere ich manuell die richtige Jalousie, setze ich den entsprechenden state Wert 0/10/20/100 wieder in dem dummy
________________________________________________
Der Orginal Jalousie Aktor HM-LC-Ja1PBU-FM ist über HMCCUDEV eingebunden. Das spielt aber keine große Rolle, die folgenden Schritte unterscheiden sich bei anderen Aktoren dann nur bei den set Befehlen im DOIF für Shading und Privacy
Zu 1. und 2.) DUMMY anlegen:
define HM_WohnzimmerJalBar_Dummy dummy
attr HM_WohnzimmerJalBar_Dummy ASC 2
attr HM_WohnzimmerJalBar_Dummy readingList pct
attr HM_WohnzimmerJalBar_Dummy setList pct:slider,0,10,100
attr HM_WohnzimmerJalBar_Dummy webCmd pct
Danach im ASC den Scan starten:
set MyASC scanForShutters
Dadurch hat der Dummy weitere Attribute erhalten, die wie folgt (oder wie es Euch beliebt) konfiguriert werden können:
attr HM_WohnzimmerJalBar_Dummy ASC_Closed_Pos 0
attr HM_WohnzimmerJalBar_Dummy ASC_Down astro
attr HM_WohnzimmerJalBar_Dummy ASC_Pos_Reading pct
attr HM_WohnzimmerJalBar_Dummy ASC_Open_Pos 100
attr HM_WohnzimmerJalBar_Dummy ASC_PrivacyDownValue_beforeNightClose 1800
attr HM_WohnzimmerJalBar_Dummy ASC_PrivacyDown_Pos 10
attr HM_WohnzimmerJalBar_Dummy ASC_PrivacyUpValue_beforeDayOpen 1800
attr HM_WohnzimmerJalBar_Dummy ASC_PrivacyUp_Pos 10
attr HM_WohnzimmerJalBar_Dummy ASC_Up astro
Der Dummy wird also bei Sonnenuntergang und Sonnenaufgang auf 0 und 100 gesetzt. jeweils eine halbe Stunde (1800 Sekunden) vorher werden die Lamellen auf Sichtschutz gekippt (Position des Dummys 10 Prozent). Auf Shading habe ich im Moment noch verzichtet, da im Moment noch kein Shading zu dieser Jahreszeit gebraucht wird. Das Prinzip ist aber identisch.
3.) DOIF erstellen
define d_HM_WohnzimmerJalBar_Dummy DOIF ([HM_WohnzimmerJalBar_Dummy:pct] == 0) (set HM_WohnzimmerJalBar down) DOELSEIF ([HM_WohnzimmerJalBar_Dummy:pct] == 10) (set HM_WohnzimmerJalBar Sichtschutz) DOELSEIF ([HM_WohnzimmerJalBar_Dummy:pct] == 20 ) (set HM_WohnzimmerJalBar Lichtschutz) DOELSEIF ([HM_WohnzimmerJalBar_Dummy:pct] == 100 ) (set HM_WohnzimmerJalBar up)
Lichtschutz (Behang 0%, Lamellenstellung 100%) und Sichtschutz (Behang 0%, Lamellenstellung 40%) stammen aus der EventMap des Aktors:
attr HM_WohnzimmerJalBar IODev d_ccu
attr HM_WohnzimmerJalBar alias Jalousie Bar
attr HM_WohnzimmerJalBar ccureadingfilter (LEVEL|INHIBIT|DIRECTION|WORKING)
attr HM_WohnzimmerJalBar ccureadingname LEVEL:+pct
attr HM_WohnzimmerJalBar ccuscaleval LEVEL:0:1:0:100,LEVEL_SLATS:0:1:0:100
attr HM_WohnzimmerJalBar cmdIcon up:control_centr_arrow_up stop:control_x down:control_centr_arrow_down Sichtschutz:fts_blade_arc_close_50 Lichtschutz:fts_blade_arc_close_00
attr HM_WohnzimmerJalBar controldatapoint LEVEL
attr HM_WohnzimmerJalBar event-on-change-reading .*
attr HM_WohnzimmerJalBar eventMap /datapoint STOP 1:stop/datapoint LEVEL 0:down/datapoint LEVEL 100:up/datapoint LEVEL_COMBINED "0x00,0x50":Sichtschutz/datapoint LEVEL_COMBINED "0x00,0xC8":Lichtschutz/
attr HM_WohnzimmerJalBar group Jalousien
attr HM_WohnzimmerJalBar icon fts_shutter_40
attr HM_WohnzimmerJalBar room Wohnbereich
attr HM_WohnzimmerJalBar statedatapoint LEVEL
attr HM_WohnzimmerJalBar stripnumber 1
attr HM_WohnzimmerJalBar substexcl control|pct
attr HM_WohnzimmerJalBar substitute LEVEL,LEVEL_SLATS!#0-0:Geschlossen,#1-2:Sichtschutz,#3.1-5:Lichtschutz,#100-100:Offen
attr HM_WohnzimmerJalBar webCmd Sichtschutz:Lichtschutz:down:up:stop
attr HM_WohnzimmerJalBar widgetOverride control:slider,0,10,100
"set HM_WohnzimmerJalBar Lichtschutz" kann aber durch jeden beliebigen set-Befehl ersetzt werden, der zu Eurem Aktor passt.
Punkt 4 muss ich noch eruieren. So wie ich es ursprünglich vorhatte, komme ich in eine Dauerschleifen: wenn ich den Aktor manuell anfahre, ändert sich auch der Dummy, darauf hin wieder per DOIF der Aktor usw. Falls jemand dazu eine Idee hat... her damit. :)
Eine Klippe gibt es noch zu umschiffen:
der state des Dummys wird durch ASC nicht "10" gesetzt, sonder als "state 10". Ich muss wohl statt state pct im Dummy füllen und das ASC Reading auf pct setzen. Darum kümmere ich mich später.
Zitat von: daelch am 15 April 2020, 06:20:51
Eine Klippe gibt es noch zu umschiffen:
der state des Dummys wird durch ASC nicht "10" gesetzt, sonder als "state 10". Ich muss wohl statt state pct im Dummy füllen und das ASC Reading auf pct setzen. Darum kümmere ich mich später.
Das wäre sowieso sauberer, da state Events ander aussehen können wie alle anderen Readings Events.
Ich habe den Code im ersten Post angepasst, so dass alles über pct läuft.
Hi Zusammen,
ihr seid ja schon weit.
Ich hätte noch die Idee, dass man statt eine Dummys ein readingsProxy nehmen könnte. Dann spart man sich ggf das Doif und die states wären aktuell, zumindest habe ich den readingsProxy so verstanden.
Kann der rP mit ASC zusammen arbeiten?
Was meint ihr?
Zitat von: Wscheff am 15 April 2020, 13:16:18
Hi Zusammen,
ihr seid ja schon weit.
Ich hätte noch die Idee, dass man statt eine Dummys ein readingsProxy nehmen könnte. Dann spart man sich ggf das Doif und die states wären aktuell, zumindest habe ich den readingsProxy so verstanden.
Kann der rP mit ASC zusammen arbeiten?
Was meint ihr?
Bei einem Test vor über einem Jahr hat das nicht geklappt weil readingsProxy kein Event wirft.
Zitat von: CoolTux am 15 April 2020, 13:25:30
Bei einem Test vor über einem Jahr hat das nicht geklappt weil readingsProxy kein Event wirft.
Hmm, nachdem mir vorhin das Stichwort event-on-update-readings über den Weg gelaufen ist: Vielleicht könnte man den readingsProxy damit nutzbar machen?
Grundsätzlich: Wann ist denn mit dem Lamellen-Thema in ASC selbst zu rechnen?
Denn die hier vorgeschlagene Lösung läuft im Prinzip auf was ähnliches raus wie das, was ich vorgeschlagen hatte, nur eben außerhalb ASC umgesetzt: Eine feste Zuordnung von Zielleveln und Lamellenposition. MMn. sollte man eher versuchen, innerhalb ASC wenigstens diese Minimallösung umzusetzen und ggf. Optionen vorzusehen, wie man das später aufbohren kann. Falls mein Vorschlag in dem anderen Thread nicht verständlich formuliert gewesen sein sollte, kann ich gerne versuchen, das dort oder anderswo besser zu erklären...
Wenn erst mal genug Leute einen Workaround gebastelt haben, wird es schwerer werden, Tester zu finden und genau der Wildwuchs tritt an anderer Stelle ein, den wir eigentlich beim Start der Entwicklich verhindern wollten. Das wäre unbefriedigend, oder?
Du kommst mir da ein wenig zu vor, ich war drum und dran heute morgen zu schreiben das ich denke das ich das relativ einfach umsetzen kann. Also mit diesen Zuordnungen wie Beschattung, Lueften und so.
Aber ich wollte das erstmal testen. ;D
Zitat von: CoolTux am 15 April 2020, 13:49:10
Du kommst mir da ein wenig zu vor, ich war drum und dran heute morgen zu schreiben das ich denke das ich das relativ einfach umsetzen kann. Also mit diesen Zuordnungen wie Beschattung, Lueften und so.
Aber ich wollte das erstmal testen. ;D
Sehr geil!
(Dann warte ich noch oder teste gerne mit! Habe das seit diesem Beitrag hier wieder etwas intensiver auf dem Schirm: https://forum.fhem.de/index.php/topic,110046.0.html; in dem Zusammenhang hatte ich mal auf die Schnelle versucht, ein userReading zu basteln, das die Lamellenposition mit steuert, aber das hatte nicht auf Anhieb geklappt...)
Zitat von: CoolTux am 15 April 2020, 13:49:10
Du kommst mir da ein wenig zu vor, ich war drum und dran heute morgen zu schreiben das ich denke das ich das relativ einfach umsetzen kann. Also mit diesen Zuordnungen wie Beschattung, Lueften und so.
Aber ich wollte das erstmal testen. ;D
Das gefällt mir auch gut, wenn es einfach umgesetzt werden kann.
Wird es eine Lösung sein, bei dem nur ein set Befehl zulässig (zB 'set Jalo Schatten' ist oder kann man da mehrere Variablem übergeben (oder sogar Perlcode)?
Bei mir lautet der Befehl 'set Jalo shadow' für den Homematic HmIP-BBL: 'set Jalo datapoint '".sprintf("datapoint 4.LEVEL_2 0.0 4.LEVEL %0.1f", ReadingsVal("$NAME","3.LEVEL",1))."', wobei anders als bei daelch 'set Jalo datapoint LEVEL_COMBINED "0x00,0xC8"'
gruss
ws
Hmm, wir hatten dazu extra mal eine Materialsammlung gestartet; unschön, wenn jetzt jeder wieder mit was neuem um's Eck kommt...
War es nicht so, dass es bei HM-IP neben den "combined"-Varianten auch möglich war, einfach zwei Befehle (an unterschiedliche Adressaten (=Datapoints?) ) abzusetzen?
Ja man kann auch
Set Jalo datapoint level1 xx level2 yy
Mit 2 werten für xx und yy
senden, da kann man den aktuellen Wert der Behangehöhe oder des Winkels nicht eingehen.
Ist aber ggf. nice2have
Und, sorry, wollte nicht neue Themen generieren.....
Die Frage war: Kann man ZWEI Befehle nehmen, nicht, ob EIN ANDERER auch funktioniert...
Ich frage auch nicht wg. "nice to have", sondern weil genau das (zwei Befehle) mal der Vorschlag war, der sowohl mit HM-IP wie auch mit CUL_HM und ZWave zu funktionieren schien ;) .
Also HM-IP braucht nur einen Befehl mit 2 Parametern.
Die anderen kenne ich nicht.
Hmm, habe mir jetzt den anderen Thread nochmal angesehen, insbesondere https://forum.fhem.de/index.php/topic,109424.msg1035126.html#msg1035126.
Da gibt es einen datapoint LEVEL_SLATS, das klang eigentlich danach, als könnte man den Drehwinkel auch bei dieser Type getrennt setzen... Vielleicht magst du das mal testen.
Aber vielleicht warten wir jetzt einfach mal, was CoolTux aus der Materialsammlung für Schlüsse gezogen hat?
Da gehts um ein anderes derivat von homematic (nicht IP)
Leider lassen sich nach meiner Erkenntnis für die IP Komponenten die Lamellen nicht einzeln setzten, sonder n nur zusammen mit der Behanghöhe.
Puh, schade. Dann warten wir mal, was CoolTux dazu sagt...
Zitat von: Wscheff am 15 April 2020, 16:55:50
Da gehts um ein anderes derivat von homematic (nicht IP)
Leider lassen sich nach meiner Erkenntnis für die IP Komponenten die Lamellen nicht einzeln setzten, sonder n nur zusammen mit der Behanghöhe.
Von welchem IP Aktor sprichst Du? Dem HMIP-BBL?
Laut Doku: https://www.eq-3.de/downloads/download/homematic/hm_web_ui_doku/HmIP_Device_Documentation.pdf
...hat er zwei Datenpunkte Level und Level_2.
zap hatte an anderer Stelle schon mal gesagt, dass diese getrennte Befehle für Behang und Lamellen darstellen. Zumindest auf diesen IP Aktor müsste es zutreffen.
Es gibt noch einen IP Jalousieaktor, den HmIP-FBL.
Laut dieser Quelle hat er auch zwei Daten Punkt, Level und Level_2: https://homematic-forum.de/forum/viewtopic.php?t=38094
Es müssen beiden Befehle abgesetzt werden, dann fährt die Jalousie in Position und Lamellenstellung.
IP Wired habe ich nicht geprüft... aber wahrscheinlich gilt dort selbiges.
Danke für die Klarstellung!
Ich halte es auch für wahrscheinlich, dass zwei getrennte Befehle _möglich_ sind, denn das ist die einfachste Variante, um nur das eine oder nur das andere zu ändern. Alles andere ist mehr Programmieraufwand, und gute Programmierer sind faul, oder ::) ? (Bitte keine Diskussion über die Qualitäten des Hauptentwicklers der CCU-Firmware, bitte... ;D , wir sind so schon recht OT :P .).
Zitat von: daelch am 15 April 2020, 17:29:05
Von welchem IP Aktor sprichst Du? Dem HMIP-BBL?
Laut Doku: https://www.eq-3.de/downloads/download/homematic/hm_web_ui_doku/HmIP_Device_Documentation.pdf
...hat er zwei Datenpunkte Level und Level_2.
zap hatte an anderer Stelle schon mal gesagt, dass diese getrennte Befehle für Behang und Lamellen darstellen. Zumindest auf diesen IP Aktor müsste es zutreffen.
Es gibt noch einen IP Jalousieaktor, den HmIP-FBL.
Laut dieser Quelle hat er auch zwei Daten Punkt, Level und Level_2: https://homematic-forum.de/forum/viewtopic.php?t=38094
Es müssen beiden Befehle abgesetzt werden, dann fährt die Jalousie in Position und Lamellenstellung.
IP Wired habe ich nicht geprüft... aber wahrscheinlich gilt dort selbiges.
Ja genau. Ich habe den HmIP-BBL. Danke fürs recherchieren.
Aus der Doku und dem link habe ich mir die Verstellung mittels eventMap gebastelt. Dasgeht sehr gut
ich habe rausgefunden dass höhe mit Level gefahren werden kann, für die Lamellenverstellung müssen aber zwingend BEIDE Level und Level 2 eingegeben werden.
Ich mach das im Prinzip so wie du daelch.
nach einem Vorschlag von alkazaa
{
usr=>{'^up' => 'datapoint 4.LEVEL 100',
'^down' => 'datapoint 4.LEVEL 0',
'^mid' => 'datapoint 4.LEVEL 50',
'^open' => '".sprintf("datapoint 4.LEVEL_2 1.0 4.LEVEL %0.1f", ReadingsVal("$NAME","3.LEVEL",1))."',
'^half' => '".sprintf("datapoint 4.LEVEL_2 0.5 4.LEVEL %0.1f", ReadingsVal("$NAME","3.LEVEL",1))."',
'^close' => '".sprintf("datapoint 4.LEVEL_2 0.0 4.LEVEL %0.1f", ReadingsVal("$NAME","3.LEVEL",1))."',
'(hoehe|h)\s(\d{1,3})' => '".sprintf("datapoint 4.LEVEL %0.2f", $2/100)."',
'(winkel|w)\s(\d{1,3})' => '".sprintf("datapoint 4.LEVEL_2 %0.2f 4.LEVEL %0.2f", $2/100, ReadingsVal("$NAME","3.LEVEL",1))."'},
fw =>{'^up' => 'up',
'^down' => 'down',
'^mid' => 'mid',
'^open' => 'open',
'^half' => 'half',
'^close' => 'close',
'(hoehe|h)\s(\d{1,3})' => 'pct',
'(winkel|w)\s(\d{1,3})' => 'w'}
}
Ich habe nun eine erste Version für die Unterstützung von "festen Zuordnungen"
Voraussetzung ist das das Rollo mit set ROLLONAME "feste Zurodnung" fährt.
Beispiel:
set ROLLOKuecheRechts Beschattung
Was musst Du machen?
Zusätzlich in den Positionsattributen noch ein :"feste Zuordnung" vergeben.
Beispiel:
attr ROLLOKuecheRechts ASC_Shading_Pos 15:Beschattung
ACHTUNG!!! Das geht aktuell ausschließlich bei Shading_Pos und Ventilate_Pos
Ist ja nun mal vorerst zum testen.
Und hier nun die Version
https://git-tuxnet.ddns.net/FHEM/mod-AutoShuttersControl
(Sollte das aufrufen der Seite nicht funktionieren befindest Du Dich nicht in Deutschland oder dessen Nachbarländer)
Happy testing
Fast vergessen. Testen kann man am besten mit Ventilator.
Warten bis dunkel ist oder ein Raum mit Roommate nehmen und den Roommate schlafen legen und dann Fenster öffnen wenn ein Sensor eingerichtet ist.
Grüße
Na ja, das mit der "festen Zuordnung" war eigentlich anders gemeint gewesen :o .
Da ich keinen Dummy nehmen will und mein ZWave-Aktor keinen setter Beschattung kennt, kann ich wohl nicht mittesten...
(Ansonsten hätte ich noch eine etwas andere Idee, wie man das ganze ggf. irgendwie in den Griff bekommen könnte).
Zitat von: Beta-User am 15 April 2020, 19:46:07
Na ja, das mit der "festen Zuordnung" war eigentlich anders gemeint gewesen :o .
Da ich keinen Dummy nehmen will und mein ZWave-Aktor keinen setter Beschattung kennt, kann ich wohl nicht mittesten...
(Ansonsten hätte ich noch eine etwas andere Idee, wie man das ganze ggf. irgendwie in den Griff bekommen könnte).
Das ist erstmal nur ein Anfang. Ich bilde mir ein das ich da Recht viel Platz für andere Befehle gelassen habe.
Wie wäre denn genau Dein Befehl. Kannst Du in einem einzigen Befehl bei Dir die komplette Stellung übergeben?
Nein. Einer reicht nicht, brauche zwei FHEM-Befehle.
Aber evtl. wäre es eine Idee, mit zwei Attributen zu arbeiten: Einer für die "feste" Zuordnung von pct-Werten zu Slat-pct-Werten (oder "Ereignis" - Slat-Werten), einer für den Befehl (analog dem, was z.B. WeekdayTimer kennt). Da könnte man dann "set $NAME dim $pct; set <slatdevice> dim $slatpct" reinschreiben...? (Oder einen Perl-Befehl). Damit könnte der User "seinen" Befehl beliebig zusammenbauen, auch sowas wie hex-Umwandlungen wären denkbar.
Die "eigentlichen" ASC-Attribute so zu "mißbrauchen", finde ich nicht so toll, dann sind die Werte wieder sehr viel schwerer einzustellen. Mit einem einzigen slat-Werte-Attribut wäre wenigstens alle Ungemach an einer Stelle vereint...
Ich denke es geht ja um Beschatten und Lüften und so, da finde ich die Slat Werte schon korrekt als zweiten Wert in den jeweiligen Positionsattributen aufgehoben.
Bei Dir wäre also
set $NAME dim $pct; set <slatdevice> dim $slatpct
??
Zitat von: CoolTux am 15 April 2020, 20:36:13
Bei Dir wäre also
set $NAME dim $pct; set <slatdevice> dim $slatpct
Ja. Das würde hier passen.
Für einen CUL_HM kann man das afaik kombinieren, müßte aber dann trotzdem beide Level-Angaben irgendwie in den Befehl einbauen, der dann aber nur an ein Device geht.
Zitat von: CoolTux am 15 April 2020, 20:36:13
Ich denke es geht ja um Beschatten und Lüften und so, da finde ich die Slat Werte schon korrekt als zweiten Wert in den jeweiligen Positionsattributen aufgehoben.
Jein. Da der Slatlevel nach jeder Fahrt bei diesem Typ (und afaik auch bei den HM) wieder hergestellt wird, ist das auch relevant, wenn man z.B. von lüften auf zu fährt... Kurz: Es spielt bei JEDER FAHRT eine Rolle. Wird es nicht über ASC gelöst, brauche ich für den Rest einen Würgaround. Wäre schön, wenn wir das vermeiden könnten.
Wir können das weiter ausbauen.
Jetzt interessiert mich aber ob diese einfache Lösung erstmal geht.
CoolTux, vielen Dank für Deine Mühen.
Eine blöde Anfängerfrage: wie bekomme ich den Code von https://git-tuxnet.ddns.net/FHEM/mod-AutoShuttersControl in mein FHEM?
Viele Grüße
Christoph
Hinter dem HTTPS bla bla bla auf der rechten Seite gibt es ein Symbol mit File nach unten. Da rauf drücken.
Die alte 73_AutoShuttersControl.pm sicherst Du weg.
cp -v /opt/fhem/FHEM/73_AutoShuttersControl.pm /opt/fhem/FHEM/73_AutoShuttersControl.pm.old
Dann die 73_AutoShuttersControl.pm Datei nach /opt/fhem/FHEM/ kopieren.
Die Rechte anpassen
chown fhem: /opt/fhem/FHEM/73_AutoShuttersControl.pm
Im Anschluss einen kompletten Neustart von FHEM machen.
@Beta-User
Als Attributnamen für das Slatdevice
ASC_Slatdevice ?
Zitat von: CoolTux am 16 April 2020, 07:48:23
@Beta-User
Als Attributnamen für das Slatdevice
ASC_Slatdevice ?
"An sich" würde das passen, ABER:
Vor dem Hintergrund der gestrigen Diskussion hier (und dem dimPosition (?)-Hinweis aus dem anderen Thread) komme ich immer weniger von dem Gedanken weg, dass wir für das ganze genau
zwei Attribute ein oder zwei Attribut(e) benötigen
sollten würden, die z.B. heißen könnten:
ASC_SlatPositions
ASC_SlatCommandPattern
In "ASC_SlatPositions" sollten dann nur Zuordnungen nach dem Motto "shading:30 close:0 open:99 ...", in "ASC_SlatCommandPattern" dann der jeweilige Befehl bzw. die Befehle reinschreiben zu lassen (FHEM-Befehl, aber auch Perl zulässig).
Vor der Übergabe an fhem.pl würde ich dann die Ersetzung von ein paar Varablen zulassen, nämlich $NAME (oder $name, für den Namen des aktuellen Devices), $position (für den Ziellevel), $slatPosition (für die Lamellenstellung) und $reason (für den Fahrtanlass). Eventuell könnte man das noch ergänzen durch die Hex-Umrechnung (@HMCCU.*), aber scheinbar ist das nicht zwingend. Das Zieldevice für die Lamellen (so es denn erforderlich ist), müßte der User dann eben da "vermosten", aber das ist eine einmalige Sache, die man mit ein paar Beispielen m.E. ganz gut in den Griff bekäme.
Am Vorhandensein der "ASC_SlatPositions" (während des Schreibens für besser befunden: am Vorhandensein des anderen Attributs) kann man erkennen, dass es sich um eine Jalousie handelt.
"ASC_SlatPositions" muß mMn. auch nicht "vollständig" sein, also für jeden Fahranlass eine Zuordnung enthalten; z.B. für auf oder zu wäre es ein "Service", einfach die Zielposition auch als SlatPositon zu verwenden, falls nichts anderes angegeben ist... Damit würde sich die "notwendige Angabe" auf den CommandPattern reduzieren, alles andere ist Feinjustage.
Setzt halt voraus, dass die Endverarbeitung erst beim Fahrbefehl stattfindet, ich habe jetzt nicht in den Code gesehen, wie du das umgesetzt hast und kann daher nicht sagen, ob das noch viel Aufwand wäre.
(Ist denn der Gedanke verständlich formuliert?)
Ich versuche es aus Sicht des bisherigen Anwenders zu sehen und versuche meine Logik mit ein zu bringen
Wir haben doch schon für jede Position ein Attribut, wieso soll man das nicht nehmen und einfach erweitern.
Zitat
In "ASC_SlatPositions" sollten dann nur Zuordnungen nach dem Motto "shading:30 close:0 open:99
Genau das meine ich, wieso doppelt machen. Verstehst was ich meine?
Einfach einen zweiten Wert hinter den schon vorhandenen Positionswert für die Lamellenwinkel (oder wie man das nennt) und dann wird das ausgewertet.
Kann man davon ausgehen das sofern der Slat im selben Device statt findet der Command der selbe ist wie beim normalen fahren? Also pct oder dim??
Noch was anderes. Für Deine Lamellen hast Du ja zwei Fahrbefehle.
Müssen die Nacheinander kommen oder kann der zweite Befehl ausgeführt werden während der erste noch abgearbeitet wird?
Zitat von: CoolTux am 16 April 2020, 08:58:24
Ich versuche es aus Sicht des bisherigen Anwenders zu sehen und versuche meine Logik mit ein zu bringen
Wir haben doch schon für jede Position ein Attribut, wieso soll man das nicht nehmen und einfach erweitern.
Weil es teils nicht nötig ist, und wenn man das so macht, ist es relativ umständlich zu ändern.
Habe ich das richtig verstanden, dass du nur aus dem Vorhandensein des zweiten Werts jeweils ablesen willst, dass es eine Jalousie ist? (Dann wird der user gezwungen, das wirklich überall zu pflegen und kann unsere schönen readingsGroups nicht nutzen... Wäre ggf. ok, wenn es eine andere GUI dafür gäbe, so ist es "lästig".).
Zitat
Genau das meine ich, wieso doppelt machen. Verstehst was ich meine?
Einfach einen zweiten Wert hinter den schon vorhandenen Positionswert für die Lamellenwinkel (oder wie man das nennt) und dann wird das ausgewertet.
Wie gesagt: Es muß m.E. nicht doppelt (oder bei deiner Lösung: zwingend mehrfach) sein, sondern eben genau an einer Stelle, wobei wir sogar eine der zwei "überflüssig" (optional) machen können, und die zweite in irgendeiner Form "sowieso" brauchen (Command oder was auch immer).
ZitatKann man davon ausgehen das sofern der Slat im selben Device statt findet der Command der selbe ist wie beim normalen fahren? Also pct oder dim??
Wenn ich das richtig verstanden habe, ist es genau umgekehrt: Dasselbe Device bedeutet zwingend, dass der Befehl unterschiedlich ist (z.B. slatLevel bei CUL_HM, afaik).
Zitat von: CoolTux am 16 April 2020, 09:03:12
Noch was anderes. Für Deine Lamellen hast Du ja zwei Fahrbefehle.
Müssen die Nacheinander kommen oder kann der zweite Befehl ausgeführt werden während der erste noch abgearbeitet wird?
Die können miteinander abgesetzt werden, Reihenfolge ist sogar beliebig.
Zu eventuellen zeitlichen Abhängigkeiten noch: In anderen Fällen mag das anders gelagert sein, und wenn du Perl zulassen würdest, kann das der User erledigen. Z.B. würde ich für meine "nicht-lamellenfähigen" CUL_HM-Geräte eigenen Code zwischenschalten können und z.B. über benannte sleep (mit notify-Logik) passende Fahrbefehle zusammenbauen, die zeitliche Abhängigkeiten berücksichtigen ;) . In dem anderen (Ideen-Sammel-) Thread hatte ich das ja mal erläutert.
Ok ich versuche es erstmal mit einem zusätzlichen Attribut. Hinzufügen ist immer einfach, wegnehmen oder sogar ändern schon bei weitem schwieriger.
ASC_SlatPosCmd_SlatDevice = pct:RolloKuecheLinksSlat
Die Positionen werden als zweiten Wert hinter des Positions Attributen angegeben. Ist nichts angegeben wird die Lamelle auch nicht verstellt.
Soweit die Idee. Die Umsetzung wird zeigen ob es klappt. Mittlerweile ist der Code so flexibel das der Aufwand einer Änderung gering aus fällt.
...bin nicht 100% damit glücklich, aber du bist der Maintainer, also darfst du das so entscheiden. Werde also ab heute abend bzw. Bereitstellung mal testen, ob das klappt. Link ist wieder https://git-tuxnet.ddns.net/FHEM/mod-AutoShuttersControl?
Bzgl. nicht glücklich: https://forum.fhem.de/index.php/topic,110263.0.html (ich habe den Beitrag nicht bestellt...). Bei den Helligkeitswerten hatten wir das btw. mit dem Argument akzeptiert, dass der user das ja typischerweise nie mehr ändert; da sehe ich bei Leveln einen großen Unterschied. (Und war es nicht so, dass da Perl-Code stehen kann für den Ziellevel bei Beschattung?)
Ja der Link wäre der selbe.
Das mit Readingsgroup habe ich gelesen und verstehe das es doof ist. Aber aktuell geht Funktion vor Schönheit.
Das mit Readingsgroup bekommen wir später hin. Können wir dann dann mit den gettern und settern der ASC API machen.
Lass uns testen wie es funktioniert. Umbauen geht immer noch wenn es total doof ist.
Testen ist ok, kein Ding, bin ja froh, dass es vorangeht!
Aber wie gesagt: An sich finde ich es fast schon doof, dass ich überhaupt die Attribute anfassen muß. Für meine Zwecke ist es ausreichend, wenn die Jalousie bei geschlossen=0=>slat=0, offen=99=>slatlevel=99, lüften=60=>slatlevel=60 machen würde. Dafür muß ASC eigentlich wirklich nur wissen, dass es eine Jalousie ist...
Zitat von: CoolTux am 15 April 2020, 18:29:25
Ich habe nun eine erste Version für die Unterstützung von "festen Zuordnungen"
Voraussetzung ist das das Rollo mit set ROLLONAME "feste Zurodnung" fährt.
Hi CoolTux, kurze Verständnisfrage:
Geht wirklich nur ventilate/shading und ich muss fürs testen manuell wieder zu fahren?
=> Wo kann ich die Open und Close Anweisungen eintragen: ASC_Sleep_Pos und ASC_Open_Pos?
oder gibt's da eine Logik zwischen Shading_Pos und Ventilate_Pos?
Zitat von: Typ1er am 16 April 2020, 12:08:22
diese set Befehle stehen zur Verfügung:
-positionBlind (beim Fahren wird die Lamelle nicht verändert, 0-99)
-positionSlat (Lamelle, 0-99)
-dim (hier tritt ein eigenartiger Fehler auf, beim öffnen auf 99, wird die Lamelle am Ende auf 99 gesetzt, was beim nächsten Fahrbefehl bewirkt das die Lamellen am ende offen stehen, da Slat 99 ist).
Reading kommt über position rein:
position Blind 0 Slat 0
ich splitte das dann auf per userReading auf:
position_blind 0
position_slat 0
Zitat von: Beta-User am 16 April 2020, 12:17:31
Da wir das grade im anderen Thread diskutieren: Kann man den Aktor auch "in einem Aufwasch" beide Werte mitgeben, also
set <aktor> positionBlind 0 positionSlat 0
(Dass es mit zwei Befehlen auch geht, ist klar, und ich gehe mal davon aus, dass man die auch "gleich" loswerden kann und nicht erst warten muß, bis "blind" erreicht ist, bevor man "slat" setzen darf).
(for the records: Das ist ein FGR-222, oder? @CoolTux: Wenn ja, ist der ist noch ein "Einheitsdevice", aber Fibaro hat beim Nachfolger dann der "Norm" den Vorzug gegeben und das aufgesplittet, deswegen habe ich als FGR-223-Nutzer 2 bzw. 3 Geräte für den einen Aktor).
das klappt nicht beide Befehle mit einmal, bekomme diesen Fehler:
set positionBlinds needs one parameter
ja ist der Model FIBARO System FGRM222 Roller Shutter Controller 2
Zitat von: Wscheff am 16 April 2020, 12:42:34
Hi CoolTux, kurze Verständnisfrage:
Geht wirklich nur ventilate/shading und ich muss fürs testen manuell wieder zu fahren?
=> Wo kann ich die Open und Close Anweisungen eintragen: ASC_Sleep_Pos und ASC_Open_Pos?
oder gibt's da eine Logik zwischen Shading_Pos und Ventilate_Pos?
Es ist ja erstmal nur zum testen. Ich will nur wissen ob meine Logik in der Praxis Bestand hat. Der Rest kommt dann noch.
Das mit OpenPos und ClosePos verstehe ich nicht.
Es gibt ASC_Open_Pos und ASC_Close_Pos
Ich wollte heute Ein wenig testen und stelle mir das so vor:
Fenster auf - jalo geht in ventilate
Fenster zu - nix passiert (weil das close command noch nicht umgesetzt ist), also muss ich ,,manuell zumachen"
Shading kann ich nachts nicht machen, ventilate Tags nicht. Oder übersehe da was?
Könntest du nicht bitte noch das close umsetzten?
Dann kann man Fenster auf/zu testen
Das Close sollte eigentlich auch funktionieren. Aber halt nur auf das fahren beschränkt, also keine Lamellenverstellung.
Am Tag kannst Du testen in dem Du dem Rollo einen Roommate zu weist und diesen dann schlafen legst.
Alles weitere zum Thema ASC und Lamellenfunktion bitte im neuen Thread
https://forum.fhem.de/index.php/topic,110277.0.html
Nur damit ich dazu nochmal deutlich meine Meinung gesagt habe:
Es macht für mich keinen Sinn, erst Komplexität zu erhöhen, indem man überall weitere Angaben erzwingt (einzeln bei allen Positionsangaben), und dann für die Lösung auf eine Einrichtungs-GUI zu verweisen, die letztlich auch nur dazu dienen muß, alle diese (unnötigen!) Angaben zusätzlich zu pflegen...
Da das Eröffnen eines neuen Threads auf mich wirkt, als wäre dazu im Moment keine weitere Diskussion erwünscht, werde ich das beherzigen und mich auch an einem Test nicht beteiligen, der einen Dummy als Zwischendevice braucht.
Bin mal auf das Endergebnis gespannt, ob das dann einfacher ist, als ich das grade befürchte...
Der Threadtitel hieß Workaround und ich habe eine Version welche nun Lamellen unterstützt, das hat halt nicht gepasst. Daher neuer Thread.
Zitat von: CoolTux am 16 April 2020, 21:56:27
Der Threadtitel hieß Workaround und ich habe eine Version welche nun Lamellen unterstützt, das hat halt nicht gepasst. Daher neuer Thread.
YMMD ;D ...
Wir nennen es preAlpha, und schon ist die Zwischenschaltung eines Dummy kein workaround mehr? Wieder was neues gelernt...
Im Ernst: Das mit den zusätzlichen Argumenten in den Pos.-Angaben ist und bleibt keine gute Lösung.
Leider sind diese Änderungen in dem Commit für mich nicht auf die Schnelle nachvollziehbar, sonst würde ich versuchen, da "in Perl" was dazu zu sagen.
Vielleicht ein Argument noch in dem Gesamtzusammenhang: Wenn du am Ende einen in einem Argument enthaltenen Command-Pattern zulassen würdest (und erst darüber entscheiden, ob der "normale" interne Fahrbefehl verwendet werden soll), den mit ein paar Variablen extrapolierst und dann an AnalyzeCommandChain() übergibst, machst du evtl. auch den einen oder anderen (KNX?)-User glücklich, der eigentlich gar nichts mit Jalousien und Lamellendrehwinkeln am Hut hat ;) .
Zitat von: Beta-User am 17 April 2020, 09:23:45
YMMD ;D ...
Wir nennen es preAlpha, und schon ist die Zwischenschaltung eines Dummy kein workaround mehr? Wieder was neues gelernt...
Im Ernst: Das mit den zusätzlichen Argumenten in den Pos.-Angaben ist und bleibt keine gute Lösung.
Leider sind diese Änderungen in dem Commit für mich nicht auf die Schnelle nachvollziehbar, sonst würde ich versuchen, da "in Perl" was dazu zu sagen.
Vielleicht ein Argument noch in dem Gesamtzusammenhang: Wenn du am Ende einen in einem Argument enthaltenen Command-Pattern zulassen würdest (und erst darüber entscheiden, ob der "normale" interne Fahrbefehl verwendet werden soll), den mit ein paar Variablen extrapolierst und dann an AnalyzeCommandChain() übergibst, machst du evtl. auch den einen oder anderen (KNX?)-User glücklich, der eigentlich gar nichts mit Jalousien und Lamellendrehwinkeln am Hut hat ;) .
Verstehe ich nicht. Wieso Dummy? In meiner Version benötigt man keinen Dummy. Bin irritiert.
Zitat von: Beta-User am 17 April 2020, 09:23:45
Vielleicht ein Argument noch in dem Gesamtzusammenhang: Wenn du am Ende einen in einem Argument enthaltenen Command-Pattern zulassen würdest (und erst darüber entscheiden, ob der "normale" interne Fahrbefehl verwendet werden soll), den mit ein paar Variablen extrapolierst und dann an AnalyzeCommandChain() übergibst, machst du evtl. auch den einen oder anderen (KNX?)-User glücklich, der eigentlich gar nichts mit Jalousien und Lamellendrehwinkeln am Hut hat ;) .
Da ich keine Ahnung vin KNX habe versteheh ich auch nicht was Du mir damit mitteilen willst.
Zitat von: CoolTux am 17 April 2020, 09:51:39
Verstehe ich nicht. Wieso Dummy? In meiner Version benötigt man keinen Dummy. Bin irritiert.
Ok, da war ich auf dem falschen Dampfer, weil neben einem Gerät TYPE Dummy wohl auch HMCCUDEV einen Befehl mit fester Zuordnung kennt... Das ist aber m.E. die Ausnahme, oder habe ich "substitute" als allg. Attribut übersehen?
attr HM_WohnzimmerJalBar substitute LEVEL,LEVEL_SLATS!#0-0:Geschlossen,#1-2:Sichtschutz,#3.1-5:Lichtschutz,#100-100:OffenZitatDa ich keine Ahnung vin KNX habe versteheh ich auch nicht was Du mir damit mitteilen willst.
Das bezieht sich auf das hier:
Zitat von: CoolTux am 16 April 2020, 18:50:48
Hallo Wolfgang,
Es tut mir leid aber ich verstehe gerade nicht wieso Du da einen (fast) leeren String für KNX zu weist. Welchen Mehrwert hat es?
Du kannst das Attribut ASC_Pos_Reading setzen welches gleichzeitig das Reading zum auslesen der Position sein soll und der Command zum fahren der Rollos. Also pct oder dim oder was auch immer.
Ich kenne KNX nicht, mir wurde gesagt das man da vieles konfigurieren kann. Auch mit welchen Befehl das Rollo fahren soll. Also entweder mit der Angabe eines die Datenpunkte (Adressen) oder mittels einen Commands der dann auf die entsprechenden Datenpunkte verweist.
Grüße
Marko
Ich habe verstanden: der Befehl geht auf das Gerät selbst, das (zusätzliche) Leerzeichen ist nur ein Trick, um den Fahrbefehl irgendwie auf das Gerät selbst umzuleiten. Weiter scheint es so zu sein, dass das Position-Reading in diesem Fall "state" ist.
Wenn der User also als Postion-Reading-Attribut "state" angeben kann, am Ende aber ein "set $NAME $position" als Command zugelassen wäre, wäre auch dieser "Fisch geputzt".
Nochmal: Warum übergibst du nicht den Fahranlass (= aus welcher Unterfnktion von ACS kommt die Anweisung) ZUSÄTZLICH an deine Fahrroutine und entscheidest dann erst in dieser, welche Variante am Ende stattfindet?
Das kann dann sein:
1. ein normaler Fahrbefehl wie bisher ODER
2. eine durch den User festgelegte Routine, die folgende Varianten ermöglicht:
-- feste Zuordnung über das Gerät (HMCCUDEV) (set $NAME $festeZurodnung);
-- beliebige Anweisung als "normaler FHEM-Befehl" (je nach Bedarf mit Übergabe einiger Variablen, die du ja kennst bzw. - was die Lamellenstellung angeht - ggf. über ein weiteres Attribut oder wenn nicht vorhanden über $position=>$lamellaPosition ermittelt)
-- Perl-Command (wieder mit denselben Variablen).
Alle Varianten 2 - mit Ausnahme der Ermittlung der Lamellenwerte - müßten stressfrei über AnalyzePerlCommand "abzufackeln" sein... Du brauchst m.E. also gar keine großen Klimmzüge zu machen oder Userängste zu schüren (bezieht sich auf https://forum.fhem.de/index.php/topic,110280.msg1043269.html#msg1043269).
Zitat von: Beta-User am 17 April 2020, 10:21:31
Ich habe verstanden: der Befehl geht auf das Gerät selbst, das (zusätzliche) Leerzeichen ist nur ein Trick, um den Fahrbefehl irgendwie auf das Gerät selbst umzuleiten. Weiter scheint es so zu sein, dass das Position-Reading in diesem Fall "state" ist.
Wenn der User also als Postion-Reading-Attribut "state" angeben kann, am Ende aber ein "set $NAME $position" als Command zugelassen wäre, wäre auch dieser "Fisch geputzt".
Soweit mir bekannt kann man im KNX Device konfigurieren welcher Befehl zu welchem Ziel führen soll.
Man kann konfigurieren das
set DEVICENAME 100
geht. Aber auch das
set DEVICENAME pct 100
geht. Wenn das wirklich so ist wie ich denke wer entscheidet dann für den User was besser ist. Deiner will die erste Variante der andere die zweite weil es eindeutiger ist. Der dritte will set DEVICENAME schließen als Unterstützung. Das mache ich nicht. Sofern meine Annahme stimmt!
Zitat von: Beta-User am 17 April 2020, 10:21:31
Nochmal: Warum übergibst du nicht den Fahranlass (= aus welcher Unterfnktion von ACS kommt die Anweisung) ZUSÄTZLICH an deine Fahrroutine und entscheidest dann erst in dieser, welche Variante am Ende stattfindet?
Das kann dann sein:
1. ein normaler Fahrbefehl wie bisher ODER
2. eine durch den User festgelegte Routine, die folgende Varianten ermöglicht:
-- feste Zuordnung über das Gerät (HMCCUDEV) (set $NAME $festeZurodnung);
-- beliebige Anweisung als "normaler FHEM-Befehl" (je nach Bedarf mit Übergabe einiger Variablen, die du ja kennst bzw. - was die Lamellenstellung angeht - ggf. über ein weiteres Attribut oder wenn nicht vorhanden über $position=>$lamellaPosition ermittelt)
-- Perl-Command (wieder mit denselben Variablen).
Alle Varianten 2 - mit Ausnahme der Ermittlung der Lamellenwerte - müßten stressfrei über AnalyzePerlCommand "abzufackeln" sein... Du brauchst m.E. also gar keine großen Klimmzüge zu machen oder Userängste zu schüren (bezieht sich auf https://forum.fhem.de/index.php/topic,110280.msg1043269.html#msg1043269).
Der Fahranlass ergibt sich aus der gewählten Position welche angefahren werden soll. Das kann ich auch nicht ändern weil man mit Fahranlässen "Strings" keine Positionsabfrage auf einfache Weise hinbekommt um festzustellen ob das Rollo nicht schon in dieser Position ist ob es unterhalb dieser Position ist oder Oberhalb.
Es gäbe da vielleicht etwas aber das muss ich erst testen und das dauert.
Der User kann in der derzeitigen Variante bereits entscheiden wie sein Fahrbefehl zusammen gesetzt wird.
Die feste Zuordnung war ein Test den ich schnell umsetzen könnte und der mir zeigen sollte ob meine generelle Überlegung tatsächlich funktioniert. Daher geht das jetzt schon.
Das andere ist auch schon fertig und wird aktuell von mir getestet.
OK, KNX ist verstanden, man muß nicht jede mögliche Konfigurationoption für eine Technik "abfackeln" können. Sehe ich auch so.
Zitat von: CoolTux am 17 April 2020, 10:40:06
Der Fahranlass ergibt sich aus der gewählten Position welche angefahren werden soll.
Das ist etwas, das nicht nur ich vermutlich nie verstehen werde und für einen Webfehler halte. Aus gegebenem Anlass würde ich empfehlen, genau aus dieser Denke irgendwann auszusteigen und dafür eben die Tür jetzt aufmachen (das waren afaik gerade mal 5-7 Stellen im Code, die man anfassen müßte, und keine grundlegenden Dinge).
ZitatDas kann ich auch nicht ändern weil man mit Fahranlässen "Strings" keine Positionsabfrage auf einfache Weise hinbekommt um festzustellen ob das Rollo nicht schon in dieser Position ist ob es unterhalb dieser Position ist oder Oberhalb.
Deswegen hatte ich "zusätzlich" geschrieben. Und welcher Anlaß es ist, muß eigentlich imo nicht im Attribut selbst stehen, weil du den Anlaß ja kennst (oder woher weißt du welches der Attribute du brauchst?).
ZitatEs gäbe da vielleicht etwas aber das muss ich erst testen und das dauert.
Kein Ding. Es eilt nicht, ich hatte (und habe immer noch) die große Sorge, dass das in eine unnötig komplizierte Richtung geht und wollte dies rechtzeitig mitteilen.
Zitat
Der User kann in der derzeitigen Variante bereits entscheiden wie sein Fahrbefehl zusammen gesetzt wird.
Die feste Zuordnung war ein Test den ich schnell umsetzen könnte und der mir zeigen sollte ob meine generelle Überlegung tatsächlich funktioniert. Daher geht das jetzt schon.
Das andere ist auch schon fertig und wird aktuell von mir getestet.
:) Dann bin ich jetzt mal ruhig und lasse dich in Ruhe testen!