Neue Firmware für HM_LC_Sw1PBU_FM mit getrenntem Aktor, Taster + Wechselschalter

[jab]

Moin,

KEQ0123456 sollte gehen. So wie ich es dokumentiert habe. Die ist hardcoded aktuell. Der flasher flash-ota erwartet als erstes Zeichen auch immer ein K. Daher ging mein CUS nicht (wie im Kommentar). Die HMID ist egal. Zumindest flash-ota nimmt einfach die die das Gerät sendet. Ob sie später anders ist interessiert nicht. Das Windowstool wäre zu testen.

Hast du auf den seriellen Output geguckt? Sind die Fuses gesetzt? Die Status LED muss beim starten des Bootloaders einmal blinken. Ansonsten ist er nicht richtig geflashed. Alternativ müsste FHEM auch die Message sniffen können, wenn sich der Bootloader meldet.


Gruß,
Jan

[peterk_de]

Ja, auch KEQ0123456 geht leider weder mit flash-ota noch mit dem Windowstool (habe ich sicherheitshalber immer noch mal damit probiert, da mein Raspberry immer mal wieder zu hohe USB-Latenzen meldet). Die Firmware frisst das Windows Tool übrigens anstandslos; flash-ota erkennt das konvertierte eq3-File als eine Firmware mit 80 Blöcken. Die Fuses habe ich vorher mit AVR-Dude gesetzt und das hat lt. Ausgabe geklappt. Ich habe während des OTA-Flashens den Schalter auch jeweils mehrfach ein- und ausgesteckt (230V), bzw. mal erst in den Strom gesteckt und umgekehrt, das hat nix gebracht. LED blinkt so wie sie soll, wenn ich mir den Source richtig verstanden habe - geht nach dem reinstecken kurz an und blinkt dann periodisch (4-5 Sekunden) kurz auf, d.h. das Bootloader-Programm startet von vorn.

Das mit dem mitsniffen werde ich heute abend mal probieren, ansonsten löte ich dann auch mal die UARTs dran.

[peterk_de]

Ich hab jetzt mal mit hmsniff geloggt, nix was auch nur ansatzweise nach der Update-Init-Nachricht aussieht - naja ... dann wird nochmal der Lötkolben geschwungen.

[peterk_de]

UART sagt:


Timeout reached. Starting application!
Sending bootloader sequence
Timeout reached. Starting application!
Sending bootloader sequence
Timeout reached. Starting application!

Usw.

hmsniff parallel empfängt nix von ABCDEF. Ist mein Funkmodul kaputt? Mit der Originalfirmware lief er aber eigentlich super ... hrm ... ich flash nochmal direkt deine Firmware drauf.

Edit: Muss ich die Fuses dazu wieder irgendwie zurückstellen?

Edit2: Nö die alternative Firmware von dir scheint, direkt geflasht, nach wie vor gut zu funzen und der Funk geht bestens.

[jab]

Spannend. Das ist mehr oder weniger der gleiche Code. Welche GCC Version hast du denn? Ggf ist da irgendwas mit den Timings nicht perfekt in der Klasse. Das Problem hatten leider schon ein paar andere. Ich hänge mal meine hex vom Bootloader an. Vielleicht geht die bei dir.


Gruß,
Jan

[peterk_de]

Fuses gesetzt, dein Bootloader-Hexfile draufgezogen - dasselbe. Ich habe eben einmal einen ganz frischen Raspberry mit Debian Wheezy aufgesetzt um es sowas wie reproduzieren zu können ...

Code Auswählen Erweitern


pi@raspberrypi ~ $ gcc --version
gcc (Debian 4.6.3-14+rpi1) 4.6.3

pi@raspberrypi ~ $ sudo avrdude -p m644 -c linuxspi -P /dev/spidev0.0 -U lfuse:w:0xFD:m -U hfuse:w:0xD8:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9609
avrdude: reading input file "0xFD"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFD:
avrdude: load data lfuse data from input file 0xFD:
avrdude: input file 0xFD contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xD8"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xD8:
avrdude: load data hfuse data from input file 0xD8:
avrdude: input file 0xD8 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified

avrdude: safemode: Fuses OK (E:FD, H:D8, L:FD)

avrdude done.  Thank you.

pi@raspberrypi ~ $ sudo avrdude -p m644 -c linuxspi -P /dev/spidev0.0 -U flash:w:bootloader-jab.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9609
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "bootloader-jab.hex"
avrdude: input file bootloader-jab.hex auto detected as Intel Hex
avrdude: writing flash (61372 bytes):

Writing | ################################################## | 100% 1.37s

avrdude: 61372 bytes of flash written
avrdude: verifying flash memory against bootloader-jab.hex:
avrdude: load data flash data from input file bootloader-jab.hex:
avrdude: input file bootloader-jab.hex auto detected as Intel Hex
avrdude: input file bootloader-jab.hex contains 61372 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.26s

