Hauptmenü

eventMap mit RegEXP

Begonnen von Ralli, 26 Oktober 2015, 14:15:01

Vorheriges Thema - Nächstes Thema

Ralli

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?
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

Bennemannc

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
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

Ralli

#2
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.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

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

Ralli

#5
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.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

Ralli

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?
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

rudolfkoenig

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.

Ralli

#8
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.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

RomanticBoy83

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.

rudolfkoenig

Danke fuer die Meldung, habs gefixt und eingecheckt, ab morgen um 8 per update.

jhohmann

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?

Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

rudolfkoenig


jhohmann

Super, das war es.
Da muss ich mir selbst einen Merker setzen, dass ich mehr Dokumentation lesen muss.
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna