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

[mmattern]

Hallo,

Nachdem ich das Ganze mit meinem Raspberry gemacht habe, musste ich erst noch eine angepasste Version vom avrdude installieren, da es mit der aus dem Raspbian-Repository nicht funktioniert. Und dann hatte ich das große Glück, eine Version zu erwischen, bei dem die GPIO-PINs im avrdude anders definiert waren, als scheinbar bei den meisten anderen Versionen. Dadurch konnte nach dem Flashen kein Reset gemacht werden und ja... wo kein Reset, da auch keine Erfolg.

wie ist der Programmer "gpio" in deiner avrdude.conf denn jetzt definiert?

Unter https://owncloud.isengard.at/public.php?service=files&t=0df535e31ad6999664f0e84c95bd2ea5
gibt es eine, in der folgende Konfiguration angegeben ist:
"
#
#This programmer bitbangs GPIO lines using the Linux sysfs GPIO interface

#
#Set the configuration below to match the GPIO lines connected to the
#relevant ISP header pin. max GPIO number is 255, defined in gpio.c
#
# gordon@drogon.net:
#   Defaults changed to use the SPI port on Raspberry Pi
programmer  id    = "gpio";
desc  = "Use sysfs interface to bitbang GPIO lines";
type  = gpio;
reset = 8;
sck   = 11;
mosi  = 10;
miso  = 9; 

;
"?

Ist das die richtige?

Vielen Dank & beste Grüße
Michael

[Mr. P]

Hej Michael,

die Konfiguration in dem File entspricht derselben, die auch im FHEMWiki angegeben ist.
Ist also die Richtige, ja.

Wenn du noch Fragen hast... ich bin sicherlich noch eine Stunde "greifbar".

[mmattern]

Hallo Gemeinde,

ich glaube ich komme meinem Problem näher um mit etwas mit zu loggen.

Ich glaube die Serielle Schnittstelle ist bei mir nicht online. Wie kann ich feststellen das sie genutzt wird bzw. sie nutzen.

[...]

Hi nephdrasil,

hast du es eigentlich noch hinbekommen? Ich habe exakt dasselbe Problem... sehe keinerlei Debug-Messages über den Raspberry-UART...

Viele Grüße
Michael

[Mr. P]

hast du es eigentlich noch hinbekommen? Ich habe exakt dasselbe Problem... sehe keinerlei Debug-Messages über den Raspberry-UART...

Ihr wisst aber schon, dass die serielle Ausgabe am Schalter seit einem Monat per Default deaktiviert ist und erst in der Register.h von der Firmware einkommentiert und somit das FW-File neu gebaut werden muss?

Code Auswählen Erweitern

-//#define USE_SERIAL
+#define USE_SERIAL

[mmattern]

Ihr wisst aber schon, dass die serielle Ausgabe am Schalter seit einem Monat per Default deaktiviert ist und erst in der Register.h von der Firmware einkommentiert und somit das FW-File neu gebaut werden muss?

Code Auswählen Erweitern

-//#define USE_SERIAL
+#define USE_SERIAL

Hallo Mr. P,

vielen Dank für den Hinweis, das hatte ich tatsächlich nicht gesehen... hat aber leider auch nicht zum Erfolg geführt.

Der Bootloader ist davon aber auch unabhängig, oder?

Ich habe jetzt mehrere Varianten probiert:
A)
(1) Bootloader von https://owncloud.isengard.at/public.php?service=files&t=0df535e31ad6999664f0e84c95bd2ea5 mit avrdude geflashed (Fuses: avrdude -p m644 -P gpio -c gpio -U lfuse:w:0xFD:m -U hfuse:w:0xD8:m dann avrdude -p m644 -P gpio -c gpio -U flash:w:bootloader_HM-LC-Sw1PBU-FM.hex)
-> Ergebnis: Device zeigt über Blinken Einstieg in den Bootloader an; aber keine Meldungen über UART
(2) dann mittels flash-ota aus hmland (mit HM-CFG-USB an zweitem Raspberry) die Firmware von https://owncloud.isengard.at/public.php?service=files&t=0df535e31ad6999664f0e84c95bd2ea5 (eq3-File) eingespielt
-> Ergebnis: Der Schalter hängt immer noch im Bootloader - in regelmäßigen Abständen ca. 10 Sekunden einmaliges Blinken der LED; es ist auch ein erneutes Flashen mit flash-ota möglich, was wohl heißt, dass der Schalter immer noch die Bootloader-Sequenz schickt...
weiterhin keinerlei UART-Meldungen; auch vorübergehendes Stromlos-Schalten des Devices bringt keine Änderung