avrdude: verifying ...
avrdude: 61372 bytes of flash verified

avrdude: safemode: Fuses OK (E:FD, H:D8, L:FD)

avrdude done.  Thank you.



Sniffing mach ich mit hmsniff (hmland checkout von heute) am selben Raspberry (HM-USB-CFG-2 am Raspi). Da sehe ich meinen gesamten Homematic-Zoo, aber halt eben nicht die ersehnte init-Nachricht. Seufz. Ideen die ich noch probieren könnte:

- Ablöten + Test mit 230V (3,3V des Raspberrys vllt nicht stabil genug? Andererseits quatsch, mit der Schalterfirmware gehts ja auch...)
- Sniffing mit meinem irgendwo vergabenem SDR-DVB-T-Stick, ob überhaupt irgendwas gesendet wird (das müsst ich dann aber wohl mal in einer Homematic-unverseuchten Umgebung tun)

LG Peter

[peterk_de]

Nachtrag - mit deinem hex-File empfängt er aber wohl jetzt mal was:

Code Auswählen Erweitern



pi@raspberrypi ~ $ minicom -b 57600 -o -D /dev/ttyAMA0 -w

Got data but not for us
Timeout reached. Starting application!
Sending bootloader sequence
Timeout reached. Starting application!
Sending bootloader sequence
Got data but not for us
Timeout reached. Starting application!
Sending bootloader sequence
Timeout reached. Starting application!
Sending bootloader sequence
Timeout reached. Starting application!
Sending bootloader sequence
Got data but not for us


"Got data but not for us" kam mit meinem selbstcompilierten hex-File nie obwohl ichs bestimmt ne Viertelstunde an der selben Stelle mit dem selben umgebenden Homematic-Geräten am Laufen hatte.

[jab]

Na dann sollte er auch flashen. Stange die Sache mit dem Compiler.


Gruß
Jan

[peterk_de]

Es geschehen noch zeichen und wunder ... du glaubst nicht woran es liegt ... ich habe den Abstand der beiden (HM-CFG und Aktor) mal erhöht und siehe da:

Code Auswählen Erweitern


pi@raspberrypi ~/hmcfgusb $ sudo ./flash-ota -f ../Asksin_HM_LC_Sw1PBU_FM.cpp.eq3 -s KEQ0123456
HomeMatic OTA flasher version 0.096-git

Reading firmware from ../Asksin_HM_LC_Sw1PBU_FM.cpp.eq3...
Firmware with 80 blocks successfully read.

Rebooting HM-CFG-USB to avoid running out of credits

HM-CFG-USB not in bootloader mode, entering bootloader.
Waiting for device to reappear...
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB in bootloader mode, rebooting
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!


HM-CFG-USB opened

HM-CFG-USB firmware version: 967
Entering 10k-mode
Waiting for device with serial KEQ0123456
Device with serial KEQ0123456 (hmid: abcdef) entered firmware-update-mode
Adding HMID
usb-transfer took more than 100ms (721ms), this may lead to timing problems!
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 80 blocks: 0001/0080 /
Missing ACK!
Flashing 80 blocks: 0001/0080 /
Missing ACK!
Flashing 80 blocks: 0001/0080 /
Missing ACK!
Flashing 80 blocks: 0001/0080 /
Missing ACK!
Flashing 80 blocks: 0001/0080 /
Missing ACK!

Too many errors, giving up!


Das krieg ich jetzt auch noch ganz zum fliegen

Edit: Flash done!! Sehr geil. Für alle die ähnliche Probleme haben: Zu nah sollte das zeug nicht nebeneinander liegen. Argh. steht ja auch bei jedem Homematicgerät in der Anleitung.

[peterk_de]

Einmal fürs Protokoll: Flashen mit dem Windowstool, einem HM-CFG-USB-2 und dem Bootloader auf dem Aktor, den jab gestern gepostet hat, klappt auch prima! Und einmal flashen überschreibt auch den bootloader nicht, d.h. nach einem Powercycle kann man wieder neu flashen. Funktioniert also perfekt Die tar.gz Datei mit einem aktuellen Build, die ich für das Windowstool gebastelt habe, habe ich einmal angehängt, falls es wer braucht.

Jetzt muss ich das Ding nur noch in FHEM zum laufen bekommen, aktuell hängt es sich mit der 99 ... .pm Datei für den Aktor aus github sofort auf - aber ich suche noch nach der Ursache.

Edit: Ein update von fhem hats gefixt, jetzt klappt alles. Danke nochmal an alle beteiligten!

[peterk_de]

OK leider doch nicht ganz:

- Wenn ich die Anlernentaste am geflashten aktor drücke, legt autocreate das Device korrekt mit allen Kanälen an.
- Wenn ich allerdings (danach) das pairen versuche, schmiert FHEM komplett ab, in der Konsole steht:

