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

[unimatrix]

Wenn das dein erstes Device ist, dann ist es vll ein wenig viel auf einmal. Um den Schalter  mit einer immerhin von Nutzern selbst geschriebenen Firmware in Betrieb zu nehmen ist schon etwas mehr FHEM (und vor allem aber Homematic-Wissen) erforderlich als bei dem SChalter mit der Hersteller-Firmware, der ja auch so schon "einfach funktioniert" (dann allerdings auch nicht mehr)

Du solletst du unbedingt den Homematic-Teil, insbesondere das Peering, in "Heimautomatisierung mit FHEM" durchlesen. Das ist also der Anhang, der ist dafür am wichtigsten.

http://fhem.de/Heimautomatisierung-mit-fhem.pdf

Bevor du irgendwas mit  Peering machst musst du sichergehen, dass der Schalter überhaupt korrekt eingebunden ist. Wenn dein Custom-FW File nicht korrekt geladen wurde dann muss das zunächst geschehen.

Der Schalter muss als 1 Device mit 2 Aktorkanälen und 2 Buttons erscheinen und als Modell "HM-LC-Sw1PBU-FM-CustomFW" (Attribut) eingetragen sein.

Sobald das so ist, kannst du einen internen Taster mit einem der internen Aktorkanäle peeren. Z.B. "set <button1> peerChan 0 <aktor_virtuell> single set" (<button1> und <aktor_virtuell> hier entsprechend durch deine Kanalnamen ersetzen). Sobald das peering da ist, müssen ggf. noch die Einstellungen davon angepasst werden, denn du musst ja auch definieren was der Taster bei Tastnedruck genau bewirken soll. Homematic bietet hier sehr viele möglichkeiten, dementsprechend ist ein gewisses Verständnis erforderlich. Ich bin mir gerade nicht sicher, ob in der "stable"-Release des Schalters von Jan sinnvolle Defaultwerte für das Peering drin stehen.

[Mr. P]

Ja, ich hatte die Datei auch im FHEM Verzeichnis. Trotz dessen wurde der Schalter als unknown model erkannt. Ich weis jetzt auch nicht ob es daran liegt.
Naja, ich hatte Probleme den Schalter mit FHEM zu pairen. Ich habe aufgrund dessen den Schalter mit hmsniff mal beobachtet. Mir ist unklar wie ich ihn dazu bringen kann, dass er sich paired. Irgendwie hat es dann doch geklappt.

Da kann ich dir nur beipflichten... Beim ersten HB-Device ist bisschen Fingerspitzengefühl gefragt, bei allen weiteren geht es dafür umso einfacher.

Wie kann ich denn z.B einen physischen Schalter dazu bringen, dass er mir das Relais schaltet? Ich habe mich schon wieder durch etliche Seiten gelesen, aber konkret habe ich es nicht gefunden. Man muss den Schalter (Button) irgendwie mit dem switch pairen. Aber wie?

Gepairt wird immer nur gegen die Zentrale. Wenn du Devices untereinander direkt verbindest (auch wenn es nur virtuelle Verbindungen wie bei dem Schalter sind) dann wird gepeert - über diese Feinheit stolpern beinahe alle Einsteiger.

Irgendwie scheint es ja auch möglich sein den current auszulesen. Aber wo?
In der Readme steht: "Showing current sensor value in FHEM. (Copy device config below)."
Welche 'device config' ist damit denn gemeint (im text kommt nix mehr)? Die Datei hab ich schon in FHEM.

Falls du die Version von unimatrix verwendest, kann ich mich dunkel daran erinnern, dass er einmal zu seiner Version geschrieben hatte, dass current noch nicht funktioniert (bitte nicht schlagen, falls ich gerade Blödsinn schreibe). Falls doch, müsste es im zweiten Switch, also Kanal 04 stehen.

Ich habe 5 FHEM devices durch den Schalter. 1x das Gerät selbst, 2x button und 2x switches. In keinem habe ich eine current anzeige gesehen.

Durch den Schalter hast du 5 "Geräte". Das physikalische Gerät ist von der Bezeichnung her das ohne Zusatz im Namen und außerdem auch gut durch die 6-stellige HMID erkennbar. Über die restlichen vier "Kanäle" werden die Funktionen der Aktoren und Sensoren abgebildet.
Um daher das Relay des Schalters mit den Taster nutzen zu können, musst du zumindest einen der beiden Buttons mit dem ersten der Switches peeren.
Am besten siehst du dir mal die Anfängerdoku an, dann kommst du recht schnell dahinter, wie das klappt (und deinem Beiträgen nach zu urteilen bist du nicht jemand, der zwei linke Hände hat).

