Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?
Moderator: Co-Administratoren
-
- Beiträge: 47
- Registriert: 30.03.2016, 07:22
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 1 Mal
Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?
Hallo Zusammen,
ich habe mich heute mal rangewagt, meinen defekten HM-Sec-Rhs mit der alternativen FW zu flashen.
Eine Frage, die sich mir dabei gestellt hat, welches Board muss ich denn in der Arduino IDE einstellen?
Habe es mit dem Pro Mini und dort dem ATmega168 3,3V, 8Mhz versucht, aber da kommt bei „kompilierte Binädatei exportieren“ auch der Compilierfehler mit dem verwendeten Speicherplatz. D.h. ich bekomme keine Hex-Datei, die ich mit AVR Dude flashen könnte.
Nun habe ich es mit der Minicore 168 Board-Einstellung versucht, welche keinen Compilierfehler mehr bringt. Ich kann den Sketch dann sogar via „Hochladen mit Programmer“ in der IDE flashen. Danach kann ich das Gerät auf der CCU anlernen (drüberlernen hat leider nicht funktioniert), aber es werden keine Zustandsänderungen der Fensterposition erfasst.
Da die AskSin Kommunikation funktioniert, gehe ich davon aus, dass der Sketch auf dem Gerät drauf ist und läuft. Aber ggf. funktioniert die Kommunikation zwischen Atmega und MSP nicht richtig, weil ggf. die verwendeten Pins zum MSP beim Minicore anders bezeichnet sind.
Bevor ich die fummeligen Drähte für den seriellen Test des MSP anlöte, liegt das ggf. an der falschen Boardeinstellung oder ist bei meiner HW doch der MSP hinüber?
VG Heiko
ich habe mich heute mal rangewagt, meinen defekten HM-Sec-Rhs mit der alternativen FW zu flashen.
Eine Frage, die sich mir dabei gestellt hat, welches Board muss ich denn in der Arduino IDE einstellen?
Habe es mit dem Pro Mini und dort dem ATmega168 3,3V, 8Mhz versucht, aber da kommt bei „kompilierte Binädatei exportieren“ auch der Compilierfehler mit dem verwendeten Speicherplatz. D.h. ich bekomme keine Hex-Datei, die ich mit AVR Dude flashen könnte.
Nun habe ich es mit der Minicore 168 Board-Einstellung versucht, welche keinen Compilierfehler mehr bringt. Ich kann den Sketch dann sogar via „Hochladen mit Programmer“ in der IDE flashen. Danach kann ich das Gerät auf der CCU anlernen (drüberlernen hat leider nicht funktioniert), aber es werden keine Zustandsänderungen der Fensterposition erfasst.
Da die AskSin Kommunikation funktioniert, gehe ich davon aus, dass der Sketch auf dem Gerät drauf ist und läuft. Aber ggf. funktioniert die Kommunikation zwischen Atmega und MSP nicht richtig, weil ggf. die verwendeten Pins zum MSP beim Minicore anders bezeichnet sind.
Bevor ich die fummeligen Drähte für den seriellen Test des MSP anlöte, liegt das ggf. an der falschen Boardeinstellung oder ist bei meiner HW doch der MSP hinüber?
VG Heiko
VG Heiko
-
- Beiträge: 12116
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 849 Mal
- Danksagung erhalten: 2150 Mal
- Kontaktdaten:
Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?
Du musst in der boards.txt die maximum size auf für den Mega168 auf 16384 ändern.
https://github.com/pa-pa/AskSinPP/blob/ ... est.sh#L30
-
- Beiträge: 12116
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 849 Mal
- Danksagung erhalten: 2150 Mal
- Kontaktdaten:
Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?
Ja, Pro Mini 168 / 3.3V / 8MHz
Dann "Sketch " -> "kompilierte Binärdatei exportieren"; anschließend im Sketch Ordner die .HEX ohne Bootloader flashen
Dann "Sketch " -> "kompilierte Binärdatei exportieren"; anschließend im Sketch Ordner die .HEX ohne Bootloader flashen
Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?
Hallo,
habe den Versuch gestartet meine diversen HM-SEC-RHS zu flashen.
Hänge im Moment an 3 Punkten:
1. Die Zeile "// #define USE_OTA_BOOTLOADER" kann die auskommentiert bleiben. Stimmt das?
2. Das Hex File wird nicht erstellt. (test.sh ist auf "BUILD_PROPERTY="upload.maximum_size=16384"" gesetzt.)
- Mit auskommentierter Zeile bricht die Hex Erstellung mit der Meldung ab:
"Der Sketch verwendet 15594 Bytes (108%) des Programmspeicherplatzes. Das Maximum sind 14336 Bytes." ab.
- Mit der " #define USE_OTA_BOOTLOADER" Zeile bricht die HEX Erstellung mit der Meldung ab:
"Der Sketch verwendet 15500 Bytes (108%) des Programmspeicherplatzes. Das Maximum sind 14336 Bytes."
3. Flashen des Hex via avrdude über einen USB ISP-Programmer wie Dimex Prog 2 via CLI ?
LG Thomas
habe den Versuch gestartet meine diversen HM-SEC-RHS zu flashen.
Hänge im Moment an 3 Punkten:
1. Die Zeile "// #define USE_OTA_BOOTLOADER" kann die auskommentiert bleiben. Stimmt das?
2. Das Hex File wird nicht erstellt. (test.sh ist auf "BUILD_PROPERTY="upload.maximum_size=16384"" gesetzt.)
- Mit auskommentierter Zeile bricht die Hex Erstellung mit der Meldung ab:
"Der Sketch verwendet 15594 Bytes (108%) des Programmspeicherplatzes. Das Maximum sind 14336 Bytes." ab.
- Mit der " #define USE_OTA_BOOTLOADER" Zeile bricht die HEX Erstellung mit der Meldung ab:
"Der Sketch verwendet 15500 Bytes (108%) des Programmspeicherplatzes. Das Maximum sind 14336 Bytes."
3. Flashen des Hex via avrdude über einen USB ISP-Programmer wie Dimex Prog 2 via CLI ?
LG Thomas
-
- Beiträge: 12116
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 849 Mal
- Danksagung erhalten: 2150 Mal
- Kontaktdaten:
Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?
Ja
Du musst das in deiner boards.txt ändern.
viewtopic.php?f=76&t=46123&p=730492#p683637
Das ist dir überlassen.
Ich nutze auf dem Mac "AVRFuses", um HEX-Files zu flashen
Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?
Hallo
Top hat funktioniert.
Der Trick ist die Datei in der Arduino Konfiguration zu suchen ...
Habe jetzt 2 Hex Files.
1.) HM-SEC-RHS-ATmega168.ino.eightanaloginputs.hex
2.) HM-SEC-RHS-ATmega168.ino.with_bootloader.eightanaloginputs.hex
Ich nehme das ohne Bootloader richtig?
Welche Parameter benötigt man zum schreiben?
Gruss Thomas
Top hat funktioniert.
Der Trick ist die Datei in der Arduino Konfiguration zu suchen ...
Habe jetzt 2 Hex Files.
1.) HM-SEC-RHS-ATmega168.ino.eightanaloginputs.hex
2.) HM-SEC-RHS-ATmega168.ino.with_bootloader.eightanaloginputs.hex
Ich nehme das ohne Bootloader richtig?
Welche Parameter benötigt man zum schreiben?
Gruss Thomas
-
- Beiträge: 12116
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 849 Mal
- Danksagung erhalten: 2150 Mal
- Kontaktdaten:
Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?
Schade, dass du dir nicht mal die letzten Threads auf dieser Seite durchgelesen hast, dann wüsstest du es:
Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?
Hallo,
Wer lesen kann ist im Vorteil ...
Das Flashen ohne Bootloader hat funktioniert.
Beim ersten Versuch habe ich, gemäß Kommentierung im Sktech die Zeile rein kommentiert.
Nach meinem Verständnis hätte beim Flashen dann die bisherige ID übernommen werden müssen.
Leider wurde der Sensor jedoch ohne Seriennummer zum Tausch in der CCU angezeigt.
Ich habe dann den Sketch mit "// #define USE_OTA_BOOTLOADER" kompeiliert, das HEX geflasht und Sensor nach der Anmeldung getauscht.
Jetzt taucht der getauschte Sensor wie folgt in den Service Meldungen auf:
Unter Geräteeinstellungen ist der Vorgängersensor angelegt zu sein.
Der Sensor reagiert nicht auf Veränderung des Schließers, jedoch den Sabotage Schalter löst er aus wenn ich das Batteriefach öffene.
Frage:
1. Kann mann die Geräte ID des Sensors ggf. wiederherstellen? Bzw. spielt das für die Funktion überhaupt eine Rolle?
2. Läst sich Konfiguration auf den geflashten Sensor überhaupt übertragen ?
Vielen Dank im Voraus!
Wer lesen kann ist im Vorteil ...
Das Flashen ohne Bootloader hat funktioniert.
Beim ersten Versuch habe ich, gemäß Kommentierung im Sktech die Zeile rein kommentiert.
Code: Alles auswählen
// define this to read the device id, serial and device type from bootloader section
#define USE_OTA_BOOTLOADER
Leider wurde der Sensor jedoch ohne Seriennummer zum Tausch in der CCU angezeigt.
Ich habe dann den Sketch mit "// #define USE_OTA_BOOTLOADER" kompeiliert, das HEX geflasht und Sensor nach der Anmeldung getauscht.
Jetzt taucht der getauschte Sensor wie folgt in den Service Meldungen auf:
Unter Geräteeinstellungen ist der Vorgängersensor angelegt zu sein.
Der Sensor reagiert nicht auf Veränderung des Schließers, jedoch den Sabotage Schalter löst er aus wenn ich das Batteriefach öffene.
Frage:
1. Kann mann die Geräte ID des Sensors ggf. wiederherstellen? Bzw. spielt das für die Funktion überhaupt eine Rolle?
2. Läst sich Konfiguration auf den geflashten Sensor überhaupt übertragen ?
Vielen Dank im Voraus!