B) Firmware von https://owncloud.isengard.at/public.php?service=files&t=0df535e31ad6999664f0e84c95bd2ea5 direkt mittels avrdude auf das Device gespielt - Ergebnis: totes Device, kein Blinken bei Betätigen der Config-Taste, nichts über UART, Pairing mit FHEM weder über pairSerial noch pairForSec möglich

C) also wieder den Bootloader drauf, selbst gebaute Firmware nach Konvertierung in eq3-File mittels flash-ota auf das Device zu spielen versucht - hatte 294 Blöcke, nach 224 Blöcken wurden aber keine mer genommen... Speicher voll? Ich habe Arduino-Version 1.5.6-r2 auf Windows - welche nehmt ihr denn?
Device war dann erstmal tot, also Bootloader drauf...

D) dann mit avrdude die selbt erzeugte Firmware drauf - nichts, kein Blinken, auch Stromlos-schalten bringt nichts...

Könnt ihr vielleicht mal eine Firmware posten, die mit Serial-Debugging erzeugt wurde und bei euch funktioniert?

Vielen Dank & beste Grüße
Michael

[unimatrix]

Anhängend eine Firmware, von heutigem GIT, mit serieller Ausgabe.

Habs bei mir heute getestet und läuft.

Der Bootloader hat ja auch serielle Ausgabe (gerade ausprobiert)

Ich hatte am Anfang Probleme mit den Fuses....da liefs auch nicht. irgendwann gings dann. Wieso plötzlich, weiß ich nicht mehr.

[mmattern]

Ich hatte am Anfang Probleme mit den Fuses....da liefs auch nicht. irgendwann gings dann. Wieso plötzlich, weiß ich nicht mehr.

Hallo unimatrix,

vielen Dank - werde ich gleich mal ausprobieren!
Welche Einstellung nutzt du denn für die Fuses?

Viele Grüße
Michael

P.S.:
Welche Arduino-Version nutzt du denn?

[Mr. P]

Welche Einstellung nutzt du denn für die Fuses?

Ich vermute, unimatrix meint auch die Stelle, die ich in meinem HowTo beschrieben habe, dass beim ersten Setzen der Fuses ein Problem festgestellt wurde.

Was mir gerade noch einfällt: Hast du Reset und GND auch richtig mit dem Raspberry verbunden?
Mir ist es passiert, dass ich die beiden, aufgrund der (für mich) nicht eindeutigen Beschriftung am Schalter, vertauscht hatte. Richtig ist, wenn sowohl die 3.3V als auch GND in der selben Reihe angelötet sind. Das Problem dabei ist, dass auch im umgekehrten Fall der Schalter ein paar Lebenszeichen von sich gibt und somit gänzlich verwirrt.

[unimatrix]

Ich vermute, unimatrix meint auch die Stelle, die ich in meinem HowTo beschrieben habe, dass beim ersten Setzen der Fuses ein Problem festgestellt wurde.

Genau, bin nach deinem HowTo vorgegangen. Es kam zu dieser SafeMode Meldung. Ich habe dann geflasht und als ich später die Fuses nochmal gesetzt habe kam keine Fehlermeldung mehr.

Es sollte jedem klar sein, trotzdem hab ich mich zuerst vertan: Beim UART muss natürlich RxD mit TxD verbunden werden...beim lesen des Howtos hatte ich zuerst verstanden Pin XXX "an RxD" und nicht Pin XXX "ist RxD" und muss dementsprechend beim Pi an TxD...

habe den Pi UART einfach mit "screen /dev/ttyAMA0 57600" benutzt und das lief dann einwandfrei (allerdings fehlende CRs in der Ausgabe)

