unterschiedliches Verhalten von ActionDetector (en)

misave · 05 August 2015, 18:53:42

Hallo zusammen,

ich habe insgesamt 5 ActionDetectoren im Einsatz, einen Bewegungsmelder, einen Drehgriffkontakt und drei optische Fenster/Tür-Sensoren. Alle fünf sind dem device ActionDetector zugeordnet, der ActionDetector hat das attr Event-on-Change-reading .* soweit so gut.

Bei keinem der Sensoren ist dieses attr selbst eingetragen. bei dem Drehgriffkontakt und bei dem optischen haustürsensor läuft ein notify, der mir eine Pushnachricht schickt, wenn der Zustand Haustuer:open .* eintritt. Bei diesem optischen Sensor kommt die Nachricht 2-4 mal wenn die Haustür aufbleibt. Die Haustür kann das ruhig weiter aufbleiben, es kommen keine neuen Nachrichten.

Der notify auf dem Drehgriffkontakt läuft auf Terrassentuer:open.* Hier kommt dann die Pushnachricht genau einmal, egal wie lange die Terrassentür auf ist.

Reagieren die beiden Typen von Sensoren unterschiedlich? Wie gesagt, bei keinem der Sensoren ist das attr event-on-Change-reading .* selbst gesetzt.

frank · 05 August 2015, 19:01:35

entweder du hast etwas missverstanden oder ich verstehe deine aussage nicht. das device actiondetector ist nicht für die events der devices zuständig. der meldet sich nur, wenn ein device in festgelegter zeit nichts mehr meldet.

misave · 05 August 2015, 20:17:10

Du hast Recht, das event-on-changing-reading beim ActionDetectoer überwacht nur die zugeordneten Sensoren, so weit dachte ich das auch.

Ich habe probeweise einen gleichen notify bei einem weiteren optischen Sensor eingebaut. Auch hier wird 4 mal die Nachricht gesendet. Danach ist Ruhe, egal wie lange die Tür aufbleibt.

Trotzdem bleibt dann die Frage offen, warum bei dem einen Sensor der notify 2-4 mal ausgelöst wird und bei dem anderen nur einmal. Einen Eintrag in Form von event-on... irgendwas steht bei keinem Sensor drin. Oder sind die nur in internen Registern sichtbar und ich müsste zunächst die internen Readings sichtbar machen wie auch die internen Peers von Schaltaktoren erst sichtbar gemacht werden müssen?

Ein attr Eintrag mit event-on... bei einem der optischen Sensoren führt natürlich dazu, dass der notify nur einmal ausgelöst wird.

Irgendeinen Grund muss es doch für das unterschiedliche Verhalten geben.

Kann jemand dies Verhalten bei sich nachvollziehen?

frank · 05 August 2015, 21:29:26

nicht nur "überfliegen", sondern "aufmerksam" lesen und wenigstens versuchen zu verstehen.

Zitatdas event-on-changing-reading beim ActionDetectoer überwacht nur die zugeordneten Sensoren,

falsch, denn

Zitatdas device actiondetector ist nicht für die events der devices zuständig.

ZitatAuch hier wird 4 mal die Nachricht gesendet.

schau im eventmonitor dort siehst du sämtliche events. was du dann damit in deinen notifys tust, weist nur du.

misave · 05 August 2015, 23:31:07

Im eventmonitor steht viermal das open drin, komischerweise aber viermal mit derselben count-Nr. deshalb wird auch viermal der notify ausgelöst.

der sensor kann doch nicht "prellen" wie ein mechanischer Schalter. anbei auch der Auszug vom Event-Monitor mit den entsprechenden Einträgen aus mehr oder weniger 1-2 sec.

frank · 06 August 2015, 09:23:23

dann sniffe mal die raw-messages => wiki: homematic sniffen.
ist dein fhem aktuell?

misave · 06 August 2015, 11:08:20

Meine fhem.pl ist die 9002 vom 29.07.2015

Das sniffen mache ich dann sobald ich das wiki dazu gelesen habe.

