HMUARTLGW: Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway

[mgernoth]

Hallo,

Habe das Funkmodul mit der aktuellen Firmware geflasht.

Das Flashen ist wohl irgendwie schiefgelaufen, zumindest startet das Modul die Firmware nicht und hängt sich dann irgendwann auf. Deswegen kannst Du es auch mit den GPIO-Befehlen kurzzeitig wiederbeleben, es funktioniert dann aber trotzdem nicht:

Code Auswählen Erweitern


2016.07.26 14:59:53 3: HMUARTLGW myHmUART currently running Co_CPU_BL
2016.07.26 14:59:53 1: HMUARTLGW myHmUART failed to enter App!


Hier einfach nochmal die Firmware flashen, das sollte das beheben.

Ich bekomme das Lan Gateway HM-LGW-O-TW-EU nicht ans laufen.

Code Auswählen Erweitern


2016.07.27 16:51:41 1: HMUARTLGW myHmLGW application switch failed, application-firmware probably corrupted!


Auch hier scheint die Firmware des LGW ein Problem zu haben. Das Flashen des LGW geht allerdings leider nicht so einfach wie beim UART-Modul.

Vorbereitung:

Code Auswählen Erweitern


$ git clone https://github.com/eq-3/occu
...
$ cd occu
$ sudo ln -s $(pwd)/firmware /firmware
$ cd arm-gnueabihf/packages-eQ-3/LinuxBasis/bin (auf ARM) bzw. cd X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin (auf X86/X86_64)
$ chmod 755 eq3configcmd


Update der LAN-Firmware:

Code Auswählen Erweitern


$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-lgw-firmware -u ../../../../firmware/hm-lgw-o-tw-w-eu_update.eq3  -console -l 1 -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:25:24.264 <Info> LAN Gateway Firmware Update...

2016/07/28 09:25:24.265 <Info> Gateway NEQ0218723
2016/07/28 09:25:26.273 <Info> Gateway type is eQ3-HM-LGW-App
cryptEnabled true2016/07/28 09:25:33.313 <Info> Updating firmware....

2016/07/28 09:25:38.467 <Info> Update performed. Waiting for gateway to get ready.


Update der Applikationsfirmware:

Code Auswählen Erweitern


$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-coprocessor -u -f -c -l 0 -d ../../../../firmware -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:33:03.791 <Debug> firmware filename is: coprocessor_update_hm_only.eq3

cryptEnabled true2016/07/28 09:33:05.801  LanConnection::connect
2016/07/28 09:33:05.802  LanConnection::connect done
2016/07/28 09:33:05.805 <Info> Lan Device Information:
Protocol-Version: 1
Product-ID: eQ3-HM-LGW
Firmware-Version: 1.1.5
Serial Number: NEQ0218723

2016/07/28 09:33:06.007  LanConnection::connect
2016/07/28 09:33:06.008  LanConnection::connect done
2016/07/28 09:33:06.010 <Info> Lan Device Information:
Protocol-Version: 1
Product-ID: eQ3-HM-LGW
Firmware-Version: 1.1.5
Serial Number: NEQ0218723

