Variable an Attribute übergeben?

[flummy1978]

Hallöchen zusammen,

auch wenn ich schon ein paar Sachen mit Fhem probiert habe, bin ich ganz sicher noch in den Kinderschuhen. Da ich aber jetzt durch die Winterzeit n bisschen mehr Zeit hab mich damit zu befassen, versuche ich meine Programmierung für später zu planen, bzw so einfach wie möglich gestalten. Ich möchte gerne, einige Einstellungen, die ich während des Testens sicherlich öfter mal hin und her stelle, die aber später möglicherweise auf einem Wert bleiben mittels Variablen übergeben.

Aus diesem Grund habe ich mir einen Dummy gemacht, der ein paar Einstellungen enthalten soll (später noch mehr):

Code Auswählen Erweitern

Internals:
   CFGFN     
   FUUID      5c5c4d09-f33f-bea8-d591-7186f0e5cb8e82cc
   NAME       setupVars
   NR         334
   STATE      off
   TYPE       dummy
   OLDREADINGS:
   READINGS:
     2019-02-07 17:11:33   state           off
     2019-02-07 17:11:33   zaehler_interval 1200
     2019-02-07 17:11:33   zaehler_oldread gerundet,vorheriger
Attributes:
   alias      Variablen
   devStateIcon .*:icoTool
   group      Zähler
   room       Keller
   setList    on off
   sortby     99
   userReadings zaehler_interval {"1200"},
zaehler_oldread {"gerundet,vorheriger"}
   webCmd     :

Diese Variablen möchte ich dann eben an diverse Devices übergeben. Um bei dem Beispiel oben zu bleiben übergebe ich z.B. den Inhalt von zaehler_interval (1200) zum rechnen an ein Userreading:

Code Auswählen Erweitern

..... (ReadingsVal("setupVars","zaehler_interval",0)) .....

Hier funktioniert das Ganze auch wunderbar (Es wird korrekt gerechnet etc)
Dummerweise bekomme ich Fehlermeldungen, wenn ich versuche diesen Wert bsw. in ein event-min-interval oder oldreadings Attribut zu übergeben. Die Inhalte wären in diesem Beispiel:

attr zaehler.strom.keller event-min-interval state:1200
attr zaehler.strom.keller oldreadings gerundet,vorheriger

Fett geschrieben sind die Variablen die ich aus dem Dummy heraus gerne übergeben würde.

Alles was ich bisher hinbekommen habe, waren diverseste Syntax / Lese oder sonstige Fehler 
Wenn das funktioniert, bin ich mir sicher, dass ich mir in vielen Fällen die Progerammierung hinterher erleichtern kann.

Vielleicht hat ja jemand von Euch ne Idee, wie ich das umsetzen kann..... Oder auch einfache Argumente, warum ich das so keinesfalls machen sollte

Vielen Dank im Voraus
Grüße
Andreas

[CoolTux]

Wie genau hast du denn versucht diesen Wert in das Attribut zu bekommen?

[flummy1978]

Eben genauso wie es im Userreading (und stateformat auch) funktioniert hat:

"original"
event-min-interval                      state:1200

versuch
event-min-interval state:ReadingsVal("setupVars","zaehler_interval",0)

und ähnlichen diversen Formatierungen.

Mir ist durchaus bewusst, dass das vollkommener Blödsinn war, weil ich dadurch nur Syntaxfehler produziert hab, aber so leider auch keinen Befehl gefunden die Vars aus dem Dummy heraus zu übergeben. z.B. Mit einem Befehl alá "Set Attribute ........ "

[CoolTux]

Eben genauso wie es im Userreading (und stateformat auch) funktioniert hat:

"original"
event-min-interval                      state:1200

versuch
event-min-interval state:ReadingsVal("setupVars","zaehler_interval",0)

und ähnlichen diversen Formatierungen.

