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

[Marshal]

Habe mich nun wieder an das Flashen eines neuen Schalters gewagt. Leider kann ich zum Flashen des OTA Bootloaders den Lock nicht auf 0x2f setzen, so dass das Flashen des Bootloaders fehlschlägt. Woran kann das liegen - schlampig gelötet?
Die Firmware kann ich hingegen flashen, da dafür der Lock nicht gebraucht wird. Der Schalter sollte doch dann auch funktionieren? Tut er aber leider nicht. Irgendwelche Tipps dazu?
Danke!

Hi, ich hatte auch Probleme mit dem "Setzten der Fuses".
Ich habe den Befehl noch etwas erweitert, dann ging es:
avrdude -p m644p -P gpio -c gpio -U lfuse:w:0xFD:m -U hfuse:w:0xD8:m -U lock:w:0x3F:m -B 4800 -u -e

[wires.io]

@Frank
1. Danke, dass Du hier so geduldig Support leistest!
2. Habe jetzt auf unterschiedlichsten Systemen jeweils Bootloader und Firmware kompiliert bzw. geflasht. Das Bootloaderblinken hört aber nicht auf, Pairen ist nicht möglich. Lt. Deinen Erklärungen hängt der Bootloader wohl in einer Loop. Irgendeine Ahnung was da schief läuft?

@Marshal
Danke, funzt bei mir aber nicht. Ich nehme den "AVR mySmartUSB light" zum Flashen.

[wires.io]

Habe gerade auf https://github.com/kc-GitHub/Asksin_OTA_Bootloader gelesen, dass mir noch die Checksum fehlt. Habe ich 4k oder 8k "Bootloader Space"?


Sent from my iPad using Tapatalk

[frank]

Habe ich 4k oder 8k "Bootloader Space"?

das kannst nur du wissen, denn du gibst uns/mir keine infos.
vor tagen habe ich bereits gefragt, wie deine fuses gesetzt sind. damit stellst du den space ein.

fuses, bootloader und firmware müssen jeweils zum gewählten bootloader space passen.
du musst dich entscheiden, ob du 4k oder 8k möchtest. dementsprechend wählst du die jeweiligen einstellungen und komponenten. ich habe und würde immer wieder 8k nutzen.

und auch das wiki sollte alle schritte für 8k bereitstellen.

warum zeigst du nicht schritt für schritt nach welcher anleitung du vorgehst und wie die protokolle dafür aussehen?

[wires.io]

- Windows 10 Bash
  - Bootloader gebaut

- Windows 10 myAVR_ProgTool.exe
  - Hardware: mySmartUSB light, Controller ATmega644
    - wenn ich als Controller ATmega644a einstelle, kann ich die Fuses nicht auslesen bzw. setzen
  - Fuses auf 0xFD (Low) - 0xDA (High) - 0x2F (Lock) versucht zu setzen
    - anschließendes Auslesen ergibt: 0xFD (Low) - 0xDA (High) - 0xEF (Lock)
  - damit Bootloader über die angelöteten Drähte geflasht
    - Flashen läuft durch, aber am Schluss kommt die Warnung das geschriebene / gelesene Daten unterschiedliche Längen haben

- Windows 10 Windows Bash
  - Firmware mit Arduino kompiliert
  - .hex to .bin
    /opt/srecord-1.64/bin/srec_cat Asksin_HM_LC_Sw1PBU_FM.cpp.hex -intel -fill 0xFF 0x0000 0xEFFE -Cyclic_Redundancy_Check_16_Little_Endian 0xEFFE -o Asksin_HM_LC_Sw1PBU_FM.cpp.bin -binary
  - .bin to .eq3
    ./bin2eq3 Asksin_HM_LC_Sw1PBU_FM.cpp.bin Asksin_HM_LC_Sw1PBU_FM.cpp.eq3
   
- Windows 10 Homematic Firmware Tool
  - Asksin_HM_LC_Sw1PBU_FM.cpp.eq3 OverTheAir mit HM-CFG-USB-2geflasht
  - LED blinkt nicht mehr Bootloader typisch alle 15s, sondern leuchtet nur bei Knopfdruck auf
 
- Ubuntu FHEM
  - "hart gepairt" durch Hinzufügen der entsprechenden Einträge in die fhem.cfg
  - im Log kommt die Meldung: "hmusb: Unknown code A110DA00238636B34656A04B0670000671900::-97:hmusb, help me!"
  - getConfig liefert nix zurück trotz "CMDs_done" (siehe Bild)

[frank]

- Windows 10 Homematic Firmware Tool
  - Asksin_HM_LC_Sw1PBU_FM.cpp.eq3 OverTheAir mit HM-CFG-USB-2geflasht
  - LED blinkt nicht mehr Bootloader typisch alle 15s, sondern leuchtet nur bei Knopfdruck auf

das hört sich doch sehr gut an. jetzt aber bitte nicht mehr flashen. 

- "hart gepairt" durch Hinzufügen der entsprechenden Einträge in die fhem.cfg

du kannst das device so anlegen, aber pairen musst du trotzdem.

wie es aussieht, hast du das auch geschafft.
es fehlen aber noch die 4 channel.
am besten noch mal drüber pairen und nichts löschen.

- im Log kommt die Meldung: "hmusb: Unknown code A110DA00238636B34656A04B0670000671900::-97:hmusb, help me!"

das ist wahrscheinlich vom nachbarn. definiere eine vccu wie im wiki, dann ist schluss mit "help me".

[wires.io]

Nachdem ich das

Code Auswählen Erweitern


define HM_123458_Btn_01 CUL_HM 12345801
define HM_123458_Btn_02 CUL_HM 12345802
define HM_123458_Sw_01 CUL_HM 12345803
define HM_123458_Sw_02 CUL_HM 12345804

manuell eingegeben habe, bekomme ich nun auch State CMDs_done nach getConfig.
So: Jetzt noch einbauen und schauen, ob er tut was er soll.

[frank]

So: Jetzt noch einbauen und schauen, ob er tut was er soll.

was war denn nun eigentlich das grosse flash problem?

[wires.io]

Erstmal einbauen (und an der CCU2 anmelden), dann endgültiges Fazit.

Vorläufiges Fazit:
Fast endgültiges Fazit:
- Ich habe mich von den Warnungen beim Setzen der Fuses und dem Flashen des Bootloaders irritieren lassen.

- Es gibt drei bis vier verschiedenen Anleitungen, die in Details voneinander abweichen und zusätzlich zu Irritationen beitragen. Evtl. solle in diesem Forum ein "sticky" Thread angelegt, werden, wo die einzig wahre, aktuelle Anleitung steht.

- Der CRC Check bzw. das Erstellen einer Firmware mit gültigem CRC hat mich etwas Nerven gekostet, da ich beim Flashen der ersten Schalter vor ca. 1 1/2 Jahren dies nicht (bewusst) gemacht habe. "bin2eq3" gab's da noch nicht bzw. ich hab's seinerzeit nicht benutzt.

- Der Anmeldeprozess an FHEM klappt auch nicht automatisch, sondern nur durch manuelles Eintragen einiger Daten in fhem.cfg und Absetzen div. Befehle über das Webinterface. "set hmusb hmPairForSec 60" und "set hmusb hmPairSerial KEQ000000x" mit kurzem Druck auf das Knöpfchen am Schalter haben nichts bewirkt. Bin gespannt, ob das an der CCU2 funktioniert, wo ich die seinerzeit geflashten Schalter schon angemeldet habe. Man muss das Knöpfchen am Schalter länger als vier Sekunden gedrückt halten, dann klappt das auch automatisch - wer das Wiki lesen kann, ist klar im Vorteil.

- Durch Systemumzug habe ich mir eine neue Buildchain aufgebaut. Damit müsste ich in Zukunft den Bootloader und die Firmware wieder bauen und beides auch Flashen können. Für die Anmeldung an FHEM habe ich auch einige "Best Practices" gewonnen.

- Weitere Best Practice: Die Flashkabel werden erst abgelötet, wenn die Anmeldung an FHEM erfolgreich war. Habe mir durch zu häufiges An- und Ablöten schon mal die Lötaugen ruiniert.

- Ein gewisser "Glücksspielfaktor" bleibt

Die Firmware ist für meine Einsatzzwecke, um entfernte Aktoren anzusteuern, echt genial! Vielen Dank dafür an Alle, die dazu beigetragen haben!

[frank]

- Es gibt drei bis vier verschiedenen Anleitungen, die in Details voneinander abweichen und zusätzlich zu Irritationen beitragen. Evtl. solle in diesem Forum ein "sticky" Thread angelegt, werden, wo die einzig wahre, aktuelle Anleitung steht.

- Der CRC Check bzw. das Erstellen einer Firmware mit gültigem CRC hat mich etwas Nerven gekostet, da ich beim Flashen der ersten Schalter vor ca. 1 1/2 Jahren dies nicht (bewusst) gemacht habe. "bin2eq3" gab's da noch nicht bzw. ich hab's seinerzeit nicht benutzt.

am sichersten ist sicherlich immer die original anleitung und beim "mischen" von anleitungen wird es meistens nochmal komplizierter.
bin2eq3 gibt es mindestens seit dem 19.08.2014. das ist das änderungsdatum der README.md datei, wo es erwähnt wird. wahrscheinlich sogar schon seit der ersten fw. das scipt konvertiert eigentlich nur nach eq3 format.

[EinEinfach]

Hallo zusammen,