2016/07/28 09:33:07.516 <Debug> (NEQ0218723) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in application.
2016/07/28 09:33:07.516 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:07.517 <Debug> CCU2CoprocessorCommandMod::isResponseStatusOk(): System status OK
2016/07/28 09:33:07.517 <Debug> CCU2CommControllerMod::handleIncomingResponse() System response OK
2016/07/28 09:33:07.517 <Debug> (NEQ0218723) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in application.
2016/07/28 09:33:07.535 <Debug>  deliver firmware...
2016/07/28 09:33:11.036 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2016/07/28 09:33:11.037  CoprocessorUpdate::startBootloader()
2016/07/28 09:33:11.039 <Debug> (NEQ0218723) CCU2CommControllerMod::startCoprocessorBootloader(): Trying to start coprocessor bootloader
2016/07/28 09:33:11.040 <Debug> CCU2CommControllerMod::sendSystemCommand(): Start Application / Bootloader
2016/07/28 09:33:11.044 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:11.044 <Debug> CCU2CoprocessorCommandMod::isResponseStatusOk(): System status OK
2016/07/28 09:33:11.044 <Debug> CCU2CommControllerMod::handleIncomingResponse() System response OK
2016/07/28 09:33:13.149 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:13.149 <Debug> (NEQ0218723) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in bootloader.
2016/07/28 09:33:13.540 <Debug> CoprocessorUpdate::startBootloader():Coprocessor entered bootloader.
2016/07/28 09:33:14.090 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:14.090 <Debug> CCU2CoprocessorCommandMod::isResponseStatusOk(): System status OK
2016/07/28 09:33:14.090 <Debug> CCU2CommControllerMod::handleIncomingResponse() System response OK
...
2016/07/28 09:33:21.138 <Info> Firmwareupdate successfull

2016/07/28 09:33:21.139  LanConnection::disconnect
2016/07/28 09:33:21.141  Closing socket 3
2016/07/28 09:33:32.144 <Debug> Wait for disconnect timed out
...


Das "Wait for disconnect" kann man mit CTRL-C abbrechen.

NEQ0218723 durch die eigene Serial ersetzen, und geheimesLGWPasswort durch das LGW-Passwort. Falls die Verschlüsselung deaktiviert wurde, dann das -k komplett weglassen.

Viele Grüße
  Michael

[raspberry]

Hallo Michael,

vielen Dank für die schnelle Rückmeldung!

Hallo,

Das Flashen ist wohl irgendwie schiefgelaufen, zumindest startet das Modul die Firmware nicht und hängt sich dann irgendwann auf. Deswegen kannst Du es auch mit den GPIO-Befehlen kurzzeitig wiederbeleben, es funktioniert dann aber trotzdem nicht:

Hier einfach nochmal die Firmware flashen, das sollte das beheben.

Habe die Firmware nun schon mehrmals neu aufgespielt (sowohl 1.2.3 als auch 1.4.1). Wenn ich das Modul (HM-MOD-UART) mehrmals resette, bekomme ich es meistens zum Laufen (oft mehr als 50 Resets).

Gibt's noch weitere Möglichkeiten die ich probieren kann?