[jab]

Moin,

Das ich wenig schreibe liegt daran dass ich mal wieder unterwegs bin. Aktuell im Urlaub in Griechenland. Übernächste Woche bin ich mal wieder im Land. Habe den Pull Request gemerged und dir Rechte gegeben. Unimatrix hat ansonsten auch Rechte. Wenn ihr Lust habt können wir kurz nach Weihnachten auf dem CCC Congress in Hamburg ein kleines Entwicklertreffen veranstalten.

@unimatrix: Im default gibt es kein Peering mit dem Aktor selber. Wenn man peert habe ich die gleichen defaults wie normale Aktoren. Wenn du willst können wir deine Version auch mergen.

Gruß
Jan

[Dirk]

Aktuell im Urlaub in Griechenland.

Unserer ist leider schon vorbei   

Habe den Pull Request gemerged und dir Rechte gegeben.

Cool, danke.

Wenn ihr Lust habt können wir kurz nach Weihnachten auf dem CCC Congress in Hamburg ein kleines Entwicklertreffen veranstalten.

Klingt interessant. Könnte man ja mal einplanen.

Gruß
Dirk

[DOCa Cola]

Danke Mr. P & unimatrix für die hilfreichen Tipps
Ja, das Gerät ist in FHEM wunderbar erkannt. Ich werde mir die Doku mal Gemüte führen und dann mal mein Glück versuchen.

Der Bootloader macht auch keine Probleme soweit. Hatte noch ein paar 'resets' gemacht - also Sicherung raus um Schalter wieder ordentlich einzubauen - und bootet immernoch alles wie gehabt. Kann da also grünes Licht geben für alle die Dirks Bootloader Variante nutzen wollen.

[Mr. P]

Ein paar Gedanken für zukünftige Versionen:
Ich behaupte an der Stelle, dass der zuletzt von Dirk bearbeitete Bootloader sich zukünftig auf etlichen Devices einfinden wird. Ganz gleich ob HB- oder HM-Devices.
Bislang ist es bei den Sw1PBU's so, dass im Grunde sowohl für den Bootloader als auch für das Hauptprogramm unabhängig voneinander ID's vergeben werden können.
Wenn jetzt aber die letzten Bytes des BL zum Speichern eben dieser Infos verwendet werden und sowohl der BL als auch das Hauptprogramm darauf zugreifen (was ja auch äußerst sinnvoll ist), würde man für zukünftige Versionen des Hauptprogramms nicht um den neuen Bootloader herum kommen und somit ist ein neuerliches Flashen mit dem Programmer unumgänglich, oder?

[Dirk]

... würde man für zukünftige Versionen des Hauptprogramms nicht um den neuen Bootloader herum kommen und somit ist ein neuerliches Flashen mit dem Programmer unumgänglich, oder?

Naja, man kann in das Hauptprogramm ja auch weiterhin die Adresse fest einprogrammieren. Wenn man den Bootloader nicht ändern will / kann.
Dann bleibt alles wie beim alten.

Für das Flashen des Bootloaders braucht man sich aber nicht unbedingt einen ISP zuzulegen.
Man kann auch z.B. einen Arduino zu einem ISP machen. Auch mit den GPIO-Pins vom Raspberry-Pi und einem angepassten AVRDUDE kann man den Bootloader aktualisieren.

Gruß
Dirk

[Mr. P]

Man kann auch z.B. einen Arduino zu einem ISP machen. Auch mit den GPIO-Pins vom Raspberry-Pi und einem angepassten AVRDUDE kann man den Bootloader aktualisieren.

Schon klar... Wollte nur verdeutlichen, dass man um das Schalter aus der Wand nehmen und PINs anlöten nicht herum kommen wird.

[unimatrix]

also ein einziges mal muss man ja an jeden Schalter den ISP anlöten (egal ob selbstgebaut, Pi, etc.).

Wer einen alten Bootloader drin hat, kann den behalten. Er muss dann (so wie vorher auch) sicherstellen, dass Serial, HMID, etc. fest in der Applikation vorgegeben sind. Updated er auf einen neuen BL, hat er die Flexibilität, diese Daten weiterhin in der App fest einzukodieren oder die Daten aus dem BL-Bereich zu holen.

Ich habe übrigens an dem sich selbst updatedenden Bootloader gearbeitet. Erste Tests waren erfolgreich, was mir allerdings noch unklar ist, ist, wie man so ein BL-Update Package dass ja dann per eq3 File auf den Chip muss am besten gestaltet.

