Hallo,
man kann ja nun mittels eventMap relativ komplex umwandeln.
attr store eventMap { dev=>{"^on(-for-timer)?(.*)"=>"open$2"}, usr=>{"^open(.*)"=>"on$1"}, fw=>{"^open(.*)"=>"open"} }
Ich habe jetzt schon recht viel rumprobiert, komme aber damit nicht so recht klar.
Ein Dimmer erreicht Werte im Reading LEVEL von 0.000000 bis 1.000000.
Im Zusammenhang mit der Umstellung von einigen Devices und Definitionen bräuchte ich folgendes für einen Dimmer:
set Dimmer 100 soll werden zu set Dimmer LEVEL 1.0
set Dimmer 0 soll werden zu set Dimmer LEVEL 0
set Dimmer on soll werden zu set Dimmer LEVEL 1.0
set Dimmer off soll werden zu set Dimmer LEVEL 0
set Dimmer [1-99] soll werden zu set Dimmer LEVEL 0.[1-99]
Umgekehrt sollen die Rückmeldungen des Devices dann wie folgt umgewandelt werden:
1.000000 => on
0.000000 => off
0.000001 bis 0.999999 => gerundet auf zwei Stellen hinter dem Komma mal 100.
Sinn der Sache: mittels webCmd on:pct:off darstellen, welches in einen passenden Set-Befehl umgewandelt wird.
Bislang habe ich lediglich "dumm" umgewandelt:
/LEVEL 1.0:on/LEVEL 1.0:100/LEVEL 0.0:off/LEVEL 0.0:0/LEVEL 0.5:50/ ... usw.
Kann mir da jemand weiterhelfen?
Hallo,
mal einfach eine Frage - wofür ist das gut bzw. was willst Du erreichen ? Die Anzeige könnte man mit einem userReading beeinflussen - einfach durch 100 teilen. Eine "Werteliste" kannsr Du mit dem Attribut setList erzeugen.
Gruß Christoph
Nein, so einfach ist das im Zusammenhang mit HMRPC-Devices leider nicht.
Du kannst einen Dimmer-Device nicht einfach mit
set Dimmer 40
setzen wie bsp. bei CUL_HM-Devices.
Das geht immer mit
set Dimmer LEVEL 0.4
usw.
In der Web-Oberfläche möchte ich - wie sonst auch üblich - aber eben halt einen Slider setzen. Dieser liefert standardmäßig einfach den Wert zurück. Und genau das reicht nicht. Das muss dann per eventMap übersetzt werden. Jede Zahl muss in einen %-Wert umgerechnet werden (also durch 100) und mit dem Präfix LEVEL ergänzt werden.
Umgekehrt muss für eine korrekte Darstellung der vom Device zurückgemeldeten Werte eben eine entsprechende Umwandlung vorgenommen werden.
Nach meinem Verständnis sollte das ein erster Ansatz sein:
{ dev=>{"^0\.([0-9]{2})"=>"$1"}, usr=>{"^([0-9]{1,2})"=>"LEVEL 0.$1"} }
bei einem
set Dimmer 55
kommt aber nur ein LEVEL 0. raus - ohne die 55.
was ist das denn für ein device von dem du redest?
wenn du ein LEVEL kommando brauchst sollte das device auch ein LEVEL kommando haben und der slider sollte dann mit dem LEVEL kommando verwendet werden. das geht dann mit widgetOverride.
gruss
andre
define f dummy
attr f eventMap {\
dev=>{ '^(\d\.\d*)$'=>'".($1==1.0 ? "on" : ($1==0.0 ? "off" : sprintf("%d", $1*100)))."' },\
usr=>{ '^100$' => 'LEVEL 1.0',\
'^0$' => 'LEVEL 0' ,\
'^on$' => 'LEVEL 1.0',\
'^off$' => 'LEVEL 0' ,\
'^([1-9]|[1-9][0-9])$' => '".sprintf("LEVEL %0.2f", $1/100)."' } }
Achtung: mehrzeilige eventMaps mit {} funktionieren erst ab den morgigen update.
Test:
fhem> info timer
fhem> set f 12
2015-10-26 19:18:01 dummy f LEVEL 0.12
fhem> set f on
2015-10-26 19:18:08 dummy f LEVEL 1.0
fhem> set f off
2015-10-26 19:18:11 dummy f LEVEL 0
fhem> set f 0
2015-10-26 19:18:13 dummy f LEVEL 0
fhem> set f 100
2015-10-26 19:18:15 dummy f LEVEL 1.0
fhem> tri f 0.000000
2015-10-26 19:19:01 dummy f off
fhem> tri f 1.000000
2015-10-26 19:19:07 dummy f on
fhem> tri f 0.12
2015-10-26 19:19:10 dummy f 12
Rudi, vielen vielen Dank!!
Und so sieht ein grundsätzlich funktionierendes Dimmer-Device für das Modul HMRPC aus:
Internals:
CCU2_MSGCNT 105
CCU2_TIME 2015-10-26 20:13:28
DEF LEQ0105xyz:1
IODev CCU2
LASTInputDev CCU2
MSGCNT 105
NAME HWR_Wandleuchte
NR 762
STATE off
TYPE HMDEV
hmaddr LEQ0105xyz:1
hmdevtype DIMMER
CHANGETIME:
Readings:
2015-10-26 20:13:26 DIRECTION 0
2015-10-26 20:13:27 ERROR_OVERHEAT 0
2015-10-26 20:13:27 ERROR_OVERLOAD 0
2015-10-26 20:13:27 ERROR_REDUCED 0
2015-10-26 20:13:25 LEVEL 0.000000
2015-10-26 20:13:28 LEVEL_REAL 0.000000
2015-10-26 20:13:26 WORKING 0
2015-10-26 20:13:28 state off
Hmdevinfo:
ADDRESS LEQ0105xyz:1
AES_ACTIVE 0
DIRECTION 2
FLAGS 1
INDEX 1
LINK_SOURCE_ROLES
LINK_TARGET_ROLES SWITCH WCS_TIPTRONIC_SENSOR WEATHER_CS
PARENT LEQ0105xyz
PARENT_TYPE HM-LC-Dim1TPBU-FM
TYPE DIMMER
VERSION 13
PARAMSETS:
LINK
MASTER
VALUES
Attributes:
IODev CCU2
alias Wandleuchte HWR
devStateIcon [0-9]{1,2}\.?[0-9]?:dim50%
eventMap {usr=>{ '^100$' => 'LEVEL 1.0','^0$' => 'LEVEL 0.0','^on$' => 'LEVEL 1.0','^off$' => 'LEVEL 0.0','^([1-9]|[1-9][0-9])$' => '".sprintf("LEVEL %0.2f",$1/100)."' }}
group Licht
icon light_wall_2
room Anbau
userReadings state {ReadingsVal($name,"LEVEL",0) == 0 ? "off" : ReadingsVal($name,"LEVEL",0) == 1 ? "on" : sprintf("%d",ReadingsVal($name,"LEVEL",0)*100)}
webCmd on:off:50
Damit kann man nun wie in fhem gewohnt ein- und ausschalten als auch mit einer Prozentangabe den Dimmwert setzen. Was nun noch fehlt, ist 1) die Möglichkeit, Einschaltdauer und Rampenzeit anzugeben und 2) mit einem Slider im Frontend den Dimwert einstellen zu können. Das 1) dürfte aber etwas komplexer werden, denn dafür muss erst mal der richtige Request herausgefunden werden. Das 2) habe ich bislang mit widgetOverride noch nicht lösen können.
Hallo Rudi,
das folgende klappt nicht:
{usr=>{ 'toggle' => '".(ReadingsVal($name,"STATE",0) == 0 ? "STATE true" : "STATE false")."','off' => 'STATE false','on' => 'STATE true' }}
Das Setzen von on und off klappt, auch toggle setzt fhem grundsätzlich auf den folgenden Ausdruck um. Dieser wird aber nicht umgewandelt/ausgeführt.
Wo ist mein Fehler?
Da geht eine Menge schief:
- eval wird nur dann ausgefuehrt, falls der Schluessel (toggle) nicht exakt mit dem Befehlsargument uebereinstimmt. Frag mich nicht wieso, weiss ich nicht mehr.
- $name wird nie gesetzt, habs aber auch nicht versprochen, man muss hier $dev verwenden. Um es mit dem Rest kompatibel zu machen, habe ich gerade $NAME eingefuehrt, am morgen ist das gleich $dev.
- Es gibt kein Reading STATE, nur eins was state heisst.
- das Ergebnis von ReadingsVal per == zu vergleichen ist meist falsch, == ist numerischer Vergleich
Vielleicht gibt es noch weitere Probleme, ich hoere jetzt aber auf zu meckern. Bei mir funktioniert folgendes:
{usr=>{ '^toggle' => '".(ReadingsVal($NAME,"state","STATE true") eq "STATE true" ? "STATE false" : "STATE true")."','off' => 'STATE false','on' => 'STATE true' }}
Nicht vergessen: $NAME erst ab morgen mit dem update.
Hallo Rudi,
vielen Dank!
Zitat von: rudolfkoenig am 08 Februar 2016, 13:11:39
- Es gibt kein Reading STATE, nur eins was state heisst.
Doch - hier schon. Ist ein HMDEV-Device, die XML-RPC-Schnittstelle der CCU2 exportiert den Datenpunkt STATE, der in das gleichnamige Reading mündet.
Das Reading state gibt es auch, weil per userreadings aus den anderen Werten gesetzt.
Zitat
- das Ergebnis von ReadingsVal per == zu vergleichen ist meist falsch, == ist numerischer Vergleich
Vielleicht gibt es noch weitere Probleme, ich hoere jetzt aber auf zu meckern. Bei mir funktioniert folgendes:
Ja, ok, hier nehme ich ReadingsNum - obwohl das in anderen Konstellationen klappt :).
Zitat
Nicht vergessen: $NAME erst ab morgen mit dem update.
Danke ! So klappt's:
{usr=>{ '^toggle' => '".(ReadingsNum($dev,"STATE",0) == 0 ? "STATE true" : "STATE false")."','off' => 'STATE false','on' => 'STATE true' }}
Ausschlaggebend war das Dach vor toggle und das $dev statt $name.
Ich habe ein seltsames Phenomen:
Ich habe einen Dummy mit einer Liste um einen freien Text declarieren zu können. Leider kommt der Name der Liste mit in den State und taucht somit auch in der Variable $EVENT auf.
Ich schneide also, wenn es vorhanden ist, key(Name der Liste) mit EventMap ab und möchte zeitgleich den State 'aus' als Ziffer 0 haben.
{dev=>{ '^key.(.*)$'=>'$1' },usr=>{ '^aus$' => '0'} }
Dies funktioniert jedoch leider nicht. Es wird niemals die 0 gezeigt.
Dahingegen funktioniert der selbe Quellcode mit jedem anderen String.
{dev=>{ '^key.(.*)$'=>'$1' },usr=>{ '^aus$' => '1'} }
Das Problem ist also die 0, welche nicht akzeptiert wird. Im Log ist auch keine Information zu finden.
Danke fuer die Meldung, habs gefixt und eingecheckt, ab morgen um 8 per update.
Ich will dieses uralte Thema nochmal hoch bringen, da es mir selbst gerade eben sehr geholfen hat.
Aber eine Merkwürdigkeit ist mir dabei aufgefallen.
Ich habe ein eventMap bei mir ergänzt und es läuft so weit gut.
attr ArbeitszimmerRolladen eventMap { usr=>{'opens'=>'open', 'closes'=>'close', '^position ([0-9]|[1-9][0-9]|[1][0][0])$' => '".sprintf("pct %d",(100-$1))."'} }
Aber wenn ich nun in FHEMWEB zu diesem Device die Liste der möglichen Werte für ein set aufrufe, werden auch zwei optisch unschöne Befehle präsentiert, nämlich
^position
und
([0-9]|[1-9][0-9]|[1][0][0])$
Das ist eigentlich ja zusammen ein Befehl und keine zwei getrennte.
Einen Screenshot hänge ich noch dran.
Wirklich stören tut das jetzt nicht, aber merkwürdig finde ich das schon. Muss da der Parser für FHEMWEB noch angepasst werden?
eventMap hat einen optionalen fw Parameter:
https://fhem.de/commandref_modular.html#eventMap
Super, das war es.
Da muss ich mir selbst einen Merker setzen, dass ich mehr Dokumentation lesen muss.