Nach Umbau von SCC auf Homematic WLAN Gateway: "No I/O device found for ......."

[isy]

Hallo zusammen,
habe vor ein paar Tagen den Busware SCC ausgebaut und ein Homematic WLAN Gateway (siehe https://forum.fhem.de/index.php/topic,79559.0.html) aktiviert.
Homematic funktioniert damit super und HMInfo configCheck ist fehlerfrei.

Nur im Log habe ich nach jedem Systemstart für jedes HM Device die Fehlermeldung:

Code Auswählen Erweitern

No I/O device found for <HM-Name>

Hier die Definition des Gateways, die ich von Hand ganz nach vorne in die fhem.cfg verschoben haben

Code Auswählen Erweitern

define HmUART HMUARTLGW uart://192.168.178.47:23
attr HmUART group HomeMatic
attr HmUART hmId F11573
attr HmUART icon hm_ccu
attr HmUART room System

Hier die VCCU

Code Auswählen Erweitern

define VCCU CUL_HM F11573
attr VCCU IODev HmUART
attr VCCU IOList HmUART,miniCULhm
attr VCCU IOgrp VCCU
attr VCCU group HomeMatic
attr VCCU icon time_automatic
attr VCCU model CCU-FHEM
attr VCCU room System
attr VCCU subType virtual
attr VCCU webCmd virtual:update

Vom Timing beim Start sieht das so aus (Log-Auszug)

Code Auswählen Erweitern

2018.01.05 17:21:26 3: Opening HmUART device 192.168.178.47:23
....dann kommen diverse andere IO's usw.
2018.01.05 17:21:48 3: No I/O device found for ku_SW_Fenster_r

Diese Meldung aus dem Wiki (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi) kommt nicht beim Start:

Code Auswählen Erweitern

  2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_BL
  2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_App

Hat jemand eine Idee?

Gruß Helmut

[Otto123]

Hi,

das hier hat bei der VCCU nix zu suchen.
attr VCCU IOgrp VCCU

Gib mal ein list ku_SW_Fenster_r

Gruß Otto

[frank]

wahrscheinlich stimmt die reihenfoge der definitionen in fhem.cfg nicht. das io muss ganz nach vorne, also vor vccu und die devices.

[isy]

Moin Otto,
der Eintrag mit der VCCU ist falsch, habe ich schon gelöscht. Danke für den Hinweis, ist sicherlich bei der Einrichtung der VCCU und dem generellen Umstellen der IOgrp mit rein gekommen.

Bin heute auch schon etwas weiter und schreibe parallel auch schon mit dem User gloob (Homematic WLAN Gateway). Der HM-MOD-RPI-PCB braucht 35s zwischen "Opening" und "opened". Und in dieser Zeit melden die HM Devices das fehlende IO. Wir suchen dort im Thread nach Ursachen. Seltsamerweise ist ja das 2. Homematic IO bereits "open". Die VCCU steht hinter den HM IO's.

Code Auswählen Erweitern

2018.01.05 19:47:40 3: Opening myHmUARTLGW device 192.168.1.32:23
2018.01.05 19:47:53 3: myHmUARTLGW device opened


Hier ein List vom Device (ist ziemlich lang)

Code Auswählen Erweitern

DEF        37A881
   HmUART_MSGCNT 20
   HmUART_RAWMSG 0501003A4DA61037A881F1157306010000
   HmUART_RSSI -58
   HmUART_TIME 2018-01-06 17:30:48
   IODev      HmUART
   IODevName  SCC
   LASTInputDev miniCULhm
   MSGCNT     40
   NAME       ku_SW_Fenster_r
   NOTIFYDEV  global
   NR         346
   NTFY_ORDER 50-ku_SW_Fenster_r
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:4D - t:10 s:37A881 d:F11573 06010000
   miniCULhm_MSGCNT 20
   miniCULhm_RAWMSG A0D4DA61037A881F1157306010000::-77.5:miniCULhm
   miniCULhm_RSSI -77.5
   miniCULhm_TIME 2018-01-06 17:30:49
   peerList   ku_Abzugshaube,
   protLastRcv 2018-01-06 17:30:49
   protSnd    20 last_at:2018-01-06 17:30:48
   protState  CMDs_done
   rssi_at_HmUART cnt:20 min:-60 lst:-58 max:-56 avg:-57.74
   rssi_at_miniCULhm min:-81.5 cnt:20 lst:-77.5 avg:-79.37 max:-77.5
   READINGS:
     2018-01-05 23:20:39   Activity        alive
     2017-06-12 08:07:04   D-firmware      1.0
     2017-06-12 08:07:04   D-serialNr      MEQ0286866
     2017-06-12 08:07:04   PairedTo        0xF11573
     2016-06-02 22:53:01   R-cyclicInfoMsg on
     2016-06-02 22:53:01   R-eventDlyTime  0 s
     2017-06-12 08:07:05   R-ku_Abzugshaube_chn-01-expectAES off
     2017-06-12 08:07:05   R-ku_Abzugshaube_chn-01-peerNeedsBurst off
     2016-06-02 22:53:01   R-pairCentral   0xF11573
     2016-06-02 22:53:01   R-sabotageMsg   on
     2016-06-02 22:53:01   R-sign          off
     2017-06-12 08:07:04   RegL_00.        02:01 09:01 0A:F1 0B:15 0C:73 10:01 14:06 00:00
     2017-06-12 08:07:04   RegL_01.        08:00 20:9C 21:00 30:06 00:00
     2017-06-12 08:07:05   RegL_04.ku_Abzugshaube_chn-01 01:00 00:00
     2018-01-06 17:30:48   alive           yes
     2018-01-06 17:30:48   battery         ok
     2018-01-06 17:30:48   contact         closed (to VCCU)
     2018-01-05 23:20:39   peerList        ku_Abzugshaube,
     2017-05-21 21:28:36   powerOn         2017-05-21 21:28:36
     2018-01-06 17:30:48   recentStateType info
     2018-01-06 17:30:48   sabotageError   off
     2018-01-06 17:30:48   state           closed
     2016-08-18 20:27:06   trigDst_VCCU    noConfig
     2018-01-01 15:19:04   trigger_cnt     19
   helper:
     HM_CMDNR   77
     mId        00C7
     regLst     ,0,1,4p
     rxType     28
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +37A881,00,00,00
       nextSend   1515256249.11686
       rxt        2
       vccu       VCCU
       p:
         37A881
         00
         00
         00
     mRssi:
       mNo        4D
       io:
         HmUART     -56
         miniCULhm  -77.5
     prt:
       bErr       0
       sProc      0
       sleeping   0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         HmUART
       flg        A
       ts         1515256248.98727
       ack:
         HASH(0x352c600)
         4D8002F1157337A88100
     rssi:
       at_HmUART:
         avg        -57.75
         cnt        20
         lst        -58
         max        -56
         min        -60
       at_miniCULhm:
         avg        -79.375
         cnt        20
         lst        -77.5
         max        -77.5
         min        -81.5
     shadowReg:
     tmpl:
Attributes:
   IODev      SCC
   IOgrp      VCCU
   actCycle   001:05
   actStatus  alive
   alias      Fensterkontakt (Küche rechts)
   autoReadReg 4_reqStatus
   devStateIcon open:fts_window_1w_tilt@red closed:fts_window_1w
   event-on-change-reading state
   expert     2_full
   firmware   1.0
   group      Tür_Fensterkontakt
   icon       fts_window_1w
   model      HM-SEC-SCo
   peerIDs    00000000,2FE97401,
   room       Küche
   serialNr   MEQ0286866
   subType    threeStateSensor
   userattr   room_map structexclude

Wie gesagt, wenn der HM-MOD-RPI-PCB dann Online ist, läuft alles super.

[isy]

wahrscheinlich stimmt die reihenfoge der definitionen in fhem.cfg nicht. das io muss ganz nach vorne, also vor vccu und die devices.

Moin Frank,
Reihenfolge ist wie folgt (die Zeilen zwischendrin sind hiergelöscht):

Code Auswählen Erweitern

define HmUART HMUARTLGW uart://192.168.178.47:23
----
define miniCULhm CUL 192.168.178.63:23 0000
----
define miniCULfs20 CUL 192.168.178.68:23 0000
----
define miniCUL433 CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_00000000-if00-port0@38400 0000
----
define IR_FB dummy
----
define VCCU CUL_HM F11573

Gruß Helmut

[Otto123]

Hi Helmu,

der sucht noch nach   IODev      SCC
Die VCCU sollte das eigentlich ändern, kann sein das es ein temporäres Problem ist?

Gruß Otto

[isy]

Moin Otto,
nein, glaube ich nicht.
Lt. VCCU Wiki:
"Mit der Anlage einer VCCU hat das eventuell angelegte attribut IODev eines HM_Devices keine Funktion mehr. Vielmehr setzt die VCCU das IODev automatisch je nach Verfügbarkeit und Funklage. Es ist jedoch nicht erforderlich angelegte IODev Attribute zu entfernen."

Bis vor ein paar Tagen war ein SCC mit als 3. IO im System, habe ich dann entfernt, weil der HM-MOD so eine extrem gute Reichweite im Haus hat.

Gruß Helmut

P.S. Im Moment ist der SCC wieder drin, FM sind dann natürlich weg.

[LuckyDay]

Code Auswählen Erweitern

IODev      SCC
ändere das mal gegen ein vorhandenes device --> HmUART oder miniCULhm

Fhem beschwert sich immer über nicht definierte Device ! egal ob vccu oder nicht

[isy]

Habe ich gemacht, ändert nichts.
Ich denke, es liegt an den 35s zwischen "opening" und "opened".
Kann es sein, dass wegen der guten RSSI Werte die HM Devices alle mit dem HMUART (HM-MOD-RPI-PCB über WLAN) assoziiert sind und beim Systemstart genau dieses IO suchen?

Gruß Helmut

[Otto123]

Du könntest noch mit preferred IO arbeiten.
Oder damit leben.
Wenn der IO solange braucht?! Netzwerkprobleme?

Gruß Otto

[isy]

Habe jetzt meinen SCC wieder aktiviert. Damit ist der Fehler weg erstmal.

Es wurden von den Gateways HM-MOD mit Wlan recht viele verkauft.
Werde dort im Forum auch noch nachfragen ob andere User das gleiche Phänomen beobachten.

Vielen Dank für den Support,
Helmut

[Otto123]

Ich habe auch ein ESP8266 mit HMUART am Start, es dauert bei mir stabil 10 sec zwischen opening und opened. Wobei da keine Sekunde vorher erstmal die Meldung mit dem Featurelevel von FHEM kommt.
Lokal an der UART braucht das keine Sekunde.

Die von Dir vermissten Meldungen aus Post #1 kenne ich gar nicht. 

Gruß Otto

[isy]

Könnte also wirklich ein 2.4 GHZ WLAN Problem sein.
Ich werde morgen mal meine anderen IOs, die über WLAN laufen, der Reihe nach mal deaktivieren.
Mal sehen, ob damit eine Änderung eintritt.

Die folgenden zur fehlenden Info kommt vom Wiki, "Logbeispiel"

Beste Grüße,
Helmut

[frank]

vielleicht erbringt ja ein fhemstart mit verbose 5 mehr infos.
ich kann mir nicht vorstellen, dass bei 10s keine meldung kommt, aber bei 34s dann für jedes device.

[isy]

Ja, das könnte was bringen. Wird halt ellenlang......

Das Problem tritt übrigens nur auf, wenn kein anderes Homematic IO aktiv ist.
Wenn ich also meinen SCC von Busware wieder aktiviere, sieht es so aus, als ob der SCC alle Anfragen beim Start bedient und später dann, über die VCCU, das IO mit den besten RSSI Werten verbunden wird.

Gruß Helmut