Um sicher zu gehen, die LogID ist die hexadezimale ID der bei mir zwei HMLan? also z.B. AAAAAA wenn diese ID bei der VCCU, HMLan1 und HMLan2 eingetragen sind, oder?

frank · 06 August 2015, 13:15:21

ZitatMeine fhem.pl ist die 9002 vom 29.07.2015

entscheidend für hm sind 10_cul_hm.pm, 00_hmlan.pm, hmconfig.pm. das sollte aber wohl ok sein.

Zitatdie LogID ist die hexadezimale ID

vom device. oder der devicename. kommagetrennte liste aller devices, die du loggen willst.

misave · 06 August 2015, 20:34:12

So, hier der Logfile mit den gesnifften Daten. Um diese zu erzeugen habe bei meinen beiden HMLan (HMlan1 und HMLan2, beide AAAAAA als ID) das LogIDs gesetzt auf das device Tuer_Terrasse mit dem Zusatz all,sys.

logfile siehe zwei Beiträge weiter, dann in code tag

3BC00F ist die Nummer des Tür/Fenster-Kontaktes. Diese Nummer steht unter DEF im device drin. Ich kann mit diesen Zahlenreihen natürlich noch gar nix anfangen.

Die Meldung über die geöffnete Tür kam zweimal.

frank · 06 August 2015, 20:45:56

Zitatbei meinen beiden HMLan

und du nutzt keine vccu? wenn nicht, gleich eine definieren.

hast du ausserdem noch einen repeater?

es wäre sehr augenfreundlich, die logzeilen im post mit code tags einzuschliessen.

misave · 07 August 2015, 13:35:58

Mit codetag habe ich es nicht so geschafft, weil ich den Eventmonitor auf einem Tablet laufen gelassen habe und den Text hier über ein Handy eingetragen habe.

Ja ich habe eine VCCU definiert und alle device sind mit der VCCU gepairt, kein device ist mit einen der beiden HMLAN gepairt. Bei allen device ist die IOGrp:VCCU gepflegt, keine HMLan direkt. Habe mich schön an die Empfehlung im Wiki gehalten und umgesetzt.

Beide HMLAN tragen dieselbe ID wie auch die VCCU (AAAAAA). Die optischen Sensoren Haustuer, Fenster_Fitness, Tuer_Terrasse sind mit dem VCCU_Btn4 gepeert. Mitgesnifft hatte ich bei beiden HMLan jeweils den Tuer_Terrasse Kontakt.

Code Auswählen


2015.08.06 20:24:13.671 0: HMLAN_Send:  HMLAN1 I:K
2015.08.06 20:24:13.676 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FB504E IDcnt:000B L:2 %
2015.08.06 20:24:38.687 0: HMLAN_Send:  HMLAN1 I:K
2015.08.06 20:24:38.757 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FBB209 IDcnt:000B L:2 %
2015.08.06 20:25:03.688 0: HMLAN_Send:  HMLAN1 I:K
2015.08.06 20:25:03.693 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FC13B7 IDcnt:000B L:2 %
2015.08.06 20:25:28.691 0: HMLAN_Send:  HMLAN1 I:K
2015.08.06 20:25:28.695 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FC7565 IDcnt:000B L:2 %
2015.08.06 20:25:53.237 0: HMLAN_Send:  HMLAN2 I:K
2015.08.06 20:25:53.241 0: HMLAN_Parse: HMLAN2 V:03C4 sNo:LEQ0578979 d:2BACF0 O:AAAAAA t:52DED0ED IDcnt:0003 L:2 %
2015.08.06 20:25:53.693 0: HMLAN_Send:  HMLAN1 I:K
2015.08.06 20:25:53.697 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FCD713 IDcnt:000B L:2 %
2015.08.06 20:25:54.062 0: HMLAN_Parse: HMLAN1 R:E3BC00F   stat:0000 t:16FCD876 d:FF r:FFBE     m:A8 A641 3BC00F AAAAAA 019000
2015.08.06 20:25:54.153 0: HMLAN_Send:  HMLAN1 S:S044328E3 stat:  00 t:00000000 d:01 r:044328E3 m:A8 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:25:54.165 0: HMLAN_Parse: HMLAN2 R:E3BC00F   stat:0000 t:52DED418 d:FF r:FFBD     m:A8 A641 3BC00F AAAAAA 019000
2015.08.06 20:25:54.186 0: HMLAN_Parse: HMLAN2 R:EAAAAAA   stat:0000 t:52DED493 d:FF r:FF9E     m:A8 8002 AAAAAA 3BC00F 00
2015.08.06 20:25:54.446 0: HMLAN_Parse: HMLAN1 R:R044328E3 stat:0002 t:00000000 d:FF r:7FFF     m:A8 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:25:54.453 0: HMLAN_Parse: HMLAN2 R:EAAAAAA   stat:0000 t:52DED59E d:FF r:FF9D     m:A8 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:25:54.624 0: HMLAN_Parse: HMLAN1 R:E3BC00F   stat:0000 t:16FCDAA9 d:FF r:FFC2     m:A9 A241 3BC00F AAAAAA 019000
2015.08.06 20:25:54.715 0: HMLAN_Send:  HMLAN1 S:S04432B14 stat:  00 t:00000000 d:01 r:04432B14 m:A9 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:25:54.728 0: HMLAN_Parse: HMLAN2 R:E3BC00F   stat:0000 t:52DED64B d:FF r:FFBD     m:A9 A241 3BC00F AAAAAA 019000
2015.08.06 20:25:54.748 0: HMLAN_Parse: HMLAN2 R:EAAAAAA   stat:0000 t:52DED6C5 d:FF r:FF9E     m:A9 8002 AAAAAA 3BC00F 00
2015.08.06 20:25:55.008 0: HMLAN_Parse: HMLAN1 R:R04432B14 stat:0002 t:00000000 d:FF r:7FFF     m:A9 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:25:55.015 0: HMLAN_Parse: HMLAN2 R:EAAAAAA   stat:0000 t:52DED7D0 d:FF r:FF9D     m:A9 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:00.086 0: HMLAN_Parse: HMLAN1 R:E1676EF   stat:0000 t:16FCF000 d:FF r:FFB7     m:AA A441 1676EF AAAAAA 01A700
2015.08.06 20:26:00.100 0: HMLAN_Parse: HMLAN2 R:E1676EF   stat:0000 t:52DEEBA1 d:FF r:FFA5     m:AA A441 1676EF AAAAAA 01A700
2015.08.06 20:26:00.210 0: HMLAN_Parse: HMLAN2 R:EAAAAAA   stat:0000 t:52DEEC1C d:FF r:FF95     m:AA 8002 AAAAAA 1676EF 00
2015.08.06 20:26:08.156 0: HMLAN_Parse: HMLAN1 R:E3BC00F   stat:0000 t:16FD0F87 d:FF r:FFCA     m:AA A641 3BC00F AAAAAA 0191C8
2015.08.06 20:26:08.247 0: HMLAN_Send:  HMLAN1 S:S04435FF0 stat:  00 t:00000000 d:01 r:04435FF0 m:AA 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:09.068 0: HMLAN_Parse: HMLAN2 R:E3BC00F   stat:0000 t:52DF0B28 d:FF r:FFB6     m:AA A641 3BC00F AAAAAA 0191C8
2015.08.06 20:26:09.072 0: HMLAN_Parse: HMLAN2 R:EAAAAAA   stat:0000 t:52DF0BA3 d:FF r:FF9D     m:AA 8002 AAAAAA 3BC00F 00
2015.08.06 20:26:09.078 0: HMLAN_Parse: HMLAN2 R:EAAAAAA   stat:0000 t:52DF0CAE d:FF r:FF9C     m:AA 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:09.084 0: HMLAN_Parse: HMLAN2 R:E3BC00F   stat:0000 t:52DF0D5D d:FF r:FFB3     m:AB A241 3BC00F AAAAAA 0191C8
2015.08.06 20:26:09.088 0: HMLAN_Send:  HMLAN1 I:-3BC00F
2015.08.06 20:26:09.090 0: HMLAN_Send:  HMLAN2 I:+3BC00F,00,00,
2015.08.06 20:26:09.091 0: HMLAN_Send:  HMLAN2 S:+3BC00F,00,00,00
2015.08.06 20:26:09.091 0: HMLAN_Send:  HMLAN2 S:S04436391 stat:  00 t:00000000 d:01 r:04436391 m:AB 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:09.902 0: HMLAN_Parse: HMLAN2 R:EAAAAAA   stat:0000 t:52DF0DD7 d:FF r:FF9C     m:AB 8002 AAAAAA 3BC00F 00
2015.08.06 20:26:09.908 0: HMLAN_Parse: HMLAN1 R:R04435FF0 stat:0002 t:00000000 d:FF r:7FFF     m:AA 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:09.909 0: HMLAN_Parse: HMLAN1 R:E3BC00F   stat:0000 t:16FD11BB d:FF r:FFC9     m:AB A241 3BC00F AAAAAA 0191C8
2015.08.06 20:26:09.913 0: HMLAN_Parse: HMLAN1 R:EAAAAAA   stat:0000 t:16FD1354 d:FF r:FFA0     m:AB 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:09.918 0: HMLAN_Parse: HMLAN1 R:E1676EF   stat:0000 t:16FD1423 d:FF r:FFC2     m:AB A441 1676EF AAAAAA 01A8C8
2015.08.06 20:26:10.761 0: HMLAN_Parse: HMLAN2 R:R04436391 stat:0002 t:00000000 d:FF r:7FFF     m:AB 8002 AAAAAA 3BC00F 0101C800
2015.08.06 20:26:10.762 0: HMLAN_Parse: HMLAN2 R:E1676EF   stat:0000 t:52DF0FC5 d:FF r:FFA4     m:AB A441 1676EF AAAAAA 01A8C8
2015.08.06 20:26:10.766 0: HMLAN_Parse: HMLAN2 R:EAAAAAA   stat:0000 t:52DF103F d:FF r:FF9A     m:AB 8002 AAAAAA 1676EF 00
2015.08.06 20:26:18.246 0: HMLAN_Send:  HMLAN2 I:K
2015.08.06 20:26:18.250 0: HMLAN_Parse: HMLAN2 V:03C4 sNo:LEQ0578979 d:2BACF0 O:AAAAAA t:52DF32A2 IDcnt:0004 L:2 %
2015.08.06 20:26:18.695 0: HMLAN_Send:  HMLAN1 I:K
2015.08.06 20:26:18.699 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FD38C2 IDcnt:000A L:1 %
2015.08.06 20:27:02.804 1: PERL WARNING: Use of uninitialized value $aVal in split at ./FHEM/00_HMLAN.pm line 254.
2015.08.06 20:27:08.699 0: HMLAN_Send:  HMLAN1 I:K
2015.08.06 20:27:08.703 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FDFC1E IDcnt:000A L:1 %
2015.08.06 20:27:17.050 0: HMLAN_Parse: HMLAN1 R:E2F2DB6   stat:0000 t:16FE1CB0 d:FF r:FFC6     m:D7 8410 2F2DB6 AAAAAA 06013E00
2015.08.06 20:27:33.701 0: HMLAN_Send:  HMLAN1 I:K
2015.08.06 20:27:33.705 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:KEQ1024189 d:23D58D O:AAAAAA t:16FE5DCC IDcnt:000A L:1 %
Use of uninitialized value in numeric gt (>) at fhem.pl line 798.

LuckyDay · 07 August 2015, 15:16:27

Zeig mal bitte ein list von deinem türsensor,

frank · 07 August 2015, 15:19:59

Code Auswählen

2015.08.06 20:25:54.062 0: HMLAN_Parse: HMLAN1 R:E3BC00F   stat:0000 t:16FCD876 d:FF r:FFBE     m:A8 A641 3BC00F AAAAAA 019000
2015.08.06 20:25:54.165 0: HMLAN_Parse: HMLAN2 R:E3BC00F   stat:0000 t:52DED418 d:FF r:FFBD     m:A8 A641 3BC00F AAAAAA 019000
2015.08.06 20:25:54.624 0: HMLAN_Parse: HMLAN1 R:E3BC00F   stat:0000 t:16FCDAA9 d:FF r:FFC2     m:A9 A241 3BC00F AAAAAA 019000
2015.08.06 20:25:54.728 0: HMLAN_Parse: HMLAN2 R:E3BC00F   stat:0000 t:52DED64B d:FF r:FFBD     m:A9 A241 3BC00F AAAAAA 019000

pro ereignis werden 2x2 msgs empangen. je 2 von hmlan1 und hmlan2. ich denke du könntest die anzahl halbieren, wenn du das peering mit dem vccu_button wieder rückgängig machst. hattest du das eingerichtet, weil du es gelesen hast, oder gab es sonst keine rückmeldung? denn es wird auf alles geantwortet. ausserdem solltest du preffered io definieren, und zwar das mit den besseren rssi. das device wird ja fest verbaut sein, denke ich. teste doch mal für das device 3BC00F. dann noch ein event-on-change attr am kontakt und alles sollte passen.
ein list der vccu wäre auch noch interessant.