[mmattern]

Ich vermute, unimatrix meint auch die Stelle, die ich in meinem HowTo beschrieben habe, dass beim ersten Setzen der Fuses ein Problem festgestellt wurde.

Was mir gerade noch einfällt: Hast du Reset und GND auch richtig mit dem Raspberry verbunden?
Mir ist es passiert, dass ich die beiden, aufgrund der (für mich) nicht eindeutigen Beschriftung am Schalter, vertauscht hatte. Richtig ist, wenn sowohl die 3.3V als auch GND in der selben Reihe angelötet sind. Das Problem dabei ist, dass auch im umgekehrten Fall der Schalter ein paar Lebenszeichen von sich gibt und somit gänzlich verwirrt.

Hallo Mr. P,

merci - GND und Reset sollten korrekt sein - ich habe mal im Attachment das ISP-Foto von https://github.com/jabdoa2/Asksin_HM_LC_Sw1PBU_FM mit Beschriftung versehen angehängt (so wie ich es verlötet habe)... so ist es korrekt, oder?

Wegen Fuses:
Laut howto.txt von https://owncloud.isengard.at/public.php?service=files&t=0df535e31ad6999664f0e84c95bd2ea5 soll Low-Fuse auf FD und High-Fuse auf D8 stehen. Ursprünglich ist Low-Fuse wohl auf FF (was avrdude auch anmerkt). Auf jeden Fall funktioniert es nicht mit High-Fuse FF, sondern nur FD (laut http://www.engbedded.com/fusecalc/ wird mit Fuse-Setting FD der externe Takt auf 3.0-8.0 MHz gesetzt mit Startup Time 65ms, FF bedeutet Frequenz 8.0 Mhz und aufwärts.

Viele Grüße
Michael

[mmattern]

Ihr wisst aber schon, dass die serielle Ausgabe am Schalter seit einem Monat per Default deaktiviert ist und erst in der Register.h von der Firmware einkommentiert und somit das FW-File neu gebaut werden muss?

Code Auswählen Erweitern

-//#define USE_SERIAL
+#define USE_SERIAL

Hallo zusammen,

peinlich, aber ich poste es mal, falls jemand anders drüber stolpert - natürlich muss MP10 (Debug-TX) mit dem *RX* des Raspberry und MP9 (Debug-RX) mit dem *TX* des Raspberry verbunden werden...

[mmattern]

Hallo zusammen,

so, mittlerweile funktioniert einiges mehr...
Firmware bauen mit Arduino 1.0.5-r2, Flashen, serielle Debug-Meldungen auslesen...

Aufgefallen ist mir noch, dass Firmwares mit mehr als 224 Blöcken sich nicht OTA flashen lassen - ab Block 225 gibt es keine ACKs mehr, auch nicht, wenn man MAX_RETRIES in flash-ota.c z.B. auf 100 setzt... dabei sollte eigentlich noch Platz sein (atmega644a hat 64k programmierbaren Flash-Speicher, Bootloader nimmt ca. 12k und eine Firmware mit allen aktivierten Debug-Settings liefert Sketchgröße von 33.914 Bytes kompiliert... das sind aber mehr als 300 Blöcke und lässt sich dann nur noch per avrdude direkt flashen... Auskommentieren von USE_SERIAL verringert die Größe auf genau 224 Blöcke).
Beobachtet ihr das gleiche Verhalten?

Nun gut, also erstmal mit der direkt geflashten Firmware versucht mit FHEM zu pairen... per Config-Button ging es nicht, "p" per serieller Konsole hat zunächst dazu geführt, dass FHEM ein Device erkannt und autokonfiguriert hat.
Das war aber leider auch schon fast alles... testweises "on/off"-Setzen der Switches per WebCmd funktioniert nicht, das Log ist voll von Messages wie

Code Auswählen Erweitern

