Betatester für neues Modul AutoShuttersControl gesucht!

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

Vorheriges Thema - Nächstes Thema

Deckoffizier

Hallo,

das mit den 16 Sekunden war ich.
Ist aber noch nicht die ganze Wahrheit da die Laufzeit für hoch und runter unterschiedlich ist.
Musste die Zeit auf 21 ändern ist die Zeit für hoch, beim runter fahren greift ja die Endabschaltung bei 16 sek.
Sonst wurde der Rollladen nicht komplett zurück nach oben gefahren in pos 0.

Komisch nur musste die AutoShuttersControl_Open_Pos auf 1 setzen 0 wurde nicht angenommen.
Nun gut scheint schon echt knifflig zu sein hängt ja wohl auch vom Typ wie viel Intelligenz schon drin steckt.
Momentan macht es ja für mich wie es soll.

Gruß
Hans-Jürgen
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Beta-User

Meine Güte, geht das wieder schnell hier...

Zitat von: CoolTux am 13 September 2018, 13:51:02
Mann kann die alternative Oprion zum Einstellen, also zu Fuß über die FHEMWEB Kommandozeile per attr ja im Wiki festhalten.
Danke für die Rückmeldung. Sehe ich genauso, dass man mind. erst mal sonst nichts tun sollte:

Wer was exotisches hat, soll halt eine andere Variante nutzen für's Einstellen als die angebotenen Dropdowns im Device selbst, wichtig ist nur, dass es funktioniert (tut es scheinbar).

Jede Art der Umrechnung dürfte erst mal zu Inkonsistenzen führen, das sollte man im (Modul-) Device selbst erledigen, sofern möglich, oder eben damit leben, dass die Wicklung dicker wird.

Just my2ct.

Wie gesagt, die Frage war _nur_ die nach der sachlichen Richtigkeit der (derzeitigen) Doku!

Zitat von: Cluni am 13 September 2018, 13:56:25
Das ist mir klar. Die Idee ist, dass du dem Rollladen ein min und einen max mitgibst, den man einstellen kann.  Der Wertebereich für zum Beispiel ganz zu (0) bis ganz offen (100) (oder anders herum) bleibt erhalten und wird zum Beispiel in 5% oder auch 10% Schritten angegeben. Der endgültige setvalue wird dann aber über die min und max Angabe berechnet und ggf. gerundet. Daher würde ich 5% Schritte empfehlen, da man dann auch bei 1..16 jeden Wert treffen kann mit einer Angabe von 0..100 in 5% Schritten. Das ginge bei 1ß% Schritten nicht.
Spontane Reaktion: eher dagegen. Kann nämlich z.B. sein, dass ich im Schlafzimmer gerne automatisiert nur zwischen 0 und 20% (=OpenPos) fahren will, aber beim Lüften/ganz offen auf 30%. Wenn da im Hintergrund noch weiter rumgerechnet wird, habe ich Bedenken, dass das insgesamt zu Merkwürdigkeiten führt. Dann lieber immer einen Absolutwert in der Hoffnung, dass im Aktorcode genug Toleranz drin ist, dass das auch auf Dauer halbwegs paßt...

Das dürfte für 99% der User einfacher zu durchschauen sein als eine Lösung, die (auf den ersten Blick) scheinbar mit Absolutwerten arbeitet, aber vom code her vorrangig auf Sonderlocken zielt und irgendwas im Hintergrund umwandelt. Insbesondere dann, wenn es Lösungsmöglichkeiten für die Sonderlocken gibt.

Gruß, 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

Cluni

Zitat von: Beta-User am 13 September 2018, 14:06:16
Spontane Reaktion: eher dagegen. Kann nämlich z.B. sein, dass ich im Schlafzimmer gerne automatisiert nur zwischen 0 und 20% (=OpenPos) fahren will, aber beim Lüften/ganz offen auf 30%. Wenn da im Hintergrund noch weiter rumgerechnet wird, habe ich Bedenken, dass das insgesamt zu Merkwürdigkeiten führt. Dann lieber immer einen Absolutwert in der Hoffnung, dass im Aktorcode genug Toleranz drin ist, dass das auch auf Dauer halbwegs paßt...

Das dürfte für 99% der User einfacher zu durchschauen sein als eine Lösung, die (auf den ersten Blick) scheinbar mit Absolutwerten arbeitet, aber vom code her vorrangig auf Sonderlocken zielt und irgendwas im Hintergrund umwandelt. Insbesondere dann, wenn es Lösungsmöglichkeiten für die Sonderlocken gibt.

Es geht darum, dass man verschiedene Aktoren damit abdecken könnte. Wenn du dir einen Aktor kaufst, der halt nur mit 1 bis 16 gesteuert wird, dann hättest du sonst die Arschkarte und könntest ihn nicht oder nur über Umwegen mit dem Modul steuern.

Ich würde vorschlagen:
- min und max als Attribut anbieten, werden aber nicht vorbesetzt.
- wenn nicht besetzt wird wie gehabt (ohne Umrechnung) angesteuert
- wenn gesetzt, dann wird linear umgerechnet und entweder die Nachkommastellen abgeschnitten oder auf-/abgerundet

Deckoffizier

Hallo Cluni,

der Knackpunkt ist nicht unbedingt alleine der Aktor
ZitatEs geht darum, dass man verschiedene Aktoren damit abdecken könnte. Wenn du dir einen Aktor kaufst, der halt nur mit 1 bis 16 gesteuert wird, dann hättest du sonst die Arschkarte und könntest ihn nicht oder nur über Umwegen mit dem Modul steuern