misave · 07 August 2015, 19:30:05

Hallo,

hier zunächst das list VCCU:

Code Auswählen


Internals: 
   DEF        AAAAAA 
   HMLAN1_MSGCNT 684 
   HMLAN1_RAWMSG EAAAAAA,0000,1BBF0155,FF,FFA8,288002AAAAAA30A6E800 
   HMLAN1_RSSI -88 
   HMLAN1_TIME 2015-08-07 18:36:14 
   HMLAN2_MSGCNT 769 
   HMLAN2_RAWMSG EAAAAAA,0000,57C27696,FF,FFAE,428440AAAAAA0000000401 
   HMLAN2_RSSI -82 
   HMLAN2_TIME 2015-08-07 19:12:47 
   IODev      HMLAN1 
   LASTInputDev HMLAN2 
   MSGCNT     1453 
   NAME       VCCU 
   NR         22 
   STATE      CMDs_done 
   TYPE       CUL_HM 
   assignedIOs HMLAN1,HMLAN2 
   channel_01 VCCU_Btn1 
   channel_02 VCCU_Btn2 
   channel_03 VCCU_Btn3 
   channel_04 VCCU_Btn4 
   channel_05 VCCU_Btn5 
   channel_06 VCCU_Btn6 
   channel_07 VCCU_Btn7 
   channel_08 VCCU_Btn8 
   channel_09 VCCU_Btn9 
   channel_0A VCCU_Btn10 
   channel_0B VCCU_Btn11 
   channel_0C VCCU_Btn12 
   channel_0D VCCU_Btn13 
   channel_0E VCCU_Btn14 
   channel_0F VCCU_Btn15 
   channel_10 VCCU_Btn16 
   channel_11 VCCU_Btn17 
   channel_12 VCCU_Btn18 
   channel_13 VCCU_Btn19 
   lastMsg    No:42 - t:40 s:AAAAAA d:000000 0401 
   protLastRcv 2015-08-07 19:12:47 
   protSnd    1 last_at:2015-08-07 19:12:47 
   protState  CMDs_done 
   rssi_at_HMLAN1 avg:-85.57 min:-103 max:-79 lst:-88 cnt:684 
   rssi_at_HMLAN2 avg:-90.35 min:-107 max:-81 lst:-82 cnt:769 
   Readings: 
     2015-08-07 19:09:14   CommandAccepted yes 
     2015-08-07 19:12:47   state           CMDs_done 
     2015-08-01 15:24:57   unknown_30D433  received 
     2015-08-01 15:25:22   unknown_30D727  received 
     2015-08-03 00:15:20   unknown_377770  received 
   Helper: 
     HM_CMDNR   66 
     mId        FFF0 
     rxType     1 
     Io: 
       nextSend   1438967567.4525 
       prefIO 
       vccu 
       ioList: 
         HMLAN1 
         HMLAN2 
     Mrssi: 
       mNo        42 
       Io: 
         HMLAN2     -82 
     Prt: 
       bErr       0 
       sProc      0 
       Rspwait: 
     Q: 
       qReqConf 
       qReqStat 
     Role: 
       dev        1 
     Rssi: 
       At_hmlan1: 
         avg        -85.5774853801169 
         cnt        684 
         lst        -88 
         max        -79 
         min        -103 
       At_hmlan2: 
         avg        -90.3511053315995 
         cnt        769 
         lst        -82 
         max        -81 
         min        -107 
