HM virtual CCU

[swisshome]

Un das nur kurz zu untermauern. Das selbe ist bei mir seit dem heutigen Update der Fall.
Rauchmelder stehen seit dem spontan auf missing ack  und Fenster (3-State) Sensoren auf Response timeout. Die devices von 2 HM-CC-RT-DN stehen auch auf Timeout.

Irgendwas ist da zerschossen

[betateilchen]

könnte mit einem Bug zu tun haben - der Transmit mode war falsch berechnet.
Ist schon behoben (heute).

Ich hab mal die aktuelle SVN Version einkopiert, mal schauen, ob sich was ändert.
Aktiv an den Sensoren oder an deren Konfiguration in fhem habe ich NICHTS gemacht.

[betateilchen]

scheint jetzt zu funktionieren. Zumindest steht jetzt in state wieder der tatsächliche Status (interessanterweise war auch im Fehlerfall das Reading "contact" korrekt gefüllt)

[martinp876]

habe den Fehler erst heute bemerkt, als ich meine RTs nicht mehr erreichen konnte - kann nicht lange drin gewesen sein. Faktisch wurde der Transmitmode errechnet als die Model-Info noch nicht vorhanden war. Kann jetzt nicht mehr vorkommen.

Wäre nur die Frage, wie autoReadReg bei den Aktoren steht

[betateilchen]

Bei mir steht autoReadReg im Normalfall auf 3 (wenn es nicht auf 0 steht)

[frank]

hallo martin,

könnte die v-ccu dann nicht das management der device-registerwerte übernehmen. also automatisch sichern und restaurieren?

vielleicht sogar komplett hminfo.

gruss frank

[martinp876]

Hallo Frank,

HMInfo steht ueber gesamt CUL_HM. Eine CCU nur ueber einem Teil. Die meinsten werden nur eine CCU nutzen - aber wer will kann mehr.
Und eine CCU ist nicht Pflicht... es passt nicht ganz.
Eine CCU nach HMInfo hochzuziehen (oder jedenfalls einen Level oberhalb von CUL_HM) ist auch nicht ganz einfach - zumindest aktuell nicht sinnvoll.

Das handling der Registerwerte mit HMInfo sollte doch mittlerweile einfach sein. Ich wuerde autoArchive vorschlagen, ausserdem autoReadReg 5 und beim (nach dem) booten ein loadConfig. Das sollte dann alles im Hintergrund funktionieren.

immernoch zu kompliziert?

Gruss Martin

[betateilchen]

immernoch zu kompliziert?

immer noch komplizierter...

[martinp876]

wie kann man es einfacher machen?
jedes erfolgreiche lesen wird gespeichert - automatisch.
Automatisches lesen ist einstellbar - passiert im Hintergrund.
automatisches laden kann mit einem Kommando erreicht werden.
komplettes pruefen mit einem Kommando moeglich

man kann das ganze fix einbauen... das widerspricht aber der FHEM philisophie.

wo kann/sollte man einhaken?

[mcfly71]

Hallo Martin,

ich weiss nicht, ob es damit zu tun hat, aber bei mir sind einige Module seit dem neusten Update mit "missing ack" sozusagen beschriftet. Es sind meist diejenigen, die einen BURST Modus verwenden ( z.B. HM-LC-SW1-BA-PCB)

Kann es sein, dass deine Änderung diesbezüglich was zerschossen hat ?


VG
mcfly

[betateilchen]

Da scheint auch noch so ein Fall zu sein:

http://forum.fhem.de/index.php/topic,23035.0.html

[martinp876]

ja, hat sie. Ist weiter oben beschrieben - der transmittmode wird nicht korrekt ermittelt.
Der Fix ist schon in SVN, aber erst morgen im Update.

p.s. mit dem Blind aktor sollte es nichts zu tun haben - dessen mode ist "always" und damit kein Problem.

[frank]

immernoch zu kompliziert?

darum ging es jetzt gar nicht.

mir ging es darum, so eine vccu attraktiver zu gestalten. je mehr "must-have"-features, desto mehr werden sie einsetzen.
wenn eine immer "master"-ccu wäre könnten auch mehrere nebeneinander existieren.

mein verständnis von "zentrale" ist halt ein zentrales device, welches zentrale features vereinigt.

ich habe mir gerade eine ccu definiert, mit cul_hm aus svn. ich habe sie mit der hmid von meinem hmlan definiert. komischerweise hat sie sich als iodev aber meinen cul geschnappt, der eine andere hmid hat. der hmlan ist aber als assignedio eingetragen. cul aber nicht.

gruss frank

[martinp876]

Hi Frank,

eine HM-CCU macht das ganze Parsing, Senden und verwalten. Das macht FHEM schon - und erledigt damit einen großen Teil einer CCU-Arbeit.

Unschön ist bislang das unkoordinierte handling der IOs. Die HMId ist in CUL_HM nicht erfasst, gleiche HMIds werden nicht zusammengefasst. Ein device ist mit einen IO gepairt... das stimmt so nicht, insbesondere wenn es mehrere IOs gibt.

Ausserdem hängen die Kanäle einer vccu in der Luft, sind nirgend definiert. Man kann sich nicht wirklich peeren. Die Anzeige von Peers in diversen Readings macht Probleme, da die HMId nicht wirklich existiert.
Die CCU wird nicht HMInfo ersetzen, das ist noch ein Level höher. Warum sollte es auch. Ich habe nicht vor, für alle Kommandos noch einen Level einzuziehen, nach channel->devices->ccu->CUL_HM (in HMInfo).
Auch ein Actiondetector ist nicht auf eine CCU beschränkt.

komischerweise hat sie sich als iodev aber meinen cul geschnappt, der eine andere hmid hat.

kannst du ein List der CUL schicken? Ist das Attribut HMId gesetzt?

Gruss Martin

[frank]

Code Auswählen Erweitern

Internals:
   CMDS       BCFiAZEGMKURTVWXefmltux
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/ttyACM1@9600 1134
   DeviceName /dev/ttyACM1@9600
   FD         14
   FHTID      1134
   NAME       cul868
   NR         38
   PARTIAL
   RAWMSG     A0E088002D1D1D11D252E010100000055
   RSSI       -31.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.58 CUL868
   cul868_MSGCNT 1485
   cul868_TIME 2014-04-29 16:58:04
   initString X21
Ar
   owner_CCU  ccu
   .clientArray:
     CUL_HM
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2014-04-18 16:05:41   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2014-04-29 14:09:47   cmds             B C F i A Z E G M K U R T V W X e f m l t u x
     2014-04-29 16:58:04   state           Initialized
     2014-04-18 16:02:35   version         No answer
   Helper:
     Bm:
       Cul_attr:
         cnt        2
         dmx        0
         mAr
         max        0
         tot        0
       Cul_get:
         cnt        4
         dmx        0
         mAr
         max        0
         tot        0
       Cul_read:
         cnt        1312
         dmx        0
         mAr        HASH(0xde8e38)
         max        632
         tot        169185
       Cul_set:
         cnt        1796
         dmx        0
         mAr        HASH(0xde8e38); cul868; ?
         max        2
         tot        18
Attributes:
   hmId       C1C1C1
   hmProtocolEvents 3_dumpTrigger
   model      CUL
   rfmode     HomeMatic
   room       90_Technik
   verbose    5

hmid war gesetzt. vor diesem list hatte ich aber iodev bei der vccu bereits auf hmlan geändert. nur als info, fals sich dadurch dieses list geändert hat.

gruss frank