FHEM > Automatisierung

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

(1/3) > >>

Beta-User:
Hallo Cooltux,

gelegentlich gab es Bedarf an speziellen Fahrbefehlen. Dazu hatte ich vor einiger Zeit mal geschrieben:

--- Zitat ---Vielleicht 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?).
--- Ende Zitat ---

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

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?

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

CoolTux:
https://git.cooltux.net/FHEM/mod-AutoShuttersControl/issues/53

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

--- Ende Zitat ---

Ich habe das Attribut ASC_CommandTemplate genannt. Gleich den anderen Attributen in einem Rollo Device

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln