Hallo zusammen,
ich habe einen RPi mit CUL und nun auch mit HMLAN laufen. Zunächst hatte ich meine Komponenten ausschließlich mit CUL betrieben und nun noch einen HMLAN dazugenommen. Wie in diversen Freds und auch im WIKI beschrieben habe ich nach einem Update des HMLAN die Komponenten alle noch einmal in der Windows-Software angelernt, nachdem ich dort von Hand die hmId in die bestehende geändert habe.
In fhem habe ich alle IODev auf HMLAN geändert.
Dann habe ich erfolgreich den HMLAN an fhem ans Laufen bekommen. Den CUL möchte ich mit gleicher hmId parallel laufen lassen. Funktioniert auch grundsätzlich, allerdings habe ich durch doppelten Empfang dann die unschönenen Meldungen im Log:
2014.10.08 06:39:38 3: CUL0: Unknown code A0A888002AAF00728B75000::-51.5:CUL0, help me!
2014.10.08 06:41:38 3: CUL0: Unknown code A0F0B803FAAF00728B7E002041BC77D01::-52:CUL0, help me!
2014.10.08 06:41:38 3: CUL0: Unknown code A0F0B803FAAF00728B7E002041BC77D01::-52:CUL0, help me!
2014.10.08 06:46:19 3: CUL0: Unknown code A0A058002AAF00726C37000::-52:CUL0, help me!
2014.10.08 06:46:30 3: CUL0: Unknown code A0A078002AAF00726C37000::-51:CUL0, help me!
2014.10.08 06:47:06 3: CUL0: Unknown code A0A1A8002AAF00726992100::-51.5:CUL0, help me!
2014.10.08 06:47:11 3: CUL0: Unknown code A0A1B8002AAF00726992100::-51.5:CUL0, help me!
2014.10.08 06:47:30 3: CUL0: Unknown code A0A098002AAF00726C37000::-51:CUL0, help me!
2014.10.08 06:55:17 3: CUL0: Unknown code A0A108002AAF00728263A00::-51.5:CUL0, help me!
2014.10.08 06:55:18 3: CUL0: Unknown code A0D108002AAF00728263A0101C800::-52:CUL0, help me!
2014.10.08 07:00:35 3: CUL0: Unknown code A0A588002AAF00728240F00::-53:CUL0, help me!
2014.10.08 07:00:35 4: CUL_HM GAR_MK_Tor dupe: dont process
2014.10.08 07:00:35 3: CUL0: Unknown code A0D588002AAF00728240F0101C800::-53:CUL0, help me!
2014.10.08 07:03:14 3: CUL0: Unknown code A0A598002AAF00728240F00::-50.5:CUL0, help me!
2014.10.08 07:03:14 4: CUL_HM GAR_MK_Tor dupe: dont process
2014.10.08 07:03:14 3: CUL0: Unknown code A0D598002AAF00728240F0101C800::-50.5:CUL0, help me!
Die Dupes sind mir noch einleuchtend. Aber nicht die Unknown codes, die CUL0 sendet.
Was ist die Ursache bzw. wie kann ich das abstellen außer durch Deaktivieren des CUL oder einer anderen hmId?
Hallo, Stichwort vccu. Sieh mal hier im Fred, da gibt es schon einiges dazu.
VG
Frank
Herzlichen Dank für das schnelle(!) Stichwort!
"Eingebaut", funktioniert!
Noch eine Frage zur IOgrp: bislang habe ich bei allen Devices ein IODev stehen. Muss ich das nun auskommentieren und durch IOgrp ersetzen? Bei zwei Devices, die ich auf ein bestimmtes IO zwingen will, habe ich das mit attr <Dev> IOgrp vccu:HMLAN1 getan.
Ne, ist alles OK, so wie du es eingerichtet hast. Bin jetzt erstma arbeiten :)
VG
Frank
Frohes Schaffen und danke für die Hilfe!
Wichtig ist mir abschließend Folgendes: bei diversen Aktoren habe ich AES aktiv, diese müssen daher zumindest für Schaltbefehle über den HMLAN angesprochen werden. Wenn ich es richtig verstanden habe, erreiche ich das grundsätzlich ja mit attr <Dev> IOgrp vccu:HMLAN1. Kann es sein, dass vccu trotzdem bei besserer RSSI auch mal über CUL geht, obwohl HMLAN1 funktional ist?
http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU hat Martin was dazu geschrieben
Danke - das hatte ich wohl gelesen, war mir aber in der Wirkung des prefered nicht ganz klar.
Funktioniert bei mir. Habe es so eingerichtet:
define HMLAN0 HMLAN 10.0.0.5:1000
attr HMLAN0 group Schnittstellen
attr HMLAN0 hmId 123456
attr HMLAN0 hmKey 01:xyz
attr HMLAN0 hmLanQlen 1_min
attr HMLAN0 icon hm_lan
attr HMLAN0 room System
define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 group Schnittstellen
attr CUL0 hmId 123456
attr CUL0 icon cul_cul
attr CUL0 rfmode HomeMatic
attr CUL0 room System
define CCU CUL_HM 123456
attr CCU IODev CUL0
attr CCU IOList CUL0,HMLAN0
attr CCU model CCU-FHEM
attr CCU subType virtual
attr CCU webCmd virtual:update
Ist das so ok? Oder soll/muss die hmId bei den IOs nun weg? Das IODev bei der CCU hat CCU selbst eingetragen - ist das das Default-Device der CCU, welches ich dann so ändern kann?
http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU#HMId_w.C3.A4hlen
Steht nichts von wegnehmen.
http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU#Bemerkungen:
"Das Attribut IODev wird automatisch gesetzt, der User muss hier nichts mehr eintragen. Es ist aus Systemgründen weiter notwendig und kann sich verändern. Es zeigt das letzte genutzte output-device an."
ZitatKann es sein, dass vccu trotzdem bei besserer RSSI auch mal über CUL geht, obwohl HMLAN1 funktional ist?
sollte nicht so sein.
für die devices, bei denen du aes eingeschaltet hast, solltest du das attr IOgrp eventuell entfernen, und nur attr IODev nutzen. der cul kann das ja nicht übernehmen.
deine cfg ist ok. default device gibt es wohl nicht.
@krikan
ZitatEs zeigt das letzte genutzte output-device an.
nicht das attribut, sondern das internals reading IODev.
gruss frank
Danke!
@frank: Das war ein Zitat aus dem Wiki.
Gruß, Christian
ZitatDas war ein Zitat aus dem Wiki.
hatte ich auch so verstanden. wird durch zitieren der aussage aber nicht besser. ;)
gruss frank
Dann erkläre mir bitte meinen Fehler, ich begreife es nicht. Ralli hat Attribut gezeigt, danach gefragt und Martin hat im Wiki genau das Zitierte zum Attribut geschrieben. Muss was im Wiki klargestellt werden? Danke
Zitat von: krikan am 08 Oktober 2014, 11:20:06
Dann erkläre mir bitte meinen Fehler, ich begreife es nicht. Ralli hat Attribut gezeigt, danach gefragt und Martin hat im Wiki genau das Zitierte zum Attribut geschrieben. Muss was im Wiki klargestellt werden? Danke
ZitatBemerkungen
Es wird empfohlen, das Attribut IOgrp in allen Devices zu setzen. Kanäle senden nicht selbständig, haben daher auch kein Attribut IOgrp.
Das Attribut IODev wird automatisch gesetzt, der User muss hier nichts mehr eintragen. Es ist aus Systemgründen weiter notwendig und kann sich verändern. Es zeigt das letzte genutzte output-device an.
Die besprochene Steuerung betrifft das Senden. Empfangen und verarbeitet werden Nachrichten immer von allen verfügbaren Quellen.
also ich habe noch nie bemerkt, dass sich das attr iodev von selbst geändert hätte. wenn ich mal ein neues pairing eines schon vorhandenen devices durchführe, habe ich dort schon mal veränderungen erlebt. ich ändere das attribut dann aber immer wieder nach einem festen schema, sodass dort das io eingetragen ist, dass benutzt werden sollte, wenn das attribut iogrp nicht vorhanden wäre.
nach meinem verständnis sind attribute auch nicht zur anzeige von zuständen gedacht, sondern readings. in diesem fall gibt es auch ein reading unter internals mit gleichem namen. hier kann ich durchaus eine änderung des aktuell genutzten io erkennen. dort wird sofort eine änderung eines prefered io eingetragen.
also der text sagt eindeutig, dass das attribut das aktuelle io anzeigt. ich habe gerade noch einen test gemacht. bei mir ändert sich nur das internals-reading, aber nicht das attribut. somit ist entweder mein fhem zu alt, oder der text sagt etwas falsches aus. da muss ich wohl wieder mal ein update machen. :)
gruss frank
Danke frank für Deine ausführliche Erklärung. :) Dein Verständnis Attribut/Readings teile ich grds.; meine aber es gibt bei Homematic aus bestimmten Gründen "fließende" Grenzen.
Dann brauchen wir wohl Martin. Er weiß am Besten, ob er sich nur vertippt hat. Seine Angaben im Wiki will ich nicht ohne Bestätigung ändern.
@martinp876: Liest Du mit und könntest das bitte kurz klar stellen. Danke!
Gruß, Christian
Ich muss noch mal mit einer kurzen Nachfrage stören. Die Konfiguration meiner vCCU ist ja im oberen Beitrag dokumentiert.
Trotzdem erhalte ich noch folgende Log-Einträge:
2014.10.08 12:18:19 4: CUL_HM GAR_MK_Tor dupe: dont process
2014.10.08 12:20:44 4: CUL_HM GAR_MK_Tor dupe: dont process
2014.10.08 12:54:30 4: CUL_HM GAR_MK_Tor dupe: dont process
2014.10.08 12:59:38 4: CUL_HM GAR_MK_Tor dupe: dont process
2014.10.08 13:01:17 4: CUL_HM GAR_MK_Tor dupe: dont process
Das Log vom Sensor zeigt:
2014-10-08_12:18:19 GAR_MK_Tor trigDst_CCU: noConfig
2014-10-08_12:18:19 GAR_MK_Tor battery: ok
2014-10-08_12:18:19 GAR_MK_Tor open
2014-10-08_12:18:19 GAR_MK_Tor contact: open (to CCU)
2014-10-08_12:20:44 GAR_MK_Tor trigDst_CCU: noConfig
2014-10-08_12:20:44 GAR_MK_Tor battery: ok
2014-10-08_12:20:44 GAR_MK_Tor closed
2014-10-08_12:20:44 GAR_MK_Tor contact: closed (to CCU)
2014-10-08_12:54:30 GAR_MK_Tor trigDst_CCU: noConfig
2014-10-08_12:54:30 GAR_MK_Tor battery: ok
2014-10-08_12:54:30 GAR_MK_Tor open
2014-10-08_12:54:30 GAR_MK_Tor contact: open (to CCU)
2014-10-08_12:55:32 GAR_MK_Tor trigDst_CCU: noConfig
2014-10-08_12:55:32 GAR_MK_Tor battery: ok
2014-10-08_12:55:32 GAR_MK_Tor closed
2014-10-08_12:55:32 GAR_MK_Tor contact: closed (to CCU)
2014-10-08_12:59:38 GAR_MK_Tor trigDst_CCU: noConfig
2014-10-08_12:59:38 GAR_MK_Tor battery: ok
2014-10-08_12:59:38 GAR_MK_Tor open
2014-10-08_12:59:38 GAR_MK_Tor contact: open (to CCU)
2014-10-08_13:01:17 GAR_MK_Tor trigDst_CCU: noConfig
2014-10-08_13:01:17 GAR_MK_Tor battery: ok
2014-10-08_13:01:17 GAR_MK_Tor closed
2014-10-08_13:01:17 GAR_MK_Tor contact: closed (to CCU)
Man erkennt, dass der Sensor richtigerweise an die CCU meldet. Warum gibt es dann trotzdem noch Dupes im Log, sollten die nicht von der CCU bereits raus gefiltert werden?
Welchen loglevel hast du ? Etwas hoch meine ich. Bei default kommt das nicht.
Wie will die cul duplicate erkennen ? Die erste msg kam von einer anderen instanz, die kennt die cul nicht.
Dupe macht cul_hm
Hallo Martin,
Loglevel normal 3, für den Garagentor-MK aber 4.
Die Dupes kommen ja von CUL_HM, nicht von CUL. Und vom Typ CUL_HM ist die CCU. Schau:
define HMLAN0 HMLAN 10.0.0.5:1000
attr HMLAN0 group Schnittstellen
attr HMLAN0 hmId 123456
attr HMLAN0 hmKey 01:xyz
attr HMLAN0 hmLanQlen 1_min
attr HMLAN0 icon hm_lan
attr HMLAN0 room System
define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 group Schnittstellen
attr CUL0 hmId 123456
attr CUL0 icon cul_cul
attr CUL0 rfmode HomeMatic
attr CUL0 room System
define CCU CUL_HM 123456
attr CCU IODev CUL0
attr CCU IOList CUL0,HMLAN0
attr CCU model CCU-FHEM
attr CCU subType virtual
attr CCU webCmd virtual:update
ZitatLoglevel normal 3, für den Garagentor-MK aber 4.
logs über duplicate kommen bei Level 4 - passt also
ZitatDie Dupes kommen ja von CUL_HM, nicht von CUL.
so muss es sein
ZitatUnd vom Typ CUL_HM ist die CCU
gut
ist also alles prima, wie es sein soll.
Das ist kein Fehler sondern eine Info zum debuggen, wenn man so will. Daher in einem loglevel unter normal.