[73_AutoShuttersControl.pm] Workaround Jalousien:Lamellen steuern -Version 0.8.x

Begonnen von daelch, 14 April 2020, 23:33:18

Vorheriges Thema - Nächstes Thema

daelch

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. :)

daelch

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.

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

daelch

Ich habe den Code im ersten Post angepasst, so dass alles über pct läuft.

Wscheff

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?

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

CoolTux

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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

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...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Wscheff

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


Beta-User

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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Wscheff

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.....

Beta-User

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 ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Wscheff

Also HM-IP braucht nur einen Befehl mit 2 Parametern.
Die anderen kenne ich nicht.

Beta-User

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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors