Hallo,
mach ich da einen gedanklichen Fehler bei der Anwendung des Attributs ccuaggregate in HMCCU oder sind da noch Variablen im Code vertauscht.
Meine Raw-definition des HMCCU Device ist wie folgt:
defmod CCU2 HMCCU 192.168.1.32 waitforccu=120
attr CCU2 DbLogExclude .*
attr CCU2 ccuReqTimeout 8
attr CCU2 ccuaggregate name:battery,filter:room=Homematic,read:(LOWBAT|LOW_BAT),if:any=yes,else:no,prefix=battery_,coll:alias;;;;\
name:DutyCycle,filter:room=Homematic,read:(0.DUTY_CYCLE),if:any=(1|true),else:(0|false),prefix=dutycycle_,coll:alias
attr CCU2 ccuflags procrpc,nonBlocking
attr CCU2 cmdIcon on:general_an off:general_aus
attr CCU2 eventMap /rpcserver on:on/rpcserver off:off/
attr CCU2 group Hardware
attr CCU2 icon hm_ccu
attr CCU2 room Homematic
attr CCU2 rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
attr CCU2 rpcport 2001,2010,9292
attr CCU2 rpcqueue /tmp/ccuqueue
attr CCU2 rpcserver on
attr CCU2 stateFormat rpcstate/state
setstate CCU2 running/OK
setstate CCU2 2018-12-31 18:58:27 DutyCyclecount 65
setstate CCU2 2018-12-31 18:58:27 DutyCyclelist no match
setstate CCU2 2018-12-31 18:58:27 DutyCyclematch 0
setstate CCU2 2018-12-31 18:58:27 DutyCyclestate (0|false)
setstate CCU2 2018-12-31 18:59:23 Status_DutyCycle 21.000000
setstate CCU2 2018-12-31 18:59:23 Status_Watchdog 1
setstate CCU2 2018-12-31 18:58:27 batterycount 65
setstate CCU2 2018-12-31 18:58:27 batterylist no match
setstate CCU2 2018-12-31 18:58:27 batterymatch 0
setstate CCU2 2018-12-31 18:58:27 batterystate no
setstate CCU2 2018-12-31 16:46:19 count_channels 329
setstate CCU2 2018-12-31 16:46:19 count_devices 64
setstate CCU2 2018-12-31 16:46:19 count_groups 5
setstate CCU2 2018-12-31 16:46:19 count_interfaces 3
setstate CCU2 2018-12-31 16:46:19 count_programs 23
setstate CCU2 2018-12-31 17:09:29 iface_addr_1 NEQ0478113
setstate CCU2 2018-12-31 17:09:29 iface_addr_2 3014F711A0000....
setstate CCU2 2018-12-31 17:09:29 iface_conn_1 1
setstate CCU2 2018-12-31 17:09:29 iface_conn_2 1
setstate CCU2 2018-12-31 17:09:29 iface_ducy_1 11
setstate CCU2 2018-12-31 17:09:29 iface_ducy_2 24
setstate CCU2 2018-12-31 17:09:29 iface_type_1 CCU2
setstate CCU2 2018-12-31 17:09:29 iface_type_2 HMIP_CCU2
setstate CCU2 2018-12-31 16:46:47 rpcstate running
setstate CCU2 2018-12-31 18:01:23 state OK
Durch die Prefixangabe "dutycycle_" im HMCCU Device sollte ich doch auch Readings mit "dutycycle_...." erwarten können?
Bei mir beginnt aber der Readingname mit dem Namen der Aggregation "DutyCycle....", ohne Unterstrich.
Ist das bei euch auch so?
Guten Rutsch nach 2019
Gruß Reinhard
Normalerweise funktioniert das. Deine battery Regel müsste eigentlich korrekt arbeiten, d.h. die Readings sollten alle mit 'battery_' beginnen und nicht mit 'battery'.
Bei der DutyCycle Regel könnte das Problem in der falschen Syntax liegen. "if" und "else" akzeptieren nämlich nur feste Werte und keine regulären Ausdrücken. Du müsstest also z.B. schreiben "if:any=1,else:0" oder "if:any=true,else:false".
Ein andereres Problem ist, dass es bei Homematic keinen Datenpunkt 0.DUTY_CYCLE gibt. Oder ist das ein UserREading von Dir?
Wenn Du den DutyCycle von Schnittstellen abfragen willst, nimm den get dutycycle Befehl vom I/O Device. Den kannst Du regelmäßig per AT ausführen lassen. Der schreibt die Werte in Readings im I/O Device.
Noch ein gesundes neues Jahr alleseits!
Hallo zap,
da ich derzeit bei mir Probleme mit dem Duty Cycle vermute, wollte ich über
ccuaggregate vom HMCCU Device sporadisch abfragen, ob bei irgend einem
HmIP-Device der CCU2 das Reading "
0.DUTY_CYCLE" gesetzt ist. Das sollte doch Grundsätzlich mit
ccuaggregate gehen.
ZitatEin andereres Problem ist, dass es bei Homematic keinen Datenpunkt 0.DUTY_CYCLE gibt. Oder ist das ein UserREading von Dir?
Ich habe viele HmIP-Geräte, da gibt es solch ein Reading 0.DUTY_CYCLE.
defmod HM_OG_Bm_Flur HMCCUDEV 000915699D38CB
attr HM_OG_Bm_Flur DbLogExclude .*
attr HM_OG_Bm_Flur IODev CCU2
attr HM_OG_Bm_Flur event-on-change-reading 1.MOTION
attr HM_OG_Bm_Flur eventMap /datapoint 1.MOTION_DETECTION_ACTIVE 1:detection-on/datapoint 1.MOTION_DETECTION_ACTIVE 0:detection-off/
attr HM_OG_Bm_Flur group Batterieanzeige_Spannung,Haustier
attr HM_OG_Bm_Flur icon people_sensor
attr HM_OG_Bm_Flur room Hofanlagen,Homematic,OG_Flur
attr HM_OG_Bm_Flur statedatapoint 1.MOTION
attr HM_OG_Bm_Flur substitute MOTION!(0|false):Ruhe im Flur,(1|true):Bewegung im Flur
attr HM_OG_Bm_Flur userReadings Batteriezustand {\
return "00" if(ReadingsVal($name,"0.OPERATING_VOLTAGE","0") < "2.2" );;;; \
return "25" if(ReadingsVal($name,"0.OPERATING_VOLTAGE","0") < "2.4" );;;; \
return "50" if(ReadingsVal($name,"0.OPERATING_VOLTAGE","0") < "2.6" );;;; \
return "75" if(ReadingsVal($name,"0.OPERATING_VOLTAGE","0") < "2.8" );;;; \
return "100" },\
Devicename {return 'OG Flur - Bewegungsmelder' },\
Batteriespannung { ReadingsVal($name,"0.OPERATING_VOLTAGE","");; },\
Batterie_leer { ReadingsVal($name,"0.LOW_BAT","");; }
setstate HM_OG_Bm_Flur Ruhe im Flur
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 0.CONFIG_PENDING 0
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 0.DUTY_CYCLE 0
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 0.ERROR_CODE 0
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 0.LOW_BAT 0
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 0.OPERATING_VOLTAGE 2.9
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 0.OPERATING_VOLTAGE_STATUS 0
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 0.RSSI_DEVICE -51
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 0.RSSI_PEER -61
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 0.SABOTAGE 0
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 0.UNREACH 0
setstate HM_OG_Bm_Flur 2018-12-31 16:46:48 0.UPDATE_PENDING false
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 1.ILLUMINATION 9.1
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 1.ILLUMINATION_STATUS 0
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 1.MOTION Ruhe im Flur
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 1.MOTION_DETECTION_ACTIVE 1
setstate HM_OG_Bm_Flur 2019-01-01 16:10:22 1.PRESS_SHORT 1
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 Batterie_leer 0
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 Batteriespannung 2.9
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 Batteriezustand 100
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 Devicename OG Flur - Bewegungsmelder
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 control Ruhe im Flur
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 hmstate Ruhe im Flur
setstate HM_OG_Bm_Flur 2019-01-01 16:10:35 state Ruhe im FlurEs verwirrt etwas, da es bei mir bisher auch ein Userreading "
Status_DutyCycle" gab, welches ich in der CCU2 über ein script angelegt hatte und dann für Fhem über Systemvariablen zur Verfügung stellte, bevor ich im HMCCU Device das "
get <device> dutycycle" entdeckt habe.
Ich habe dieses nun umgestellt und lasse die Readings über ein at am I/O Device selbst aktualisieren (wie von dir auch vorgeschlagen), man lernt ja immer wieder dazu ;).
Somit kann ich den Duty Cycle der CCU2 Schnittstellen über "
set <device> dutycycle" als %-Wert sehen und will zusätzlich noch mit
ccuaggregate prüfen, ob ein Gerät den Duty Cycle überschritten hat.
ZitatBei der DutyCycle Regel könnte das Problem in der falschen Syntax liegen. "if" und "else" akzeptieren nämlich nur feste Werte und keine regulären Ausdrücken. Du müsstest also z.B. schreiben "if:any=1,else:0" oder "if:any=true,else:false".
Wenn ich mit
ccuaggregate bei einem Reading auf
0 und
off afragen will kann ich das somit nicht unter einen
name: erledigen, ich muss hier jeweils unter verschiedenen
name: getrennt abfragen? Oder ich stelle bei den Devices sicher, dass hier nur
0 und nicht
off vorkommt.
Irgendwie habe ich noch immer das Problem mit den Readingnamen, bei mir wird da kein Unterstich eingefügt, es wird definitiv nicht das
Prefix= als Readingname verwendet, sondern der
name: vom
ccuaggregate.
Siehe mein Device als RAW-Definition, direkt nach einen "
shutdown restart"
defmod CCU2 HMCCU 192.168.1.32 waitforccu=120
attr CCU2 DbLogExclude .*
attr CCU2 ccuReqTimeout 8
attr CCU2 ccuaggregate name:Batterie,filter:room=Homematic,read:(LOWBAT|LOW_BAT),if:any=yes,else:no,prefix=batt_,coll:alias
attr CCU2 ccuflags procrpc,nonBlocking
attr CCU2 cmdIcon on:general_an off:general_aus
attr CCU2 eventMap /rpcserver on:on/rpcserver off:off/
attr CCU2 group Hardware
attr CCU2 icon hm_ccu
attr CCU2 room Homematic
attr CCU2 rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
attr CCU2 rpcport 2001,2010,9292
attr CCU2 rpcqueue /tmp/ccuqueue
attr CCU2 rpcserver on
attr CCU2 stateFormat rpcstate/state
setstate CCU2 running/OK
setstate CCU2 2019-01-01 17:43:14 Batteriecount 65
setstate CCU2 2019-01-01 17:43:14 Batterielist no match
setstate CCU2 2019-01-01 17:43:14 Batteriematch 0
setstate CCU2 2019-01-01 17:43:14 Batteriestate no
setstate CCU2 2019-01-01 17:43:22 Status_Watchdog 1
setstate CCU2 2019-01-01 17:41:19 count_channels 329
setstate CCU2 2019-01-01 17:41:19 count_devices 64
setstate CCU2 2019-01-01 17:41:19 count_groups 5
setstate CCU2 2019-01-01 17:41:19 count_interfaces 3
setstate CCU2 2019-01-01 17:41:19 count_programs 23
setstate CCU2 2019-01-01 17:40:02 iface_addr_1 NEQ0478113
setstate CCU2 2019-01-01 17:40:02 iface_addr_2 3014F711A0000........
setstate CCU2 2019-01-01 17:40:02 iface_conn_1 1
setstate CCU2 2019-01-01 17:40:02 iface_conn_2 1
setstate CCU2 2019-01-01 17:40:02 iface_ducy_1 11
setstate CCU2 2019-01-01 17:40:02 iface_ducy_2 12
setstate CCU2 2019-01-01 17:40:02 iface_type_1 CCU2
setstate CCU2 2019-01-01 17:40:02 iface_type_2 HMIP_CCU2
setstate CCU2 2019-01-01 17:41:47 rpcstate running
setstate CCU2 2019-01-01 17:41:52 state OKDie Zeile kommt direkt aus dem WIKI zum HMCCU, ich habe bewusst das battery abgeändert, damit man die Unterschiede sehen kann.
Entweder ich hab da Tomaten auf den Augen oder da spuckt noch was anderes hinein.
Gruß Reinhard
Ich schaue mir das nochmal an. Das mit dem Reading bei HMIP stimmt natürlich. Und das kann tatsächlich true/false oder 1/0 werden.
Zitat von: Rewe2000 am 01 Januar 2019, 17:50:43
Wenn ich mit ccuaggregate bei einem Reading auf 0 und off afragen will kann ich das somit nicht unter einen name: erledigen, ich muss hier jeweils unter verschiedenen name: getrennt abfragen? Oder ich stelle bei den Devices sicher, dass hier nur 0 und nicht off vorkommt.
Ich habe mir nochmal meinen Code angeschaut. Bei if:any= und if:all= kann doch ein regulärer Ausdruck angegeben werden. Sowas wie
if:any=0|off müsste also funktionieren. Du kannst Dir das aber ersparen, indem du in den einzelnen Devices konsequent mit dem Attribut substitute die Ersetzung vornimmst.
Zitat
Irgendwie habe ich noch immer das Problem mit den Readingnamen, bei mir wird da kein Unterstich eingefügt, es wird definitiv nicht das Prefix= als Readingname verwendet, sondern der name: vom ccuaggregate.
Dieses Verhalten kann ich bei mir nicht nachvollziehen. D.h. bei mir wird das Prefix korrekt angewendet.
Hallo zap,
danke für deine Mühe.
Ich habe mir jetzt auch angewöhnt, die Readings konsequent mit substitute zu vereinheitlichen.
Das mit dem ccuaggregate kann ich mir nicht erklären, woher dieses Verhalten bei mir kommt. Ich behelfe mir jetzt damit, dass ich name und prefix gleich, mit folgendem Unterstrich eingebe, somit passt zumindest der Readingname.
Ich hätte natürlich gerne diesem Problem auf den Zahn gefühlt, will aber deswegen auf meinem Produktivsystem HMCCU nicht löschen und neu anlegen, da alles andere (derzeit) prima läuft. Hast du noch eine Idee nach was ich da noch gucken könnte, irgend etwas muss ja da bei mir dann nicht passen, wenn ich der einzige mit diesem Problem bin.
Theoretisch kann man ja mit ccuaggregate auf einfache Weise viele Zustände der Geräte abfragen, wirkt sich das eigentlich sehr auf die Performance der CCU2 oder des Raspi3 aus, auf welchem Fhem installiert ist?
Wie sind dazu deine Beobachtungen.
Ich plane hier bis zu 5 Abfragen (name) einzurichten, mit Abfragezyklen alle 5 Minuten.
Gruß Reinhard
Man kann die Berechnung der aggregierten Readings natürlich mit dem Befehl "get aggregation" erzwingen. Das geht dann schon auf die FHEM Performance. Die CCU wird dadurch nicht belastet, da hier lediglich Readings ausgewertet werden und keine Anfrage in Richtung CCU geht.
Eigentlich ist die explizite Abfrage aber nicht notwendig, da HMCCU bei jedem Event von der CCU bzw. bei jedem darauf folgenden Reading Update automatisch die Aggregationen neu berechnet.
Ich habe bei mir Aggregationen für Batterien, Batteriespannung, Erreichbarkeit, Dachfenster und Türen/Fenster definiert. Hat keine negativen Auswirkungen auf die FHEM Performance.
Das sieht so aus:
name:battery,filter:name=^HM_.*,read:battery,if:any=low,else:ok,prefix:battery_,coll:comment!Batterien OK;
name:voltage,filter:type=(HM-CC-RT-DN|HM-TC-IT-WM-W-EU),read:BATTERY_STATE,if:le=2.2,else:0,prefix:voltage_,coll:comment!Batteriespannung OK;
name:lock,filter:name=^HM_TF.*,read:state,if:any=open,else:closed,prefix:lock_,coll:comment!Alle Fenster/Türen geschlossen,html:/opt/fhem/scripts/conf/lock_list.cfg;
name:lockroof,filter:group=Dachfenster,read:state,if:any=open,else:closed,prefix:lockroof_,coll:comment!Alle Dachfenster geschlossen;
name:lockwin,filter:name=^HM_TF.*!Haustuer$,read:state,if:any=open,else:closed,prefix:lockwin_,coll:comment!Alle Fenster/Türen geschlossen,html:/opt/fhem/scripts/conf/windowlist.cfg;
name:hummax,filter:name=^HM_KL.*,read:HUMIDITY,if:ge=60,else:0,prefix:hummax_,coll:alias!Luftfeuchte OK;
name:unreach,filter:name=^HM_.*,read:activity,if:any=dead,else:alive,prefix:unreach_,coll:comment!Alle Devices erreichbar
Kannst Du natürlich nicht alles 1:1 übernehmen, da Deine Geräte vermutlich anders heißen.
Hallo zap,
ZitatEigentlich ist die explizite Abfrage aber nicht notwendig, da HMCCU bei jedem Event von der CCU bzw. bei jedem darauf folgenden Reading Update automatisch die Aggregationen neu berechnet.
Das klappt bei mir definitiv (auch) nicht. Ich habe es heute mit einer leeren Batterie beobachtet, die CCU2 hat die leere Batterie bei den Systemmeldungen erkannt, HMCCU bekam das erst mit, wenn ich nach ca. 2 Stunden ein "
get <HMCCU> aggregation all" ausgeführt habe. Muss ich da noch etwas anderes bei den attr des HMCCU Device einstellen, dass es so klappt wie bei dir?
Bisher habe ich den Befehl "
get <HMCCU> aggregation all" stündlich über ein doif ausgeführt, damit die entsprechenden Readings im HMCCU Device aktualisiert wurden.
Sollte das erneut wieder ein öminöser Fehler in einer Funktion im Device bei mir sein, so muss ich mir ernshaft Gedanken machen, wie ich die beseitigen kann.
Es wäre nett du könntest nochmals meine Einstellungen ansehen, ob dir da etwas fehlerhaftes auffällt.
HMCCU als RAW Definition:
defmod CCU2 HMCCU 192.168.1.32 waitforccu=120
attr CCU2 DbLogExclude .*
attr CCU2 ccuReqTimeout 8
attr CCU2 ccuaggregate name:HmIP_battery_,filter:group=HmIP-Device,read:(Batterie),if:any=leer,else:ok,prefix=HmIP_battery_,coll:alias;;\
name:HM_battery_,filter:group=HM-Device,read:(Batterie),if:any=leer,else:ok,prefix=HM_battery_,coll:alias;;\
name:DutyCycle_,filter:group=HmIP-Device,read:(0.DUTY_CYCLE),if:any=(1|true),else:(0|false),prefix=DutyCycle_,coll:alias
attr CCU2 ccuflags procrpc,nonBlocking
attr CCU2 cmdIcon on:general_an off:general_aus
attr CCU2 eventMap /rpcserver on:on/rpcserver off:off/
attr CCU2 group Hardware
attr CCU2 icon hm_ccu
attr CCU2 room Homematic
attr CCU2 rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
attr CCU2 rpcport 2001,2010,9292
attr CCU2 rpcqueue /tmp/ccuqueue
attr CCU2 rpcserver on
attr CCU2 stateFormat rpcstate/state
setstate CCU2 running/OK
setstate CCU2 2019-01-19 11:30:00 DutyCycle_count 54
setstate CCU2 2019-01-19 11:30:00 DutyCycle_list no match
setstate CCU2 2019-01-19 11:30:00 DutyCycle_match 0
setstate CCU2 2019-01-19 11:30:00 DutyCycle_state (0|false)
setstate CCU2 2019-01-19 11:30:00 HM_battery_count 4
setstate CCU2 2019-01-19 11:30:00 HM_battery_list no match
setstate CCU2 2019-01-19 11:30:00 HM_battery_match 0
setstate CCU2 2019-01-19 11:30:00 HM_battery_state ok
setstate CCU2 2019-01-19 11:30:00 HmIP_battery_count 54
setstate CCU2 2019-01-19 11:30:00 HmIP_battery_list HM_EG_FK1_Dusche
setstate CCU2 2019-01-19 11:30:00 HmIP_battery_match 1
setstate CCU2 2019-01-19 11:30:00 HmIP_battery_state leer
setstate CCU2 2019-01-19 12:03:52 Status_Watchdog 1
setstate CCU2 2019-01-17 21:24:49 count_channels 329
setstate CCU2 2019-01-17 21:24:49 count_devices 64
setstate CCU2 2019-01-17 21:24:49 count_groups 5
setstate CCU2 2019-01-17 21:24:49 count_interfaces 3
setstate CCU2 2019-01-17 21:24:49 count_programs 12
setstate CCU2 2019-01-19 11:59:53 iface_addr_1 NEQ1284235
setstate CCU2 2019-01-19 11:59:53 iface_addr_2 3014F711A000015569C13D2A
setstate CCU2 2019-01-19 11:59:53 iface_conn_1 1
setstate CCU2 2019-01-19 11:59:53 iface_conn_2 1
setstate CCU2 2019-01-19 11:59:53 iface_ducy_1 9
setstate CCU2 2019-01-19 11:59:53 iface_ducy_2 11
setstate CCU2 2019-01-19 11:59:53 iface_type_1 CCU2
setstate CCU2 2019-01-19 11:59:53 iface_type_2 HMIP_CCU2
setstate CCU2 2019-01-17 21:25:17 rpcstate running
setstate CCU2 2019-01-17 21:25:23 state OK
Ich habe bei vielen HmIP-Devices
"event-on-change-reading 1.STATE" gesetzt, muss ich hier eventuell mit "
.*" events für alle geänderten Readings zulassen?
Gruß Reinhard
Definitiv. Die automatische Aggregation hängt sich in die interne Notify Funktion von FHEM. Wenn also das Reading nicht in event-on... drin ist, bekommt HMCCU das nicht mit.