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:
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
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
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)
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:
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
Hi,
das hier hat bei der VCCU nix zu suchen.
attr VCCU IOgrp VCCU
Gib mal ein list ku_SW_Fenster_r
Gruß Otto
wahrscheinlich stimmt die reihenfoge der definitionen in fhem.cfg nicht. das io muss ganz nach vorne, also vor vccu und die devices.
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.
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)
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.
Zitat von: frank am 06 Januar 2018, 18:22:12
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):
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 F11573Gruß Helmut
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
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.
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
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
Du könntest noch mit preferred IO arbeiten.
Oder damit leben.
Wenn der IO solange braucht?! Netzwerkprobleme?
Gruß Otto
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
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
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
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.
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
Nur rein Informativ, etwas reduziert:
2017.12.11 09:41:30 1: Including fhem.cfg
2017.12.11 09:41:32 3: telnetPort: port 7072 opened
2017.12.11 09:41:38 3: WEB: port 8083 opened
2017.12.11 09:41:39 3: WEBphone: port 8084 opened
2017.12.11 09:41:39 3: WEBtablet: port 8085 opened
2017.12.11 09:41:43 2: eventTypes: loaded 1419 events from ./log/eventTypes.txt
2017.12.11 09:41:52 3: WEBapi: port 8088 opened
2017.12.11 09:41:52 3: WEBfest: port 8089 opened
...
2017.12.11 09:41:57 3: FHEM2FHEM opening F2Fb3 at 192.168.178.83:7072
2017.12.11 09:41:58 3: myHmUARTLGW device closed
2017.12.11 09:41:58 3: Opening myHmUARTLGW device 192.168.178.109:23
2017.12.11 09:42:05 1: Including ./log/fhem.save
2017.12.11 09:42:07 3: Device HM_3447F9 added to ActionDetector with 000:10 time
2017.12.11 09:42:07 3: Device HM_4C1BB8 added to ActionDetector with 002:50 time
...
2017.12.11 09:42:08 0: Featurelevel: 5.8
2017.12.11 09:42:08 0: Server started with 120 defined entities (fhem.pl:15182/2017-10-03 perl:5.020002 os:linux user:fhem pid:1117)
...
2017.12.11 09:42:08 3: myHmUARTLGW device opened
Wenn ich ein close mache und dann ein open, geht das auch ohne Verzögerung2018.01.06 23:43:55 3: Opening myHmUARTLGW device 192.168.178.154:23
2018.01.06 23:43:55 3: myHmUARTLGW device opened
Gruß Otto
Cool.
Ist bei mir auch so. Nur beim Systemstart dauert es die 35s.
Mal drüber nachdenken........
Habe einige IO's, die zu starten sind. Vielleicht kommt der HM-MOD... zu kurg.
Apptime ist alles Ok
Gruss Helmut
Setze doch mal die vccu vor die Devices.
Also:
IODev -> vccu -> device.
Im device ist ja die vccu als iogrp drin. (oder sollte)
Mit dem Handy online, daher kurz gefasst...
Das ist so.
Erst die diversen HM IO's, dazwischen noch IR verschiebe ich noch), dann die VCCU, dann kommen noch Fritzbox usw.
Und dann erst die Devices.
Jetzt, wo ich das schreibe, werde ich nur morgen auch noch mal das IR 360 Grad Gateway anschauen