Hallo
ich habe irgendwie Probleme mit meinem HM-CFG-USB-2.
Er lief jetzt zwei monate problemlos.
Zuerst an einen Raspberry jetzt seid zwei Wochen auf meinem i3 x64 Ubuntu Server.
Am Montag ging der Spaß los.
Plötzlich reagiert kein HM gerät mehr auf FHEM.
Stick wird von Ubuntu nicht mehr erkannt.
An 2 Windows PC´s versuch dort erst Unbekanntes Gerät dann Gerät nicht erkannt.
Wohl Hardware defekt.
Also ab zurück mit dem Stick.
Ein bekannter hat noch einen alten HM-CFG-USB (der große alte)
der wurde von den Windows PC´s erkannt und auf neuste FW geflasht.
Bis eben lief er dann am Server bis er jetzt auch tot ist.
Ich kann mir das nicht erklären.
Beide HM-CFG-USB waren am selben Hub wie zwei Jeelink und ein Arduino UNO und die machen keine Probleme!
Der alte HM-CFG-USB hat auch keine Garantie mehr.
Natürlich habe ich trottel mir am Montag sofort einen neuen HM-CFG-USB bestellt der hoffentlich morgen ankommt.
Da ich jetzt aber angst habe das der dann auch gleich wieder den Geist auf gibt habe ich mir grade noch einen HM-CFG-LAN hinterher bestellt.
Zur eigentlichen frage
Kennt jemand dieses Problem und/oder hat jemand eine Lösung dafür parat oder kennt die Ursache???
Hi Henno,
meiner ist auch vor einigen Wochen kaputt gegangen: http://forum.fhem.de/index.php/topic,20570.0.html
Der neue Stick läuft seit dem aber ohne Problem. Ich hab leider bis heute nicht verstanden wieso das Gerät kaputt gegangen ist.
Gruß,
Jan
Der neue ist heute angekommen und hängt jetzt zur Sicherheit am USB 3 port .
Hoffentlich hält der jetzt länger
Abend,
mir ist gestern der zweite hm-cfg-usb-2 kaputt gegangen. Ich habe einige mal flash-ota benutzt um Firmware zu updaten. Das ging auch hervorragend. Danach habe ich wieder hmland gestartet und dabei ist das Gerät verreckt. In etwa wie beim letzten. Hat jemand eine Idee woran das liegen kann?
[ 345.696094] hub 4-0:1.0: unable to enumerate USB device on port 1
[ 361.732072] usb 4-1: new full-speed USB device number 14 using uhci_hcd
[ 361.856054] usb 4-1: device descriptor read/64, error -71
[ 362.084052] usb 4-1: device descriptor read/64, error -71
[ 362.300058] usb 4-1: new full-speed USB device number 15 using uhci_hcd
[ 362.420071] usb 4-1: device descriptor read/64, error -71
[ 362.648074] usb 4-1: device descriptor read/64, error -71
[ 362.864070] usb 4-1: new full-speed USB device number 16 using uhci_hcd
[ 363.272068] usb 4-1: device not accepting address 16, error -71
[ 363.384072] usb 4-1: new full-speed USB device number 17 using uhci_hcd
[ 363.796094] usb 4-1: device not accepting address 17, error -71
[ 363.796124] hub 4-0:1.0: unable to enumerate USB device on port 1
Gruß,
Jan
Könnte das ein Hitzeproblem sein? Ich hab das Gefühl, dass das Ding bei Beanspruchung (OTA flashen) recht warm wird - werd ich mal nachmessen...
Moin,
Beim flashen ist beides mal nichts passiert. Erst danach als ich wieder hmland benutzt habe. Vielleicht kommt der sick nicht richtig aus dem Update Mode und geht irgendwie in einen illegalen State. Danach bootet er nicht mehr.
Ich würde ihm ja selber flashen aber eq3 veröffentlicht ja leider keine Firmware.
Gruß
Jan
Hallo,
mein HM-CFG-USB-2 ist Vorgestern auch plötzlich kaputt gegangen. Zu dem Zeitpunkt hatte ich einige Zeit mit dem Raspberry "rumgespielt" (mit verschiedenen SD Karten, deshalb öfters Strom weg)
Ist dies jetzt noch bei mehreren Aufgetreten? Ich habe mir einen gekauft weil ich gedacht habe, daß er stabiler läuft als ein CUL. Jetzt bin ich aber ganz froh, daß ich den CUL noch nicht verkauft habe, aber überlege jetzt, ob ein HM-CFG-USB-2 wirklich die robustere Variante ist.
Habt ihr dazu eine Meinung?
Danke
Martin
Abend,
ein Stick ist bei mir beim flashen gestorben. Der andere einige Zeit nach dem ich viel geflasht habe beim täglichen Reboot. Beide male war der Austausch problemlos. Vermutlich ein Firmware Problem.
Gruß,
Jan
Zitat von: DosiRocker am 12 Juni 2014, 14:30:29
daß ich den CUL noch nicht verkauft habe, aber überlege jetzt, ob ein HM-CFG-USB-2 wirklich die robustere Variante ist.
Habt ihr dazu eine Meinung?
Der HM-CFG-USB ist definitiv die robustere und unproblematischere Variante. Meine drei Sticks laufen seit Anbeginn ihrer Tage absolut problemlos. Ok, ich flashe da aber auch nicht permanent drauf rum, und wenn es wirklich ein notwendiges (!) Update gibt, mache ich mir die Mühe, die Original-Tools von eq3 zu verwenden.
also ich habe ja nicht mal oft geflasht (nur beim Kauf vor ca. 2-3 Monaten ebenfalls mit OriginalTool).. Nur den Raspberry mußte ich mehrmals neu booten, und danach ging nichts mehr.
Gruß,
Martin
Morgen,
Mit flashen meinte ich immer Flash-ota. Nicht den Stick selber. Allerdings sind meine beiden auch am RaspberryPi gestorben.
Gruß
Jan
Moin !
Also meiner hat heute nach rund einem Jahr Betrieb auch den Geist aufgegeben. Er hat nur einmal ein
aktuelle Firmware Update bekommen und das ist auch Wochen her. Die Häufung der Ausfälle finde
ich schon eigenartig ....
OTA Devices gabe ich über den Stick nie geflasht, da ich auch gar keine besitze ...
Gruß, Marc
Ich kann auch einen defekten HM-CFG-USB-2 vermelden.
- lief ca 4 Monate fehlerfrei
- Betrieb am RPi
- aktuelle Firmware 0.967 wurde direkt nach dem Kauf im Februar mit dem HomeMatic windows Tool geflasht
Fehlerbild:
- hmland init funktioniert nicht mehr
- Stick wird unter Windows nicht mehr erkannt - Fehler im Gerätemanager
Ich habe die hmland Reboot-Routine nach 24h in Verdacht, die in den hmland Versionen vor dem 14.05.2014 per default aktiv war. Bei mir ist der Stick nämlich just während eines solchen Reboot/Inits gestorben. Wenn ich das Log der letzten Tage betrachte, hat der Stick auch vorher schon teilweise einige init Versuche benötigt, bis er wieder aktiv war:
2014-06-30_17:03:22 hmusb CONNECTED
2014-06-30_17:05:10 hmusb cond: ok
2014-06-30_17:05:10 hmusb Xmit-Events: ok:1
2014-06-30_17:05:10 hmusb prot_ok: last
2014-07-01_17:03:29 hmusb DISCONNECTED
2014-07-01_17:03:30 hmusb cond: init
2014-07-01_17:03:30 hmusb Xmit-Events: init:1
2014-07-01_17:03:30 hmusb prot_init: last
2014-07-01_17:03:30 hmusb CONNECTED
2014-07-01_17:03:30 hmusb DISCONNECTED
2014-07-01_17:03:30 hmusb cond: init
2014-07-01_17:03:30 hmusb Xmit-Events: init:1
2014-07-01_17:03:30 hmusb prot_init: last
2014-07-01_17:03:30 hmusb CONNECTED
2014-07-01_17:03:33 hmusb cond: ok
2014-07-01_17:03:33 hmusb Xmit-Events: ok:1
2014-07-01_17:03:33 hmusb prot_ok: last
2014-07-02_17:03:38 hmusb DISCONNECTED
2014-07-02_17:03:38 hmusb cond: init
2014-07-02_17:03:38 hmusb Xmit-Events: init:1
2014-07-02_17:03:38 hmusb prot_init: last
2014-07-02_17:03:38 hmusb CONNECTED
2014-07-02_17:03:41 hmusb DISCONNECTED
2014-07-02_17:03:41 hmusb cond: init
2014-07-02_17:03:41 hmusb Xmit-Events: init:1
2014-07-02_17:03:41 hmusb prot_init: last
2014-07-02_17:03:41 hmusb CONNECTED
2014-07-02_17:03:42 hmusb DISCONNECTED
2014-07-02_17:03:42 hmusb cond: init
2014-07-02_17:03:42 hmusb Xmit-Events: init:1
2014-07-02_17:03:42 hmusb prot_init: last
2014-07-02_17:03:42 hmusb CONNECTED
2014-07-02_17:03:44 hmusb DISCONNECTED
2014-07-02_17:03:44 hmusb cond: init
2014-07-02_17:03:44 hmusb Xmit-Events: init:1
2014-07-02_17:03:44 hmusb prot_init: last
2014-07-02_17:03:49 hmusb DISCONNECTED
2014-07-02_17:03:49 hmusb cond: init
2014-07-02_17:03:49 hmusb Xmit-Events: init:1
2014-07-02_17:03:49 hmusb prot_init: last
2014-07-02_17:03:49 hmusb CONNECTED
2014-07-02_17:04:26 hmusb cond: ok
2014-07-02_17:04:26 hmusb Xmit-Events: ok:1
2014-07-02_17:04:26 hmusb prot_ok: last
2014-07-03_17:03:57 hmusb DISCONNECTED
2014-07-03_17:03:57 hmusb cond: init
2014-07-03_17:03:57 hmusb Xmit-Events: init:1
2014-07-03_17:03:57 hmusb prot_init: last
2014-07-03_17:03:57 hmusb CONNECTED
2014-07-03_17:03:58 hmusb DISCONNECTED
2014-07-03_17:03:58 hmusb cond: init
2014-07-03_17:03:58 hmusb Xmit-Events: init:1
2014-07-03_17:03:58 hmusb prot_init: last
2014-07-03_17:03:58 hmusb CONNECTED
2014-07-03_17:03:59 hmusb DISCONNECTED
2014-07-03_17:03:59 hmusb cond: init
2014-07-03_17:03:59 hmusb Xmit-Events: init:1
2014-07-03_17:03:59 hmusb prot_init: last
2014-07-03_17:03:59 hmusb CONNECTED
2014-07-03_17:04:01 hmusb DISCONNECTED
2014-07-03_17:04:01 hmusb cond: init
2014-07-03_17:04:01 hmusb Xmit-Events: init:1
2014-07-03_17:04:01 hmusb prot_init: last
2014-07-03_17:04:01 hmusb CONNECTED
2014-07-03_17:04:03 hmusb DISCONNECTED
2014-07-03_17:04:03 hmusb cond: init
2014-07-03_17:04:03 hmusb Xmit-Events: init:1
2014-07-03_17:04:03 hmusb prot_init: last
2014-07-03_17:04:03 hmusb CONNECTED
2014-07-03_17:04:07 hmusb DISCONNECTED
2014-07-03_17:04:08 hmusb cond: init
2014-07-03_17:04:08 hmusb Xmit-Events: init:1
2014-07-03_17:04:08 hmusb prot_init: last
2014-07-03_17:04:08 hmusb CONNECTED
2014-07-03_17:04:08 hmusb DISCONNECTED
2014-07-03_17:04:08 hmusb CONNECTED
2014-07-03_17:04:08 hmusb DISCONNECTED
2014-07-03_17:04:09 hmusb cond: init
2014-07-03_17:04:09 hmusb Xmit-Events: init:1
2014-07-03_17:04:09 hmusb prot_init: last
2014-07-03_17:04:09 hmusb CONNECTED
2014-07-03_17:04:11 hmusb cond: ok
2014-07-03_17:04:11 hmusb Xmit-Events: ok:1
2014-07-03_17:04:11 hmusb prot_ok: last
2014-07-04_17:04:14 hmusb cond: timeout
2014-07-04_17:04:14 hmusb Xmit-Events: timeout:1
2014-07-04_17:04:14 hmusb prot_timeout: last
2014-07-04_17:04:14 hmusb DISCONNECTED
2014-07-04_17:04:14 hmusb cond: init
2014-07-04_17:04:14 hmusb Xmit-Events: init:1
2014-07-04_17:04:14 hmusb prot_init: last
2014-07-04_17:04:14 hmusb CONNECTED
2014-07-04_17:04:17 hmusb DISCONNECTED
2014-07-04_17:04:17 hmusb cond: init
2014-07-04_17:04:17 hmusb Xmit-Events: init:1
2014-07-04_17:04:17 hmusb prot_init: last
2014-07-04_17:04:17 hmusb CONNECTED
2014-07-04_17:06:09 hmusb cond: ok
2014-07-04_17:06:09 hmusb Xmit-Events: ok:1
2014-07-04_17:06:09 hmusb prot_ok: last
2014-07-05_17:04:24 hmusb DISCONNECTED
2014-07-05_17:04:24 hmusb cond: init
2014-07-05_17:04:24 hmusb Xmit-Events: init:1
2014-07-05_17:04:24 hmusb prot_init: last
2014-07-05_17:04:25 hmusb CONNECTED
2014-07-05_17:04:25 hmusb DISCONNECTED
2014-07-05_17:04:25 hmusb cond: init
2014-07-05_17:04:25 hmusb Xmit-Events: init:1
2014-07-05_17:04:25 hmusb prot_init: last
2014-07-05_17:04:25 hmusb CONNECTED
2014-07-05_17:04:26 hmusb DISCONNECTED
2014-07-05_17:04:26 hmusb cond: init
2014-07-05_17:04:26 hmusb Xmit-Events: init:1
2014-07-05_17:04:26 hmusb prot_init: last
2014-07-05_17:04:26 hmusb Xmit-Events: init:1
2014-07-05_17:04:26 hmusb prot_init: last
2014-07-05_17:04:26 hmusb CONNECTED
2014-07-05_17:04:28 hmusb DISCONNECTED
2014-07-05_17:04:28 hmusb cond: init
2014-07-05_17:04:28 hmusb Xmit-Events: init:1
2014-07-05_17:04:28 hmusb prot_init: last
2014-07-05_17:04:28 hmusb CONNECTED
2014-07-05_17:04:30 hmusb DISCONNECTED
2014-07-05_17:04:30 hmusb cond: init
2014-07-05_17:04:30 hmusb Xmit-Events: init:1
2014-07-05_17:04:30 hmusb prot_init: last
2014-07-05_17:04:30 hmusb CONNECTED
2014-07-05_17:04:35 hmusb DISCONNECTED
2014-07-05_17:04:35 hmusb cond: init
2014-07-05_17:04:35 hmusb Xmit-Events: init:1
2014-07-05_17:04:35 hmusb prot_init: last
2014-07-05_17:04:35 hmusb CONNECTED
2014-07-05_17:07:06 hmusb cond: ok
2014-07-05_17:07:06 hmusb Xmit-Events: ok:1
2014-07-05_17:07:06 hmusb prot_ok: last
2014-07-06_17:04:43 hmusb DISCONNECTED
2014-07-06_17:04:43 hmusb cond: init
2014-07-06_17:04:43 hmusb Xmit-Events: init:1
2014-07-06_17:04:43 hmusb prot_init: last
2014-07-06_17:04:43 hmusb CONNECTED
2014-07-06_17:04:44 hmusb DISCONNECTED
2014-07-06_17:04:44 hmusb cond: init
2014-07-06_17:04:44 hmusb Xmit-Events: init:1
2014-07-06_17:04:44 hmusb prot_init: last
2014-07-06_17:04:44 hmusb CONNECTED
2014-07-06_17:06:13 hmusb cond: ok
2014-07-06_17:06:13 hmusb Xmit-Events: ok:1
2014-07-06_17:06:13 hmusb prot_ok: last
2014-07-06_21:10:04 hmusb cond: ok
2014-07-06_21:10:04 hmusb Xmit-Events: ok:1
2014-07-06_21:10:04 hmusb prot_ok: last
2014-07-07_21:10:04 hmusb cond: timeout
2014-07-07_21:10:04 hmusb Xmit-Events: timeout:1
2014-07-07_21:10:04 hmusb cond: timeout
2014-07-07_21:10:04 hmusb Xmit-Events: timeout:1
2014-07-07_21:10:04 hmusb prot_timeout: last
2014-07-07_21:10:04 hmusb DISCONNECTED
2014-07-07_21:10:04 hmusb cond: init
2014-07-07_21:10:04 hmusb Xmit-Events: init:1
2014-07-07_21:10:04 hmusb prot_init: last
2014-07-07_21:10:04 hmusb CONNECTED
2014-07-07_21:10:07 hmusb DISCONNECTED
2014-07-07_21:10:07 hmusb cond: init
2014-07-07_21:10:07 hmusb Xmit-Events: init:1
2014-07-07_21:10:07 hmusb prot_init: last
2014-07-07_21:10:07 hmusb CONNECTED
2014-07-07_21:10:36 hmusb cond: timeout
2014-07-07_21:10:36 hmusb Xmit-Events: timeout:1
2014-07-07_21:10:36 hmusb prot_timeout: last
2014-07-07_21:10:36 hmusb DISCONNECTED
2014-07-07_21:10:36 hmusb cond: init
2014-07-07_21:10:36 hmusb Xmit-Events: init:1
2014-07-07_21:10:36 hmusb prot_init: last
2014-07-07_21:10:36 hmusb CONNECTED
2014-07-07_21:10:39 hmusb DISCONNECTED
2014-07-07_21:10:39 hmusb cond: init
2014-07-07_21:10:39 hmusb Xmit-Events: init:1
2014-07-07_21:10:39 hmusb prot_init: last
2014-07-07_21:10:39 hmusb CONNECTED
2014-07-07_21:11:08 hmusb cond: timeout
2014-07-07_21:11:08 hmusb Xmit-Events: timeout:1
2014-07-07_21:11:08 hmusb prot_timeout: last
2014-07-07_21:11:09 hmusb DISCONNECTED
2014-07-07_21:11:09 hmusb cond: init
2014-07-07_21:11:09 hmusb Xmit-Events: init:1
2014-07-07_21:11:09 hmusb prot_init: last
2014-07-07_21:11:09 hmusb CONNECTED
2014-07-07_21:11:12 hmusb DISCONNECTED
2014-07-07_21:11:12 hmusb cond: init
2014-07-07_21:11:12 hmusb Xmit-Events: init:1
2014-07-07_21:11:12 hmusb prot_init: last
...
Bis 06.07. waren die 24h Reboots immer kurz nach 17:00 Uhr - zum Teil hat es schon einige Versuche benötigt. Am 06.07. habe ich FHEM um 21:10 manuell durchgestartet (shutdown restart). Der Reconnect an den hmland hat auf Anhieb geklappt. Exakt 24h später am 07.07. um 21.10 hat sich der HM-CFG-USB-2 nach "timeout" und "init" nicht mehr berappelt.
Ersatz von A$$zon ist unterwegs. Ich habe bereits auf die neueste hmland Version aktualisiert, bei der der 24h Reboot mit Firmware 0.967 nicht mehr gemacht wird. Hoffentlich hält der Stick dann zukünftig länger...
Tobias
PS: War ein guter Test für die IODev Failover Funktionalität von Martins VCCU. Besten Dank hierfür! :D
+1 wie es aussieht.
Habe ihn unter Windows per hmland (http://forum.fhem.de/index.php/topic,29441.0.html) seit 8 Tagen laufen (D-firmware 0.967). Davor für max. 2 Wochen mit Homematic Konfigurator. D.h. er ist nicht mal einen Monat alt.
Can't open device: Access denied (insufficient permissions)
Can't find/open hmcfgusb!
Can't initialize HM-CFG-USB!
FHEM sagte HmUsb new condition timeout, ab hier nur noch HmUsb new condition disconnected.
Windows sagt nach Abziehen+Reinstecken Gerät unbekannt + Empfehlung Gerät zu ersetzen.
Nun die Frage ob es Sinn macht sich einen weiteren Stick zu besorgen, sich diesen ggf. genauso schnell zerschießt, ob der Hm-Lan evtl. stabiler ist und ob jener Fall eigentlich noch als Garantie gilt?
Ich hatte zuletzt wiederholt Schreibbefehle per Notify und Perlfunktion abgesetzt.
-> alle 2,5 min Werte ausgelesen und ab und zu valveMaxPos gesetzt
-> je für 3 Geräte über einen Tag
-> da regset valveMaxPos 25 (bsp) oft mit set_25 % hängen blieb, wurde gleicher Befehl mit teils neuem Wert wiederholt abgesendet, was wiederum einige Stunden vorher für hohe ERROR-Overloads sorgte
-> den ERROR-Overloads begegnete ich wiederum mit hmlan -r 60, um das Debugging zumindest für den Abend zu ermöglichen
-> als die Sachen stabil liefen, schaltete ich insgesamt 8 Geräte in die Prozedur
-> ERROR-Overloads waren 0, wohl aber die zweite Zahl bei msgLoadEst ?/>75/?/?/?,
-> nach etwa 5 bis 10 min das beschriebene Verhalten
+1 auch von mir :(
Mein HM-CFG_USB-2 ist nach ca. 11 Monaten gestorben. Ich habe ihn Anfangs zum Flashen einiger Thermostate genutzt und dabei nur die eq3 Originalsoftware unter Windows benutzt. Danach lief er einige Monate unter hmland an meinem NAS ohne Probleme, bis er dann einfach den Geist aufgegeben hat.
Hat von Euch jemand von eq3 Ersatz und/oder Aussagen bekommen, was defekt ist? Könnte es ein einfacher Hardware-Defekt wie z.B. ein Elko minderer Qualität sein, der einfach nach einer gewissen Nutzungszeit kaputt geht?
> Nun die Frage ob es Sinn macht sich einen weiteren Stick zu besorgen, sich diesen ggf. genauso schnell zerschießt, ob der Hm-Lan evtl. stabiler ist und ob jener Fall eigentlich noch als Garantie gilt?
http://forum.fhem.de/index.php/topic,13071.630.html
> Es besteht auch noch die Möglichkeit, die Geschwindingkeit der USB-Schnittstelle auf die USB1.1 zu reduzieren.
Würde das ggf. das von mir vermutete Überhitzungsproblem mindern?
+Kann es ggf. sein, dass die Zerfetzung kam da der USB-Port nicht auf USB 1.1 umgeschalten war (weil unter Windows und ich sowieso nicht verstanden hab warum die Umstellung sein muss und wie man sie unter Windows bewerkstelligt)?
+Oder hatte der HM-CFG-USB2 ggf. Sendeprobleme aufgrund hoher Reichweiten und kam daher wegen hohen Wiederholungen ins schwitzen? Bei dem Gerät für das hinterste Zimmer standen in FHEM (unter time-request) Werte von -80 was glaube ich schlecht ist?