[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

Begonnen von CoolTux, 28 Februar 2019, 09:09:18

Vorheriges Thema - Nächstes Thema

Beta-User

Kommt darauf an, wie wir weiter vorgehen.

Machen wir einen "Kanal" aus dem ganzen, ist es auch mit Einzel-Angaben ok (tauchen nur auf, wenn gesetzt, default-Werte auch vorhanden, wenn nicht ausdrücklich gesetzt).

Bleibt es "as is", finde ich die Zusammenfassung gut, würde dann aber in die Richtung tendieren
ASC_BlockingTimes 1200 [3600[:3600]]
Also als Minimalangabe wäre eine einzige Zeit erforderlich, die dann auch für die anderen beiden Werte gilt. Gibt man den optionalen beforeDayOpen-Wert an, wird der dann auch für abends verwendet, wenn der nicht auch noch separat angegeben ist.
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

Ich bin noch am schwanken. Eigentlich würde ich gerne ein Frontend haben wo alle Rollläden Horizontal stehen und die Attribute Vertikal.
Dort macht man dann seine ganzen Einstellungen und drückt auf speichern. Danach wird die Konfig als verstecktes Reading in JSON Format in den jeweiligen Rollladen geschrieben.

Was denkst Du darüber?
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

Mir gefällt zunehmend der "Kanal"-Ansatz, aber wie bereits geschrieben: Wir sollten da m.E. mal auch Leute befragen, die mehr Erfahrung mit möglichen Ansätzen dazu haben, mein eigener Horizont ist da möglicherweise immer noch zu beschränkt. Vielleicht gibt es noch bessere Ideen?

Ich sehe folgende Vorteile bei "Kanal":
- Wir müßten gar nicht in fremden Devices rumschreiben, ASC-Einstellungen und Rollladenaktor wären getrennt bzw. nur lose verbunden.
- Die ASC-Einstellungen können FHEM-Raum-mäßig getrennt vom Rollladen behandelt werden; damit wäre die Anwenderebene von der Konfigurationsebene getrennt bzw. trennbar.
- Die Zahl der Attribute ist nicht mehr so wichtig, weil nur sichtbar zu machen wäre, was der User anders haben will wie das, was der jeweilige Default vorsieht; außerdem wäre die Liste insgesamt erst mal kürzer, weil die Readings des Rollladens selber dann ja nicht an der Stelle vorweg kommen.
- Internals pro Rollladen wären für den informierten User leichter sichtbar zu machen.
- damit wäre der ReadingsGroup-Ansatz weiter kein Problem und wir an der Stelle schneller fertig.
- Die Konfiguration würde weiter "ganz normal" in der cfg stehen (in der statefile hat auch Nachteile).

(Das mal auf die Schnelle). Außer dem "ist nicht mehr beim Rollladen direkt" und dem vielleicht nochmals erforderlichen massiven Umbau sehe ich - aus Anwendersicht - nicht die großen Nachteile.
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 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

Auch nur kurze Info: Läuft seit eben, werde wie üblich berichten, wenn mir was auffällt...
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

FunkOdyssey

Ich würde mir ja gerne ein Bild von der aktuellen Entwicklungsversion machen.
Es ist doch richtig, dass damit keine ReadingsGroups mehr anlegbar sind, oder?
Oder habe ich etwas übersehen und es gibt bereits Lösung dafür?

Beta-User

Zitat von: FunkOdyssey am 29 März 2019, 13:44:57
Ich würde mir ja gerne ein Bild von der aktuellen Entwicklungsversion machen.
Es ist doch richtig, dass damit keine ReadingsGroups mehr anlegbar sind, oder?
Oder habe ich etwas übersehen und es gibt bereits Lösung dafür?
Soweit ich mich entsinne, haben wir nur dort "Probleme" mit ReadingsGroups, wo jemand dann erweiterte Einstellmöglichkeiten sucht/benötigt. Die "normale" Konfiguration müßte auch so gehen.

Also z.B. wind: Es reicht, die obere Grenze anzugeben, ab der gefahren werden soll. Wohin, ergibt sich dann automatisch aus der open Position (bzw. dem ASC-Aktortyp). Die untere Grenze wird ebenfalls errechnet. Nur wer was anderes haben will, kann nicht einfach _einen_ nummerischen Wert in das Feld schreiben, alle anderen schon ;) .
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

