Autor Thema: [ASC] - ACHTUNG!!! Tester gesucht, @Reinhard. M, @marvin78 und @sukram und ALLE!  (Gelesen 2189 mal)

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 27260
Hallo Leute,

Dank Beta-User gibt es in ASC nun die Möglichkeit für jedes Rollo einen User definierten Fahrbefehl an zu geben.
Siehe hierzu auch
https://forum.fhem.de/index.php/topic,123659.0.html

Beta-User und ich würden uns sehr freuen wenn die User welche Probleme mit den Standardfahrbefehl in ASC haben einmal den aktuellen Patch testen könnten.
Hierzu am besten einen zusätzlichen Updatekanal in update einfügen

update add https://git.cooltux.net/FHEM/mod-AutoShuttersControl/raw/branch/patch-implementationCommandTemplate/controls_AutoShuttersControl.txt
und dann

update
gefolgt von

shutdown restart
Entfernen könnt ihr das ganze dann wieder mit

update add https://git.cooltux.net/FHEM/mod-AutoShuttersControl/raw/branch/patch-implementationCommandTemplate/controls_AutoShuttersControl.txt
wenn der Patch später dann offiziell ist.

Wie das ganze mit dem zusätzlichen Attribut ASC_CommandTemplate zu händeln ist kann man der aktualisierten CommandRef entnehmen.


Meldet Euch wenn es Fragen oder Probleme gibt.



Grüße
Marko
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/
Mein Dokuwiki:
https://www.cooltux.net
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline marvin78

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5857
Vielen Dank @CoolTux. Ich werde es nachher probieren. :)

Offline marvin78

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5857
Direkt eine (vermutlich doofe) Frage:

Wenn ich den Fahrbefehl so definiere, woher bekommt ASC die Werte für $slatLevel und $level?

set $name datapoint 4.LEVEL_2 $slatLevel 4.LEVEL $level
« Letzte Änderung: 26 Oktober 2021, 09:03:31 von marvin78 »

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 27260
Direkt eine (vermutlich doofe Frage):

Wenn ich den Fahrbefehl so definiere, woher bekommt ASC die Werte für $slatLevel und $level?

set $name datapoint 4.LEVEL_2 $slatLevel 4.LEVEL $level

Das sind Platzhalter für die Umwandlung in interne Variablen. Er nimmt dann entsprechend die Werte welche für den jeweilige Fahrgrund angegeben wurden.
Beispiel:
ASC_Closed_Pos 0:3
Dann ist $level 0 und $slatlevel 3


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/
Mein Dokuwiki:
https://www.cooltux.net

Offline marvin78

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5857
Danke. Ist das auch irgendwo dokumentiert? Ich habe es zumindest so explizit nicht gesehen.

Die Doku sagt ja für ASC_Closed_Pos als Beispiel:

Zitat
the closed position value from 0 to 100 percent in increments of 10. (Default: dependent on attributASC 100/0).

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16258
(auch schon fertig...)
Das sind die Werte, die für das jeweilige "Ereignis" im entsprechenden Attribut hinterlegt sind. Also wenn "morgens öffnen" mit "100:100" belegt ist, kommt da $level=100 und $slatLevel=100, für "shading" "30:50" wäre es dann $level=30 und $slatLevel=50.

Dieser Zusammenhang mit den normalen "venetian"-Optionen war der Grund, warum das in der commandref direkt hinter dem "Jalousieattribut" auftaucht.

Verbesserungsvorschläge für die commandref sind gerne gesehen, falls da was unklar ist...

@CoolTux: evtl. sollte man noch einen "echten Perl-Befehl" in der commandref ergänzen, etwa
myPerlCode("$name", $level, $slatLevel)
Apropos commandref:
the closed position value from 0 to 100 percent in increments of 10. (Default: dependent on attributASC 100/0).Das ist m.E. mehrfach nicht ganz richtig: Der Wertebereich ist im Prinzip beliebig, und nur die 10-er-Schritte kommen aus der (m.E. in Teilen unnötig strengen) Vorgabe für die Attribute, man kann aber auch völlig andere Werte setzen...
Vielleicht könnte man das auch bei Gelegenheit mal anpassen.
« Letzte Änderung: 26 Oktober 2021, 09:12:36 von Beta-User »
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline marvin78

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5857
Ich würde die Option tatsächlich bei den entsprecheden Positions-Attributen in der Doku mit aufnehmen. Laut commandref kann man dort nur  Werte von 0-100 angeben und wenn man es so liest, würde man vermuten, dass es nur Integer-Werte sind. Auch ist das Widget bei bspw. ASC_Open_Pos ein Dropdown (bei Closed_Pos gibt es keines).