ich wollte mich an dieser Stelle auch für die tolle Umsetzung bei den Entwicklern bedanken. Am Wochenende habe ich meinen ersten HM_LC_Sw1PBU_FM geflasht und in die erste Wechselschaltung installiert. Läuft!!

Allerdings habe ich noch 2 Fragen, auf die ich spontan keine Antwort gefunden habe:
1. In der FHEM Wiki steht, dass Switch_1 der virtuelle Kanal ist, der abhängig vom Stromfluss den Zustand auf On bzw. Off ändert. Bei mir eindeutig ist das der Switch_2. Ist das nur bei mir so, oder handelt es sich hier um einen Fehler in der Wiki?
2. Vor dem kompilieren muss die Stromschwelle bei Bedarf geändert werden. Standard ist 5000, den Wert habe ich auch so gelassen. Wie hängt diese Schwelle mit dem Reading "current" zusammen? Im eingeschaltetem Zustand ist bei mir current=700. Trotzdem wird der Zustand als eingeschaltet erkannt, obwohl der Wert deutlich unter 5000 ist.

[kingmathers]

Hallo,

ich habe auch mehrere HM_LC_Sw1PBU_FM im Einsatz und würde gerne diese Firmware draufspielen.

Ich habe einen Raspberry Pi und kann löten. Als Schnittstelle zu FHEM benutze ich HM-CFG-LAN (und vccu, falls das relevant ist). Den Wiki Artikel habe ich mir durchgelesen, es sind jedoch noch ein paar Fragen bei mir offen geblieben:

1. Ist mit der alternativen Firmware auch die Unterscheidung zwischen kurzem und langem Tastendruck (sowie beim HM-RC-2-PBU-FM) möglich?

2. Welche Teile kann ich mit meiner Hardware OTA machen und wofür muss ich den HM_LC_Sw1PBU_FM anlöten?

3. Ist diese Anleitung noch aktuell?

4. Ich habe ja mehrere HM_LC_Sw1PBU_FM. Liege ich richtig in der Annahme, dass ich jeden davon erst einbauen muss, in FHEM anlernen, die Daten rausschreiben um damit die neue Firmware zu kompilieren, dann ausbauen, flashen und erneut einbauen muss?

Grüße

[EinEinfach]

Hallo,

ich habe auch mehrere HM_LC_Sw1PBU_FM im Einsatz und würde gerne diese Firmware draufspielen.

Ich habe einen Raspberry Pi und kann löten. Als Schnittstelle zu FHEM benutze ich HM-CFG-LAN (und vccu, falls das relevant ist). Den Wiki Artikel habe ich mir durchgelesen, es sind jedoch noch ein paar Fragen bei mir offen geblieben:

1. Ist mit der alternativen Firmware auch die Unterscheidung zwischen kurzem und langem Tastendruck (sowie beim HM-RC-2-PBU-FM) möglich?

2. Welche Teile kann ich mit meiner Hardware OTA machen und wofür muss ich den HM_LC_Sw1PBU_FM anlöten?

3. Ist diese Anleitung noch aktuell?

4. Ich habe ja mehrere HM_LC_Sw1PBU_FM. Liege ich richtig in der Annahme, dass ich jeden davon erst einbauen muss, in FHEM anlernen, die Daten rausschreiben um damit die neue Firmware zu kompilieren, dann ausbauen, flashen und erneut einbauen muss?

Grüße

Hi, ich versuche mal deine Fragen zu beantowrten:
1. Ja, die Unterscheidung gibt es ("kurz oder lang" Taster oben und "kurz oder lang" Taster unten) Ich habe gerade noch mal ausprobiert, die Unterscheidung gibt es doch nicht... 
2. OTA geht erstmal nicht. Anlöten musst du im ersten Schritt auf jeden Fall. Wenn du später OTA flashen möchtest (aus welchen Gründen auch immer, Stromschwelle doch noch anpassen usw), dann muss im ersten Schritt der Bootloader gefalsht werden. Nach dem Bootloader flashen kannst du direkt die Neue Firmware flashen, oder den Schalter einbauen und die neue FW OTA flashen.
3. Ich habe die Anleitung auch versucht, allerdings hatte ich diverse Probleme hier und da. Im Endeffekt fand ich die hier am besten, wo es sofort funktioniert hat: https://wiki.fhem.de/wiki/HM-LC-Sw1PBU-FM_Alternative_Firmware_am_Raspi_bauen_u._flashen
4. Nein nicht unbedingt. Wenn du unbedingt den Wert drauflegst die originale HMID in den Schalter zu schreiben, dann muss du ihn erstmal anlernen (Ich habe keinen anderen Weg gefunden, wie ich die HMID rauskriege ohne das Teil vorher anzulernen). Außerdem brauchst du die Seriennummer, diese findest allerdings auf der Verpackung.
Beides HMID und Seriennummer können natürlich wirkürlich gewählt werden (also ohne vorher anzulernen). Du musst nur drauf achten dass die HMID einzigartig ist.

