Zitat von: betateilchen am 18 August 2014, 21:48:15
Hallo Martin,
ich habe heute wieder "help me!" Meldungen im Log festgestellt, und zwar bei jedem fhem Neustart.
2014.08.18 21:00:24 3: wz_HMUSB: Unknown code A09998112999999000000::-63:wz_HMUSB, help me!
2014.08.18 21:00:24 3: fl_HMUSB: Unknown code A09998112999999000000::-63:fl_HMUSB, help me!
Aufgrund der "komischen" Adressdaten vermute ich, dass das irgendwelche CUL_HM-internen Werte sind, die eigentlich nicht geloggt werden sollten.
Modulversion ist die von Dir hier im Thread genannte 6415.
Gab's dafür eigentlich eine Lösung? Ich habe heute meinen HMLAN zur VCCU hinzugefügt (zusätzlich zum HMUSB) und habe seitdem auch beim FHEM-Neustart die gleichen Einträge im Log:
2014.08.26 21:06:03 3: HMLAN: Unknown code A09998112999999000000::-62:HMLAN, help me!
2014.08.26 21:06:03 3: HMUSB: Unknown code A09998112999999000000::-62:HMUSB, help me!Falls nötig, hier aktuelle Infos zu meiner VCCU:
list VCCU
Internals:
DEF 25749E
HMUSB_MSGCNT 33
HMUSB_RAWMSG E25749E,0000,04C5DCC6,FF,FFC1,11800225749E2528FD00
HMUSB_RSSI -63
HMUSB_TIME 2014-08-26 21:06:26
IODev HMLAN
LASTInputDev HMUSB
MSGCNT 33
NAME VCCU
NR 50
STATE HMLAN:ok,HMUSB:ok,
TYPE CUL_HM
assignedIOs HMLAN,HMUSB
channel_01 VCCU_01
lastMsg No:11 - t:02 s:25749E d:2528FD 00
protLastRcv 2014-08-26 21:06:26
rssi_at_HMUSB avg:-62.12 min:-63 max:-61 lst:-63 cnt:33
Readings:
2014-08-26 21:06:26 CommandAccepted yes
Helper:
mId FFF0
rxType 1
Io:
nextSend 1409079986.17611
prefIO
vccu
ioList:
HMLAN
HMUSB
Mrssi:
mNo 11
Io:
HMUSB -63
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
vrt 1
Rssi:
At_hmusb:
avg -62.1212121212121
cnt 33
lst -63
max -61
min -63
Shadowreg:
Attributes:
IODev HMLAN
IOList HMLAN,HMUSB
event-on-change-reading .*
expert 2_full
model CCU-FHEM
subType virtual
webCmd virtual:update
list VCCU_01
Internals:
DEF 25749E01
NAME VCCU_01
NR 51
STATE ???
TYPE CUL_HM
chanNo 01
device VCCU
peerList WZ_Taster_Wand_01_01,WZ_Taster_Wand_01_02,WZ_Taster_Wand_01_03,WZ_Taster_Wand_01_04,WZ_Taster_Wand_01_05,WZ_Taster_Wand_01_06,WZ_Taster_Wand_01_07,WZ_Taster_Wand_01_08,WZ_Taster_Wand_01_09,WZ_Taster_Wand_01_10,WZ_Taster_Wand_01_11,WZ_Taster_Wand_01_12,WZ_Taster_Wand_01_13,WZ_Taster_Wand_01_14,WZ_Taster_Wand_01_15,WZ_Taster_Wand_01_16,WZ_Taster_Wand_01_17,WZ_Taster_Wand_01_18,WZ_Taster_Wand_01_19,WZ_Taster_Wand_01_20,SZ_Taster_Wand_01_01,SZ_Taster_Wand_01_02,KU_Taster_Wand_01_01,KU_Taster_Wand_01_02,BZ_Taster_Wand_01_01,BZ_Taster_Wand_01_02,KU_Taster_Wand_02_01,KU_Taster_Wand_02_02,WG_Taster_Wand_01_01,WG_Taster_Wand_01_02,BZ_Taster_Wand_02_01,BZ_Taster_Wand_02_02,WZ_Taster_Hand_01_01,WZ_Taster_Hand_01_02,WZ_Taster_Hand_01_03,WZ_Taster_Hand_01_04,SZ_Taster_Hand_01_01,SZ_Taster_Hand_01_02,SZ_Taster_Hand_01_03,SZ_Taster_Hand_01_04,
Readings:
2014-08-26 21:14:12 peerList WZ_Taster_Wand_01_01,WZ_Taster_Wand_01_02,WZ_Taster_Wand_01_03,WZ_Taster_Wand_01_04,WZ_Taster_Wand_01_05,WZ_Taster_Wand_01_06,WZ_Taster_Wand_01_07,WZ_Taster_Wand_01_08,WZ_Taster_Wand_01_09,WZ_Taster_Wand_01_10,WZ_Taster_Wand_01_11,WZ_Taster_Wand_01_12,WZ_Taster_Wand_01_13,WZ_Taster_Wand_01_14,WZ_Taster_Wand_01_15,WZ_Taster_Wand_01_16,WZ_Taster_Wand_01_17,WZ_Taster_Wand_01_18,WZ_Taster_Wand_01_19,WZ_Taster_Wand_01_20,SZ_Taster_Wand_01_01,SZ_Taster_Wand_01_02,KU_Taster_Wand_01_01,KU_Taster_Wand_01_02,BZ_Taster_Wand_01_01,BZ_Taster_Wand_01_02,KU_Taster_Wand_02_01,KU_Taster_Wand_02_02,WG_Taster_Wand_01_01,WG_Taster_Wand_01_02,BZ_Taster_Wand_02_01,BZ_Taster_Wand_02_02,WZ_Taster_Hand_01_01,WZ_Taster_Hand_01_02,WZ_Taster_Hand_01_03,WZ_Taster_Hand_01_04,SZ_Taster_Hand_01_01,SZ_Taster_Hand_01_02,SZ_Taster_Hand_01_03,SZ_Taster_Hand_01_04,
2014-08-26 20:34:34 trigLast WG_Taster_Wand_01_01 :short
2014-08-26 20:34:13 trig_BZ_Taster_Wand_01_01 long
2014-08-26 20:34:08 trig_BZ_Taster_Wand_01_02 long
2014-08-26 20:34:17 trig_BZ_Taster_Wand_02_01 short
2014-08-26 20:34:02 trig_BZ_Taster_Wand_02_02 short
2014-08-21 11:46:44 trig_KU_Taster_Wand_01_01 short
2014-08-26 20:19:45 trig_KU_Taster_Wand_01_02 short
2014-08-26 20:19:47 trig_KU_Taster_Wand_02_01 short
2014-08-26 20:19:46 trig_KU_Taster_Wand_02_02 short
2014-08-26 20:32:46 trig_SZ_Taster_Hand_01_01 short
2014-08-15 20:52:52 trig_SZ_Taster_Hand_01_02 short
2014-08-15 20:53:00 trig_SZ_Taster_Hand_01_03 long
2014-08-26 20:32:50 trig_SZ_Taster_Hand_01_04 short
2014-08-26 20:33:53 trig_SZ_Taster_Wand_01_01 short
2014-08-26 20:33:51 trig_SZ_Taster_Wand_01_02 short
2014-08-26 20:34:34 trig_WG_Taster_Wand_01_01 short
2014-08-26 20:34:32 trig_WG_Taster_Wand_01_02 short
2014-08-26 20:16:26 trig_WZ_Taster_Hand_01_01 short
2014-08-15 20:32:10 trig_WZ_Taster_Hand_01_02 long
2014-08-15 20:32:49 trig_WZ_Taster_Hand_01_03 long
2014-08-26 20:16:31 trig_WZ_Taster_Hand_01_04 short
2014-08-26 20:17:27 trig_WZ_Taster_Wand_01_01 short
2014-08-26 20:17:30 trig_WZ_Taster_Wand_01_02 short
2014-08-25 21:15:17 trig_WZ_Taster_Wand_01_19 short
2014-08-25 20:47:07 trig_WZ_Taster_Wand_01_20 short
Helper:
Role:
chn 1
vrt 1
Shadowreg:
Attributes:
event-on-change-reading .*
model 1
peerIDs 1EADDD01,1EADDD02,1EADDD03,1EADDD04,1EADDD05,1EADDD06,1EADDD07,1EADDD08,1EADDD09,1EADDD0A,1EADDD0B,1EADDD0C,1EADDD0D,1EADDD0E,1EADDD0F,1EADDD10,1EADDD11,1EADDD12,1EADDD13,1EADDD14,1EDD0D01,1EDD0D02,1EDE3F01,1EDE3F02,1EDE4701,1EDE4702,1EDE6001,1EDE6002,1EDEA301,1EDEA302,1EDEFB01,1EDEFB02,237B0601,237B0602,237B0603,237B0604,252BBA01,252BBA02,252BBA03,252BBA04,
webCmd press short:press long
das ist eine HMLAN interne message - muss(werde) ich also filtern.
Eingebaut hatte ich bereits, dass die 999999 nicht kommt und die message dann automatisch verarbeitet wird. Offensichtlich ist die HMId deiner beiden IOs nicht gesetzt - jedenfalls nicht zu diesem Zeitpunkt. Ist das beim Restart? dann wird das IO in betrieb genommen, bevor die IDs gesetzt sind. Oder werden die HMIds in fhem.cfg nicht gesetzt sondern erst durch die vccu? Das würde es verzögern. Egal, ich werden es jetzt explizit filtern
Dein Update von 00_HMLAN.pm hat jetzt aber scheinbar irgendwas zerhauen, fürchte ich. Sowohl HMUSB als auch HMLAN stehen bei mir in der VCCU jetzt auf INIT und der HMLAN disconnected immer wieder. Wenn ich mir von SF die Revision von gestern ziehe, funktioniert mein Homematic wieder.
Zitat von: martinp876 am 27 August 2014, 07:30:39Ist das beim Restart? dann wird das IO in betrieb genommen, bevor die IDs gesetzt sind. Oder werden die HMIds in fhem.cfg nicht gesetzt sondern erst durch die vccu?
Ja, das war beim Restart. Und die hmId werden direkt als Attribut vom Device gesetzt, nicht erst durch die VCCU.
Warum die Devices allerdings schon in Betrieb genommen werden, bevor die IDs gesetzt sind, verstehe ich nicht. Denn die stehen eigentlich vor allen anderen defines in der fhem.cfg.
Die Ausgabe dieses "ominösen" Codes hatte ich vor ein paar Tagen doch auch schonmal gemeldet?
Muss heute abend mal in die Logs schauen, ob der zwischenzeitlich bei mir auch noch auftrat.
Richtig, deshalb hab ich Dich ja auch zitiert. ;)
Aber Vorsicht, mit der Version, die jetzt im SVN und auch schon im Update ist, funktionieren die IO Devices nicht mehr.
hm -
in meiner version, die auch in SVN sein sollte, funktionieren IOs und vccu
Ich habe das gleiche Problem. Mit der aktuellen Version aus dem Update funktioniert der erste HMLAN (geht aber häufiger mal disconnected). Der zweite und ein HMUSB (per hmland) sind in der VCCU auf init und senden und empfangen nichts. Beide stehen aber auf opened.
Ein Restore (Version von vorgestern) behebt das Problem und alles funktioniert perfekt.
habs umgebaut. besser?
Hallo zusammen,
da ich gerade ein ähnliches Problem habe steige ich mal mit in die Fehlersuche ein. Leider habe ich in anderen Threads keine Lösung zu meinem Problem gefunden.
Ich habe von einer Raspberry PI FHEM Installation auf eine Installation von FHEM auf einem QNAP gewechselt. Es hat sich sonst hardwäremässig nichts geändert. Ich habe auch nur einen HMLAN Adapter. Die Fhem.cfg habe ich per Copy und Paste im Browser einfach in die neue Installation übernommen und die Pfade für Logs etc angepasst. Seitdem bekomme ich diesen Fehler und finde noch nicht einmal heraus um welches Gerät es sich handeln könnte:
2014.08.27 15:23:22 3: HMLAN1: Unknown code A0D60A6101F862A272D2006012000::-40:HMLAN1, help me!
Könnt ihr mir weiterhelfen?
Gruß Sven
Martin, jetzt ist es besser. Die Meldung ist weg, meine beiden IO Devices stehen in der VCCU auf ok und funktionieren auch. Besten Dank!
Hi,
muss mich da nochmal einklinken. Habe heute meinen zweiten HM-Lan als Repeater eingebunden (mit eigener HMID).
Attr IO beim Device entsprechend gesetzt. Läuft soweit rund, aber bekomme aber auch diese Meldung ins logfile.
Upate hatte ich vorgestern gemacht, aktuell steht dazu ja nichts mehr an.
2014-09-03_23:35:20 HMLAN2WS UNKNOWNCODE A0B01A001456CDE224B8D010E::-73:HMLAN2WS
2014-09-03_23:35:20 HMLAN2WS UNKNOWNCODE A0B01A001456CDE224B8D010E::-73:HMLAN2WS
2014-09-03_23:35:21 HMLAN2WS UNKNOWNCODE A0B01A001456CDE224B8D010E::-73:HMLAN2WS
2014-09-03_23:35:23 HMLAN2WS UNKNOWNCODE A0B01A001456CDE224B8D010E::-72:HMLAN2WS
2014-09-03_23:35:24 HMLAN2WS UNKNOWNCODE A0B01A001456CDE224B8D010E::-72:HMLAN2WS
2014-09-03_23:35:24 HMLAN2WS UNKNOWNCODE A0B01A001456CDE224B8D010E::-73:HMLAN2WS
2014-09-03_23:35:24 HMLAN2WS UNKNOWNCODE A0B02A001456CDE224A21010E::-73:HMLAN2WS
2014-09-03_23:35:25 HMLAN2WS UNKNOWNCODE A0A028002456CDE224A2100::-73:HMLAN2WS
2014-09-03_23:35:28 HMLAN2WS UNKNOWNCODE A0B01A001456CDE224B8D010E::-72:HMLAN2WS
2014-09-03_23:35:28 HMLAN2WS UNKNOWNCODE A0B01A001456CDE224B8D010E::-72:HMLAN2WS
2014-09-03_23:35:28 HMLAN2WS UNKNOWNCODE A0B01A001456CDE224B8D010E::-72:HMLAN2WS
2014-09-03_23:35:32 HMLAN2WS UNKNOWNCODE A0B01A001456CDE224B8D010E::-72:HMLAN2WS
2014-09-03_23:35:32 HMLAN2WS UNKNOWNCODE A0B01A001456CDE224B8D010E::-72:HMLAN2WS
2014-09-03_23:35:32 HMLAN2WS UNKNOWNCODE A0B01A001456CDE224B8D010E::-72:HMLAN2WS
2014-09-03_23:35:37 HMLAN2WS UNKNOWNCODE A1003A001456CDE224B8D00040000000000::-72:HMLAN2WS
2014-09-03_23:35:37 HMLAN2WS UNKNOWNCODE A1003A001456CDE224B8D00040000000000::-72:HMLAN2WS
2014-09-03_23:35:38 HMLAN2WS UNKNOWNCODE A1003A001456CDE224B8D00040000000000::-72:HMLAN2WS
2014-09-03_23:35:43 HMLAN2WS UNKNOWNCODE A1003A001456CDE224B8D00040000000000::-72:HMLAN2WS
2014-09-03_23:35:43 HMLAN2WS UNKNOWNCODE A1003A001456CDE224B8D00040000000000::-72:HMLAN2WS
2014-09-03_23:35:43 HMLAN2WS UNKNOWNCODE A1003A001456CDE224B8D00040000000000::-72:HMLAN2WS
2014-09-03_23:35:48 HMLAN2WS UNKNOWNCODE A1003A001456CDE224B8D00040000000000::-72:HMLAN2WS
2014-09-03_23:35:48 HMLAN2WS UNKNOWNCODE A1003A001456CDE224B8D00040000000000::-72:HMLAN2WS
2014-09-03_23:35:48 HMLAN2WS UNKNOWNCODE A1003A001456CDE224B8D00040000000000::-72:HMLAN2WS
2014-09-03_23:35:52 HMLAN2WS UNKNOWNCODE A1003A001456CDE224B8D00040000000000::-72:HMLAN2WS
2014-09-03_23:35:52 HMLAN2WS UNKNOWNCODE A1003A001456CDE224B8D00040000000000::-72:HMLAN2WS
2014-09-03_23:35:53 HMLAN2WS UNKNOWNCODE A1003A001456CDE224B8D00040000000000::-72:HMLAN2WS
Gruss
Patrick
ZitatHabe heute meinen zweiten HM-Lan als Repeater eingebunden (mit eigener HMID).
cool - wie geht das?
a) HMLAN als repeater - nicht als 2. IO?
b) repeater mit eigenen HMId?
Du solltest für jede HMId, die eines deiner IOs nutzt, eine vccu einrichten. Dann kann FHEM die nachrichten zuordnen. CUL_HM kennt die IDs des HMLAN nicht direkt.
Ja klar geht das.
Habe den zweiten HMLan an den AVM Repeater E300 gehängt, der hat einen LAN Anschluss, somit bilden die
zwei eine Einheit und ich nenne ihn meinen HMLan-Repeater ;)
Hast ja recht, habe mich falsch ausgedrückt. Den echten Homematic Repeater wollte ich mir nicht leisten da
ich noch einen zweiten HMLan vor Monaten "günstig" bekommen habe und habe somit jetzt zwei Fliegen
mit einer Klappe geschlagen, da ich sowieso einen Repeater brauchte.
Eigene HMId habe ich natürlich vergeben, habe ja schließlich Deine kritische Äußerung gelesen als ein
anderer FHEMler dieselbe HMId vergeben hatte.
Bezüglich der vccu , das lass ich vorerst mal lieber sein, bin erstmal froh das mein HM-SCI-3-FM-Wassermelder anständige RSSI-Werte
hat und der zweite HMLan nun mal seit 30 Stunden stabil läuft.
Sollten die logs irgendwelchen negativen Einfluss haben werde ich mich da natürlich dann doch erstmal einlesen müssen.
Bin nicht vom Fach aber habe einfach Spass an FHEM... :)
Danke Dir für den Hinweis.
Gruss
Patrick
Hi Patrick,
wenn du 2 IOs mit getrennten HMIds nutzt müssen die devices auch mit dem jeweiligen IO gepairt sein.
Mit zumindest mit einer vccu haben wir es im Griff, dass ein Device sauber einem IO zugewiesen wird - was meine anfänglichen Bedenken bezüglich ACKs eliminiert.
Mit dem "prefered-io" des vccu systems sollten auch deine RSSI-bedenken berücksichtgt sein.
Deine Entscheidung ;)
Hallo,
muss den Thread mal ausgraben...habe bei mir seit kurzem nach jedem restart auch immer diesen Fehler im Log:
2016.06.12 01:26:30 3: CUL_0: Unknown code A09998112999999000000::-83.5:CUL_0, help me!
CUL, HMLan und vCCU werden gleich zu Beginn der fhem.cfg initialisiert.
FHEM ist auf aktuellstem Stand.
Was kann das sein bzw. was kann ich tun?
Danke!
Leider kam hier keine Antwort...ich habe das Problem noch immer beim Start von FHEM.
Hat jemand eine Idee?
Unknown code A09998112999999000000
was es ist, hat martin hier ja beschrieben. also kein fehler sondern eher ein "kosmetisches" problem.
Dann verstehe ich es nicht. Ich habe es so verstanden, dass er irgendwas umprogrammiert hat und diese Meldung nun nicht mehr auftauchen sollte.