(Noch ne Frage zum Reset: muss ich jedes Mal den GPIO 18 neu "exportieren" und die Signalrichtung angeben oder reicht es den Reset-Befehl zu senden?

Code Auswählen Erweitern


echo 1 >/sys/class/gpio/gpio18/value


Vielen Dank für den super Support!!!

Schönen Nachmittag und beste Grüße

raspberry

[Damu]

Das Flashen des LGW geht allerdings leider nicht so einfach wie beim UART-Modul.

Geht das nicht auch mit dem Netfinder von EQ3?

http://www.eq-3.de/service/downloads.html?id=53

[Ralf9]

Den Reset Pin brauchst Du nicht zwingend zum flashen. Zumindest hat das bei mir problemlos mit den "üblichen" vier Strippen funktioniert.

Das flashen hat bei mir so auch problemlos funktioniert. Ich hätte vermutet, daß das flashen nur kurz nach dem reset funktioniert.
Mir ist dabei nicht klar wie der HM-MOD-UART erkennt, daß die seriellen Daten fürs flashen sind.

Nun habe ich auch die 1.4.1 drauf und das pairen des HM-SEC-SCo hat nun auch funktioniert.

Gruß Ralf

[betateilchen]

Mir ist dabei nicht klar wie der HM-MOD-UART erkennt, daß die seriellen Daten fürs flashen sind.

vielleicht bekommt er das seriell einfach mitgeteilt

Ehrlich gesagt darüber habe ich mir keine Gedanken gemacht, weil es "einfach" funktioniert hat.

[mgernoth]

Hallo,

Habe die Firmware nun schon mehrmals neu aufgespielt (sowohl 1.2.3 als auch 1.4.1). Wenn ich das Modul (HM-MOD-UART) mehrmals resette, bekomme ich es meistens zum Laufen (oft mehr als 50 Resets).

Dann stimmt irgendwas anderes noch nicht. Ist die serielle Schnittstelle wirklich komplett frei, also läuft da kein getty und der Kernel benutzt sie auch nicht, um evtl. Konsolenausgaben auszugeben (und andere Software auch nicht)?

Gibt's noch weitere Möglichkeiten die ich probieren kann?

Was sagt denn:

Code Auswählen Erweitern


sudo lsof /dev/ttyAMA0


(Noch ne Frage zum Reset: muss ich jedes Mal den GPIO 18 neu "exportieren" und die Signalrichtung angeben oder reicht es den Reset-Befehl zu senden?

Ich bin mir nicht sicher, was das überhaupt bringt...
Da sollte sich bei allen Kommandos nichts am Signalpegel auf dem Pin ändern.

Um ihn wirklich zu toggeln müsstest Du folgendes machen (nach einmaligem export):

Code Auswählen Erweitern


echo 0 >/sys/class/gpio/gpio18/value
sleep 0.2
echo 1 >/sys/class/gpio/gpio18/value


Geht das nicht auch mit dem Netfinder von EQ3?

Nein, damit kann man nicht die Coprozessorfirmware (die hier anscheinend das Problem ist) updaten, nur die LAN-Firmware.

vielleicht bekommt er das seriell einfach mitgeteilt

Genau so ist es.

Viele Grüße
  Michael

[VB90]

Guten Morgen,

auch ich gehöre nun zu den Nutzern des Moduls.
Großes Dankeschön für eure Arbeit hier!!

Nachdem ich das Funkmodul zusammengebaut und auf den raspberry gesteckt habe, wurde die neuste Firmware geflasht. soweit alles gut.
Suche jetzt noch ein ungenutztes HM-Device zum testen.

Langfristig möchte auch ich den raspberry als zweite CCU nutzen und mit meinem vorhanden LAN-GW eine VCCU erstellen.

Erste Tests mit FHEM2FHEM waren Fehlschläge, wobei ich das eher mit meinem Unvermögen in Zusammenhang bringe.

Da ich nicht der einzige bin, der einen raspberry mit Modul quasi remote nutzen will, die Diskussion darum hier aber gern ein wenig untergeht, habe ich mal einen separaten Thread zum Thema eröffnet und hoffe auch dort auf rege Beteiligung.

https://forum.fhem.de/index.php/topic,56113.0.html

vb

[eldrik]

@Michael

ich nutze neben einem Raspberrry mit HMUART Modul derzeit testweise einen HMUART an einem USBtoTTL Adapter (angeschlossene Pins, 3,3V, GND, TX, RX), der Betrieb scheint soweit auch stabil und das Flashen auf 1.4.1 bereitete soweit auch keine Probleme, doch scheint es ab und an bei der USBtoTTL Variante zu einem "did not respond" zu kommen:

Code Auswählen Erweitern

2016.07.29 10:57:25.794 1: HMUARTLGW myHmUART did not respond, reopening
2016.07.29 10:57:25.795 1: HMUARTLGW myHmUART Reopen
2016.07.29 10:57:25.950 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.07.29 10:57:25.964 1: /dev/ttyUSB1 reappeared (myHmUART)
2016.07.29 10:57:26.977 3: HMUARTLGW myHmUART currently running Co_CPU_App


Welche Gründe könnte es hierfür geben?

Greetz
Eldrik

[betateilchen]

Welche Gründe könnte es hierfür geben?

Probleme direkt am USB port, die üblichen Spannungsversorgungsthemen.

[wiewaldi]

Hallo Michael,

Vielen Dank für die Rückmeldung.

Ich habe die Updates beim Funk-Lan-Gateway durchgeführt, bin jetzt auf Firmware 1.15 aber immer noch das gleiche Problem

im Cond:  immer wieder init,disconnect,init,disconnect.......

Im Log auch noch das gleiche:

Code Auswählen Erweitern



2016.07.29 16:15:56 3: HMUARTLGW myHmLGW:keepAlive KeepAlive-port opened
2016.07.29 16:15:57 4: HMUARTLGW myHmLGW StartInit
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW send: 00 00
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW send: (8): fd0003009200f409
2016.07.29 16:15:57 5: SW: fd0003009200f409
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW read raw (18): fd000d00920402436f5f4350555f424c87c1
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW read (17): fd000d00920402436f5f4350555f424c87c1 crc OK
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW recv: 00 0402436F5F4350555F424C, state 1
2016.07.29 16:15:57 3: HMUARTLGW myHmLGW currently running Co_CPU_BL
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW send: 00 03
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW send: (8): fd00030093037200
2016.07.29 16:15:57 5: SW: fd00030093037200
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW read raw (9): fd0004009304001244
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW read (8): fd0004009304001244 crc OK
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW recv: 00 0400, state 2
2016.07.29 16:15:57 1: HMUARTLGW myHmLGW application switch failed, application-firmware probably corrupted!
2016.07.29 16:15:57 1: HMUARTLGW myHmLGW Reopen
2016.07.29 16:15:57 3: Opening myHmLGW:keepAlive device 192.168.0.34:2001
2016.07.29 16:15:57 3: myHmLGW:keepAlive device opened
2016.07.29 16:15:57 1: 192.168.0.34:2000 reappeared (myHmLGW)
2016.07.29 16:15:57 3: HMUARTLGW myHmLGW:keepAlive KeepAlive-port opened
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW read raw (61): 4839312c30312c6551332d484d2d4c47572c312e312e352c4b4551313036343839330d0a5339322c426964436f532d6f7665722d4c414e2d312e300d0a
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW read (34): H91,01,eQ3-HM-LGW,1.1.5,KEQ1064893
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW read (23): S92,BidCoS-over-LAN-1.0
2016.07.29 16:15:57 3: HMUARTLGW myHmLGW BidCoS-port opened
2016.07.29 16:15:57 5: HMUARTLGW myHmLGW send (10): >92,0000
2016.07.29 16:15:57 5: SW: >92,0000

2016.07.29 16:15:58 4: HMUARTLGW myHmLGW StartInit
2016.07.29 16:15:58 5: HMUARTLGW myHmLGW send: 00 00
2016.07.29 16:15:58 5: HMUARTLGW myHmLGW send: (8): fd0003009400e009
2016.07.29 16:15:58 5: SW: fd0003009400e009
2016.07.29 16:15:58 5: HMUARTLGW myHmLGW read raw (18): fd000d00940402436f5f4350555f424c86c0
2016.07.29 16:15:58 5: HMUARTLGW myHmLGW read (17): fd000d00940402436f5f4350555f424c86c0 crc OK
2016.07.29 16:15:58 5: HMUARTLGW myHmLGW recv: 00 0402436F5F4350555F424C, state 1
2016.07.29 16:15:58 3: HMUARTLGW myHmLGW currently running Co_CPU_BL
2016.07.29 16:15:58 5: HMUARTLGW myHmLGW send: 00 03
2016.07.29 16:15:58 5: HMUARTLGW myHmLGW send: (8): fd00030095036600
2016.07.29 16:15:58 5: SW: fd00030095036600




Was mir aufgefallen ist das bei dir im Update der Applikationsfirmware "Coprocessor is in application" ausgegeben wird.

Code Auswählen Erweitern


2016/07/28 09:33:07.516 <Debug> (NEQ0218723) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in application.


Bei mir steht:

Code Auswählen Erweitern


2016/07/29 16:07:18.177 <Debug> (KEQ1064893) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in bootloader.
2016/07/29 16:07:18.177 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/29 16:07:18.177 <Debug> CCU2CoprocessorCommandMod::isResponseStatusOk(): System status OK
2016/07/29 16:07:18.177 <Debug> CCU2CommControllerMod::handleIncomingResponse() System response OK
2016/07/29 16:07:18.177 <Debug> (KEQ1064893) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in bootloader.
2016/07/29 16:07:18.195 <Debug>  deliver firmware...



Könnte hier das Problem sein?

Gruß
wiewaldi

[frank]

es gibt ja auch schon 2 modelle des LGW. die neuere hat eine "-2" am modelnamen.
vielleicht liegt es an den unterschiedlichen modellen. wer hat denn welches?

[wiewaldi]

Hallo Frank,

Ich habe die Version ohne 2 also

"HM-LGW-O-TW-W-EU"

/wiewaldi

[raspberry]

Dann stimmt irgendwas anderes noch nicht. Ist die serielle Schnittstelle wirklich komplett frei, also läuft da kein getty und der Kernel benutzt sie auch nicht, um evtl. Konsolenausgaben auszugeben (und andere Software auch nicht)?

Habe sonst nichts anderes am Laufen. Getty ist wie nach Anleitung für ttyAMA0 deaktiviert.

Was sagt denn:

Code Auswählen Erweitern


sudo lsof /dev/ttyAMA0


Code Auswählen Erweitern


COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
perl    1141 fhem   14u   CHR 204,64      0t0 1026 /dev/ttyAMA0

Da scheint sonst nicht zu laufen.

Um ihn wirklich zu toggeln müsstest Du folgendes machen (nach einmaligem export):

Code Auswählen Erweitern


echo 0 >/sys/class/gpio/gpio18/value
sleep 0.2
echo 1 >/sys/class/gpio/gpio18/value


Auch damit bekomme ich das Modul nicht zuverlässiger zum Laufen.

Kann es sein, dass es sich um ein Hardwareproblem handelt? Einfach mal ein neues bestellen?

Noch eine andere Frage. Wenn das Ding mal läuft bekomme ich von einem HM Sensor folgende Log.

Code Auswählen Erweitern


HM_4C1DDD trigDst_925137: noConfig

"set <HM-Gerät> getConfig" habe ich schon laufen lassen, hat aber nichts geholfen. Oder ist das gar kein Fehler?

Besten Dank!

Euch allen eine gutes Wochenende!

Schöne Grüße

raspberry

[amunra]

HMUARTLGW-USB - sogar kompakter als der HM-CFG-USB2  , und hoffentlich genauso zuverlässig.

[mgernoth]

Hallo,

Ich habe die Updates beim Funk-Lan-Gateway durchgeführt, bin jetzt auf Firmware 1.15 aber immer noch das gleiche Problem

Hmm,  er will immer noch nicht in die Applikation schalten...

Code Auswählen Erweitern


2016.07.29 16:15:57 1: HMUARTLGW myHmLGW application switch failed, application-firmware probably corrupted!


Was mir aufgefallen ist das bei dir im Update der Applikationsfirmware "Coprocessor is in application" ausgegeben wird.

Ja, da bei mir die Applikationsfirmware in Ordnung war und das LGW lief.

Bei mir steht:

Code Auswählen Erweitern


2016/07/29 16:07:18.177 <Debug> (KEQ1064893) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in bootloader.


Ist ok so.
Ist das flashen dann erfolgreich weitergelaufen?
Evtl. ist das Ding auch einfach defekt....

Kann es sein, dass es sich um ein Hardwareproblem handelt? Einfach mal ein neues bestellen?

Ja, ist moeglich. Auch mal alle Loetstellen kontrolliert?

Noch eine andere Frage. Wenn das Ding mal läuft bekomme ich von einem HM Sensor folgende Log.

Code Auswählen Erweitern


HM_4C1DDD trigDst_925137: noConfig

"set <HM-Gerät> getConfig" habe ich schon laufen lassen, hat aber nichts geholfen. Oder ist das gar kein Fehler?

Ist kein Fehler.

Viele Gruesse
  Michael, der jetzt dann eine Woche weg ist...