[via update verfügbar] [ASC] beliebigen Fahrbefehl zulassen?

Begonnen von Beta-User, 25 Oktober 2021, 17:08:40

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo Cooltux,

gelegentlich gab es Bedarf an speziellen Fahrbefehlen. Dazu hatte ich vor einiger Zeit mal geschrieben:
ZitatVielleicht muss man sich mit dem Thema auch hinter den Kulissen nochmal befassen. "Damals" gab es zwar mal eine Sammlung vorab, wer was braucht an Kommandos für die Lamellensteuerung, aber da war HM-IP noch nicht besonders verbreitet gewesen, und Lamellen hatte schon gleich keiner...
Andererseits ist jeder weitere "Tweak" geeignet, für weitere Verwirrung und/oder Komplexität zu sorgen, und rückwärtskompatibel sollte es dann auch noch sein. Schwierig.

@CoolTux: evtl. könnte man (doch) sowas wie
Code: command="set $DEVICE $cover; set xyz $slat"oder
Code: command="set $DEVICE pct $cover slats $slat"zulassen?

In der Ausführung müßte man dann erst checken, ob was "spezielles" da steht, dann entweder normal weiter oder diese drei Parameter vorher extrapolieren und dann das Ergebnis z.B. an AnalyzeCommandChain() übergeben; damit sollte sich (fast) alles erschlagen lassen, was so "kreucht und fleucht"?

(Sowas für den normalen Fahr-Command würde dann auch das SPS-Problem von weiter oben lösen?).

Eine Rückmeldung gab es bisher leider nicht, anbei daher der ungetestete Versuch, das mal "in Code" zu fassen, wobei im Attribut "ASC_commandTemplate" dann im Prinzip beliebiger Code stehen kann, also sowohl Perl wie "normale FHEM-Kommandos", und an Variablen zugelassen wären $name, $level und $slatLevel.
Klar ist, dass sich der User dann selbst darum kümmern muss, dass das Kommando in jedem Fall paßt und unnötige Fahrbefehle aussortiert werden.

Lösen könnte das insbesondere:
- HM-IP Jalousien;
- das SPS-Thema von sukram in https://forum.fhem.de/index.php/topic,112325.msg1172231.html#msg1172231;
- prinzipiell alle "atypischen Fahrbefehle"

Hab's nur kurz angetestet, scheint zu funktionieren...

Falls das gefällt, kann ich gerne die commandref entsprechend ergänzen.

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

Sieht auf den ersten Blick ok aus und wenn Du sagst das es wohl soweit geht werde ich es gerne zum testen implementieren. Ich werde das auslesen des Attributes in das entsprechende Package noch auslagern.

Magst Du für englisch und deutsch ne kurze commandref schreiben?
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

commandref folgt gerne.

Soll das Attribut weiter ASC_commandTemplate benannt werden und passen die Parameter-Benennungen?

Was Testen angeht: Prinzipiell folgt das der Logik, sie auch an anderer Stelle implementiert ist (z.B. WeekdayTimer, der ist auch gepackaged). Da bisher keine Rückmeldung kam, habe ich erst mal nur kurz angetestet, wie sich das im Testsystem verhält, und da sah das ok aus. Ist keine slat-Position hinterlegt, kommt dann die (erwartete) "-1". Viel mehr kann ich dazu nicht sagen, aber der Eingriff ist ja auch eher "minimalinvasiv"...
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

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 25 Oktober 2021, 17:32:37
commandref folgt gerne.

Soll das Attribut weiter ASC_commandTemplate benannt werden und passen die Parameter-Benennungen?

Was Testen angeht: Prinzipiell folgt das der Logik, sie auch an anderer Stelle implementiert ist (z.B. WeekdayTimer, der ist auch gepackaged). Da bisher keine Rückmeldung kam, habe ich erst mal nur kurz angetestet, wie sich das im Testsystem verhält, und da sah das ok aus. Ist keine slat-Position hinterlegt, kommt dann die (erwartete) "-1". Viel mehr kann ich dazu nicht sagen, aber der Eingriff ist ja auch eher "minimalinvasiv"...

Ich habe das Attribut ASC_CommandTemplate genannt. Gleich den anderen Attributen in einem Rollo Device
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

#5
OK, dann hier mal ein erster Wurf für die commandref :) .
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

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

#7
... Dann müssten nur noch unsere drei potentiellen Tester Bescheid bekommen.... :)   
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

Kann es sein das bei den Werten noch der eigentliche Wert aus ASC_Pos_Reading fehlt

ASC_CommandTemplate  set $name $pct

setzt state und nicht pct.
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

Das Beispiel für den Hauptkanal war schon beabsichtigt. $pct finde ich übrigens nicht gut, der Wert kann auch dim sein oder von -55 bis 42 reichen. Daher der $level-Vorschlag.
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

Also ich habe einfach stur

ASC_CommandTemplate set $name $level

gesetzt. Geht natürlich bei mir nicht.

Muss also heißen

ASC_CommandTemplate set $name pct $level
So wäre der komplette Fahrbefehl. Ich denke das sollte in der Commandref noch besser rüber kommen. Die wenigsten Rollos können mittels set ROLLO 100  aus Position hundert fahren. Mein ist ein spezielles Commando dafür da wie level, pct oder was auch immer.
Verstehst was ich meine?
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

Na ja, das ganze ist gedacht für Fälle, die eben nicht dem Standard entsprechen, und sollte daher auch nur gesetzt werden, wenn man es braucht. Testen ist da der Ausnahme-Fall... Das darf m.E. ruhig auch über die Beispiele rüberkommen.

PS: $pos und $posSlat wäre vielleicht noch eine Variante, die etwas näher an den anderen Attribut-Namen dran wäre?
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 25 Oktober 2021, 20:41:40
Na ja, das ganze ist gedacht für Fälle, die eben nicht dem Standard entsprechen, und sollte daher auch nur gesetzt werden, wenn man es braucht. Testen ist da der Ausnahme-Fall... Das darf m.E. ruhig auch über die Beispiele rüberkommen.

PS: $pos und $posSlat wäre vielleicht noch eine Variante, die etwas näher an den anderen Attribut-Namen dran wäre?

Ach ich denke wir lassen das vorerst mal so und schauen was die Tester daraus machen. Wer genau kann denn nun am besten testen?
Reinhard vielleicht?
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

#13
Reinhard. M, marvin78 und sukram? Evtl. den mega-Thread kurz aufmachen?

EDIT: Mache hier zu, weiter geht es in https://forum.fhem.de/index.php/topic,123670.0.html
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