FunkOdyssey


Beta-User

Na ja, man kann das immer noch über eine Devspec-Anweisung zentral vergeben, nur halt nicht via ReadingsGroup.

(Anmerkung am Rande: Ich mache das Öffnen und Schließen im Moment über Astro und bin echt verblüfft, wie gut das mit der aktuellen Helligkeit außen paßt). Ist zwar unabhängig vom aktuellen Wetter, aber genauer brauche ich das eigentlich gar nicht.
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

Beta-User

Doch noch was zu den Timern: auch bei mir sind die Rollläden heute morgen nicht gefahren, die timer stehen jetzt zum einen auf morgen früh, zum anderen sind sie "seltsam", da um eine Stunde verschoben; letzeres hat vermutlich mit der Zeitumstellung zu tun.

Da ist irgendwas kaputt gegangen...
(List spare ich mir, sollte einfach nachzustellen sein)
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

Vorhand

Leider geht meine Beschattung noch immer nicht. Hab inzwischen Brightness und Temperatur mittels dummy versorgt - auch ohne Erfolg.
Sind denn die verwendeten Werte der ASC über irgendeine Variable darstellbar? Bei Brightness- und Temperatursensor kann ich eintragen was ich will, die meckern nicht.

Meine Frage zu den attr ASC_AutoAstroModeEvening steht im RolloDevice auf none. Im ASCModul "ASC_autoAstroModeEvening" auf civil, war noch offen.
Muss das auch im RolloDevice auf civil gestellt werden?
Grüße
Viele Grüße
Raspi,Homatic,ESP,Fronius,KIA-PHEV,DHW300,Mi,Shelly

CoolTux

Zitat von: Beta-User am 30 März 2019, 09:47:37
Doch noch was zu den Timern: auch bei mir sind die Rollläden heute morgen nicht gefahren, die timer stehen jetzt zum einen auf morgen früh, zum anderen sind sie "seltsam", da um eine Stunde verschoben; letzeres hat vermutlich mit der Zeitumstellung zu tun.

Da ist irgendwas kaputt gegangen...
(List spare ich mir, sollte einfach nachzustellen sein)

Das mit den um eine Stunde verschoben ist bekannt. Aber da dies zweimal im Jahr vor kommt, spare ich mir vorerst ein eingreifen.

Das mit dem nicht fahren ist schon viel interessanter. Waren denn gestern die Timer korrekt?
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: Vorhand am 30 März 2019, 10:29:54
Leider geht meine Beschattung noch immer nicht. Hab inzwischen Brightness und Temperatur mittels dummy versorgt - auch ohne Erfolg.
Sind denn die verwendeten Werte der ASC über irgendeine Variable darstellbar? Bei Brightness- und Temperatursensor kann ich eintragen was ich will, die meckern nicht.

Meine Frage zu den attr ASC_AutoAstroModeEvening steht im RolloDevice auf none. Im ASCModul "ASC_autoAstroModeEvening" auf civil, war noch offen.
Muss das auch im RolloDevice auf civil gestellt werden?
Grüße

Dann brauchen wir so langsam eine verbose 4 Ausgabe vom ASC Device. Triggern tut für die Beschattung Brightness Sensor und das Astro/Twilight Device. Sobald die beiden ein Event werfen wird die Beschattungsroutine angeworfen.
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 30 März 2019, 11:29:20
Das mit dem nicht fahren ist schon viel interessanter. Waren denn gestern die Timer korrekt?
Ich hatte zwar gestern nur einen oberflächlichen Blick drüber geworfen, bin aber der Meinung: ja!

(wurde ja noch von jemandem im Parallelthread berichtet, dass die Entwicklerversion dement ist ;) . Allerdings lief die bei mir einen Tag länger, sollte also nichts mehr mit einem Neustart zu tun haben, uptime in FHEM liefert 2 days, 04:39:30.)

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