Betatester für neues Modul AutoShuttersControl gesucht!

Begonnen von CoolTux, 01 September 2018, 12:10:35

Vorheriges Thema - Nächstes Thema

Beta-User

#30
Zitat von: CoolTux am 02 September 2018, 11:02:21
Es gibt eine interne ARRAY List aller Rollos. Wir haben versucht weitestgehend flexibel zu entwickeln.
War naheliegend; wenn später alles über dieses Array läuft (im Sinne von foreach bei der Umsetzung irgendwelcher "erstelle Timer"-Aktionen usw.), ist es in der Tat egal, wie man zunächst mal auf die Array-Elemente kommt.

Zitat von: CoolTux am 02 September 2018, 11:02:21
Das ist mir viel zu speziell. Meine Rollo Devices haben zum Beispiel keines Deiner Filter. Vielleicht hat auch einer nur Dummys und steuert damit GPIOs an.
Was speziell ist, hängt individuell an der Installation;  jemand, der in USA, Frankreich, Polen oder Indien seine Devices benennt, findet evtl. "Roll.*" sehr speziell ;) . Eigentlich könnte man diverse Standard-Devspecs bei "auto" nacheinander durchloopen (was du ja vermutlich für die beiden bisherigen Vorgaben auch machst), und dann halt nur in das Array pushen, was nicht schon durch einen vorherigen Filter drin war. So eine Logik würde dann auch das Hinzufügen einzelner Devices ggf. vereinfachen (bzw. die "Reparatur", wenn jemand notwendige Atribute, Readings etc. an seinen shutter-Devices versehentlich gelöscht haben sollte.
Aber du hast recht: Das ist Kosmetik und ist ggf. auch nachträglich schnell gemacht ::) ...

EDIT:
(wieder gelöscht und in Folgebeitrag aufgenommen)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Nachtrag:

Zwei Punkte noch:
- Der Thread-Titel ist nicht besonders aussagefähig; wie wäre es mit "Betatester für AutoShutterControl gesucht!"
- Ich hoffe, es ist geplant, diesen Dummy (Rolladendummy) asap abzuschaffen? Eigentlich sollte es ohne weiteres möglich sein, die ganzen Attribute usw. direkt am Modul-Device zu setzen (dafür scheint der Dummy ja da zu sein, oder?)
EDIT: Und soll die Diskussion zum Modul hier stattfinden, in einem separaten Thread oder auf Github?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Zitat von: Beta-User am 02 September 2018, 17:34:01
Nachtrag:

Zwei Punkte noch:
- Der Thread-Titel ist nicht besonders aussagefähig; wie wäre es mit "Betatester für AutoShutterControl gesucht!"
- Ich hoffe, es ist geplant, diesen Dummy (Rolladendummy) asap abzuschaffen? Eigentlich sollte es ohne weiteres möglich sein, die ganzen Attribute usw. direkt am Modul-Device zu setzen (dafür scheint der Dummy ja da zu sein, oder?)

Du meinst jetzt sicherlich den Dummy für das 99_myUtils Skript oder? Sowas gibt es doch gar nicht mehr. Dafür ist doch das Device vom Modul da.
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

Argh, dann ist das noch ein Rest von einem alten Versuch; kommt sofort weg!

Danke!

Anbei noch eine Textfile für das Erstellen einer kompletten Familie samt zweier "Muster-Nichtmitbewohner" - Gast1 und Service1, die für Leute stehen, die nur zu bestimmten Gegebenheiten erwartet werden (Putzfrau). Da gibt es ein zusätzliches set für "xpectedPresence", was so viel bedeuten soll wie: der Besuch ist ok/geplant/bekannt, wenn "1" und außerplanmäßig, wenn "0".


Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Zitat von: Beta-User am 02 September 2018, 17:53:57
Argh, dann ist das noch ein Rest von einem alten Versuch; kommt sofort weg!

Danke!

Anbei noch eine Textfile für das Erstellen einer kompletten Familie samt zweier "Muster-Nichtmitbewohner" - Gast1 und Service1, die für Leute stehen, die nur zu bestimmten Gegebenheiten erwartet werden (Putzfrau). Da gibt es ein zusätzliches set für "xpectedPresence", was so viel bedeuten soll wie: der Besuch ist ok/geplant/bekannt, wenn "1" und außerplanmäßig, wenn "0".

Konntest Du denn schon erfolgreich etwas testen?
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

#35
Bin noch am Einrichten...

