Hallo,
ich lese Bewegungsmelder (Schaltkontakte) über ein HM-MOD-EM-8 Modul aus.
Als CCU benutze ich eine per LAN angeschlossene CCU2 welche über die Module
d_ccu und CCU RPC BidCos-RF angesprochen wird.
Nun habe ich mir die einzelnen Kanäle des Moduls per z. B. get d_ccu devicelist create Bewegungsmelder1 t=all defattr save room=_Homematic eingelesen.
Jetzt gibts ja diesen Thread hier: https://forum.fhem.de/index.php/topic,51339.0.html - damit komme ich aber nicht ganz klar...
Kann mir jmd. dabei helfen, da der State nichts anzeigt. auf der HomeMatic WebUI werden die "Schaltzustände" richtig angezeigt.
Danke!
List:
Internals:
CFGFN
DEF x:8
IODev d_ccu
NAME Bewegungsmelder1
NR 4761
STATE ???
TYPE HMCCUCHN
ccuaddr x:8
ccudevstate active
ccuif BidCos-RF
ccuname Bewegungsmelder1
ccutype HM-MOD-EM-8
channels 1
chntype SHUTTER_CONTACT
firmware 1.1
statevals devstate
READINGS:
2021-12-01 21:08:19 IODev d_ccu
2021-12-01 21:50:48 battery ok
hmccu:
devspec x:8
dp:
0.CONFIG_PENDING:
OVAL 1
VAL 0
8.LOWBAT:
OSVAL ok
OVAL 0
SVAL ok
VAL 0
8.PRESS:
OVAL 1
VAL 1
8.STATE:
OVAL 1
VAL 0
Attributes:
group Bewegungsmelder
room _Homematic
Das sind leider zu wenige Infos. Zunächst: Welche Version von HMCCU nutzt Du, 4.3 oder 5.0 ?
Hast Du alles so konfiguriert wie im Wiki beschrieben, insbesondere den RPC Server?
Hallo,
diverse andere Homematic-Geräte funktionieren, ja das war nach Anleitung aus dem Wiki.
Hier weitere Infos:
Internals:
CCUNum 1
Clients :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
DEF x
NAME d_ccu
NOTIFYDEV global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
NR 137
NTFY_ORDER 50-d_ccu
RPCState running
STATE running/OK
TYPE HMCCU
ccuaddr BidCoS-RF
ccuchannels 190
ccudevices 16
ccuif BidCos-RF
ccuinterfaces BidCos-RF,HmIP-RF,VirtualDevices
ccuip x
ccuname HM-RCV-50 BidCoS-RF
ccustate active
ccutype CCU2/3
host x
prot http
version 4.3.025
READINGS:
2021-12-01 21:08:19 count_channels 190
2021-12-01 21:08:19 count_devices 16
2021-12-01 21:08:19 count_groups 0
2021-12-01 21:08:19 count_interfaces 3
2021-12-01 21:08:19 count_programs 8
2021-11-18 22:06:12 rpcstate running
2021-11-18 22:06:12 state OK
hmccu:
defInterface BidCos-RF
defPort 2001
evtime 0
evtimeout 0
rpccount 0
rpcports 2001,2010
Internals:
CCUNum 1
DEF http://x BidCos-RF
FD 51
IODev d_ccu
NAME d_rpc002001BidCos_RF
NR 186
RPCPID x
RPCState running
STATE running/OK
TYPE HMCCURPCPROC
ccuip x
ccustate active
ccutype CCU2/3
host x
prot http
rpcid x
rpcinterface BidCos-RF
rpcip x
rpcport 2001
version 1.9.001
READINGS:
2021-11-18 22:06:12 rpcstate running
2021-11-18 22:06:12 state OK
hmccu:
defaultaddr x
devspec BidCos-RF
evtime 0
localaddr x
rpcstarttime 1637269572
rpc:
avgdelay 0.00561516263439847
cbport 7411
cburl http://x:7411/fh2001
clkey x
clurl http://x:x@x:2001
evtime 1638472117
pid x
port 2001
state running
sumdelay 2981
rec:
DD 0
EV 530884
EX 0
IN 0
ND 174
RA 0
RD 0
SL 1
ST 1062
TO 0
UD 0
snd:
DD 0
EV 530825
EX 0
IN 0
ND 174
RA 0
RD 0
SL 1
TO 0
UD 0
Attributes:
alias CCU RPC BidCos-RF
eventMap /rpcserver on:on/rpcserver off:off/
icon hm_ccu
room _Adapter,_Homematic
stateFormat rpcstate/state
verbose 2
Um den Status in "state" zu bekommen, sollte genügen:
attr ccureadingfilter .*
attr statedatapoint STATE
Du kannst noch die Werte ersetzen, also z.B.
attr substitute STATE!(0|false):noMotion,(1|true):motion
Traumhaft, danke!
So klappts!
Hallo,
also irgendwas scheint doch nicht richtig zu laufen. An dem HM-MOD-EM-8 sind mehrere Bewegungsmelder angeschlossen. -> und entsprechende Lichter gehen je bei Bewegung an.
Nun habe ich aber festgestellt, dass ich mit folgendem DOIF: immer alle Lichter einschalte:
define FL_Terrasse_Motion.di DOIF ([Bewegungsmelder_Terrasse:"Motion"] and [Aussenbeleuchtung_Modus.dum] eq "auto" and [FL_Terrasse_Modus.dum] eq "auto" and [Tageslicht.dum] eq "nein") (set FL_Terrasse on) (set FL_Terrasse off)
...mit einem do resetwait und einem wait 0,[Scheinwerfer_Zeit.dum]
Nun habe ich etwas geschaut und festgestellt, dass das Problem vom HM-MOD-EM-8 kommt -> der setzt bei einer einzelnen Bewegung alles auf "Motion" - folglich greifen alle entsprechenden DOIFs mit den dazugehörigen Lichtern.
Ich kann es mir gerade nicht erklären.
Internals:
DEF x
IODev d_ccu
NAME Bewegungsmelder_Garagentuer
NR 298
STATE noMotion
TYPE HMCCUCHN
ccuaddr x
ccudevstate active
ccuif BidCos-RF
ccuname Bewegungsmelder_Garagentuer
ccutype HM-MOD-EM-8
channels 1
chntype SHUTTER_CONTACT
firmware 1.1
statevals devstate
READINGS:
2021-12-05 20:20:21 0.AES_KEY on
2021-12-05 20:20:21 0.CONFIG_PENDING false
2021-12-05 20:20:21 0.DEVICE_IN_BOOTLOADER false
2021-12-05 20:20:21 0.RSSI_DEVICE 1
2021-12-05 20:20:21 0.RSSI_PEER 205
2021-12-05 20:20:21 0.STICKY_UNREACH false
2021-12-05 20:20:21 0.UPDATE_PENDING false
2021-12-05 21:07:48 IODev d_ccu
2021-12-05 21:08:03 activity alive
2021-12-05 21:08:03 battery ok
2021-12-05 21:08:03 control noMotion
2021-12-05 21:20:36 hmstate noMotion
2021-12-05 21:08:03 state noMotion
hmccu:
devspec x
dp:
0.AES_KEY:
OVAL 1
VAL 1
0.CONFIG_PENDING:
OVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
OVAL false
VAL false
0.LOWBAT:
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
OVAL 1
VAL 1
0.RSSI_PEER:
OVAL 205
VAL 205
0.STICKY_UNREACH:
OVAL false
VAL false
0.UNREACH:
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
OVAL false
VAL false
7.LOWBAT:
OSVAL ok
OVAL false
SVAL ok
VAL false
7.STATE:
OSVAL noMotion
OVAL false
SVAL noMotion
VAL false
Attributes:
ccureadingfilter 7.STATE
group Bewegungsmelder
room Garten,Perimeter,_Homematic
statedatapoint 7.STATE
substitute STATE!(0|false):noMotion,(1|true):motion
Der hmstate scheint das Problem zu sein, da er global nun "Motion anzeigt" und damit quasi mit den weiteren DOIFs auch die anderen Lichter steuert.
2021-12-05 21:20:36 hmstate noMotion
Das stellen der Attribute auf 7.STATE (dass ist der entsprechende Kanal des HM-MOD-EM-8 Moduls, den es auszuwerten gilt) brachte nix - hier mache ich aber irgendwas falsch, da hmstate auch weiterhin in den Readings vorkommt.
Hallo,
hat hier jmd. vielleicht doch noch einen Tipp, wie ich nur zB 7. Starte Auslese?
Danke
Also Du hast für jeden Kanal vom HM-MOD-EM-8 ein HMCCUCHN angelegt, oder?
Korrekt, so wie in Antwort #5.
Und in diesen HMCCUCHNs werden die Stati korrekt signalisiert? Wenn ja, liegt das Proble wohl an Doif
Hallo,
ich habe immer noch oben stehendes Problem.
das ist mein DOIF:
([Bewegungsmelder_Terrasse:"Motion"] and [Aussenbeleuchtung_Modus.dum] eq "auto" and [FL_Terrasse_Modus.dum] eq "auto" and [Tageslicht.dum] eq "nein") (set FL_Terrasse on) (set FL_Terrasse off)
Das Problem ist einfach, dass auch immer der hmstate des 8fach Moduls berücksichtigt wird (der scheint egal bei welchem Eingang ein dann entsprechendes "Motion" auszugeben).
READINGS:
2021-12-18 15:24:05 0.AES_KEY on
2021-12-18 15:24:05 0.CONFIG_PENDING false
2021-12-18 15:24:05 0.DEVICE_IN_BOOTLOADER false
2021-12-18 15:24:05 0.RSSI_DEVICE 1
2021-12-18 15:24:05 0.RSSI_PEER 205
2021-12-18 15:24:05 0.STICKY_UNREACH false
2021-12-18 15:24:05 0.UPDATE_PENDING false
2022-01-05 20:16:32 8.STATE noMotion
2022-01-05 20:16:18 IODev d_ccu
2022-01-05 20:16:32 activity alive
2022-01-05 20:16:32 battery ok
2022-01-05 20:16:32 control noMotion
2022-01-06 10:19:09 hmstate noMotion
2022-01-05 20:16:32 state noMotion
Ich denke ich habe pro Kanal hier etwas falsch eingestellt. Bei dem Bewegungsmelder_Terrasse soll z. B. nur Channel 8 des Moduls berücksichtigt werden:
ccureadingfilter 8.STATE
group Bewegungsmelder
room Garten,Perimeter,_Homematic
statedatapoint 8.STATE
substitute STATE!(0|false):noMotion,(1|true):motion
Momentan wirkt es sich aus, dass egal an welchem Channel ausgelöst wird immer auch "hmstate" ein Motion erhält. Das wiederum wird als "motion" in jedem DOIF interpretiert.
Also nicht nur der betroffende Channel wird auf Motion gesetzt, sondern allgemein "hmstate" dies kriege ich in der Interpretation der einzelnen Channel (Motion/noMotion) nicht heraus.
Da schnalle ich Programmierung nicht.
Lös das doch im DOIF - dein Konstrukt [Bewegungsmelder_Terrasse:"Motion"] triggert nach meinem Verständnis von DOIF auf einen Event im Gerät Bewegungsmelder_Terrasse der das Wort Motion enthält (siehe Dokumentation DOIF), der triggert also auch bei noMotion :-X
Aber eben auch bei 8.STATE: Motion , bei hmstate: noMotion und bei state: MotionAgentur usw. - Also mMn ist das völlig ungeeignet!
setzt den Trigger auf "8.STATE: Motion^" oder "8.STATE:.Motion^" (ich bin wegen dem Leerzeichen und der Umsetzung im DOIF nicht sicher)
Oder Besser: schau im Eventmonitor und erzeuge Dir ein Beispiel mit dem Event Deiner Wahl!
wie es geht? https://wiki.fhem.de/wiki/Event_monitor
Lieber Otto,
wieder einmal vielen Dank!
Ich hatte es ganz anders interpretiert.
Grüße
funktioniert nach meinem Vorschlag?
"8.STATE: motion" - exakt so, mit Leerzeichen. Stand irgendwo, dass Leerzeichen im DOIF egal wären.
Danke!