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

[jab]

Ich werde auf alle Fälle das WIKI noch entsprechend anpassen, damit zukünftige Bastler nicht mehr darüber stolpern.
Genau. Reboot wird (allem Anschein nach) aus FHEM ausgelöst, aber dann kommt es eben zu dem schnellen geblinke vom LED und ohne stromlos machen, geht nichts mehr.

Top!

Vermutlich hab ich das in dem langem Thread einfach überlesen, aber wie kann ich den Schalter OTA flashen, wenn er erst einmal in der Wand versenkt ist? Solange die PINs angelötet waren, war das ja kein Problem (zuerst den Bootloader mit dem Raspberry und dann über flash-ota die Firmware). Aber jetzt? Wie kann ich ihn neu starten und bekomme ihn lauschend ohne FHEM?

Sicherung raus und wieder rein geht . Ich muss das mal ausführlicher testen. Vermutlich springt er nicht richtig in den Bootloader. Ich teste es die Tage.

Vielleicht stelle ich mir das gerade auch vieeel zu einfach vor, aber wäre es aber nicht besser, wenn bereits der Schalter entscheidet, an wen die Nachricht gehen soll? Würde unnötigen Funkverkehr ersparen.

Möglich ja aber nicht vorgesehen im HM Protokoll. Allerdings kann man vieles (nicht alles) auch an Broadcast senden, dann geht es nur einmal durch die Luft.


Gruß,
Jan

[Mr. P]

Sicherung raus und wieder rein geht . Ich muss das mal ausführlicher testen. Vermutlich springt er nicht richtig in den Bootloader. Ich teste es die Tage.

Nur gut, dass meine Lampen an einer eigenen Sicherung hängen.

Wofür eigentlich der battery- und sign-Register?
battery nehm ich an, ist einfach noch nicht raus geflogen, aber sign? Weiß deine Firmware mit der Verschlüsselung umzugehen?

[jab]

Die Register sind von dem ursprünglichen Register Set von homematic. Die kann man auch nicht so einfach ändern. Signieren und Verschlüselung unterstützt die Firmware nicht. Wollte ich aber noch mal Reverse engineeren. Ist aber sicher nicht einfach.


Gruß
Jan

[Mr. P]

Also ich bin auch schon so

Die Register sind von dem ursprünglichen Register Set von homematic. Die kann man auch nicht so einfach ändern. Signieren und Verschlüselung unterstützt die Firmware nicht. Wollte ich aber noch mal Reverse engineeren. Ist aber sicher nicht einfach.

Nicht, dass es egal wäre, aber jetzt hast du meine Neugierde geweckt. Ich hab zwar diesen Schalter nicht mehr mit originaler Firmware hier, aber es gibt doch andere Geräte, die ohne Batterie auskommen und bei denen steht dann auch nicht kein 'battery' im Device. Wie meinst du das also mit 'ursprünglichen Register Set'?!
Verschlüsselung ist sicher ein großer Brocken. Und ganz ehrlich, du kannst schon äußerst zufrieden sein mit dem, was du bislang geschafft hast! *thumbsUp*

[Mr. P]

Hej folks,

jetzt brauch ich nochmal eure Hilfe.
Mittlerweile hab ich auch einen zweiten Schalter geflasht und im Laborbetrieb (dH mit angelöteten PINs am Raspberry) tut er, wie er soll.
Sobald ich ihn aber gemeinsam mit dem Relais-Modul in die Wand verfrachte und die Sicherung einschalte, gibt er keinen Laut mehr von sich.
Ich hab auch schon das Relais-Modul vom zweiten Schalter (wo ich ja weiß, dass es funktioniert) probiert. Selbes Ergebnis - bleibt dunkel.
Hänge ich ihn aber wieder zurück an den Raspberry, lässt er sich normal bedienen.
Hat jemand einen Tipp für mich, was ich vielleicht übersehe? Alles bisschen Vodoo hier.

Vielen Dank!

[Bennemannc]

Hallo,

ich hatte letztens ein ähnliche Problem - ich hatte mir die Teile als Bausatz beschafft. Zusammengelötet, mit "fliegender" Verdrahtung getestet (nicht nachmachen, ich darf das, ich habe Elektriker gelernt), alles funktioniert. Eingebaut - alles gut, nach ca. einem Tag, kein Kontakt mehr. Getauscht, mit dem zweiten das gleiche Spiel.
Nach längerem Suchen, habe ich festgestellt, das die Steckverbindung zwischen der Elektronik-Platine und der Leistungsplatine (230 V) ziemlich knapp ist und die Kabel so viel Zug über die Klemmleiste auf diese Verbindung ausübten, das kein Kontakt (also Spannungsversorgung) der Elektronik-Platine mehr gegeben war.
Gelöst habe ich das damit, das ich die Steckerleiste (die Seite wo nicht das Relais ist) etwas entfernt von der Platine angelötet habe. 1 bis 2 mm reichen.

Gruß Christoph

[jab]

Abend,

sieht mir in auch eher nach einem Hardware Problem aus. Auf der Relais Platine ist nichts für den Betrieb des Controller wichtiges. Abgesehen natürlich von der Spannungsversorgung. Entweder ein Verbindungsproblem wie Bennemannc schreibt oder der Spannungswandler hat einen abbekommen.


Gruß,
Jan

[Mr. P]

Hej Bennemannc,
hej Jan,

vielen Dank für eure Antworten.
Nachdem ich Bennemannc's Antwort gelesen hatte, hab ich mich noch etwas mit den Verbindungskontakten beschäftigt, in der Hoffnung, es doch noch zu schaffen. Aber bislang - ohne herum zu löten - ist es mir nicht gelungen, eine Besserung zu erzielen. :-/

Entweder ein Verbindungsproblem wie Bennemannc schreibt oder der Spannungswandler hat einen abbekommen.

Aber der Wandler ist doch auf der Relais-Platine und die hab ich ja bereits mit der vom funktionierenden Schalter ausgetauscht.

Edit:
Gerade den Schalter zerlegt und "fliegend" angeschlossen. Testweise sogar den Abstandshalter weggelassen, nur um sicher zu gehen, dass es sich um keinen Kontaktfehler handelt. Aber ganz egal, was ich mache... Keine Reaktion. :-/

[Bennemannc]

Hallo,

bei dem Bausatz ist ein Schaltbild dabei - wenn Dir das weiter helfen würde, könnte ich das posten (erst heute Nachmittag).

Gruß Christoph

[Mr. P]

Gerne... Ist einen Versuch Wert!

Vielen Dank!

[Bennemannc]

Hallo Mr. P,

hier kommt der versprochene Schaltplan

Gruß Christoph

[Mr. P]

Passt!

Nochmals vielen Dank!

[Mr. P]

Hej zusammen,

also es geschehen doch noch Zeichen und Wunder... auch wenn der Weg dorthin äußerst steinig ist.

Vorab: Der Schalter ist in der Wand versenkt und er funktioniert.

Was war letztendlich der Fehler?
Ich hab mir meinen OTA-Bootloader selbst auf meinem RaspberryPI gebaut und dabei passt offensichtlich irgend etwas nicht.
Erst als ich mir den Bootloader von Jan geflasht hab, lief alles wie am Schnürchen. Offensichtlich hab ich meinen ersten Schalter auch noch mit dem Bootloader von Jan geflasht.
Interessant ist nur, dass wenn ich meinen Bootloader flashe, kann ich anschließend die Firmware OTA draufspielen und auch konfigurieren. Solange der Schalter nicht völlig stromlos ist und ich ihn wieder anstecke, funktioniert alles weiter.
Kaum vom Strom getrennt, leuchtet zwar das LED beim Neustart kurz auf, mehr passiert aber auch schon nicht. Weder ist ein neuerliches Flashen möglich, noch lässt sich das Gerät bedienen.
Soviel also dazu....

Nun sind mir bei dem Schalter ein paar Dinge aufgefallen, die im laufenden Betrieb noch nicht ganz passen. Könnte natürlich auch zum Teil an dem CUL_HM-Modul-Problem liegen.
Also:
Ich hab den Schalter so konfiguriert, dass der obere Taster das interne Relais steuert, während der Untere einen Zwischenstecker ein- und ausschaltet.
Wenn ich jetzt den Raum verlasse und beide Taster drücke, passieren zwei Dinge:
1) nachdem die beiden Taster recht flott hintereinander gedrückt werden, wird der zweite Befehl oft nicht angenommen und
2) wenn ich den oberen Taster ein paar Mal hintereinander drücke, stimmt dann oftmals der tatsächliche Ralaiszustand nicht mit dem Wert überein, der an FHEM übermittelt wurde.

Weiters habe ich noch eine ganz interessante Beobachtung gemacht. Der Schalter lässt sich zur Zeit nicht pairen (R-pairCentral   0x0). Hab mir zwar vorhin die aktuelle CUL_HM.pm aus dem SVN geholt, aber entweder liegt es am File für die Alternative-FW oder es ist wohl immer noch was nicht ganz in Ordnung. Dadurch vermute ich einmal, ist auch Channel 4 leer.
Und jetzt kommt das ABER: Trotz fehlendem Pairings, kann ich den Schalter ein- und ausschalten, kann die Peerings setzen UND bekomme die Status-Meldungen vom Relais trotzdem an die Zentrale geschickt:
deviceMsg   on (to myHM)

