HueDevice Update für Eurotronic Spirit ZigBee

[justme1968]

ich würde den cmdalias in diesem fall mit ins template stecken. er ist ja zwingend nötig damit man die temperatur in grad angeben kann statt in 100tel.

im json code kann ich ja leider nicht rechnen und die syntax umzustellen wird unhandlich da ich nicht einfach und sicher zwischen json und perl code unterscheiden kann. beide verwendend die gleichen geschweiften klammern an anfang und ende mit etwas dazwischen.


wenn das mit den bedingungen tatsächlich schon geht haben wir hier den perfekten anlass es auszuprobieren .

[rudolfkoenig]

Die AttrTemplate-Syntax dafuer ist prereq:XXX
Wenn XXX die Form {.*} hat, dann wird sie ausgewertet (und muss 1 zurueckliefern), sonst muss sie den Names eines Geraetes zurueckliefern, per devspec2array Syntax.
prereq wird beim FHEM-Start / { AttrTemplate_Initialize() } ausgewertet, und die Templates, bei denen prereq schiefgeht, werden aus der Liste entfernt.

[justme1968]

ich habe auch den tread mit den ursprünglichen ideen wieder gefunden: https://forum.fhem.de/index.php/topic,99195.0.html .

[Beta-User]

ich würde den cmdalias in diesem fall mit ins template stecken. er ist ja zwingend nötig damit man die temperatur in grad angeben kann statt in 100tel.

Dann eventuell ja, wobei dann für diesen Teil die Auswertefrage via prereq ggf. sinnvoll sein könnte; denn an sich sollte jedes neue Device einen "room" bekommen (hier m.E. optimalerweise den HUE-default), was aber nur dann "ok" ist, wenn der user noch nichts festgelegt hatte (so eine Auswertung macht die GeneralBridge im mqtt2.template-file, wenn ich mich recht entsinne), und eigentlich ist es auch sinnvoll, den user dann zum neuen Device zu leiten (also das anzuzeigen). Das ist einleuchtender, wenn es via post-Behandlung läuft (denke ich jedenfalls, das sind aber alles eher nebensächliche Geschmacksfragen, gebe ich gerne zu...).

Eventuelle Gedanken zum Aufbau der Sprachsteuerungstemplates würde ich ggf. in dem anderen Thread beisteuern... (im Moment fällt mir aber nix neues ein).

[Shojo]

Dann eventuell ja, wobei dann für diesen Teil die Auswertefrage via prereq ggf. sinnvoll sein könnte; denn an sich sollte jedes neue Device einen "room" bekommen (hier m.E. optimalerweise den HUE-default)

So z.B. ?

Code Auswählen Erweitern


....
par:DeviceRoom;Room of the Device.;{AttrVal("heatsetpointX100","room","HUEDevice" )}
....
attr heatsetpointX100 room DeviceRoom


und eigentlich ist es auch sinnvoll, den user dann zum neuen Device zu leiten (also das anzuzeigen). Das ist einleuchtender, wenn es via post-Behandlung läuft.

Und wie ist das umzusetzen ?

[justme1968]

ich habe eben eingebaut das man bei configList statt {...} als json code auch perl:{...} angeben kann. der perl code muss dann einen gültigen json string zurück geben. im perl teil kann man rechnen und spart so den cmdalias.

noch völlig ungetestet... vielleicht hats du kurz zeit dazu.

falls es geht baue ich es auch für setList ein.

edit 2019-06-27: ist jetzt eingecheckt.

[Shojo]

noch völlig ungetestet... vielleicht hats du kurz zeit dazu.

Huhu, gleich mal probiert!

Code Auswählen Erweitern

/heatsetpoint (.*)/:perl:{'{"heatsetpoint":' . $1 * 100 . '}'}
erzeugt den Fehler

Code Auswählen Erweitern

invalid value, 0, for parameter heatsetpoint

[justme1968]

es kann sein as die $X bei eval zurück gesetzt werden. nimm mal bitte $VALUE1 statt $1.

wenn das nicht hilft muss ich in schauen sobald zeit ist.

[Shojo]

nimm mal bitte $VALUE1 statt $1.

Ja das war es  \o\ \o/ /o/  nun geht es!
Sehr geil!

[Beta-User]

Und wie ist das umzusetzen ?

Mit einem Perl-Aufruf aus dem template heraus; DEVCID ist hier der Name des neuen Devices.
Aus dem Code zum A_00_MQTT2_CLIENT_general_bridge (Zeile 41 mqtt2.template):

Code Auswählen Erweitern

{ fhem "trigger $FW_wname JS:location.href='$FW_ME?detail=DEVCID'" if($cl && $cl->{TYPE} eq "FHEMWEB") }
(Credit goes to Rudi)

[Beta-User]

So z.B. ?

Code Auswählen Erweitern


....
par:DeviceRoom;Room of the Device.;{AttrVal("heatsetpointX100","room","HUEDevice" )}
....
attr heatsetpointX100 room DeviceRoom


(hatte ich erst überlesen...)
Im Prinzip ja, wobei ich mich bei allen par-Abfragen an Rudi's Vorarbeit orientiert hatte und grundsätzlich alle Parameter groß schreibe und den Unterstrich als ausschließliches Trennzeichen verwende; das vermeidet tendenziell auch versehentliches Überschreiben anderer Teile beim Ersetzen, man sieht m.E. einfach schneller, was passieren wird.

[justme1968]

sollte man das umleiten aufs device (und andere solche dinge) nicht jeweils in eine routine stecken die nur noch mit den nötigen parametern aufgerufen wird?

das macht die template files kleiner und übersichtlicher und macht auch spätere änderungen einfacher wenn sich in der verbindung zum frontend etwas ändert.

[Beta-User]

Hmm, in der Tendenz finde ich den Ansatz richtig, aber...:
- Zusätzliche Devices zu erstellen, sollte man möglichst soweiso vermeiden (s.o.)
- Das hier ist der 2. Fall, in dem das notwendig ist (neben ein paar ebus-templates, dieses Geräte-Thema erfordert aber mMn sowieso eine etwas intensivere Einarbeitung auf Userseite)
=> geringe praktische Relevanz
- Es ist jeweils eine Zeile pro Zusatzdevice. Kürzer wird es kaum (höchstens innerhalb der Zeile)- würde show (analog list) bei devspec, die nur ein Device erfaßt, auch nur das anzeigen, hätte ich "damals" diesen Befehl genommen. Da hier jetzt am Ende zwei Devices rauskommen, die ggf. noch nachzuarbeiten sind, könnte es sein, dass show hier die bessere Wahl wäre (zusammen mit einem post-Hinweis-Dialogfeld, was jetzt zu tun ist). (Da dieses Verhalten bei show mWn. gar nicht gewollt war mit der Anzeige des "vollen Programms", fällt das aber für obiges Problem weg; dieser Ablauf bei dem Bridge-MQTT2_DEVICE ist (und bleibt vermutlich) ein Spezialfall).

Aber wenn es was zentrales geben sollte, pflege ich das dann gerne ein...

[Shojo]

...
Das hier ist der 2. Fall, in dem das notwendig ist...
...

Durch die neue Möglichkeit jetzt auch Perl bei der configList einzusetzen, fällt hier zum Glück das zusätzlich Device weg

[justme1968]

ich habe die perl code variante für setList und configList eingecheckt.