Kommandos im Userreading ... warum nicht ?

[dirk.k]

Hallo zusammen,

immer wieder lese ich hier, dass Kommandos/Set-befehle usw. im userreading "böse" sind.
Ich glaube diese Aussage der "Wissenden" ja, verstehe nur nicht warum.
Im Beispiel unten (aus meinen Anfangszeiten) schaltet ein Fensterkontakt den Strom für ein Gerät und stellt die Temperatur der Heizung ein.
Aus meiner Sicht ist das so ganz einfach... viele Funktionen übersichtlich aufgelistet ... und funktioniert immer noch.
Kann mir jemand sagen, wo die Nachteile sind oder welche technischen Probleme auftreten könnten?
Und zum Schluss ... Vorschläge wie das besser/richtig gelöst werden würde?
(FHEM-> PERL->FHEM -Mischung bitte ignorieren, das ist/wird ein anderes Thema)

Code Auswählen Erweitern

attr MAX_SC_02543a userReadings LastMaxTemp:onoff.* { ReadingsVal("MAX_TH_1a9aeb","maximumTemperature",0);; },\
\
tmp:onoff.* { \
  if(ReadingsVal("$NAME","onoff",0) == 1 ) { \
    fhem("set Sonoff_S20_01 0") ;;\
    fhem("set MAX_TH_1a9aeb maximumTemperature 9");;\
    return "auf"\
  };; \
  my $tmp = OldReadingsVal("MAX_TH_1a9aeb","maximumTemperature","4");;\
  fhem("set MAX_TH_1a9aeb maximumTemperature on");;\
  fhem("set MAX_TH_1a9aeb desiredTemperature auto");;\
  fhem("set PostIt remove AlarmLevel3 KellerFenster lange offen");;\
  return "zu";;\
},\
\
ConnectionState {\
return "offline" if ((time - time_str2num(ReadingsTimestamp("$name","battery","1970-01-01 0:00:00"))) > (48*60*60));;\
return "online";;\
} ,\

[pwlr]

Moin,

ich bin (auch) ein Fan von userReadings. Ich sehe und nutze userReadings als "Funktionserweiterung" für ein Device, also eine Art "allgemeiner Exit für User-Anwendungen". Stellt sich m.E. für die Userebene als "integriertes" notify dar. Ich schätze den Vorteil der Übersichtlichkeit, da man im Device sofort sieht, ob was und wie eine Folgeaktion ausgelöst wird. Und man spart sich ein notify Entity und muss sich keinen blöden Namen dafür ausdenken...

Die Aktionen habe ich dann allerdings abweichend vom obigen Beispiel in der 99_myUtils als sub definiert, weil man m.E. "übersichtlicher" programmieren kann und mehr Kommentare / Doku einfügen kann. Außerdem kann man eine Routine mehrfach für verschiedene Devices nutzen.Aber das ist sicher Geschmackssache.

Was nicht geht und bei mir immer zu fhem-Loops führt, sind reading Modifikationen für das eigene bzw. das aufrufende Device. Warum auch immer, das scheint verboten zu sein. Ich gehe dann den Umweg über ein temporäres at. ($name als Beispiel, bei mir der Name des aufrufenden Device in dem ein reading verändert werden soll).

Code Auswählen Erweitern

{fhem("define temp_01_at_$name at +00:00:01 setreading $name ...action....")};

Alles andere nutze ich ausgiebig. Zum Beispiel für eine attribut-gesteuerte Master-Slave Schaltung. Also eine Kopplung von Aktoren, was ja per peering leider nicht geht. Prinzip: Master Device_1 on/off -> Slave Device_2 on/off.
Und man sollte den Aufruf des userReadings wirklich mit einer vernünfigen Bedingung verknüpfen, damit es nicht mehrfach ausgeführt wird.

Mal sehen, ob wer widerspricht...
Moin
Bernd

[amenomade]

Das grösste Problem ist tatsächlich die mögliche endlose Schleife, die man damit bauen kann. Teilweise sind die von Fhem unterbunden.

Es ist aber möglich (es gibt sogar solche Beispiele im Wiki zu userReadings). Erfahrungsmässig ist es nur schwieriger, Problemen zu debuggen als mit einer reinen Reading => Event => Reaktion (notify, DOIF, watchdog, usw) Kette