So... jetzt bin ich hier einiges losgeworden und gespannt, was ihr darüber denkt bzw. was ihr dazu zu sagen habt.

Und nochmals vielen Dank an alle, die hier mit Rat und Tat zur Seite stehen!

[Mr. P]

Hej,

bin gerade ein wenig durch meine Devices "geschlendert" und dabei ist mir bei dem Schalter eine Sache aufgefallen:

Code Auswählen Erweitern

avg:-39.21 min:-45 max:-36 lst:-38 cnt:10379
Seit dem letzten Neustart von FHEM wurden über 10000 Nachrichten vom Schalter empfangen.

Eine meiner Funksteckdosen (HM-ES-PMSw1-Pl) hat hingegen nur knappe 1300 Nachrichten gesendet.

Code Auswählen Erweitern

avg:-51.66 min:-64 max:-48 lst:-51 cnt:1266

Ist es denn wirklich notwendig, dass der Schalter mehr als 8x soviele Nachrichten versendet, als es andere Devices tun, die ebenfalls am Netz hängen?
Nicht nur, dass es sich dabei um erhöhte Funklast und damit womöglich einhergehende Störungen anderer Devices einhergeht (ein Schalter sendet X Nachrichten, vier solcher Schalter entsprechend mehr), aber - ohne es jetzt kontrolliert zu haben - wie sieht es denn mit der 1%-Regel aus? Läuft man nicht Gefahr, bereits über die Grenze hinaus zu schießen?

@Jan: Was hältst du davon, die Sendefrequenz um - sagen wir - Faktor 8 zu reduzieren? Dann hätten wir ungefähr die selbe Häufigkeit, wie auch vom Zwischenstecker.

[mmattern]

Hallo zusammen,

bin wirklich beeindruckt, was ihr hier mit der Custom-Firmware auf die Beine stellt...
Ich habe es mittlerweile geschafft, den Bootloader zu erzeugen und flashen (direkt mittels GPIO-Pins am Raspberry)...
Wenn man mehr als einen Schalter modifiziert, muss man das wohl sowieso tun - und mit einer angepassten Version je Schalter,
da in der Funktion "send_bootloader_sequence" (in "bootloader.c") in der Message, auf die das Flash-Tool wartet, HMID und Serial kodiert sind, korrekt? Ebenso die hmid (ganz am Anfang von "bootloader.c")...

Der Bootloader markiert seinen Start auch korrekt durch Blinken - habe testweise mal ein "kurz-lang-kurz"-Muster implementiert, das auch korrekt ausgeführt wird, also bin ich sicher, dass der Schalter nach dem Start in den Bootloader springt...

Flashen der Firmware funktioniert dann nicht...

Ich würde nun mal gern per UART nach Debug-Meldungen schauen, aber zumindest auf dem Raspberry (per screen oder minicom) sehe ich nichts...
GPIO #14/15 = Pins 8 und 10 für TXD und RXD an MP10 bzw. MP9 und MP16 an GND
Ich habe sichergestellt, dass das OS das Device ttyAMA0 nicht belegt (über /boot/commandline.txt und /etc/inittab, vgl. z.B. http://www.hobbytronics.co.uk/raspberry-pi-serial-port) und auch mal die grundsätzliche Funktion des UART getestet, indem ich direkt TXD und RXD verbunden habe... dann zeigt minicom genau, was getippt wird.

Nutzt sonst jemand den UART des Raspberry oder was hat sich bei euch bewährt?

Nachdem das OTA-Flashen nicht funktioniert hat, habe ich testweise auch direkt die Firmware-Datei (einmal von hier: https://owncloud.isengard.at/public.php?service=files&t=0df535e31ad6999664f0e84c95bd2ea5, einmal selbst mit Arduino erzeugt) geflashed, dann klappt aber das Pairing nicht (über HM-LAN-CFG). Weder pairForSec noch pairSerial haben irgendeinen Effekt.
Wenn ich das Device manuell in der fhem.cfg anlege, ist es ebenfalls nicht funktionsfähig.

Ich habe in der Firmware nicht gefunden, wie das Pairing am Device initialisiert werden kann (z.B. Config-Button betätigen wie in der Original-Firmware) - habe ich es nur übersehen oder könnt ihr mir einen Tipp geben?
Auch hier sehe ich übrigens keinerlei Debug-Meldungen über UART... kann ich irgendwie testen, ob der Schalter überhaupt was sendet über Serial?

Wäre echt cool, wenn ihr mir hier einen Tipp geben könntet...

Viele Grüße
Michael

P.S.:
Ich habe eine prototypische Version für OTA-Flash per FHEM geschrieben (basierend auf flash-ota und dem bestehenden fwUpdate für andere Schaltertypen) - sobald das funktioniert, teile ich natürlich gern... aber eben noch Debugging notwendig, was ohne UART schwierig wird