Offline marvin78

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5857
Apropos commandref:
the closed position value from 0 to 100 percent in increments of 10. (Default: dependent on attributASC 100/0).Das ist m.E. mehrfach nicht ganz richtig: Der Wertebereich ist im Prinzip beliebig, und nur die 10-er-Schritte kommen aus der (m.E. in Teilen unnötig strengen) Vorgabe für die Attribute, man kann aber auch völlig andere Werte setzen...
Vielleicht könnte man das auch bei Gelegenheit mal anpassen.

Genau das meinte ich.

Offline marvin78

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5857
Eine andere Frage: Kann ich die Positionen für und bei ASC testen, ohne das eine Bedinung (Astro, Helligkeit...) zutreffen muss? Also sowas wie: Fahre jetzt Closed_Pos an?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16258
Na ja, wenn du die Zeiten entsprechend anpaßt, sollte das gehen...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 27260
Ich schaue mir die Doku noch mal genauer an.
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/
Mein Dokuwiki:
https://www.cooltux.net

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16258
Ich schaue mir die Doku noch mal genauer an.
...und vielleicht auch die Attribut-Vorbelegung an sich? (Es gab da mal vor Ewigkeiten einen Vorschlag mit widgets, und ich habe auch noch im Ohr, dass da ein "geht nicht" kam mit dem Hinweis, das später dann ggf. nochmal intensiver zu beleuchten ;) .)
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline marvin78

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5857
Ich habe bei einer der HmIP-Wired Jalousien folgendes gemacht:

attr HM_Roll_EzTerrasse ASC_Down time
attr HM_Roll_EzTerrasse ASC_Closed_Pos 0:0
attr HM_Roll_EzTerrasse ASC_Time_Down_Early 09:25
attr HM_Roll_EzTerrasse ASC_CommandTemplate set $name datapoint 2.LEVEL_2 $slatLevel 2.LEVEL $level

Die Fahrt hat funktioniert.

Weitere Tests sind Live-Tests. Ich werde versuchen, wenn ich es zeitlich schaffe, das in alle Jalousien der Schwiegermutter einzubauen und schauen, ob die Fahrten stattfinden.

Vielen Dank an euch beide @Beta-User und @CoolTux. Das wertet ASC um ein vielfaches auf, wie ich meine. Ich mag solche generisch nutzbaren Dinge :)
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16258
Vielen Dank an euch beide @Beta-User und @CoolTux. Das wertet ASC um ein vielfaches auf, wie ich meine. Ich mag solche generisch nutzbaren Dinge :)
Danke zurück für's schnelle testen!

(Ich mag auch generisch nutzbare Schnittstellen, finde allerdings, dass es auch eine Stärke von ASC ist, dass man sowas in der Regel gar nicht braucht :) ).

@CoolTux:
Einen Ergänzungs-Vorschlag hätte ich noch: könnten wir evtl. den Fahrtgrund noch mit übergeben? Dann hätte der User wirklich alle Infos, die er braucht, um selbst was anzuflanschen. (Ich hatte mir das nicht intensiver angesehen, und wollte erst mal einen funktionierenden Vorschlag für die drei genannten Problemkreise liefern; also: falls es eine einfache Möglichkeit gibt, das mitzugeben...?).
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline marvin78

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5857


(Ich mag auch generisch nutzbare Schnittstellen, finde allerdings, dass es auch eine Stärke von ASC ist, dass man sowas in der Regel gar nicht braucht :) ).

Ja. Ich bin da zwiegespalten und schieße mich auf das "in der Regel" ein. Usability ist eine Frage der Definition und des Userkreises. Die Welt dreht sich (schnell) weiter. Da wird sowas schnell veraltet, wenn man nicht auf alles reagiert. HMIP und Jalousien bzw. die anderen Fälle sind hier sicher nur ein Anfang. Wenn Module, wie ASC einen nicht festlegen, weil es solche Mittel, wie dieses bzw. APIs gibt, dann ist das nahe an perfekt :)