HM virtual CCU

[justme1968]

das schaut viel besser aus.

danke
  andre

[marc2]

Hi !

Da gestern mein HM-USB-CFG das Zeitliche gesegnet hat, habe ich derzeit einen Live Test der VCCU. Dieser sind neben
dem jetzt auf "disconnected" stehenden Stick (HMUSB1) ein HMLAN (HMLAN1) zugewiesen. Ich hätte nun erwartet, dass
- mal abgesehen von Devices, die sich nicht mehr in der Reichweite des HMLAN befinden - alles normal weiterlaufen würde.
Dies ist aber leider nicht der Fall. Alle Devices, welche als Default den HMUSB1 eingetragen haben (IOgrp vccu:HMUSB1), werden
nicht mehr angesprochen. Die Befehle werden entweder gequeued oder die Devices gehen auf "IOerr".  Auch wenn ich den
Default nicht setze (IOgrp vccu) änder sich leider nichts am Verhalten. Die VCCU setzt nach jedem Befehl das IODev des
Devices wieder auf HMUSB1, obwohl der Stick dauerhaft auf "disconnected" steht. Habe ich den Sinn der VCCU falsch verstanden ?

Auch nach dem heutigen Update (6142) hat sich am verhalten nicht geändert. Anbei ein Beispiel:

Code Auswählen Erweitern

Internals:
   CFGFN      ./cfg/hm_misc.cfg
   DEF        1A5C90
   IODev      HMUSB1
   NAME       Licht_KU_Fenster
   NR         238
   STATE      set_toggle
   TYPE       CUL_HM
   protCmdDel 6
   protCmdPend 1 CMDs_pending
   protIOerr  2 last_at:2014-06-20 22:05:25
   protState  CMDs_pending
   CHANGETIME:
   Helper:
     Dblog:
       State:
         Mydblog:
           TIME       1403294805.7298
           VALUE      set_toggle
   Readings:
     2014-06-18 23:09:01   CommandAccepted yes
     2014-04-09 22:52:53   D-firmware      1.9
     2014-04-09 22:52:53   D-serialNr      JEQ0163703
     2014-06-18 23:09:01   deviceMsg       off (to vccu)
     2014-06-19 23:05:12   lastAutoAction  off
     2014-06-18 23:09:01   level           0
     2014-06-18 23:09:01   pct             0
     2014-06-16 07:09:48   powerOn         -
     2014-06-18 23:09:01   recentStateType ack
     2014-06-20 22:06:45   state           set_toggle
     2014-06-18 23:09:01   timedOn         off
   cmdStack:
     ++A011F143211A5C900201C80000
   Helper:
     dlvl       C8
     dlvlCmd    ++A011F143211A5C900201C80000
     mId        0011
     rxType     1
     Io:
       newChn     +1A5C90,00,01,00
       rxt        0
       p:
         1A5C90
         00
         01
         00
     Mrssi:
       mNo       
     Prt:
       bErr       0
       sProc      2
     Q:
       qReqConf   
       qReqStat   
     Role:
       chn        1
       dev        1
       prs        1
     Rssi:
     Shadowreg:
Attributes:
   IODev      HMUSB1
   IOgrp      vccu
   autoReadReg 0
   considerWindows 1
   expert     2_full
   firmware   1.9
   icon       light_led
   model      HM-LC-SW1-PL
   peerIDs    00000000,
   room       Kueche
   serialNr   JEQ0163703
   subType    switch
   webCmd     toggle:on:off:statusRequest



Gruß, Marc

[marc2]

Hi !

Ich war davon ausgegangen, dass alle IODevs, die die gleiche HMID wie die VCCU nutzen, automatisch in den
IODev Pool der VCCU wandern würden (war das nicht auch ursprünglich so ) und hatte keine dedizierte IOList
gesetzt. Mit der IOList läuft es jetzt wie erwartet. Sorry ....

Gruß, Marc

[marc2]

Hi !

Nach dem Pairen neuer Devices wird als IODev der Hash, statt der Name des IO Devices
gespeichert:

Code Auswählen Erweitern

attr Rauchmelder_Wohnzimmer IODev HASH(0x8151a0)

Gruß, Marc

[hexenmeister]

Nach dem Pairen neuer Devices wird als IODev der Hash, statt der Name des IO Devices
gespeichert:

Ist mir auch gerade aufgefallen...

[betateilchen]

kann ich nicht nachvollziehen:

(http://up.picr.de/18687018aq.png)

diese neue Fernbedienung habe ich vor ca. drei Stunden eingerichtet.

[hexenmeister]

Evtl. Ein bereits behobener Fehler der Vorversion?

[betateilchen]

Code Auswählen Erweitern


# $Id: 10_CUL_HM.pm 6142 2014-06-19 16:39:19Z martinp876 $
# $Id: 00_HMLAN.pm 6069 2014-06-05 14:21:43Z martinp876 $


[tpm88]

Ist bei mir heute mit einem neu definierten (Pairing) Rollladenaktor auch passiert:

Code Auswählen Erweitern


2014.06.22 16:59:24 3: tim_Rollo: unknown IODev specified
2014.06.22 16:59:25 1: Including ./log/fhem.save
2014.06.22 16:59:27 1: configfile: tim_Rollo: unknown IODev specified

2014.06.22 16:59:27 2: Error messages while initializing FHEM: configfile: tim_Rollo: unknown IODev specified

In der fhem.cfg:

Code Auswählen Erweitern

attr tim_Rollo IODev HASH(0x19f9d38)

Alle anderen HM Devices hatten den richtigen Eintrag

Code Auswählen Erweitern

attr <HM-Device> IODev hmusb

Gleiche Versionen wie betateilchen:

Code Auswählen Erweitern


# $Id: fhem.pl 6080 2014-06-07 16:12:09Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 6142 2014-06-19 16:39:19Z martinp876 $
# $Id: 00_HMLAN.pm 6069 2014-06-05 14:21:43Z martinp876 $


Gruß
Tobias

[martinp876]

wird behoben

[automatisierer]

Hallo,
ich habe mir auch eine vccu eingerichtet,  meine zwei HMLAN haben die gleiche hmid, wie auch die vccu und beide HMLAN stehen in der IOList der vccu. Ich habe bei allen HM Devices das IODev und auch IOgrp mit vccu:prefIO festgelegt.
Das Problem das nun auftaucht: nach jedem Neustart oder rereadcfg hat der HM-SEC-KEY Missing ACK und in den Internals steht als IODev der HMLAN der nicht in den attr festgelegt ist. Nach einem statusRequest ändert sich der Eintrag in den Internals und alles ist wieder in Ordnung.
Bei dem HM-SEC-KEY tritt das bei jedem rereadcfg auf, bei anderen Aktoren nur sporadisch, darunter zwei HM-LC-Dim1TPBU-FM, ein HM-LC-SW4-PCB und ein HM-LC-SW4-BA-PCB.
Hat da einer ne Idee woran es liegen kann?

Gruß
Ingo

[martinp876]

hm - das IODev wird sicher erst einmal nach dem Attribut IODev festgelegt. Nach einem statusRequest legt die vccu das IODev (Internals) neu fest.
was sendet HM_SEC_KEY nach rereadcfg? evtl ist es zu "früh" (noch nicht alle Daten vorhanden) ...

[automatisierer]

Ich hab mal das LOG eines rereads angehangen.

Die HMLAN's und die vccu hatte ich auf "Verbose 5", ist das so richtig.

Es ist der berühmte Vorführeffekt eingetreten, der HM_SEC_KEY hatte die letzten 2 Tage bei jedem reread "missing ACK" und es waren bestimmt 30 rereads, aber seit deinem POST macht er das nicht mehr...
Die Geräte die dieses mal "missing ACK" hatten:

HM-LC-Dim1TPBU-FM  2669E0

HM-LC-SW4-PCB  224AF6

Ist das das was du wissen willst?

Gruß
Ingo

[martinp876]

hm - seltsam
Bei mir geht es - insbesondere mit dem dim1TPBU

werde noch einmal forschen

[automatisierer]

Hallo Martin,

ich habe auch mal noch weiter rum experimentiert, dabei habe ich festgestellt, dass der Fehler nicht nur nach rereadcfg auftaucht und das ich ihn reproduzieren kann.

Ich nutze zum öffnen der Haustuer einmal den HM_SEC_KEY (zu auf und abschließen) und den HM_SW4_PCB (zum betätigen des Tueroeffners).


Ist die Haustuer abgeschlossen, kommt folgender Befehl zu einsatz:

Code Auswählen Erweitern


define Flur_ak_Tuer_Oeffner_an_locked notify Flur_sci_Tuer_Finger:closed|Flur_dm_Tuer_Schloss:open { if (Value("Flur_ak_Tuer_Schloss") !~ m/^unlocked/) {fhem "set Flur_ak_Tuer_Schloss unlock ;; define Flur_ak_Tuer_Oeffner_5sek at +00:00:05 set Flur_ak_Tuer_Oeffner on-for-timer 25"}}


Ist die Tuer nicht abgeschlossen dieser:

Code Auswählen Erweitern


define Flur_ak_Tuer_Oeffner_an_unlocked notify Flur_sci_Tuer_Finger:closed|Flur_dm_Tuer_Schloss:open { if ((Value("Flur_ak_Tuer_Schloss") =~ m/^unlocked/) && (Value("Flur_ak_Tuer_Oeffner") !~ m/^on/)) { fhem("set Flur_ak_Tuer_Oeffner on-for-timer 25") ;; } else {fhem ("set Flur_ak_Tuer_Oeffner off") ;; }}


Wenn die Haustuer abgeschlossen ist und ich den Befehl fuers oeffnen ausloese, hat der HM_SW4_PCB (Flur_ak_Tuer_oeffner) anschliessend ein "Missing ACK" und hat in den "Internals" wieder den falschen HMLAN, betätige ich ihn danach nochmal von Hand oder ueber den Befehl "Haustuer nicht abgeschlossen" ist alles wieder OK und der richtige HMLAN steht wieder in den "Internals"

Das sieht für mich irgenwie so aus, als hätte der HMLANingo1 (habe sie umbenannt in der Hoffnung das es was bringen koennte, hats aber nicht ) in dem Moment zu viel zu tun und die vccu entscheidet deshalb das die restlichen Befehle ueber den anderen HMLAN gesendet werden...

... Idee waehrend dem Tippen...

Habe die vccu mal auskomentiert (##) und "rereadcfg", dann sind die "Missing ACK" weg und die Befehle funzen...

Vielleicht hilft dir das bei der Fehlersuche weiter... Wenn ich dir sonst noch wie behilflich sein kann, lass es mich wissen...

Gruß
Ingo

und einen schoenen Wochenstart an alle Mitleser!!