2014.06.23 13:49:42.367 3: CUL_HM set CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2A32E7_Sw_01 statusRequest
2014.06.23 13:49:42.536 3: HMLAN1: Unknown code A0B01E00126EC1A2A32E7030E::-72:HMLAN1, help me!
2014.06.23 13:49:42.666 3: HMLAN1: Unknown code A0B01E00126EC1A2A32E7030E::-72:HMLAN1, help me!
2014.06.23 13:49:42.866 3: HMLAN1: Unknown code A0B01E00126EC1A2A32E7030E::-72:HMLAN1, help me!
2014.06.23 13:49:43.382 3: CUL_HM set CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2A32E7_Sw_02 statusRequest
2014.06.23 13:49:47.033 3: HMLAN1: Unknown code A0B01E00126EC1A2A32E7030E::-71:HMLAN1, help me!
2014.06.23 13:49:47.231 3: HMLAN1: Unknown code A0B01E00126EC1A2A32E7030E::-72:HMLAN1, help me!
2014.06.23 13:49:47.431 3: HMLAN1: Unknown code A0B01E00126EC1A2A32E7030E::-72:HMLAN1, help me!
2014.06.23 13:49:51.248 3: HMLAN1: Unknown code A0B01E00126EC1A2A32E7030E::-73:HMLAN1, help me!
2014.06.23 13:49:51.446 3: HMLAN1: Unknown code A0B01E00126EC1A2A32E7030E::-74:HMLAN1, help me!
2014.06.23 13:49:51.646 3: HMLAN1: Unknown code A0B01E00126EC1A2A32E7030E::-74:HMLAN1, help me!
2014.06.23 13:49:56.321 3: HMLAN1: Unknown code A0B01E00126EC1A2A32E7030E::-71:HMLAN1, help me!
2014.06.23 13:49:56.519 3: HMLAN1: Unknown code A0B01E00126EC1A2A32E7030E::-72:HMLAN1, help me!
2014.06.23 13:49:56.721 3: HMLAN1: Unknown code A0B01E00126EC1A2A32E7030E::-72:HMLAN1, help me!
2014.06.23 13:50:03.455 3: CUL_HM set CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2A32E7 getConfig
2014.06.23 13:50:03.558 3: HMLAN1: Unknown code A1002E00126EC1A2A32E700040000000000::-71:HMLAN1, help me!
2014.06.23 13:50:03.759 3: HMLAN1: Unknown code A1002E00126EC1A2A32E700040000000000::-71:HMLAN1, help me!
2014.06.23 13:50:03.958 3: HMLAN1: Unknown code A1002E00126EC1A2A32E700040000000000::-71:HMLAN1, help me!
2014.06.23 13:50:08.379 3: HMLAN1: Unknown code A1002E00126EC1A2A32E700040000000000::-71:HMLAN1, help me!
2014.06.23 13:50:08.579 3: HMLAN1: Unknown code A1002E00126EC1A2A32E700040000000000::-72:HMLAN1, help me!
2014.06.23 13:50:08.793 3: HMLAN1: Unknown code A1002E00126EC1A2A32E700040000000000::-71:HMLAN1, help me!
2014.06.23 13:50:12.719 3: HMLAN1: Unknown code A1002E00126EC1A2A32E700040000000000::-72:HMLAN1, help me!
2014.06.23 13:50:12.918 3: HMLAN1: Unknown code A1002E00126EC1A2A32E700040000000000::-72:HMLAN1, help me!
2014.06.23 13:50:13.117 3: HMLAN1: Unknown code A1002E00126EC1A2A32E700040000000000::-72:HMLAN1, help me!
2014.06.23 13:50:17.266 3: HMLAN1: Unknown code A1002E00126EC1A2A32E700040000000000::-74:HMLAN1, help me!
2014.06.23 13:50:17.467 3: HMLAN1: Unknown code A1002E00126EC1A2A32E700040000000000::-72:HMLAN1, help me!
2014.06.23 13:50:17.667 3: HMLAN1: Unknown code A1002E00126EC1A2A32E700040000000000::-72:HMLAN1, help me!
2014.06.23 13:50:31.985 3: CUL_HM set CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2A32E7_Sw_01 off
2014.06.23 13:50:32.088 3: HMLAN1: Unknown code A0E03E01126EC1A2A32E70203000000::-72:HMLAN1, help me!
2014.06.23 13:50:32.308 3: HMLAN1: Unknown code A0E03E01126EC1A2A32E70203000000::-72:HMLAN1, help me!
2014.06.23 13:50:32.486 3: HMLAN1: Unknown code A0E03E01126EC1A2A32E70203000000::-72:HMLAN1, help me!
2014.06.23 13:50:33.785 3: HMLAN1: Unknown code A0E03E01126EC1A2A32E70203000000::-72:HMLAN1, help me!
2014.06.23 13:50:33.983 3: HMLAN1: Unknown code A0E03E01126EC1A2A32E70203000000::-72:HMLAN1, help me!
2014.06.23 13:50:34.183 3: HMLAN1: Unknown code A0E03E01126EC1A2A32E70203000000::-72:HMLAN1, help me!
2014.06.23 13:50:36.281 3: CUL_HM set CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2A32E7_Sw_01 on
2014.06.23 13:50:37.931 3: HMLAN1: Unknown code A0E03E01126EC1A2A32E70203000000::-71:HMLAN1, help me!
2014.06.23 13:50:38.153 3: HMLAN1: Unknown code A0E03E01126EC1A2A32E70203000000::-71:HMLAN1, help me!
2014.06.23 13:50:38.331 3: HMLAN1: Unknown code A0E03E01126EC1A2A32E70203000000::-72:HMLAN1, help me!
2014.06.23 13:50:43.341 3: HMLAN1: Unknown code A0E03E01126EC1A2A32E70203000000::-72:HMLAN1, help me!
2014.06.23 13:50:43.540 3: HMLAN1: Unknown code A0E03E01126EC1A2A32E70203000000::-72:HMLAN1, help me!
2014.06.23 13:50:43.740 3: HMLAN1: Unknown code A0E03E01126EC1A2A32E70203000000::-72:HMLAN1, help me!

Anmerkung: 26EC1A ist der HMLAN-Adapter (HMLAN1), 2A32E7 ist die hmId des geflashten HM-LC-Sw1 (autocreate-Name CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2A32E7).

Sicherheitshalber auch nochmal letzte Version von 99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm von https://github.com/jabdoa2/Asksin_HM_LC_Sw1PBU_FM/tree/master/fhem gezogen, FHEM neu gestartet (mit für Testzwecke minimaler fhem.cfg, es ist nur der HMLAN1 definiert und eben das CustomFW-Device).
Das sind auch alles Messages von der Zentrale 26EC1A an das Device 2A32E7 - wieso kann HMLAN1 dann damit nichts anfangen?


Gibt es noch etwas Spezielles zu beachten, damit das Device vernünftig gepairt wird? In der Firmware ist übrigens über #firstLoad die pairCentral schon auf 26EC1A gesetzt...

Vielen Dank schonmal & viele Grüße
Michael

[Tobias]

Hi,
in der anleitung steht, das in dem FW-Hexfile die HMID fwest einkompiliert ist. Ich dachte die HMID wird durch das pairen mit FHEM angenommen? Oder habe ich etwas falsch verstanden? Ich habe eine vorhandene HM-Instanz per CUL, -> define CUL_HM CUL /dev/ttyACM0 1234

[mmattern]

Hi,
in der anleitung steht, das in dem FW-Hexfile die HMID fwest einkompiliert ist. Ich dachte die HMID wird durch das pairen mit FHEM angenommen? Oder habe ich etwas falsch verstanden? Ich habe eine vorhandene HM-Instanz per CUL, -> define CUL_HM CUL /dev/ttyACM0 1234

Hallo,

mein Verständnis: die HMID ist die Device-ID, nicht die der Zentrale (die in der Tat beim Pairing gesetzt wird).
Es ist eine eindeutige ID, die in der fhem.cfg mit dem Device verknüpft wird (in diesem Beispiel 2A32E7):

Code Auswählen Erweitern

define CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_2A32E7 CUL_HM 2A32E7

Viele Grüße
Michael

[Tobias]

ahh, alles klaro... also muss man definitiv selbst kompilieren da man i.d.R. ja nicht nur einen Schalter hat