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

[Mr. P]

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

Genauso ist es. Sobald mehr als ein Schalter im Spiel ist, muss man zumindest im Moment noch selbst bauen.

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):

Ebenso richtig.

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

Großartig, gratuliere.

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?

Tritt das bei allen Firmwarefiles auf? Ich habe die genaue Zahl nicht mehr im Kopf, aber es waren beim Flashen der Firmware (OTA) immer nur so um die 70 Blöcke, die verbraten wurden.

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.

Kannst du bitte einmal ein Listing deines Schalters posten?

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

Hast in der Register.h nur die ID von der Zentrale angepasst, oder auch firstLoad einkommentiert?

[mmattern]

Tritt das bei allen Firmwarefiles auf? Ich habe die genaue Zahl nicht mehr im Kopf, aber es waren beim Flashen der Firmware (OTA) immer nur so um die 70 Blöcke, die verbraten wurden.

Ja...
Es ist doch richtig, dass für OTA-Flash das File im .eq3-Format (konvertiert aus .hex mittels convert.php https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/convert.php) vorliegen muss?
flash-ota aus hmland (neueste Version von hier: https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb/) zeigt diese Anzahl von Blöcken an...
Grob gesagt etwa doppelt so viele, wie ich erwarten würde - ein Block hat doch 256 Byte?

Kannst du bitte einmal ein Listing deines Schalters posten?
Hast in der Register.h nur die ID von der Zentrale angepasst, oder auch firstLoad einkommentiert?

Das Problem mit den Unknown Codes hatte wohl nichts mit dem Schalter zu tun, sondern eher hiermit: http://forum.fhem.de/index.php/topic,24475.0.html
Man sollte halt nicht mehrere Dinge gleichzeitig ändern...

Ich bin auf ältere Versionen für die HM-.pm-Skripte zurückgegangen, dann klappt es.

Eine mögliche Falle für das erste Pairing lauert auch noch darin, dass nicht immer alle Module geladen werden, sondern nur die nötigen... wenn man kein CustomFW-Device definiert hat, wird 99_Asksin..... .pm wohl nicht geladen, was dazu führt, dass das Device dann nicht richtig erkannt wird.
Also einfach eins definieren, bevor man das erste Mal pairt, damit das Asksin-Modul geladen wird...

Habe jetzt trotz fehlender OTA-Möglichkeit mal zwei Schalter eingebaut, die jetzt funktionieren wie gewünscht... in meinem Fall: Wechselschaltung mit nur einem Aktor; wenn der "herkömmliche" Schalter betätigt wird, erkennt der modifizierte Schalter das am Stromfluss und aktualisiert dann den Status entsprechend... Cool - vielen Dank an die Urheber! 

Viele Grüße
Michael

[Mr. P]

Es ist doch richtig, dass für OTA-Flash das File im .eq3-Format (konvertiert aus .hex mittels convert.php https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/convert.php) vorliegen muss?

Ja, passt eigentlich.

flash-ota aus hmland (neueste Version von hier: https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb/) zeigt diese Anzahl von Blöcken an...
Grob gesagt etwa doppelt so viele, wie ich erwarten würde - ein Block hat doch 256 Byte?

Ich hätte eher 512 Byte pro Block angenommen.

Das Problem mit den Unknown Codes hatte wohl nichts mit dem Schalter zu tun, sondern eher hiermit: http://forum.fhem.de/index.php/topic,24475.0.html
Man sollte halt nicht mehrere Dinge gleichzeitig ändern...

Ich bin auf ältere Versionen für die HM-.pm-Skripte zurückgegangen, dann klappt es.

Das Problem gab es zwischendurch, ja. Aber warst du denn nicht am aktuellen SW-Stand? Habe bei mir alles aktuell und da funktioniert zur Zeit alles.

Eine mögliche Falle für das erste Pairing lauert auch noch darin, dass nicht immer alle Module geladen werden, sondern nur die nötigen... wenn man kein CustomFW-Device definiert hat, wird 99_Asksin..... .pm wohl nicht geladen, was dazu führt, dass das Device dann nicht richtig erkannt wird.
Also einfach eins definieren, bevor man das erste Mal pairt, damit das Asksin-Modul geladen wird...

Das sollten wir uns bei Zeiten näher ansehen. Wäre wirklich eine böse Falle und müsste zumindest dokumentiert sein. Wobei mMn sich das Autocreate um das Laden des Moduls kümmern müsste.

Edit:
Ich hab jetzt zur Sicherheit mein flash-ota mit meinem aktuellen 40248 Byte großen .eq3-File angeworfen und bekomme auch gleich die Meldung:

Code Auswählen Erweitern

Firmware with 78 blocks successfully read.
Mit den 512 Byte dürfte ich damit wohl richtig liegen.

[Tobias]

Hi Frank,

das sieht mir aus als wenn dein Compiler nur atmega644 und nicht atmega644a als Target kennt. Ich habe das mal schnell in Jabduino eingefügt (https://github.com/jabdoa2/jabduino/blob/master/boards.txt). Update das mal dann und wähle dann "Jabduino ATmega644".

Der Unterschied zwischen atmega644 und atmega644a ist eh nur marginal. Funktioniert auf jeden Fall mit beiden.

Gruß,
Jan

Nach Anleitung alles Installiert und beim ersten Mal am selben Fehler gescheitert. Mit atmega644 läuft die Kompilierung sauber durch Damit kann ich meine eigenen HMIDs einbauen

[mmattern]

Edit:
Ich hab jetzt zur Sicherheit mein flash-ota mit meinem aktuellen 40248 Byte großen .eq3-File angeworfen und bekomme auch gleich die Meldung:

Code Auswählen Erweitern

Firmware with 78 blocks successfully read.
Mit den 512 Byte dürfte ich damit wohl richtig liegen.

Hallo Mr. P,

wenn man sich wundert, stimmt was nicht:
Ich hatte einen wichtigen Schritt übersehen:
Auf der Bootloader-Page von jab (https://github.com/jabdoa2/Asksin_OTA_Bootloader) steht:

You need to convert your elf file to binary first (For arduino GUI you can find this in /tmp/buildXXXXX/)

Code Auswählen Erweitern

avr-objcopy -j .text -j .data -O binary payload.elf payload.bin

Use the converter (need php-cli):

Code Auswählen Erweitern

php convert.php payload.bin payload.eq3 # convert to eq3 hex format

Dann wird das File auch deutlich kleiner... 

Würde sich ggf. ein Hinweis im Wiki (http://www.fhemwiki.de/wiki/HM-LC-Sw1PBU-FM_Alternative_Firmware) lohnen unter

Firmware

• Firmware mit arduino bauen
• In eq3 File konvertieren

(bei der Gelegenheit würde es sich auch noch lohnen:
- genauer auf die Anleitung von jab zur Installation der atmega644-Definitionen in Arduino 1.0.5 bzw. 1.5 (Achtung, in 1.5 anderer Ordner notwendig!) hinzuweisen
- im Part zu UART-Debugging den Hinweis zu geben, dass man natürlich Debug-TX and RX und Debug-RX and TX des UART anschließen muss
- ebenfalls im Part zu UART-Debugging für Raspberry-User zu verlinken, wie man die in raspbian default-mäßig gesetzte serielle Konsole deaktiviert
- kurz zu beschreiben, wo man HMID, Seriennummer und Pairing-Zentrale anpassen kann
- #define firstLoad und #define USE_SERIAL zu erklären
- zu verlinken auf https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb für flash-ota

das wären dann einige Stolpersteine weniger für interessierte Neulinge...  )

[Mr. P]

Hej Michael,

vielen Dank für dein Feedback.
Werde deine Vorschläge bei Gelegenheit einpflegen.

Demnach läuft jetzt alles so, wie es soll?

[mmattern]

Hej Michael,

vielen Dank für dein Feedback.
Werde deine Vorschläge bei Gelegenheit einpflegen.

Demnach läuft jetzt alles so, wie es soll?

Hallo,

hmm... läuft doch noch nicht alles...

Das funktioniert:
- Bootloader bauen und mit avrdude flashen (mit Raspberry PI als Programmer)
- Firmware bauen, in .eq3 wandeln und mit flash-ota aufspielen
- Device startet dann nach Timeout in die Firmware (per UART-Debug sichtbar)

ABER:
- wenn man das Device jetzt einmal stromlos macht, geht es noch einmal in den Bootloader (erkennbar an Blinksequenz), dann aber nichts mehr: keine UART-Meldungen (weder vom Bootloader noch von der Firmware), der Schalter ist einfach nicht ansprechbar - Betätigen des Config-Buttons hat kein Blinken der LED oder Ausgabe der "i:0 s:0"-Meldung per UART mehr zur Folge...

Wenn die .hex-Version derselben Firmware per avrdude aufgespielt wird, funktioniert der Schalter...

Genau das werde ich jetzt auch tun... zwar schade um OTA-Update-Möglichkeit, aber für jetzt tut die FW ja genau, was ich möchte

Viele Grüße
Michael

[unimatrix]

in FHEM gibts ja nun auch die Option fwUpdate...soll das schon funktionieren? Soll dabei das Device automatisch rebooted werden ohne dass man es stromlos machen muss?

Das mit dem stromlos machen ist ein Problem, wenn mehrere Aktoren an einer Sicherung hängen. Die reagieren dann ja beiden mit dem Bootloader. Oder wenn der FHEM REchner an der gleichen Sicherung wie der Schalter hängt

Und geht das FHEM fwUpdate dann mit dem HM LAN Konfigurationsadapter?

[frank]

hallo unimatrix,

in FHEM gibts ja nun auch die Option fwUpdate...soll das schon funktionieren? Soll dabei das Device automatisch rebooted werden ohne dass man es stromlos machen muss?

mit den aktuellen versionen von fw/bootloader sollte es funktionieren. so ist der plan. hat nur noch keiner bestätigt/ausprobiert. kannst ja mal testen und berichten. meine letzten erfahrungen mit cul und fwupdate sind hier verewigt http://forum.fhem.de/index.php/topic,23329.0.html.

hmlan geht angeblich nicht (ist aber wohl nicht probiert).
hmusb geht theoretisch.

gruss frank

[Tobias]

Hi,
wird (ev. später??) der HM-LC-Sw2-PB-FM hier auch unterstützt? Ich bin zb. total unschlüssig wie ich die Serienschalter nach Homematic bringen kann...

[unimatrix]

wollte das Ding mal aufmachen hab ich aber noch nicht weil ich halt auch alle in Benutzung habe. Unterstützt wird er nicht aber es wäre natürlich theoretisch möglich (je nachdem was da drin ist)

Fwupdate über fhem habe ich probiert...passiert aber nix. Muss den Schalter stromlos machen damit er danach wieder geht ...habe allerdings auch nur einen HMLAN (habe jetzt nicht den CUL als HM Device umkonfiguriert, benutze ihn für FS20...das könnte ich noch testen)

viel einfacher wäre wohl den Dimmaktor aus der gleichen Serie zu nutzen denn der hat wohl den identischen Controller und im Grunde ist hier nur die Frontend-Hardware eine andere (kein Relais sondern entsprechend eine Dimmschaltung, soweit ich weiß über einen PWM angesteuert)

Problem hierbei ist wohl aber die grundsätzliche Dimmerunterstützung in der AskSin Library die meines Wissens nach noch fehlt und wahrsheinlich nicht ganz so einfach ist.Der Wert einer Custom-FW beim Dimmer würde sich dann aber auch auf die Nutzung des internen Tasters beschränken, da es ja hier das Strommess-Ding nicht gibt. Und auch das ist begrenzt da bei einem Dmmmer ja naturgemäß auch der Long-Press zum Dimmen benutzt wird.

[Mr. P]

Hej folks,

ich habe nun doch ein Problem mit der neuen Firmware.
Bei mir ist die Konfiguration so gewählt, dass ich Short oben für den internen Schalter zum Toggeln, Short unten für einen anderen gewählt habe.
Nun würde ich gerne ein paar mehr Funktionen nutzen und musste feststellen: es gibt kein Long-Release für Btn_01.
Ebenso wenig ist es mit bis dato gelungen einen Double auszulösen. Hatte ihn auf 200, 300 und 500ms eingestellt, aber egal was ich mache: keine Auslösen am Schalter durch einen Double-Befehl möglich. Immer nur Single-Schaltungen.

Hat noch jemand das Problem bzw. hatte es und kann mir einen Tipp geben, wie ich es beseitigen kann?

Thx a lot!

[unimatrix]

kann bestätigen dass kein LongRelease gesendet wird...habs bisher nicht genutzt würde es dann aber sobald es soweit ist ebenfalls vermissen.

wichtig wäre auch dass mit dem LongRelease wie bei anderen Devices üblich ein Zähler mitkommt. Ich nutze oftmals nicht nur short, long, sondern auch noch sozusagen "sehr long"

double ist aber etwas was auch bei der eq3-Firmware noch nicht geht - oder? Würde ja auch das single short verzögern müssen, konnte mir den Nutzwerk bisher nicht so vorstellen da es wohl bei "normalusern" (Frau) zu Fehlbedienungen kommen würde.

habe übrigens das fwUpdate in FHEM weder mit HMLAN noch HMUSB hinbekommen. Es kann schon sein dass ich was falsch mache. Was ich aber so oder so gut fände, wäre, wenn es einen Befehl in FHEM gäbe, mit dem ich das Device schlichtweg rebooten kann so dass es dann ja in den bootloader kommt und dann auf ein woanders laufendes flash-ota anspringt. Dann muss wenigstens die Sicherung  nicht mehr raus.

[unimatrix]

Nachdem ich nun 4 Schalter umgeflasht habe und die alle auch super funktionierten ist mir etwas aufgefallen. Sobald ich den internen Taster auch in FHEM sehen will muss ich ihn offenbar noch mit fhem selbst peeren und nicht nur mit dem internen Kanal, weil dann wird ansonsten offenbar der Taster selbst nicht gesendet. Habe ihn also mit einem virtuellen Device gepeert woraufhin dann auch alles kam.

Jedoch scheint jetzt teilweise eine Verzögerung beim Schalten des Lichts mit dem internen Taster zu entstehen. Wartet da der Schalter ggf. zuerst auf ein ACK von fhem bevor dann der (ggf. ja zweite) Peer abgearbeitet wird (intern) Führt dann zu Verzögerungen von 1-2 Sekunden, besonders bei mehrerem kurzen An/Ausschalten kommt es dann zu nicht so schönem verhalten

Bin ich der einzige der das Problem so gesehen hat?

Weiterhin hatte ich vorhin mal einen Zustand, in dem der Schalter nicht mehr aufgehört hat LongPresses zu senden (so als hielte man den Taster fest) - der Taster war aber definitivnicht gedrückt (da hat auch nix geklemmt)

[unimatrix]

eine letzte Sache bevor ich die Klappe halte:

ich beschäftige mich jetzt wesentlich intensiver mit dem Schalter. Ich versuche auch die Sourcen zu verstehen. Der Anwendungsspezifische Teil ist ja wirklich überschaubar, da das meiste in der Lib gemacht wird.

Finde ich irgendwo eine Dokumentation der Lib, die über die Inline-Kommentare hinausgeht?

Mir fallen beim Debuggen Kleinigkeiten auf...z.B. wenn man den Schalter per "Schalter" (Btn_01 oder 02) schaltet (und dabei ein Registerset nimmt, welches von einem Standard-Aktor mit eq3-Firmware kopiert ist (hier: Jump Targets alle auf Off) - dann sendet der CustomFW-Schalter wenn man das Licht aus macht erst noch ein 100% bevor dann geschaltet wird und ein 0% gesendet wird. Der EQ3-Firmware-Aktor tut das nicht, er schaltet und sendet dann 0%. Ich überlege ob solche Dinge zu der Verzögerung beitragen können die ich hier erfahre.

Werde mir wohl einen Haufen eigene Debug-Ausgaben einbauen um den Code nach und nach zu verstehen...