Worüber ich jetzt als erstes gestolpert bin, ist die Vorbelegung der Attribute. Das ist für meine HM's verkehrt rum...

Ist das hier das Muster für die Lösung:
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Closed_Pos 0
Oder muß man irgendeine Option setzen, damit das Modul das invertiert?

Btw.: ich habe auch einen Rolladenaktor für meine Leinwand. Die sollte nach Möglichkeit also direkt rausgeworfen werden können, wenn man das Array über den (Sub-) TYPE erstellt ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Eigentlich sollten Vorbelegungen gegeben sein. Siehe ersten Post

AutoShuttersControl_Closed_Pos 100                  in 10 Schritten von 0 bis 100
    AutoShuttersControl_Ventilate_Pos 80      in 10 Schritten von 0 bis 100
    AutoShuttersControl_Open_Pos 0
    AutoShuttersControl_Pos_Cmd pct                     der set Befehl um den Rolladen in Prozent Angaben zu fahren.

Bei dir also closed auf 0 und Open auf 100 und ventilate auf 20 oder 30

Hast du von gestern Abend die Version gezogen?
Hätte noch Änderungen drin.
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

CoolTux

Version 0.0.48 solltest Du bitte verwenden.
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

Als Version wird 0.0.48 angezeigt, war heute morgen kurz nach 8, als ich das vom github geholt habe.

Die Vorbelegung an sich ist auch vorhanden, nur paßt die eben für HM-Aktoren nicht ;) - ein weiteres Argument, um "auto" vorrangig über den TYPE zu steuern. Dann können nämlich hardwarespezifische Standards besser berücksichtigt werden... (geht natürlich auch anders).

Habe jetzt folgende Vorgaben:

attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Closed_Pos 0
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Open_Pos 100
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Ventilate_Pos 30
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Shading_Pos 55

Und dann noch für meine Drehgriffe:
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_WindowRec_subType threeStateSensor
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Shading und Drehgriff Attribute werden noch nicht berücksichtigt. Der Rest ist aber korrekt so eingestellt.
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

CoolTux

Mag sein das man über Type Hardware spezifische Standards besser berücksichtigen kann, aber dann programmieren wir uns dumm und dämlich und aus 20000 Zeilen werden 50000.
Genau dafür gibt es die Attribute pro Rolladen.
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

CoolTux

Ich habe noch bisschen was in die Beschreibung im ersten Post geschrieben.
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

Agreed, was die Vorgaben angeht, war ja auch recht einfach zu korrigieren.

Vielleicht wäre/wird es einfacher, wenn man das ganze zweistufig aufbaut: Erst das Basis-Device. Darin kann man dann die eigenen Defaults festlegen - meistens dürfte es ja reichen, wenn man die "Offen"-Position benennt. Dann erst die Devices hinzufügen. Häufig dürfte es ja so sein, dass dass in einer Installation einheitlich ist.

Ansonsten bin ich jetzt mal gespannt, wann meine diversen Rolläden zu- und wieder auf gehen....
Was das Zugehen angeht, war das gerade eben - gefühlt zu früh, da muß ich also dann gleich was umkonfigurieren. Wird aber dauern.

Habt ihr zufällig schon ein Muster für eine passende ReadingsGroup um die ganzen Zeiten usw. schön zentral einstellen zu können?

Danke jedenfalls nochmal bis dahin, vorbildlicher Support :) .

Schönen Abend noch,
Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Zitat von: Beta-User am 02 September 2018, 20:07:20.

Habt ihr zufällig schon ein Muster für eine passende ReadingsGroup um die ganzen Zeiten usw. schön zentral einstellen zu können?

Danke jedenfalls nochmal bis dahin, vorbildlicher Support :) .

Schönen Abend noch,
Beta-User

Du bist zu schnell mein Lieber. Ein Schritt nach dem anderen. Aber wenn Du magst kannst Du eine zusammenstellen. Weiß nur gerade nicht was Du da alles einstellen willst. Die Attribute stellt man einmalig ein und dann sollte es gut sein. So die Idee.


Danke Dir
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

CoolTux

Zitat von: Beta-User am 02 September 2018, 20:07:20
Was das Zugehen angeht, war das gerade eben - gefühlt zu früh, da muß ich also dann gleich was umkonfigurieren. Wird aber dauern.

Ich habe soeben noch dem HORIZON einen Wert für die Höhe über dem Horizont verpasst. Siehe ersten Post.
Desweiteren Beachtung der Attribute AutoShuttersControl_Mode_Down und AutoShuttersControl_Mode_Up



Grüße
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