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

Begonnen von jab, 29 Dezember 2013, 22:04:10

Vorheriges Thema - Nächstes Thema

Mr. P

Greetz,
   Mr. P

Dirk

Nun muss das noch jemand am HM_LC_Sw1PBU_FM testen. :)

Bei den Hex-Files für den HM_LC_Sw1PBU_FM im Git  ist dieses Verhalten übrigens noch abgeschaltet.
Das muss man vorher noch im Devicefile aktivieren.

mmattern

Zitat von: Dirk am 14 August 2014, 01:15:11
Nun muss das noch jemand am HM_LC_Sw1PBU_FM testen. :)

Bei den Hex-Files für den HM_LC_Sw1PBU_FM im Git  ist dieses Verhalten übrigens noch abgeschaltet.
Das muss man vorher noch im Devicefile aktivieren.

Hallo Dirk,

würde das schon gern am HM-LC-Sw1PBU-FM testen, habe hier noch einen herumliegen... aber wo finde ich deine Version?
Die letzte Änderung hier:
https://github.com/jabdoa2/Asksin_OTA_Bootloader

ist schon eine Weile her...

Viele Grüße
Michael
2x Raspberry Pi, 2x HM-CFG-LAN, 2x HM-CFG-USB, 2x HM-ES-PMSw1-Pl, 3x HM-LC-BL1-FM, 10x HM-LC-Bl1PBU-FM, 6x HM-LC-Sw1PBU-FM-CustomFW, 2x HM-PB-2-WM55-2, 4x HM-PB-6-WM55, 2x HM-SEC-MDIR-2, 6x HM-SEC-RHS, 2x HM-SEC-WIN, 2x HM-Sys-sRP-Pl

Dirk


Mr. P

Zitat von: mmattern am 14 August 2014, 22:53:55
würde das schon gern am HM-LC-Sw1PBU-FM testen, habe hier noch einen herumliegen...
Vielen Dank, dass du dich opferst. Ich war schon kurz davor, meinen Schalter wieder aus der Wand zu holen. :-)

@Dirk: Ich hab trotzdem vorhin versucht, den Bootloader für den HM_LC_Sw1PBU_FM zu bauen, nur passt irgendwas nicht.
In deinem Readme schreibst du:
ZitatThe config.h is configured to the Atmega328p (HB-UW-Sen-THPL). For the HM-LC-Sw1PBU-FM with Atmega644 you must rename the config-Atmega644.h to config.h
Nur leider gibt es kein File, das config-Atmega644.h oder ähnlich heißt. Überseh ich gerade etwas, oder gibt es das File auf diesem Fork schlicht einfach nicht?
Greetz,
   Mr. P

Dirk

ZitatIn deinem Readme schreibst du:
Ach mist. Das hab ich noch in der Beschreibung nicht geändert. Das ändere ich gleich.

Da muss nix mehr umbenannt werden.
Die Defines für jedes Gerät liegen im Ordner devices.
hier gibt es schon eine "HB-UW-Sen-THPL.h" für den Universalsensor und eine "HM-LC-Sw1PBU-FM.h" für den Schalter.
eigentlich brauchst du nur ein
make HM_LC_Sw1PBU_FM
auszuführen.

Ich hoffe ich habe die Einstellungen für den HM_LC_Sw1PBU_FM in der Header-Datei korrekt eingestellt.

Mr. P

Zitat von: Dirk am 15 August 2014, 00:06:37
Da muss nix mehr umbenannt werden.
Tja... und hätte ich zwischen meinen make-Tests ein 'make clean' gemacht, dann wäre mir das auch aufgefallen und der Compiler hätte schon vor meinem letzten Posting bei allen Varianten zu Ende kompiliert. ;-)

Edit: Abgesehen davon, dass bei den HM_LC_Sw1PBI_FM's der eine Bootloader 4k und der andere 8k benötigt, gibt es aber keinen Unterschied, oder? Was bringt dann eigentlich der 8k-Loader, wenn man nicht gerade die Debug-Ausgaben lesbarer machen möchte?
Greetz,
   Mr. P

Dirk

ZitatAbgesehen davon, dass bei den HM_LC_Sw1PBI_FM's der eine Bootloader 4k und der andere 8k benötigt, gibt es aber keinen Unterschied, oder?
Nein. Nur die Debugausgabe der empfangenen Daten passt da nicht mehr rein.

ZitatWas bringt dann eigentlich der 8k-Loader, wenn man nicht gerade die Debug-Ausgaben lesbarer machen möchte?
Eigentlich nix. Habs nur drinn gelassen falls noch jemand Ideen hat die dann nicht mehr in die 4k passen.
Die Debugausgaben mit DEBUG = 1 passen aktuell hier sogar auch noch rein.
DEBUG = 2 aber nicht mehr.
Theoretisch könnte man den 8k-Teil im Makefile löschen / auskommentieren oder einfach nicht ausführen.
Zum probieren und testen ist es vieleicht aber ganz gut noch etwas Platz zu haben.