Gruß
Alex

[b4rRa]

Bezüglich der Frage "Sind die Anleitungen noch aktuell"

Habe gestern meine letzten 4 Schalter mit der FIrmware geflasht. Wenn man weiß wie es geht, ist das rucki zucki erledigt. Beim ersten Schalter war ich aber kurz vorm Aufgeben. Das ganze hat mich fast den kompletten Sonntag gekostet. Hab das ganze auch mit einem rpi3 geflasht.

Die Anleitungen sind noch "aktuell" sollten aber um Hinweise ergänzt werden. Hauptproblem bei mir waren die Fuses!! Die haben sich ums verrecken nicht korrekt setzen lassen. Ich bekam immer folgende Fehlermeldung:

Code Auswählen Erweitern

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

Writing |                                                    | 0% 0.00s ***failed; 
Writing | ################################################## | 100% 0.10s

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.01s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0xfd
avrdude: verification error; content mismatch

avrdude: safemode: lfuse changed! Was fd, and is now ff
Would you like this fuse to be changed back? [y/n]

Zuerst dachte ich, dass etwas mit der Verkabelung nicht stimmt. Sah aber alles gut aus. Dennoch hingegangen und komplett neue Kabel angelötet und angesteckt.. Immer noch gleicher Fehler... Dann hab ich den kompletten rpi3 platt gemacht und neu aufgesetzt... Frisches, nacktes OS und alle Schritte penibel wiederholt. Der Fehler bleibt.

Die Suche hier im Thread war auch erfolglos. Den Fehler hatten zwar auch schon 2-3 Leute gepostet, aber ohne erkennbare Lösung. Die Fehlermeldung "Would you like this fuse to be changed back? [y/n]" habe ich mit NO quittiert. Das Auslesen der Fuses zeigte aber, dass die Werte immer noch die falschen waren.

Mir gingen die Ideen und Geduld aus und ich hab dann einfach den Bootloader so drüber geknüppelt. Und was soll ich sagen - es hat funktioniert o_O. Nach dem der Bootloader geflasht war, konnte ich nun auch einwandfrei die Fuses richtig setzen! Sicherheitshalber habe ich dann erneut den Bootloader und dann die Firmware drübergeknüppelt.

Der Schalter ließ sich auf Anhieb korrekt pairen. Das Problem mit den Fuses hatte ich im Übrigen bei ALLEN Schaltern. Hinweise auf die Problematik hätten mir ne Menge Zeit erspart Von daher hoffe ich, dass dieser Beitrag eventuell anderen "Neulingen" etwas hilft.

Ein weiteres Problem in den Anleitungen ist die Problematik mit dem Atmel M644 Chip! In der FHEM Wiki steht folgendes:

Hinweis: In älteren Beschreibungen findet man häufig die Ziel-Plattform m644. Diese unterscheidet sich praktisch in der Stromaufnahme des Chips, führt beim avrdude aber zu Fehlermeldungen, deshalb auf m6444p achten

Das ist so nicht ganz korrekt! Offenbar ist eq3 hingegangen und hat in neueren Modellen keinen M644a sondern einen M644p verbaut. Hier ist also unbedingt darauf zu achten, wie alt euer Schalter ist. Ich habe einen älteren, gebrauchten Schalter (Beginnend mit LEQxxxxx) der musste zwingend mit M644 geflasht werden. Meine neuen Schalter (Beginnend mit NEQxxxx) mussten alle mit M664p geflasht werden.

Das Auslesen der Original HMID ist im Übrigen recht leicht und steht auch schon irgendwo hier im Thread. Der versteckt sich im kleinen QR Code auf der Platine (Es gibt 3 Aufkleber. Es ist der kleine auf der Platine - nicht Funkmodul!) und beginnt mit Hxxxxx. Es ist also nicht zwingend notwendig den Schalter vorab anzulernen um die HMID zu Erfahren.

Ein weiterer Hinweis der in allen Anleitungen fehlt - aber ausgiebig hier im Thread besprochen wurde - ist die Notwendigkeit von libswitch-perl damit das alternative FHEM Modul für den Schalter funktioniert

Code Auswählen Erweitern

apt-get install libswitch-perl

[EinEinfach]

Die Anleitungen sind noch "aktuell" sollten aber um Hinweise ergänzt werden. Hauptproblem bei mir waren die Fuses!! Die haben sich ums verrecken nicht korrekt setzen lassen

Den Fehler hatte ich auch. Allerdings stand es in einer der Anleitungen, dass dieser getrost ignoriert werden kann (Weiß nicht mehr in welcher....). Also hat mich der erste Schalter nur den halben Sonntag gekostet