Im Moment favorisiere ich, den Bootloader "ganz normal zu bauen" aber eben mit dem .text-Segment ab Adresse 0x0000 und weiterhin einem Magic Word an einer anderen bestimmten unbenutzten Flash-Adresse. Dieses WOrd signalisiert quasi "Bootloader wurde OTA in Applikations-Speicher geladen und ist bereit, in den BL Bereich verschoben zu werden". Beim Starten des Chips wird ja sowieso zuerst der BL im oberen Bereich gestartet, dieser prüft dann als erstes, ob das Magic Word gesetzt ist, wenn ja, wird das Word gelöscht und der Kopiervorgang gestartet, der Rest vom Flash gelöscht, nach ABschluss wird der WD-Reset ausgeführt und somit der neue BL gestartet.

[Mr. P]

Ich habe übrigens an dem sich selbst updatedenden Bootloader gearbeitet. Erste Tests waren erfolgreich, was mir allerdings noch unklar ist, ist, wie man so ein BL-Update Package dass ja dann per eq3 File auf den Chip muss am besten gestaltet.

*huch* - und ich wollte einfach nur einmal meinen Gedanken freien Lauf lassen... und jetzt wird wirklich an einer möglichen Umsetzung gearbeitet?
Leute... Ihr seid echt ein Wahnsinn!

[Dirk]

Beim Starten des Chips wird ja sowieso zuerst der BL im oberen Bereich gestartet, dieser prüft dann als erstes, ob das Magic Word gesetzt ist, ...

Hier brauchst du noch nicht mal ein "Magic Word". Das "Hauptprogramm" mit der Bootloader-Aktualisierung besteht nur aus einer Sprungadresse zum 2. Bootloader und den Bootloader-Daten an einer festen Adresse.
An eine weitere festen Adresse schreibst du noch die Länge und die Checksumme des neuen Bootloaders.

Nach dem Sprung zu Bootloader2 schaut dieser in der Adresse mit Länge und CRC, prüft den CRC mit den Daten vom neuen Bootloader und schreibt diese in Position vom Bootloader 1
Anschließend muss der Bootloader 2 noch die Page mit Sprungadresse ungültig machen, damit der 2. Bootloader nicht mehr angesprungen wird.

was mir allerdings noch unklar ist, ist, wie man so ein BL-Update Package dass ja dann per eq3 File auf den Chip muss am besten gestaltet.

Dieser besteht "nur" aus
.text an 0x0000 (hier steht nur der sprungbefehl zur adresse von Bootloader 2
.infoData an z.B. 0x0FF0 hier steht nur die länge des neuen Bootloaders und die CRC-Checksumme
.blData an z.b. 0x1000 ab hier stehen dann die Daten des neuen Bootloaders.
.crcData das ist der CRC vom Bootloader-Aktualisierungs-Hex-file. So wie bisher auch.

Gruß
Dirk

[unimatrix]

habs jetzt anders gelöst. Was ich vorher geschrieben war war natürlich Quatsch. Habe es so gelöst dass das Bootloader-Hex file nur einmal existiert, egal ob es per OTA oder ISP geflasht wird. Für OTA wird es dann mit sreg_cat entsprechend bearbeitet (offset in den RWW-Bereich, usw.)

Checke es in einen Branch ein sobald es läuft und getestet ist.

[unimatrix]

Zwischenstand: Nach dem löschen der ersten Page (ab BOOTLOADER_START) macht das Dingen nix mehr...Interrupts natürlich alle deaktiviert, nur inline Code, usw. Werde weiter frickeln. (Per avrdude Hexfile zurückgelesen und festgestellt, dass 1. Page gelöscht wurde)

[DOCa Cola]

Der Verweis auf den Homematic Anhang in der FHEM Doku hat mir sehr geholfen. Ich hab trotzdem nochmal eine vermutlich recht generelle Frage dazu.
Ich will mir jetzt für den kurzen (normalen) Tastendruck eines der Schalter des Sw1PBU nun eine FHEM Aktion hinterlegen.
Ich war der Annahme, dass ich das nun so lösen könnte:

Code Auswählen Erweitern

define LichtTest notify LichtschalterBtn1:Short.* set Deckenlampe rgb FFC148
So wird es glaube ich bei anderen Homematic Fernbedienungen auch gelöst. Jedoch wenn ich ein Log an einen der Buttons dranhänge sind mir dort garkeine events angezeigt. Wo liegt jetzt also der Fehler? Muss ich die FHEM zentrale (den hm usb stick) irgendwie als Aktor hinterlegen?

[Bennemannc]

Hallo,

die geänderte Firmware hast Du aber draufgespielt oder ? Mit der Original-Firmware kommt man nämlich nicht an die Tasterevents dran. Deswegen gibt es ja diesen Thread.

Gruß Christoph