Hallo,
ich möchte per "setReading" einen Dummy-Wert zuweisen (Dummy erstellt und float-Wert gespeichert)
Value("dummy-Variable") gibt mir den Inhalt (Wert) zurück
das hier funktioniert:
fhem("setReading Wert_A 20.0");
das hier funktioniert aber nicht:
fhem("setReading Wert_A Value("dummy-Variable")");
Wo liegt das Problem ?
Zitat von: rspi am 27 Januar 2017, 19:07:21
Wo liegt das Problem ?
Zum Einen daran, dass Du den Befehl setreading falsch schreibst. Man achte auf Groß-/Kleinschreibung.
Zum Anderen daran, dass die Syntax innerhalb des Aufrufes von fhem() an sich falsch ist. Man lese sich perl-Grundlagen an.
Zitat von: betateilchen am 27 Januar 2017, 19:09:53
Zum Anderen daran, dass die Syntax innerhalb des Aufrufes von fhem() an sich falsch ist. Man lese sich perl-Grundlagen an.
Hallo betateilchen,
ich habe mich nun stundenlang in die "perl-Grundlagen" eingelesen und finde keine Lösung.
Allerdings verstehe ich diesen Hinweis auch nicht wirklich: Geht es hier um die perl-Syntax oder geht es, wie ich glaube, nicht eher um das Zusammenspiel zwischen perl und fhem?
Danke und Gruß,
Kurt
Hallo Kurt,
Eine Lösung:
fhem("setreading Wert_A ".Value("dummy-Variable"))
Stichwort concatenate
Testbeispiel für die RawDef
{my $string="Willi";;\
sub test {return "Lustig"};;\
return "Der ".$string." ist ".test()}
fhem() will als Übergabewert einen String der als FHEM Befehl ausführbar ist. Den Inhalt muss man entsprechend "zusammenstellen".
Gruß Otto
Ich würde nur anmerken wollen:
@Kurt77: weißt du WAS Value("Devicename") liefert!? Bzw. was willst du haben!? ;)
Value -> STATE
ReadingsVal("Devicename","Readingname","Ersatzwert") oder ReadingsNum("Devicename","Readingname",Ersatzwert) bzw. eben AttrVal, InternalVal, ... halte ich für "besser", weil da klar ist WAS man bekommt...
STATE kann durch vieles "beeinflusst" werden und dann bekommt man nicht immer was man will (denkt/erwartet ;) )...
EDIT: bzw. generell gefragt: WAS willst du eigentlich tun!? Weil Werte aus einem Dummy irgendwohin zu schreiben!? Da stellt sich (mir) immer die Frage: braucht es den (Zwischen)Dummy wirklich!? Oder ist es nur so "gelöst", weil man "es" nicht anders lösen konnte?!
Gruß, Joachim
Hallo Joachim,
ich formuliere mal allgemein.
Ich frage regelmäßig einen Wert ab und will eine Aktivität nur dann auslösen, wenn sich der Wert geändert hat.
Zu diesem Zweck speichere ich bei Ungleichheit den gelesenen Wert in einem Userreading eines Dummies.
Hast Du eine andere Lösungsmöglichkeit?
Danke und Gruß,
Kurt
Zitat von: Kurt77 am 10 September 2020, 17:14:18
Hast Du eine andere Lösungsmöglichkeit?
Ja: event-on-change-reading und dann ein notify
Weil das notify genau nur dann auslöst, wenn sich der Wert geändert hat...
...ganz ohne Zwischenspeicher und ohne Abfrage...
Weil Abfragen ist eh "nicht gut"...
fhem ist "Event-basiert"...
Anmerkung: je genauer die Beschreibung des Vorhabens und Infos zu "was schon da ist" desto "besser" die Hilfe(möglichkeiten)... ;)
Gruß, Joachim
Zitat von: MadMax-FHEM am 10 September 2020, 17:29:47
Ja: event-on-change-reading und dann ein notify
Weil das notify genau nur dann auslöst, wenn sich der Wert geändert hat...
...ganz ohne Zwischenspeicher und ohne Abfrage...
Weil Abfragen ist eh "nicht gut"...
Hallo Joachim,
danke für den Vorschlag, gucke ich mir an.
Zum Thema Abfragen: Ich bin ein Freund von Abfragen, weil sie die Lesbarkeit verbessern. Ob das allerdings immer performant ist, steht auf einem anderen Blatt.
Gruß Kurt
Die Performanz ist bei "Event" natürlich besser.
Noch dazu, wenn man die Events auf das Notwendige begrenzt (event-on-...) und auch die reagierenden Notify (DOIF/...) entsprechend "eng fasst", sodass die nur auslösen, wenn sie sollen...
Da ist doch "Nachfragen" unnötig!?
EDIT: und nat. ist die Reaktion bei tatsächlicher Änderung (deutlich) schneller -> SOFORT! :) Ähnlich nah kommst du nur, wenn du "nachfragst wie blöd" ;)
Also zyklische Dinge (at) habe ich nur, wo ich auch wirklich zyklisch was tun will/muss...
Ansonsten ist es (bei fhem) besser sich auf Events "einzulassen" ;)
Aber: dein System...
Viel Spaß, Joachim