Mir ist durchaus bewusst, dass das vollkommener Blödsinn war, weil ich dadurch nur Syntaxfehler produziert hab, aber so leider auch keinen Befehl gefunden die Vars aus dem Dummy heraus zu übergeben. z.B. Mit einem Befehl alá "Set Attribute ........ "

Das geht so nicht. userReadings arbeitet mit Events und die Konfiguration ist genau so gewollt. Und es werden ja auch nicht das Attribut userReadings dadurch geändert sondern das Reading. Der Default bei Attributen ist aber ein fester Wert. Oder Du änderst es von extern. Also über Notify oder eigene myUtils.
ABER!! Jede Änderung eines Attributes wird als strukturelle Änderung der Konfig angesehen und muss abgespeichert werden. Rotes Fragezeichen oben links in der Ecke von FHEMWEB.

[KernSani]

die event-* Attribute unterstützen kein Perl Code (siehe Doku). Du kannst dir aber ein notify schreiben, das bei Änderung deines Dummies die Werte in die Attribute schreibt... Ich sehe aber ehrlich gesagt nicht viel Sinn darin. Die event-* Attribute sind zumindest bei mir i.d.r Geräte-spezifisch gesetzt und werden äußerst selten geändert...

[flummy1978]

Hallo Ihr zwei,

zunächst einmal danke, dass Ihr Euch so schnell meinen Fragen annehmen konntet:

ABER!! Jede Änderung eines Attributes wird als strukturelle Änderung der Konfig angesehen und muss abgespeichert werden. Rotes Fragezeichen oben links in der Ecke von FHEMWEB.

Mhm an diesen Aspekt hatte ich nicht gedacht    Da ich aber beim Basteln und Versuchen diese Werte ändern würde, wäre einmal Config Speichern besser als (wie aktuell) event-min-interval an 5 Devices zu ändern, genau wie manch andere Sachen  auch.
Der Vorschlag von Dir oder auch KernSani zeigt, dass es es mir ein wenig um den Schubser in die richtige Richtung ging.

die event-* Attribute unterstützen kein Perl Code (siehe Doku). Du kannst dir aber ein notify schreiben, das bei Änderung deines Dummies die Werte in die Attribute schreibt... Ich sehe aber ehrlich gesagt nicht viel Sinn darin. Die event-* Attribute sind zumindest bei mir i.d.r Geräte-spezifisch gesetzt und werden äußerst selten geändert...

Dass man das mit einem Notify machen könnte, der dann den Perl Befehl ausführen kann wäre es ja ok:
Hast Du da ggf. einen kleinen Ansatz, wie das aussehen müsste? ( Beispiel für das das event-min-... z.B)  Es muss nicht / soll nicht zwingend der genaue Code sein, aber da ich wie gesagt in den Kinderschuhen stecke, tue ich mir mit dem Anfang noch recht schwer.

Der Sinn den ich dahinter gesehen habe:

Ich habe aktuell eine S7 SPS angebunden, an der sich mehrere Ein / Ausgänge / DB Bausteine etc. befinden die jetzt nach und nach über Fhem ausgewertet / bearbeitet werden sollen. Hier ändere ich den Interval beim Programmieren öfter mal. Damit aber alles stimmt (und ich sehe ob das was ich bastele auch wirklich korrekt arbeitet) muss ich immer mehrere devices gleichzeitig ändern.
In dem o.g. Beispiel sind es mehrere Zähler die dann in unterschiedlichen Zeiträumen abgefragt werden... Aktuell sind es 1200 sek (also 20 min) beim Basteln und testen sind es dann mal 2 oder 20 sek.

Ich bin mir sicher, dass ich mir viele "Standardeinstellungen" vereinfachen kann und so bsw. die Standardabfragen aus der S7 sich alle über das gleiche Interval abfragen lassen, oder ich z.B. beim programmieren alle Rollos gleichzeitig deaktivieren kann, anstatt jedes Rollo einzeln anzuklicken und zu deaktivieren ........ Nur so als Beispiel

Vielen Dank für Eure Mühen bis hierhin schon

Grüße
Andreas

[CoolTux]

Code Auswählen Erweitern


CommandAttr(undef,'DEVICENAME event-on-change-reading temperature');

Achtung ist Perlcode, also in einem Notify mit { in die Perlebene gehen und am Ende mit } wieder raus.
Lese am besten dazu auch im Wiki oder der Commandref.

[KernSani]

Ich möchte nicht dein Ansinnen in Zweifel ziehen (oder eigentlich doch) aber hast du dich mal mit DevSpec beschäftigt? Sinnvolle Namensgebung (oder andere Identifzierbarkeit vorausgesetzt) ist sowas ziemlich schnell in der Kommandozeile gemacht:

Code Auswählen Erweitern


set TYPE=ROLLO inactive

oder

Code Auswählen Erweitern


attr zaehler.* event-min-interval state:1200


In diesem Zusammenhang: "." in Devicenamen ist mit Vorsicht zu genießen, da der Punkt in regexp eine spezielle Bedeutung hat.

[flummy1978]

Hallo nochmal ihr zwei,


@CoolTux: Vielen Dank für den Perl Ansatz. Ich hab vor ewigen Jahren mal ein wenig in Perl programmiert, aber das ist mittlerweile schon gut und gern 15 Jahre her, so dass ich da leider das Meiste vergessen hab und mir deshalb bei sowas so schwer tue.

@KernSani: Genau sowas war damit gemeint, mich in die richtige Richtung zu schubsen. Dadurch dass ich jetzt noch sehr am Anfang bin, kann man vielleicht diese Fehler vermeiden, die mich später in einer großen ConfigFile den letzten Nerv kosten würden.
DevSepc hab ich jetzt ein wenig gelesen, könnte durchaus schnell viele der o.g. Beispiele außer Kraft setzen, bzw diese anders ändern.

Die Geschichte mit den Punkten (ist zwar offTopic, aber dafür würde ich jetzt ungern einen neuen Thread aufmachen):
Ich habe das bereits mehrmals gesehen, dass Leute das machen, aber auch schon mehrmals gelesen dass es zu Problemen führen kann, weil eben Fhem in Perl und dort viel mit RegExp gearbeitet wird, wo der Punkt eine eigene Bedeutung hat.
Für mich hat sich aus der Namensgebung: ORT.DEVICEART.ZUSATZINFO.sonstiges oder eben DEVICE(gruppe).INFO.ORT.sonstiges sehr bewährt. Um beim oberen Beispiel zu bleiben heißen die entsprechenden Geräte:  zaehler.strom.keller, zaehler.strom.eg, zaehler.strom.og und zaehler.strom.gesamt. Wenn ich jetzt bsw ein Log, oder DoIF dazu erstellt habe, kam unten automatisch immer die Reihe  "Probably associated with...." und stimmte auch in allen Belangen. Als ich die Sachen noch etwas anders benannt hatte (u.a. ohne Punkt) funktionierte diese Zuweisung nicht.

Hast Du einen Tipp für mich, wie ich mich an "sinnvolle" Namensgebung begeben könnte, wo eben dann auch das "Probably associated with" funktionieren würde ?
Oder soll ich "einfach" nur darauf achten, dass ich die Punkte in den device namen im Falle einer RegExp Abfrage entsprechend in zaehler\.strom\.gesamt escape ?

Vielen Dank nochmal

Grüße
Andreas

[KernSani]

"Probably associated with" richtet sich eigentlich rein nach dem Devicenamen, ob mit oder ohne Punkt sollte da keine große Rolle spielen. Ich persönlich habe ein ähnliches Prinzip bei der Benamsung der Devices, allerdings mit Unterstich statt Punkt. Wenn du dir aber bewusst bist, dass der Punkt in RegExen vielleicht suboptimal ist, sollte es kein größeres Problem darstellen.