HM-CFG-USB-2 defekt

Begonnen von Henno, 20 März 2014, 21:19:08

Vorheriges Thema - Nächstes Thema

Henno

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???

jab

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

Henno

Der neue ist heute angekommen und hängt jetzt zur Sicherheit am USB 3 port .
Hoffentlich hält der jetzt länger

jab

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

peterk_de

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...
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

jab

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

DosiRocker

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
Cubietruck: CUNO 868;CUL HM
1 Wire: 1 OWAD, 13 OTHERM
10 FS20 ST; 3 HMS100WD; 1 EM1000;  4 S300TH;
4 HM_CC_RT_DN, HM_SEC_SC
AVM 7390 als FHEM2FHEM, Raspberry Pi

jab

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

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

DosiRocker

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
Cubietruck: CUNO 868;CUL HM
1 Wire: 1 OWAD, 13 OTHERM
10 FS20 ST; 3 HMS100WD; 1 EM1000;  4 S300TH;
4 HM_CC_RT_DN, HM_SEC_SC
AVM 7390 als FHEM2FHEM, Raspberry Pi

jab

Morgen,

Mit flashen meinte ich immer Flash-ota. Nicht den Stick selber. Allerdings sind meine beiden auch am RaspberryPi gestorben.

Gruß
Jan

marc2

#11
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

tpm88

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
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

Trebxson

#13
+1 wie es aussieht.

Habe ihn unter Windows per hmland 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
FHEM auf NUC (NUC5i5MYBE) Lüfterlos (Akasa) bei ~10 W mit Abschaltung bei Nichtanwesenheit + Wake on Pattern Match mit EEE im Sommer.
Heizungssteuerung mit Homematic über FHEM im Winter.
Wassersäule mit Pumpe, WaKü-Technik, Luftsprudel, Wasserstrudel, RGB-Lichtorgel mit Homematic und ZWave.

reibuehl

+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?
Reiner.