HM virtual CCU

martinp876 · 30 Juni 2014, 19:48:10

Hallo Ingo,

In deinem Log versucht FHEM dem Dimmer ein Kommando zu senden und zwar über HMLAN3. HMLAN3 meldet, dass sich das Device nicht meldet - also kein ACK sendet.

Seltsam:
- normal wäre, dass das HMLAN jeweils den Funkverkehr des anderen mirhört. Das ist bei dir nicht der Fall. Liegen die beiden so weit auseinander, dass sie sich nicht empfangen können?
- ALLES was HMLAN3 sendet wird nicht beantwortet

=> bist du sicher, das HMLAN3 sendet- und in einem Empfangsbereich der beiden Aktoren ist?
=> HMLAN3 ist up-and-running - kann also genutzt werden. Ist es auch als prefered eingestellt?
=> kannst du mit dem Dimmer über HMLAN3 kommunizieren? Oder nur über HMLAN2?

automatisierer · 30 Juni 2014, 20:00:25

Nein, der HMLAN3 ist nicht in Reichweite des Dimmers, und als prefered steht "IOgrp vccu:HMLAN2" in der .cfg, auch als IODev steht da HMLAN2 drin. Daher kann ich auch nicht verstehen, dass da HMLAN3 in den Internals steht.

In meinem letzten Post hatte ich ja geschrieben das es nicht nur nach einem rereadcfg auftritt sondern auch während des Betriebs. Mein Tipp ist ja, das HMLAN2 in dem Moment viele Sendeanfragen von fhem bekommt und die vccu dann einfach denkt ich sende mal nen paar über den HMLAN3 weil der grad nix zu tun hat.

martinp876 · 30 Juni 2014, 20:08:30

kannst du ein List des Device schicken, wenn es nicht funktioniert?

FHEM zählt keine sendeaktivitäten - solange HMLAN2 ok ist (state OPENED und Xmit-Events ok:1) sollte dies genommen werden. Da muss ich einen Fehler suchen, daher bitte das List des "defekten"

mcfly71 · 04 Juli 2014, 10:44:02

Hallo Martin,

ch habe gestern nun eine virtuelle CCU angelegt, da ich bald vorhabe, mir ein 2. hmlan adapter zu kaufen, und die ccu ja anscheinend immer das beste in Bezug auf RSSI nimmt. Diese Tatsache fand ich eigentlich toll.
Ich habe alles soweit angelegt, wie du es weiter hinten beschrieben hast:

(F21104 ist die hmId von STEUERUNG_HM)

define CCU CUL_HM F21104
attr CCU IODev STEUERUNG_HM
attr CCU IOList STEUERUNG_HM
attr CCU autoReadReg 4_reqStatus
attr CCU expert 2_full
attr CCU group SYSTEM
attr CCU model CCU-FHEM
attr CCU room SETTINGS
attr CCU subType virtual
attr CCU webCmd virtual:update

und jedes HM-Device versehen mit:

attr STATUSANZEIGE IODev STEUERUNG_HM (war noch alt, aber du hast ja geschrieben, sollte drin bleiben)
attr STATUSANZEIGE IOgrp CCU

Soweit so gut. Alles läuft nach wie vor, nur so tolle readings wie ihr , wo alle Devices aufgelistet werden bekomme ich nicht, auch nicht nach einem update auf die CCU.

Bei mir steht nur:

DEF F21104
IODev STEUERUNG_HM
NAME CCU
NR 21
STATE STEUERUNG_HM:ok
TYPE CUL_HM
assignedIOs STEUERUNG_HM

Was mache ich falsch

?
(P.S. eine Doku wäre toll, da ich leider viele Fragen noch habe, wie z.B. was ist das mit den Buttons wofür sind die ? oder
warum zeigt die ccu bei den set befehlen einen slider und wofür ist der...

sorry, wenn für euch das ein wenig rookie-mäßig ist, aber wie gesagt dieses auswählen des stärksten Devices finde ich primär den Grund für eine Einführung der ccu

vg
mcfly

martinp876 · 04 Juli 2014, 12:32:56

Zitatwo alle Devices aufgelistet werden bekomme ich nicht,

alle Devices, die von der CCU gesteuert werden?

Code Auswählen

get ccu listDevice
oder meinst du etwas anderes?

Zitateine Doku wäre toll,

korrekt. der Versuch scheint ja zu funktionieren - da ist ein wiki fällig. Mal sehen, wann ich so weit bin...

Zitatwie z.B. was ist das mit den Buttons wofür sind die ?

die sind ähnlich einem Virtuellen Button. Sie werden auch von den eQ3 SW angeboten. Im Prinzip kann man das gleiche damit machen... aber im Bezug auf HMLAN sind sie etwas besser (ACKs werden korrekt behandelt)

Zitatsorry, wenn für euch das ein wenig rookie-mäßig ist, aber wie gesagt dieses auswählen des stärksten Devices finde ich primär den Grund für eine Einführung der ccu

muss man selbst wissen. Ich setze für alle stationären Devices ein prefered-IO. Für tragbare remotes lasse ich es offen. Somit habe ich eine
- gleichbleibende Zuordnung in 99% der Fälle (keine Umkonfiguration, mehr Ruhe im System)
- Ausfallsicherheit, falls ein IO versagt
- beste Auswahl bei Tragbaren/veränderlichen Devices

tpm88 · 10 Juli 2014, 21:46:09

Hallo Martin,

hier mal meinen ausdrücklichen Dank für die vccu!

Bisher hatte ich diese nur für meinen HM-USB-CFG-2 am RPi "am Mitlaufen". Diese Woche war dieser aber plötzlich defekt. Kurzerhand den defekten Stick gegen einen CUL vom Testsystem ausgetauscht, der vccu hinzugefügt und noch die IOgrp für alle HM Devices gesetzt. Sofort lief alles wieder. Kein grosses Umkonfigurieren, genial!

Für die Zukunft überlege ich, einen HM-LAN Adapter als "cold" Backup an einer IT Funksteckdose vorzuhalten. Falls dann wieder mal der HM-USB-CFG streikt, könnte der HM-LAN per notify/watchdog aktiviert werden und die HM Kommunikation übernehmen.

Gruß
Tobias

frank · 13 Juli 2014, 13:00:17

hallo martin,

die vccu hinterlegt in den readings ja meldungen, die von unbekannten devices stammen. wenn man neue devices anschafft, sind die ersten meldungen dieser geräte bis zum pairen ja auch erstmal von unbekannten devices.

könnte man nicht einen befehl "verifyUnknownDevices" spendieren, der bereits entstandene unknown-readings auf aktuell bekannte devices überprüft und die entsprechenden unknownreadings wieder löscht? somit würden nur noch die readings von weiterhin unbekannten devices mit vielleicht neuem timestamp übrig bleiben.

weiterhin könnte man anschliessend, mit einem noch zu erstellenden befehl "ignoreUnknownDevices", die restlichen unbekannten devices automatisch zusammen mit einem ignore-attribut definieren.

oder gleich eine kombination aus beidem. wobei eine doppellösung vielleicht sicherer und nachvollziehbarer ist.

gruss frank

peterk_de · 14 Juli 2014, 16:12:11

Ich hätte da auch mal noch ein Frage: Hab eben endlich mal alles auf eine vccu "umgestellt" - mit dem Ziel, meinen HM-CFG-USB-2 als Hot-Standby zum HM-LAN zu verwenden. Soweit ich das sehen kann: Funktioniert prima, danke Martin!

Was mich wundert, der HM-LAN wird trotz offensichtlicher Funktion als "state = unknown" gelistet - shutdown restart hat da auch nichts dran geändert.

CCU:

Code Auswählen


Internals: 
   DEF        34EF21 
   IODev      system.hmlan 
   LASTInputDev system.hmlan 
   MSGCNT     40 
   NAME       system.ccu 
   NR         1137 
   STATE      system.hmcfgusb:ok, system.hmlan:unknown, 
   TYPE       CUL_HM 
   assignedIOs system.hmcfgusb,system.hmlan 
   lastMsg    No:02 - t:02 s:34EF21 d:2256A5 0101C800 
   protLastRcv 2014-07-14 15:59:18 
   rssi_at_system.hmcfgusb avg:-39 min:-39 max:-39 lst:-39 cnt:1 
   rssi_at_system.hmlan avg:-38.97 min:-39 max:-38 lst:-39 cnt:39 
   system.hmcfgusb_MSGCNT 1 
   system.hmcfgusb_RAWMSG E34EF21,0000,00DEBC1D,FF,FFD9,FC800234EF212252C900 
   system.hmcfgusb_RSSI -39 
   system.hmcfgusb_TIME 2014-07-14 15:55:34 
   system.hmlan_MSGCNT 39 
   system.hmlan_RAWMSG E34EF21,0000,004262D7,FF,FFD9,02800234EF212256A50101C800 
   system.hmlan_RSSI -39 
   system.hmlan_TIME 2014-07-14 15:59:18 
   Readings: 
     2014-07-14 15:59:18   CommandAccepted yes 
     2014-07-14 15:59:18   recentStateType ack 
   Helper: 
     mId        FFF0 
     rxType     1 
     Io: 
       nextSend   1405346358.20356 
       prefIO 
       vccu 
       ioList: 
         system.hmcfgusb 
          system.hmlan 
     Mrssi: 
       mNo        02 
       Io: 
         system.hmlan -37 
     Prt: 
       bErr       0 
       sProc      0 
       Rspwait: 
     Q: 
       qReqConf 
       qReqStat 
     Role: 
       chn        1 
       dev        1 
       vrt        1 
     Rssi: 
       At_system.hmcfgusb: 
         avg        -39 
         cnt        1 
         lst        -39 
         max        -39 
         min        -39 
       At_system.hmlan: 
         avg        -38.974358974359 
         cnt        39 
         lst        -39 
         max        -38 
         min        -39 
Attributes: 
   IODev      system.hmlan 
   IOList     system.hmcfgusb, system.hmlan 
   alias      Homematic CCU 
   autoReadReg 4_reqStatus 
   expert     2_full 
   group      System 
   model      CCU-FHEM 
   room       System 
   subType    virtual 
   webCmd     update

HMLAN:

Code Auswählen


Internals: 
   CHANGED 
   DEF        192.168.178.19:1000 
   DeviceName 192.168.178.19:1000 
   FD         18 
   NAME       system.hmlan 
   NR         844 
   NTFY_ORDER 50-system.hmlan 
   PARTIAL 
   RAWMSG     E2725C6,0000,004DFFD5,FF,FFB2,11805E2725C634EF210000000000000001000000 
   RSSI       -78 
   STATE      opened 
   TYPE       HMLAN 
   XmitOpen   1 
   assignedIDs 
   assignedIDsCnt 1 
   assignedIDsReport 4 
   firmware   0.961 
   msgKeepAlive dlyMax:0.09 bufferMin:4 
   msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0 
   msgParseDly min:-21 max:3913 last:10 cnt:541 
   owner      34EF21 
   serialNr   JEQ0707462 
   system.hmlan_MSGCNT 591 
   system.hmlan_TIME 2014-07-14 16:11:59 
   uptime     000 01:25:11.765 
   Readings: 
     2014-07-14 15:39:14   Xmit-Events     ok:1 
     2014-07-14 15:39:14   cond            ok 
     2014-07-14 15:39:11   prot_disconnected last 
     2014-07-14 15:39:11   prot_init       last 
     2014-07-14 15:39:14   prot_ok         last 
   Assids: 
   Helper: 
     000001: 
       flg        0 
     Dly: 
       cnt        541 
       lst        10 
       max        3913 
       min        -21 
     K: 
       BufMin     4 
       DlyMax     0.09 
       Next       1405347126.93409 
       Start      1405347101.93409 
     Log: 
       all        0 
       sys        0 
       ids: 
         ARRAY(0x268df48) 
     Q: 
       HMcndN     0 
       answerPend 0 
       hmLanQlen  1 
       keepAliveRec 1 
       keepAliveRpt 0 
       apIDs: 
       Cap: 
         0          0 
         1          0 
         2          0 
         3          20 
         4          0 
         5          21 
         last       1 
         sum        41 
     Ref: 
       drft       -0.00011997600479904 
       hmtL       5094634 
       kTs        0 
       offL       1405342007304 
       sysL       1405347101938 
Attributes: 
   group      System 
   hmId       34EF21 
   hmLanQlen  1_min 
   room       System

Ist das Nachteilig bei der Auto-Auswahl des IO-Devices? Edit: Wenn ich die beiden tausche in der IOList, ist es genau andersherum, dann ist der USB-CFG unknown.

frank · 14 Juli 2014, 16:29:09

Code Auswählen

IOList system.hmcfgusb, system.hmlan
das sieht so aus, als würde das durch das leerzeichen hinter dem komma hervorgerufen werden.

gruss frank

peterk_de · 14 Juli 2014, 17:08:57

Hey Frank, herzlichen Dank, das war's!

geek · 18 Juli 2014, 07:32:08

Hi,

so wie's aussieht würfelt sich meine VCCU gerne schonmal das falsche IOdev. Das sehe ich sporadisch mit unterschiedlichen devices.

Hier ist HMEG als preferred konfiguriert, intern nimmt er aber HMUG:

Code Auswählen

fhem> list eg_f_lampe_decke
Internals:
   CFGFN      ./cfg/eg_f.cfg
   DEF        1B5131
   HMEG_MSGCNT 12
   HMEG_RAWMSG E1B5131,0000,119EC658,FF,FFCC,D2A4101B513183D2E0060200008000
   HMEG_RSSI  -52
   HMEG_TIME  2014-07-17 23:27:51
   IODev      HMUG
   LASTInputDev HMEG
   MSGCNT     12
   NAME       eg_f_lampe_decke
   NR         774
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 eg_f_lampe_decke_sw0
   channel_02 eg_f_lampe_decke_sw1
   channel_03 eg_f_lampe_decke_sw2
   lastMsg    No:D2 - t:10 s:1B5131 d:83D2E0 060200008000
   protCmdDel 5
   protLastRcv 2014-07-17 23:27:51
   protResnd  9 last_at:2014-07-18 06:44:47
   protResndFail 3 last_at:2014-07-18 06:44:52
   protSnd    15 last_at:2014-07-18 06:44:33
   protState  CMDs_done_Errors:1
   rssi_HMEG  avg:-54.5 min:-59 max:-52 lst:-55 cnt:4 
   rssi_at_HMEG avg:-52.25 min:-57 max:-50 lst:-52 cnt:12 
   Readings:
     2014-02-17 20:29:53   CommandAccepted yes
     2014-02-08 12:23:56   D-firmware      2.2
     2014-02-08 12:23:56   D-serialNr      JEQ0199297
     2014-06-10 10:38:14   PairedTo        0x83D2E0
     2014-06-10 10:38:14   R-intKeyVisib   invisib
     2014-06-10 10:38:14   R-pairCentral   0x83D2E0
     2014-06-10 10:38:14   RegL_00:        02:01 0A:83 0B:D2 0C:E0 15:FF 16:00 00:00
     2014-07-18 06:44:52   state           MISSING ACK
   Helper:
     cSnd       1183D2E01B51310202640640FFFF
     mId        0068
     rxType     1
     Io:
       newChn     +1B5131,00,01,00
       nextSend   1405632471.89931
       prefIO     HMEG
       rxt        0
       vccu       VCCU
       p:
         1B5131
         00
         01
         00
     Mrssi:
       mNo        D2
       Io:
         HMEG       -50
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rpt:
       IO         HMEG
       flg        A
       ts         1405632471.8066
       ack:
         HASH(0xa6d25ac)
         D2800283D2E01B513100
     Rssi:
       Hmeg:
         avg        -54.5
         cnt        4
         lst        -55
         max        -52
         min        -59
       At_hmeg:
         avg        -52.25
         cnt        12
         lst        -52
         max        -50
         min        -57
     Vdim:
       idPhy      1B5131
       idV2       1B5131
       idV3       1B513101
Attributes:
   IODev      HMEG
   IOgrp      VCCU:HMEG
   autoReadReg 5
   devStateIcon off:light_light_dim_00:on on:light_light_dim_100@yellow:off
   expert     2_full
   firmware   2.2
   group      Licht
   model      HM-LC-Dim1TPBU-FM
   room       hidden
   serialNr   JEQ0199297
   structexclude .*:.*
   subType    dimmer
   webCmd     getConfig:clear msgEvents

Was leider nicht funktioniert:

Code Auswählen

2014.07.18 06:44:33.479 3: CUL_HM set eg_f_lampe_decke_sw1 50 0 5
2014.07.18 06:44:33.480 0: HMLAN_Send:  HMUG S:+1B5131,00,01,00
2014.07.18 06:44:33.480 0: HMLAN_Send:  HMUG S:S47C9328F stat:  00 t:00000000 d:01 r:47C9328F m:65 A011 83D2E0 1B5131 0202640640FFFF
2014.07.18 06:44:34.088 0: HMLAN_Parse: HMUG R:R47C9328F stat:0008 t:00000000 d:FF r:7FFF     m:65 A011 83D2E0 1B5131 0202640640FFFF
2014.07.18 06:44:34.088 0: HMLAN_Parse: HMUG no ACK from 1B5131
2014.07.18 06:44:37.466 0: HMLAN_Send:  HMUG S:S47C94220 stat:  00 t:00000000 d:01 r:47C94220 m:65 A011 83D2E0 1B5131 0202640640FFFF
2014.07.18 06:44:38.071 0: HMLAN_Parse: HMUG R:R47C94220 stat:0008 t:00000000 d:FF r:7FFF     m:65 A011 83D2E0 1B5131 0202640640FFFF
2014.07.18 06:44:38.073 0: HMLAN_Parse: HMUG no ACK from 1B5131
2014.07.18 06:44:42.450 0: HMLAN_Send:  HMUG S:S47C95599 stat:  00 t:00000000 d:01 r:47C95599 m:65 A011 83D2E0 1B5131 0202640640FFFF
2014.07.18 06:44:42.685 0: HMLAN_Parse: HMEG R:E83D2E0   stat:0000 t:132EC7DF d:FF r:FF98     m:65 A011 83D2E0 1B5131 0202640640FFFF
2014.07.18 06:44:43.054 0: HMLAN_Parse: HMUG R:R47C95599 stat:0008 t:00000000 d:FF r:7FFF     m:65 A011 83D2E0 1B5131 0202640640FFFF
2014.07.18 06:44:43.054 0: HMLAN_Parse: HMUG no ACK from 1B5131
2014.07.18 06:44:47.014 0: HMLAN_Send:  HMUG S:S47C9676D stat:  00 t:00000000 d:01 r:47C9676D m:65 A011 83D2E0 1B5131 0202640640FFFF
2014.07.18 06:44:47.618 0: HMLAN_Parse: HMUG R:R47C9676D stat:0008 t:00000000 d:FF r:7FFF     m:65 A011 83D2E0 1B5131 0202640640FFFF
2014.07.18 06:44:47.618 0: HMLAN_Parse: HMUG no ACK from 1B5131
2014.07.18 06:44:52.186 3: eg_f_lampe_decke: ResndFail
2014.07.18 06:44:52.191 3: eg_f_lampe_decke: CMDs_done_Errors:1
2014.07.18 06:44:52.196 3: eg_f_lampe_decke: MISSING ACK

Die VCCU sagt dazu:

Code Auswählen

fhem> list VCCU
Internals:
   DEF        83D2E0
   HMEG_MSGCNT 136
   HMEG_RAWMSG E83D2E0,0000,133FD8F0,FF,FFA0,74A01183D2E02404AC81043D
   HMEG_RSSI  -96
   HMEG_TIME  2014-07-18 07:03:20
   HMUG_MSGCNT 360
   HMUG_RAWMSG E83D2E0,0000,04D537C5,FF,FF97,9B800283D2E0243B6300
   HMUG_RSSI  -105
   HMUG_TIME  2014-07-18 07:23:21
   IODev      HMEG
   LASTInputDev HMUG
   MSGCNT     496
   NAME       VCCU
   NR         56
   STATE      HMEG:ok,HMUG:ok,
   TYPE       CUL_HM
   assignedIOs HMEG,HMUG
   channel_01 VCCU_Btn1
   lastMsg    No:9B - t:02 s:83D2E0 d:243B63 00
   protLastRcv 2014-07-18 07:23:21
   rssi_at_HMEG avg:-97.13 min:-106 max:-92 lst:-96 cnt:136 
   rssi_at_HMUG avg:-99.43 min:-108 max:-92 lst:-105 cnt:360 
   Readings:
     2014-07-18 07:23:21   CommandAccepted yes
     2014-07-13 07:38:52   recentStateType ack
     2014-07-13 07:11:08   trigLast        eg_f_tast_homestatus_1 :short
     2014-07-13 07:11:08   trig_eg_f_tast_homestatus_1 short
     2014-07-11 08:03:50   trig_eg_f_tast_homestatus_2 long
   Helper:
     mId        FFF0
     rxType     1
     Io:
       nextSend   1405661001.57641
       prefIO     
       vccu       
       ioList:
         HMEG
         HMUG
     Mrssi:
       mNo        9B
       Io:
         HMUG       -105
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
       vrt        1
     Rssi:
       At_hmeg:
         avg        -97.1323529411765
         cnt        136
         lst        -96
         max        -92
         min        -106
       At_hmug:
         avg        -99.4333333333332
         cnt        360
         lst        -105
         max        -92
         min        -108
Attributes:
   IODev      HMEG
   IOList     HMEG,HMUG
   autoReadReg 4_reqStatus
   expert     2_full
   model      CCU-FHEM
   room       Unsorted
   subType    virtual
   webCmd     update

Rainer

hexenmeister · 18 Juli 2014, 10:23:43

ZitatVCCU gerne schonmal das falsche IOdev

Habe auch zwei Mal beobachtet, dass das falsche IO-Device verwendet wurde (einmal RolladenAktor, einmal Dimmer). Dann aber konsequent. Am Ende half nur ein Reset auf Werkseinstellungen. Daher habe ich vermutet, dass das Device nicht mit dem gewünschten IO wolle (was ich mir allerdings technisch nicht erklären kann, denn direkt geerte Schalter gingen weiterhin) und CCU daher das andere nahm. In der "Vor CCU" Zeiten hatte ich so etzwas jedoch nie.

geek · 19 Juli 2014, 07:43:56

Hi,

bei mir tritt das oft auf, wenn gerade viel los ist - und so wie ich den code lese, ist das ein Fall, nimmt die VCCU nicht das preferred IO device, wenn das gerade busy ist.

Ein device hat zb:

Code Auswählen

     Mrssi:
       mNo        64
       Io:
         HMEG       -60
         HMUG       -103
...
   IOgrp      VCCU:HMEG

In @ios steht also HMEG (prefIO), HMEG (Mrssi), HMUG (Mrssi). HMEG wird aber beide male ausgelassen, weil's gerade mit nem anderen kommando busy ist.

Wenn ich mir das wie folgt umbaue, verschwinden die Probleme. Das macht aus IOpref aber einen harten Filter und nicht nur eine "Preference". Fallback auf ein anderes IOdevices wird es so nie mehr geben. Denke, das ist nicht gewünscht.

Code Auswählen

--- /home/bj/git/fhem/fhem/FHEM/10_CUL_HM.pm    2014-07-17 09:01:12.000000000 +0200
+++ FHEM/10_CUL_HM.pm   2014-07-19 07:24:27.000000000 +0200
@@ -6602,8 +6602,8 @@
     unshift @ios,$prefIO if ($prefIO);# set prefIO to first choice
     foreach my $iom (@ios){
       if (  !$defs{$iom}
-          || $defs{$iom}{STATE} eq "disconnected" 
-          || InternalVal($iom,"XmitOpen",1) == 0){# HMLAN/HMUSB?
+          || $defs{$iom}{STATE} eq "disconnected"  ){
+          # || InternalVal($iom,"XmitOpen",1) == 0){# HMLAN/HMUSB?
         next;
       }
+      if( InternalVal($iom,"XmitOpen",1) == 0){
+        Log3 undef,3,"CUL_HM $iom XmitOpen==0";
+      }
       if (   $hash->{IODev} 
           && $hash->{IODev} ne $defs{$iom}
           && $hash->{IODev}->{TYPE}

Rainer

martinp876 · 20 Juli 2014, 08:28:14

Hi,

hm - mal überlegen....

bei HMLAN ist es möglich, die max Anzahl der parallel gesendeten messages einzustellen (hmLanQlen). Default ist 1, was am Stabilsten (und Langsamsten) ist. Es ist also die Anzahl ausstehender acks.

Zu berücksichtigen ist beim HMLAN also
1) Anzahl ausstehende ACKs überschritten
2) HMLAN in high-load (wird aktuell nicht zur Auswahl herangezogen)
3) HMLAN in overload
4) IO disconnected

Ich habe gerade eingebaut, dass bei kurzen (zu erwartenden) Delay gewartet wird ( 1) ).
Umgeschaltet wird weiterhin bei 3) und 4).
2) wird bei dieser Auswahl weiterhin ignoriert

Gruss Martin

geek · 20 Juli 2014, 08:35:38

Hi,

macht es vieleicht auch Sinn, IODevs mit "schlechter" RSSI (konfigurierbar, default um 80?) komplett auszulassen?

Was passiert, wenn kein IODev mit leerer/kurzer queue da ist? Queued dann die VCCU? Oder könnte man erwägen, dann die queue der IODevs zu ignorieren? edit: ah, nach der Änderung spielt queue size spielt keine Rolle mehr bei der auswahl, ok.

Rainer