sondern auch die Fenstergröße(Länge) also Rollladen die über Zeit gesteuert werden.
Deshalb fand ich Euer Modul auch so interessant da es wahrscheinlich nicht nur auf Homematic fixiert ist.

So wie ich etwas Luft habe probiere ich es auch  mit meinem Siro Rollo aus hat schon mal das Reading position statt pos.

Gruß
Hans-Jürgen
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Beta-User

Wir sind uns einig, dass es super wäre, wenn alles so universell ist, dass wirklich alles, was so verfügbar ist an Aktoren auch angesteuert werden kann.
(@Deckoffizier: Schau mal das Rollo-Modul an, vielleicht ist das eine sinnvolle logische Zwischenschicht für dich).

Jedenfalls bei allen bisher diskutierten Modellen geht das, und der einzige Umweg ist der, dass man manuell per Kommandozeile bzw. graphisch/klickibunti per ReadingsGroup (die man ja entsprechend editieren und bei Bedarf vervielfältigen kann) die richtigen Vorbelegungswerte an die Rolläden bekommt.

Und das mit den Attributen ist ja eine nette Sache, aber dass "zu viele" m.E. nicht das Anwenderfreundlichste sind, hatte ich ja bereits (mit der Bitte, das ggf. bei Gelegenheit zu reduzieren) angemerkt; wenn man durch ein Attribut dann plötzlich ein gänzlich anderes Verhalten erzeugt, ist das auch erklärungsbedürftig und im Zweifel nicht besser wie die Anleitung für das "händische" Gradebiegen.

just my2ct. ;) Die Arbeit habt im Zweifel eh' ihr :) .
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

Die Umrechnung sollte nicht unser Modul machen, sondern das Modul welches Hardwareseitig das Rollo unterstützt. Es gibt offizielle und inoffizielle Einigungen wie man zum Beispiel Volume oder Mute oder was auch immer belegt. Das selbe gilt für Rolläden. Deswegen macht man ja Prozentangaben. 0 bis 100. Auf/Zu Zu/Auf.
Also sollte das Modul vom Ralladen dafür sorgen das die 100 Prozent für zu entsprechend umgerechnet werden auf die Laufzeit.

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

Cluni

Ja ok - dann kann man ja auch direkt den Fahrbefehl auch raus schmeißen und nur "pct" unterstützen. Und wahrscheinlich so einiges andere auch noch. Hätte ich so bei der Programmierung meiner Rollladensteuerung gedacht, dann würden heute wahrscheinlich einige Leute noch keine so komfortable Rollladensteuerung in Fhem haben.... just my2ct.... ;)

Cluni


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

FHEM set Befehle sind eine Sache. Du siehst ja das es auch set Befehle ohne passendes Reading gibt was auch doof ist.

Machen wir es so. Ich habe keine Zeit für sowas. Wenn ein Patch kommt oder ein Pull request können wir gerne drüber reden.
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

Deckoffizier

Hallo Beta-User,

um Himmels Willen nur kein Streit....

Bin ja soweit zufrieden man kann sich ja auch zu Tode programmieren wenn man alles exotische mit abdecken will.
Für mich war eben die Laufzeitsteuerung nicht gerade ungewöhnlich kenne mich in den ganzen Modellen ja auch nicht aus.

Bis jetzt habe ich in FHEM für mich gesehen schon viel hinbekommen.

Danke für den Tip zum Modul Rollo hatte ich in der cmdRef nicht weiter gesehen gekannt.
Vom überfliegen her vermute ich, daß ich solch neckischen Sachen wie Astro eben auch dazu herum einbauen muss.
Man kann eben nicht alles haben oder muss sich das am besten passende Aussuchen deshalb bin ich hier erstmal mit ASC GERN dabei.

Gruß
Hans-Jürgen
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Cluni

Zitat von: Beta-User am 13 September 2018, 14:38:26
Wo habe ich die Kurbel hin?!?
;D ;D ;D

;D ;D ;D ;D


Zitat von: CoolTux am 13 September 2018, 14:41:53
FHEM set Befehle sind eine Sache. Du siehst ja das es auch set Befehle ohne passendes Reading gibt was auch doof ist.

Machen wir es so. Ich habe keine Zeit für sowas. Wenn ein Patch kommt oder ein Pull request können wir gerne drüber reden.

Na klar kannst du das so machen - das ist und bleibt dein Modul! Ich wäre der letzte, der dir da einen Vorwurf macht, wenn du etwas machst, wie du es möchtest. Ich habe mir da ja auch nicht reinreden lassen. ;)

Cluni

Nein nein, Deckoffizier - hier gibt es keinen Streit. ;)

CoolTux

Zitat von: Cluni am 13 September 2018, 14:50:50
;D ;D ;D ;D

Na klar kannst du das so machen - das ist und bleibt dein Modul! Ich wäre der letzte, der dir da einen Vorwurf macht, wenn du etwas machst, wie du es möchtest. Ich habe mir da ja auch nicht reinreden lassen. ;)

Naja denk dran ohne Dein Skript gäbe es das Modul so in der Form sicherlich nicht. Ich tue mich immer schwer mit den Anfängen.
Aber wie gesagt wenn was geliefert wird baue ich es gerne ein.  :)
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

Deckoffizier

Hallo Cluni,

eine Bitte..
wie bekomme ich die ohne mein Zutun im zweiten UNIRoll Rollo quasi geerbten Readings wie oldPos wieder weg?
deletereading hat gestern leider nicht geholfen.

Gruß
Hans-Jürgen
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus