FHEM Forum

Ich weiß, dass es in FHEM häufig viele Wege gibt, die nach Rom führen :)
Wie macht Ihr das?

Frage 1

Ich habe Werte, wie z.B. die LUFTFEUCHTIGKEIT_MAX (ein Wert, der in allen Zimmern nicht überschritten werden soll), die sich nie (oder fast nie) ändern. Die könnte man speichern

• als Konstante auslagern in die 99_myUtils.pm
• auslagern in eine eigene Datei für Konstante 99_myKonstante
• als Attribut in ein Device "Haus"
• als Attribut in global

... und sicher gäbe es noch weitere Möglichkeiten


zu 1)Konstante in 99_myUtils.pm
use const LUFTFEUCHTIGKEIT_MAX = 65;    # 65%

zu 2) in 99_myKonstante.pm
use const LUFTFEUCHTIGKEIT_MAX = 65;    # 65%
... und die dann in 99_myUtils.pm einbinden
include ./FHEM/99_myKonstante.pm

zu 3 u. 4 in Device global oder Haus
define Haus dummy
attr Haus userattr LUFTFEUCHTIGKEIT_MAX

set Haus LUFTFEUCHTIGKEIT_MAX 65

Der Vorteil von 1 und 2 wäre, dass weder Nutzer noch ich beim Spielen an Devices da versehentlich was ändern oder löschen.

Der Vorteil von 3 und 4 wäre,

• dass sowohl ich als auch user einfach nach den Werten sehen können, ohne in die Programmierung zu müssen

Bonusfrage :)
Bisher habe ich nur in Thermostaten, Temperatursensoren, Gateways ... gedacht und dafür devices angelegt.
Legt Ihr aber auch, z.B. für Räume, das ganze Haus, das Grundstück etc. (dummy-) devices an, um dort übergeordnete userattr und readings zu speichern?

ich bevorzuge Variante #1. Ob man das als const oder als my var macht sei mal dahingestellt.

Ich benutze Variante #5 und speichere Werte in readings des device "global" (wenn der Wert übergreifend gebraucht wird) oder in einem beliebigen device, wenn der Wert nur dort benötigt wird.

Das bietet mir mehrere Vorteile:

• ich kann mit regulären Mechnismen, z.B. ReadingsVal() einheitlich darauf zugreifen
• die Werte werden bei einem "save" automatisch in der Konfiguration mitgespeichert werden
• es können mit setreading beliebig viele Werte angelegt werden, die nicht erst mit userattr definiert werden müssen
• Werte können geändert werden, ohne zusätzliche Dateien bearbeiten zu müssen

Übrigens: Variante 2 mit include einzubinden ist völliger Quatsch. Aufgrund der Tatsache, dass der angedachte Dateiname mit 99_ beginnt, wird die Datei von FHEM beim Start ohnehin automatisch geladen.

Hab mir schon gedacht, dass mehr oder weniger alle Möglichkeiten genutzt werden ... je nach Vorliebe, dass es aber keine klaren Empfehlungen gibt/geben kannn

Wie handhabt Ihr das hier:

Zitat von: jannis am 02 März 2020, 12:47:33
Bonusfrage :)
Bisher habe ich nur in Thermostaten, Temperatursensoren, Gateways ... gedacht und dafür devices angelegt.
Legt Ihr aber auch, z.B. für Räume, das ganze Haus, das Grundstück etc. (dummy-) devices an, um dort übergeordnete userattr und readings zu speichern?

Zitat von: jannis am 02 März 2020, 12:47:33
Bonusfrage :)
Bisher habe ich nur in Thermostaten, Temperatursensoren, Gateways ... gedacht und dafür devices angelegt.
Legt Ihr aber auch, z.B. für Räume, das ganze Haus, das Grundstück etc. (dummy-) devices an, um dort übergeordnete userattr und readings zu speichern?

Ich besuche das Forum regelmäßig, weil es dort immer wieder Anregungen gibt, was man noch automatisieren kann. Zu Beginn war das sicher noch ergiebiger, aber es gibt immer wieder was Neues.

Zu deiner Frage: ich hab keine Devices die gesamte Räume abdecken, dafür ist mein Zoo an Hardware schon zu uneinheintlich. Ob das überhaupt geht oder sinnvoll ist, wage ich zu bezweifeln, lasse mich aber gerne eines besseren belehren.

Viele​ Grüße​ Gisbert​

Zitat von: jannis am 02 März 2020, 12:47:33
zu 1)Konstante in 99_myUtils.pm
use const LUFTFEUCHTIGKEIT_MAX = 65;    # 65%

Diese Variante hatte ich mal genutzt bzw. migriere gerade davon weg zu
Variante 7: eine Parameter-Tabelle in SQLite
Denn ich musste feststellen, dass die immer gültigen Parameter irgendwann doch eine Ausnahme erfordern.

Größter Aufwand dabei ist, dass ich eine zumindest halbwegs nutzbare Verwaltungsmöglichkeit für die Inhalte bauen muss.
Dafür habe ich jetzt eine Lösung, die etwas wie z.B. *_*_MaxHum = 60 / UG_Vorrat_MAXHUM = 70 ermöglicht. D.h. ich globale Werte festlege, die ich in spezielleren Fällen variieren kann.
Beginn dafür war der Bedarf, Beleuchtungszenarien in Abhängigkeit von Raum+Anwesende Personen+Tageszeit+Wochentag... abzulegen. Als Readings oder User-Attribute wären das in der Spitze eine hohe zweistellige Anzahl von Parametern pro Raum gewesen.

Zitat
Bonusfrage :)
Bisher habe ich nur in Thermostaten, Temperatursensoren, Gateways ... gedacht und dafür devices angelegt.
Legt Ihr aber auch, z.B. für Räume, das ganze Haus, das Grundstück etc. (dummy-) devices an, um dort übergeordnete userattr und readings zu speichern?

Ja und Nein! Genauer: ich habe ein "room"-Device geschrieben, welches die vorhandenen Räume abbildet, aber nicht für derartige Parameter dient, sondern eine Art Middleware, damit ich - wie in der Vergangenheit passiert - bspw. FS20-Dimmer durch HUE-Lampen oder FHT80 durch HM-TC-IT-WM-W-EU ersetzen kann, ohne im eigentlichen Code etwas ändern zu müssen.
Aber eine Notwendigkeit für separate Devices für das Haus oder Stockwerke habe ich noch nicht gesehen. Kommt aber vielleicht noch. Mal schauen!

Mir gefällt die Variante von betateilchen eigentlich ganz gut. Beim Ausprobieren in meiner Konfiguration bin ich allerdings prompt auf die Nase gefallen  :(

Mein Anwendungsfall ist die Bewässerung meines Gartens. Dafür habe ich mir einen recht umfangreichen Regelsatz aufgebaut (je nach Zisternen-Wasserstand mit Wasser aus der Zisterne oder vom Wasserhahn und das für drei unterschiedliche Bewässerungskreise - jeder natürlich individuell einschaltbar oder alle nacheinander im Automatikmodus  8) ). Da möchte ich nämlich nicht in den Regeln direkt jedesmal die (halbwegs konstanten) Zeiten an insgesamt 10 Stellen ändern, wenn sich die Konstante mal ändert (z.B. jetzt, weil ich eine neue, stärkere Bewässerungspumpe habe).

Die Konstanten habe ich für den Test als Readings in einem Dummy-Device abgelegt (die Zeit für Rasen Nord ist nur für den Test so kurz  :) ):

defmod BewaesserungsKonstanten dummy
setstate BewaesserungsKonstanten 2020-05-28 18:01:33 c_BewaesserungszeitRasenNord_sec 10
setstate BewaesserungsKonstanten 2020-05-28 17:52:15 c_BewaesserungszeitRasenSued_sec 240
setstate BewaesserungsKonstanten 2020-05-28 17:51:19 c_BewaesserungszeitTropfschlauch_sec 1200


Beim "händischen" Einschalten via

set Tropfschlauch on-for-timer (ReadingsVal("BewaesserungsKonstanten", "c_BewaesserungszeitRasenNord_sec", 0))

kommt die Fehlermeldung "on-for-timer requires 1 parameter".

Mache ich was falsch oder geht das einfach nicht, weil das Reading gewissermaßen keine echte Konstante ist, aber von on-for-timer eine solche erwartet wird?

Grüße vom hobby_musiker

Klassischer Fehler...

set Tropfschlauch on-for-timer (ReadingsVal("BewaesserungsKonstanten", "c_BewaesserungszeitRasenNord_sec", 0))

Du vermischt einen FHEM Befehl (set) mit perl code (ReadingsVal(...)) ohne das syntaktisch richtig zu machen.

Das hier würde beispielsweise in der Eingabezeile von FHEM funktionieren:

{fhem("set Tropfschlauch on-for-timer ".ReadingsVal('BewaesserungsKonstanten', 'c_BewaesserungszeitRasenNord_sec', 0))}

So schnell wie da die Antwort da war, konnte ich das gar nicht mehr ausprobieren - Ich liebe dieses Forum!

Und - kaum macht man's richtig, schon funktionierts  ;)

Vielen Dank, betateilchen!!!

Grüße vom hobby_musiker