Can't use string ("CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_"...) as an ARRAY ref while "strict refs" in use at ./FHEM/10_CUL_HM.pm line 2447.

Nach einem manuellen neustarten von FHEM ist das Device dann nur noch verkrüppelt da:

fhem.cfg danach:

define CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2725C4 CUL_HM 2725C4
attr CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2725C4 room CUL_HM

regList:

list:         register | range              | peer     | description
   0: pairCentral      |   0 to 16777215    |          | pairing to central

Ist das bekannt?

[jab]

Abend,
Vermutlich hat sich in FHEM was geändert. Kann Martin vielleicht was zu sagen. Ich teste das sonst wenn Ende der Woche mein neuer stick da ist.

Das mit dem Windows Tool ist ja cool. Vielleicht können wir das Makefile erweitern damit er direkt das tar.gz ausspuckt.

Ich muss auf jeden Fall noch mal schauen woran das mit dem Funk und den gcc Versionen liegt. Culfw muss das Problem ja auch gelöst haben.


Gruß
Jan

[peterk_de]

Hilft dir vllt. mein nicht funktionierender Bootloader dabei? Er ist ca. 400 Byte kleiner als deiner.

[ChristianK.]

Hallo,

ich bin gestern auch einmal in die Einbahnstraße abgebogen, allerdings wenn ich  autocreate einschalte und versuche zu pairen
geht mein FHEM in die Knie... nach einem reboot habe ich folgendes in der FHEM.cfg

Code Auswählen Erweitern

define CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2727B3 CUL_HM 2727B3
attr CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2727B3 IODev CUL_1
attr CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2727B3 autoReadReg 4_reqStatus
attr CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2727B3 expert 2_full
attr CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2727B3 peerIDs
attr CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2727B3 room Wohnzimmer

folgende Einträge befinden sich dann im LOG:

Code Auswählen Erweitern

2014.04.13 09:07:14 4: CUL_Parse: CUL_1 A 0E E3 A410 2727B3 F11234 06040000002B -52.5
2014.04.13 09:07:15 4: CUL_send:  CUL_1As 0A E3 8002 F11234 2727B3 00
2014.04.13 09:07:15 1: readingsUpdate(,level,0 %) missed to call readingsBeginUpdate first.
2014.04.13 09:07:15 1: readingsUpdate(,pct,0) missed to call readingsBeginUpdate first.
2014.04.13 09:07:15 1: readingsUpdate(,deviceMsg,off (to CUL_1)) missed to call readingsBeginUpdate first.
2014.04.13 09:07:15 1: readingsUpdate(,state,off) missed to call readingsBeginUpdate first.
2014.04.13 09:07:15 1: readingsUpdate(,timedOn,off) missed to call readingsBeginUpdate first.
2014.04.13 09:07:15 4: CUL_Parse: CUL_1 A 14 E4 805E 2727B3 F11234 000000000000008F0000002A -53
2014.04.13 09:07:15 1: readingsUpdate(,current,143) missed to call readingsBeginUpdate first.
2014.04.13 09:07:15 4: CUL_Parse: CUL_1 A 0E E5 A410 2727B3 F11234 060400000029 -53.5
2014.04.13 09:07:15 4: CUL_send:  CUL_1As 0A E5 8002 F11234 2727B3 00
2014.04.13 09:07:15 1: readingsUpdate(,level,0 %) missed to call readingsBeginUpdate first.
2014.04.13 09:07:15 1: readingsUpdate(,pct,0) missed to call readingsBeginUpdate first.
2014.04.13 09:07:15 1: readingsUpdate(,deviceMsg,off (to CUL_1)) missed to call readingsBeginUpdate first.
2014.04.13 09:07:15 1: readingsUpdate(,state,off) missed to call readingsBeginUpdate first.
2014.04.13 09:07:15 1: readingsUpdate(,timedOn,off) missed to call readingsBeginUpdate first.
das geht dann so lange bis ich fhem neu starte...

Woher kann das kommen? Fehler beim flashen?

Christian

[peterk_de]

Nee ich glaube das ist aktuell noch ein Bug, das Pairen hat bei mir auch nur extrem widerwillig funktioniert. Ich kann leider nicht mehr genau reproduzieren wie ich es hinbekommen habe, es war mit diversen Anläufen verbunden und man musste den geflashten Schalter erst per Autocreate anlegen lassen (Anlerntaste drücken, ohne HMLAN im Pair-Modus, dann sind erstmal alle 4 Kanäle da) dann die FHEM-Config speichern und danach dann erst Pairen - dabei stürzte er mir n paar mal ab aber irgendwann ging es. Allerdings sieht deine Fehlermeldung etwas anders aus als es meine sah.

Jetzt ist aktuell bei mir nur noch die sekündliche Nachricht ein Problem, wenn in einer Wechselschaltung die Lampe aus ist (hat schon jemand anderes weiter oben gepostet). Vom Prinzip her solltest du dann aber schonmal schalten können.