Attributes: 
   IODev      HMLAN1 
   IOList     HMLAN1,HMLAN2 
   model      CCU-FHEM 
   room       system 
   subType    virtual 
   webCmd     virtual:update

Ich habe die Sensoren gepeert, weil ich das a) gelesen hatte und damit angebl. den Eintrag trigDst no config beseitigen könne. Dem war aber nicht so. Die Meldungen aus den Tür/Fensterkontakten kam auch ohne das Peering. Ich nehme es mal raus. Ein event-on-change attr habe ich nun eh gesetzt, damit die Meldung zunächst nur einmal gesendet wird. Die interne Verarbeitung über beide HMLANs ist damit natürlich nicht verändert.

Ich hatte bisher kein preferred IO eingetragen weil dann auch beim Ausfall des preferred IO das VCCU das ander HMLAN verwendet. Ich hatte das so verstanden mit setzen von IOGrp mit/ohne Doppelpunkt und Nennung eines preferred.

Die in der Liste des VCCU aufgeführten unknown devices sind nach dem letzten update entstanden. Ich hatte nach dem update einen UP-Schalter neu angelernt. Es funktionierte alles, bis ich ein rename durchgeführt habe. direkt danach tauchte das device als unknown auf und mein Logfile wurde vollgemüllt mit error-Meldungen. das umbenante device hat aber trotzdem vollständig funktioniert. und es lag nicht am dazugehörigen log-file geprüft. Das war auch umbenannt. Ich habe dann das Pairing zurückgenommen und wiederholt. Irgenwann hat dann das rename komplett geklappt.

frank · 07 August 2015, 20:29:59

im state der vccu sollte eigentlich so etwas in der art stehen:

Code Auswählen

2015-08-06 08:03:40 state hmlan1:ok,hmusb1:ok,

vielleicht liegt es an den vielen channel, die du hast. ich habe keine. aber mach mal set vccu update und kontrolliere.

ZitatIch hatte bisher kein preferred IO eingetragen weil dann auch beim Ausfall des preferred IO das VCCU das ander HMLAN verwendet. Ich hatte das so verstanden mit setzen von IOGrp mit/ohne Doppelpunkt und Nennung eines preferred.

nur beim attr IOgrp kann man preffered io angeben. wenn man ein oder mehrere angibt, immer mit doppelpunkt. solange das preffered io ok ist, wird es benutzt. wenn nicht, dann das nächste preffered. wenn keine perffered io mehr da sind, dann kommt das mit dem besten rssi von den noch möglichen. mit preffered io muss nicht ständig berechnet und umassigned werden. da io und device fest verbaut sind, wird sich bei dir auch nicht viel verändern, besonders wenn die rssi auch noch dicht beieinander liegen.

ZitatDie Meldungen aus den Tür/Fensterkontakten kam auch ohne das Peering. Ich nehme es mal raus.

dann halten die batterien sicher doppelt so lange. post noch ein log davon, zum vergleichen.

ZitatEin event-on-change attr habe ich nun eh gesetzt, damit die Meldung zunächst nur einmal gesendet wird.

ich habe überall "event-on-change .*". das gilt dann für alle readings. wenn ich doch mal ein reading mit jeglichen events benötige, setze ich zusätzlich "event-on-update my_reading". das gilt dann nur für dieses reading.

ZitatDie in der Liste des VCCU aufgeführten unknown devices sind nach dem letzten update entstanden. Ich hatte nach dem update einen UP-Schalter neu angelernt.

jedes neue device müsste eigentlich ein reading erzeugen, da die erste anlernmessage vom device immer von einem unbekannten device ist. erst anschliessend wird es gepaired und dadurch bekannt gemacht. danach sollte man das reading vielleicht mal löschen. ausserdem die wirklich unbekannten definieren und auf ignore setzen. dafür gibt es sogar einen befehl.

gruss frank