Mr. P

Großartig!
Dann bin ich schon gespannt, was Michael so zu berichten hat. :-)
Greetz,
   Mr. P

Mr. P

Kurze Frage an die Maintainer:
Der Schalter mit der CustomFW wird unter FHEM als subType 'remoteAndSwitch' angelegt.
Das macht aber aktuell zB Probleme in Verbindung mit andFHEM, da dieses auf den subType 'Switch' wartet um es als Schalter anzuzeigen.
Vermutlich könnte ich den Subtype händisch ändern, andFHEM würde es anzeigen und auch sonst gäbe es keine weiteren Probleme damit.
Die Frage ist nur, wie sinnvoll es ist, es per Hand zu ändern. In meinen Augen wäre es besser, wenn entweder der Subtype auf 'Switch' geändert würde oder in andFHEM entsprechende Erweiterung für den Subtype einfließt.
Gibt es denn einen bestimmten Grund, weshalb dieser Subtype verwendet wird (mir ist schon klar, dass der Schalter mit der FW sowohl Switch als auch Remote ist, aber die Hauptfunktion ist immer noch Switch) oder wurde das entsprechend der damit gegebenen Funktionen einfach so definiert?
Greetz,
   Mr. P

DOCa Cola

Ich habe mal Dirks firmware auf meinen Sw1PBU gespielt. Ich glaube allerdings, dass die Firmware statt der LED das relais schaltet. Auf jedenfall geht bei mir das licht etwa im 5 sekunden Abstand an und aus und das Relais klackert.... :D Die LED zeigt hingegen keine funktion.
Ich kann keine vergleiche zur älteren "3rd party firmware" Version ziehen, da ich mit der noch überhaupt keinen Erfolg hatte...

Edit:
so:

#define PORT_STATUSLED       PORTB
#define DDR_STATUSLED        DDRB
#define PIN_STATUSLED        0

Dirk

ZitatIch habe mal Dirks firmware auf meinen Sw1PBU gespielt
Das war aber erstmal der Bootloader.
Damit hast du dann die Firmware mit dem ota-flash-tool geflasht?

Port B.0 sollte passen.
Das muss in "HM-LC-Sw1PBU-FM.h" rein. Meine Angabe da drin stimmen wohl nicht. Hab grade mal in den Schaltplan geschaut. Hätte ich auch vorher schon machen können   ???

Und nach den Änderungen hast du noch mal
make clean HM_LC_Sw1PBU_FM
ausgeführt?

Gruß
Dirk

Update: ich habe das grade auch im git aktualisiert.

DOCa Cola

jo, stimmt, ist echt schon spät. natürlich meinte ich den bootloader.
ich habe schon paar mal im verlauf des tages über OTA eine firmware mit flash-ota reingeladen. Blöderweise ohne zu merken, dass CRC per default verlangt wird. Nachdem nun das Problem mit der LED aus dem weg ist, weiss ich zumindest mal, was vor sich geht. Gerade kompilier ich noch srecord und dann schaun wir mal wie weit ich dann komme :)

Jo, habe immer clean neu gebaut. Alles bestens soweit. Den Bootloader kann man nicht OTA updaten? (hatte damit zumindest noch keinen erfolg).

Wozu ist eigentlich dieses 8k build target?

Dirk

ZitatDen Bootloader kann man nicht OTA updaten? (hatte damit zumindest noch keinen erfolg).
Nein. Mit den Lockbits aus "meiner" README.md kann der Bootloader auch nicht in den Bootloaderbereich schreiben.
Das habe ich gemacht, damit man sich den Bootloader nicht zerflasht falls man z.B. mal ein zu große Firmware flasht.

ZitatWozu ist eigentlich dieses 8k build target?
Nur, falls man noch mal ein bisschen spielen will.
Debug = 2 passt z.B. nicht mehr in 4k rein.

Mr. P

Zitat von: Dirk am 18 August 2014, 01:14:46
Nein. Mit den Lockbits aus "meiner" README.md kann der Bootloader auch nicht in den Bootloaderbereich schreiben.
Das habe ich gemacht, damit man sich den Bootloader nicht zerflasht falls man z.B. mal ein zu große Firmware flasht.
Ich sags ja... Der Bootloader müsste OTA als "Hauptprogramm" in den Schalter geladen werden und wenn nach dem Reset die CRC-Prüfung passt, spielt er sich von selbst in die ersten 4k und startet abermals mit dem neuen Loader neu. Das eigentliche Schalterprogramm ist dann zwar fort, aber das lässt sich ja auch wieder ohne Probleme flashen! :-)

.oO( ich und meine Ideen - irgendwann will mir jemand dafür noch an den Kragen. :-) )
Greetz,
   Mr. P