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

nephdrasil

Reboot habe ich gemacht. Wäre schön wenn du mir weiterhelfen könntest. Mir geht es im Prinzip darum was ich nach dem starten minicom machen muss. DOrt kann ich ja nichts eingeben. Es steht auch da das es offline ist.

@jab ich werde auch deine Variante testen.

Ich habe die befürchtung das der lötkolben und ich nicht die besten freunde sind.
FHEM 5.5 + Fritz Box 7390 + HM-CFG-USB + HM-CC-RT-DN

hanswetter

Hi zusammen,

mit Begeisterung verfolge ich seit einiger Zeit diesen Thread. Vielen Dank und Respekt für die Mühe und das Engagement das in diesem Projekt steckt!!!

Gestern habe ich mich dann entschlossen ebenfalls auch einen Schalter zu flashen:
Nach dem  flashen zunächst ohne #define firstLoad war ich in der Lage zu schalten, hatte aber keine Current-Werte bekommen.
Ein erneutes flashen mit #define firstLoad brachte zwar die erhofften Current-Werte, allerdings kann ich nun nicht schalten (RESPONSE TIMEOUT:RegisterRead bzw. MISSING ACK)
obwohl ich die Schalteraktionen (drücken der Wippe) registriert werden. Ein manuelles Schalten ist über FHEM-GUI nicht möglich.
Reboot, neues Pairing hat leider nichts geholfen.
Weiß jemand Rat? Neu flashen, reseten, irgendwo eine Fehler gemacht (flashen mit und ohne #define firstLoad ?)

Vielen Dank!!

Gruß
Hans

Samsi

hanswetter:

hast du in der regsiter.h die korrekte HMID des HMLAN gesetzt? Bzw. den Aktor noch mal neu mit gepairt?
FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

hanswetter

Hi Samsi,

vielen Dank für deine Antwort!
Wird in der register.h die HMID des Devices oder des HMLANs gesetzt? Ich hatte das so interpretiert, dass dort die Device ID einzutragen ist (Kommentar aus register.h: very important, must be unique. identifier for the device in the network).
Gepairt habe ich den Schalter mehrfach ohne eine Veränderung feststellen zu können. Unter den Internals wird bei IODev auch der HMLAN1 angezeigt. Die Current-Werte auf Channel 4 werden entsprechend angezeigt.
"Nur" das Schalten und die Readings funktionieren nicht.

Gruß
Hans

nephdrasil

Hallo Gemeinde,

ich glaube ich komme meinem Problem näher um mit etwas mit zu loggen.

Ich glaube die Serielle Schnittstelle ist bei mir nicht online. Wie kann ich feststellen das sie genutzt wird bzw. sie nutzen.


Im Programm arduino kann ich bei den Tool Serielle Schnittstelle nichts auswählen. Bei minicom steht auch offline.

Könnt Ihr mir bitte einen Schupps in die richtige Richtung geben.

Ich nutze übrigens einen Raspberry.

So habe jetzt screen noch versucht.  Aber keine Ausgabe.

Keine Ahnung was ich falsch mache. Kann mir jemand helfen komme nicht weiter und weiß nicht woran es liegt.

Schreibe mein vorgehen mal zusammen und poste es hier. ich verstehe es einfach nicht.
FHEM 5.5 + Fritz Box 7390 + HM-CFG-USB + HM-CC-RT-DN

Samsi

@hanswetter:

mit firstload wird immer die Zentrale (bei jedem  start des devices) gepairt die hier angegeben wird:


   reg.ch_0.pairCentral[0] = 0xA1;
   reg.ch_0.pairCentral[1] = 0xB2;
   reg.ch_0.pairCentral[2] = 0x12;
FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

hanswetter


hanswetter

Hallo zusammen,

hat jemand einen Tipp zum Peering der Channels, gerade hinsichtlich einer Wechselschaltung?
Ich habe erst einmal das definierte Peering im Firstload belassen in der Hoffnung nach dem Flashen über FHEM die Konfiguration vorzunehmen.
Leider musste ich feststellen, dass das defnierte Peering in Firstload sich nicht so einfach über FHEM löschen lässt (deleteattr peerIDs). Bei einer neuen Definition eines Peerings tauchen die alten Peerings aus Firstload wieder auf.
Oder habe ich hier einfach zu geringe FHEM-Kenntnisse?

Reicht es für ein Schalten des Aktors über den Taster den Channel 1 und Channel 2, wie folgt zu peeren:

peerdb[0][0] = 0x3meine_Schalter_ID_in_umgekehrter_Bytefolge;
peerdb[1][0] = 0x3meine_Schalter_ID_in_umgekehrter_Bytefolge;
        peerdb[2][0] = 0x01meine_Schalter_ID_in_umgekehrter_Bytefolge;
peerdb[2][1] = 0x02meine_Schalter_ID_in_umgekehrter_Bytefolge;


oder hat das Beispiel aus dem Firstload einen tieferen (mir unerschlossenen) Sinn, da hier wesentlich mehr "gepeert" wird?

LG
Hans

Samsi

Also in einer wechselschaltung musst du die Btn1 und 2 am besten nur mit SW_02 peere und dann die Register einstellen:

also erstmal 0 Sw_02 dual set both bei dem Btn_01

Und dann folgendes bei SW_02
regset shActionType jmpToTarget self01
regset lgSwJtOff on self01
regset lgSwJtOn on self01
Damit ist die obere Wippe immer zum einschalten


Und hiermit die untere Wippe immer zum Ausschalten
regset shActionType jmpToTarget self02
regset lgSwJtOff off self02
regsetlgSwJtOn off self02

Grüße
FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

unimatrix

Hallo,

ich bin erst jetzt auf dieses Thema gestoßen und bin von der Tatsache dass es da eine funktionierende Custom FW mit genau den Features gibt, die mir schon immer gefehlt haben, total begeistert.

Gibt es denn schon/noch Entwicklungen hinsichtlich anderer HM-Hardware? Ich habe einen ganzen Zoo von Aktoren und kann hier gerne meinen Teil dazu beitragen (wenn es an fehlender HW liegt)

Naheliegend wäre ja zunächst der entsprechende Dimm-Aktor, wobei mir klar ist dass Dimmen natürlich wesentlich komplizierter ist als Schalten. Hier wäre es ebenfalls schön, wenn man den internen Taster unabhängig peeren kann.

Das Feature mit dem internen Taster wäre auch bei den "alten" UP-Aktoren toll (hier wird der interne Taster ja über einen externen Eingang realisiert und es gibt wirklich nur EINEN Taster und nicht wie bei den neuen Aktoren zwei Taster(-stellungen). Bei den Schaltern ist ja der Longpress total ungenutzt. Abgesehen davon wäre wünschenswert. Was ich sagen will: Anwendungsfälle gäbe es genügend.

VG

jab

Hi unimatrix,

Wenn du die Firmware auf andere Hardware portieren willst dann helfe ich gerne. Für mich reicht mein Schalter. Das sollte technisch bei vielen Aktoren funktionieren.

Ich werde in nächster Zeit noch ein paar Bugs fixen und Tests schreiben.


Gruß
Jan

unimatrix

Dimmer ist sicher eine ganz andere Sache, ich werd demnächst mal den 2-Kanal UP Aktor auseinandernehmen und schauen welche CPU drin ist und dann mal weitersehen...

Nochmals vielen Dank!

Mr. P

Hej folks,

nach einigen hin und her ist es mir nun auch endlich gelungen, meine Schalter von der neuen Firmware zu überzeugen. :-)

Jetzt habe ich allerdings zwei Fragen, zu denen ich keine zufriedenstellenden Antworten finden konnte:
1) bin ich auch schon auf das Reboot-Problem gestoßen und wollte fragen, ob es dafür schon eine Lösung gibt und
2) eine Verständnisfrage: Wenn ich den Schalter mit anderen Geräten peere und ich möchte zB kurz oben für den internen Schalter verwenden, kurz unten für einen Zwischenstecker und lange oben und unten zum Steuern eines Rollladen-Aktors, dann wird doch immer an alle von dem Button angelernten Aktoren ein Funkbefehl gesendet und erst dort entschieden, ob reagiert wird, oder? Also zB Button_2 ist mit dem Zwischenstecker und mit dem Rollladenschalter gepeert. Der Zwischenstecker soll bei Short toggeln, der Rollladen-Aktor auf Long den Rollladen hinunter fahren lassen. Dann würde der Funkschalter zB bei einem Short doch an beide Peers senden und erst dort wird entschieden, ob darauf reagiert wird, oder?

Vielen Dank für Eure Antworten!
Greetz,
   Mr. P

jab

Hi,


Zitat von: Mr. P am 10 Juni 2014, 14:17:03
nach einigen hin und her ist es mir nun auch endlich gelungen, meine Schalter von der neuen Firmware zu überzeugen. :-)
Super :-). Woran lag es denn am Ende?

Zitat von: Mr. P am 10 Juni 2014, 14:17:03
Jetzt habe ich allerdings zwei Fragen, zu denen ich keine zufriedenstellenden Antworten finden konnte:
1) bin ich auch schon auf das Reboot-Problem gestoßen und wollte fragen, ob es dafür schon eine Lösung gibt und
Ich habe den Code aufgenommen. Rebooten sollte er. Allerdings habe ich den gesamten FHEM Firmwareupdate Prozess noch nicht implementiert. Das muss ich die Tage mal machen. Sind ein paar Änderungen am Bootloader. Ich habe das bisher selber noch gar nicht mit FHEM getestet. Hole ich noch nach.

Mit flash-ota aus hmland geht es bei mir hervorragend. Das war bisher mein Referenz Tool.

Zitat von: Mr. P am 10 Juni 2014, 14:17:03
2) eine Verständnisfrage: Wenn ich den Schalter mit anderen Geräten peere und ich möchte zB kurz oben für den internen Schalter verwenden, kurz unten für einen Zwischenstecker und lange oben und unten zum Steuern eines Rollladen-Aktors, dann wird doch immer an alle von dem Button angelernten Aktoren ein Funkbefehl gesendet und erst dort entschieden, ob reagiert wird, oder? Also zB Button_2 ist mit dem Zwischenstecker und mit dem Rollladenschalter gepeert. Der Zwischenstecker soll bei Short toggeln, der Rollladen-Aktor auf Long den Rollladen hinunter fahren lassen. Dann würde der Funkschalter zB bei einem Short doch an beide Peers senden und erst dort wird entschieden, ob darauf reagiert wird, oder?
Ja genau so ist es. Der Aktor entscheidet, ob er reagiert oder nicht. Mit Festhalten beim Longpress gibt es möglicherweise noch Bugs. Wenn du da Probleme hast sag Bescheid. Es funktioniert mit meinen Originalaktoren, aber das sind nur Schalter. Leider habe ich keine HM Remote und daher wenig als Referenz.


Gruß,
Jan

Mr. P

Zitat von: jab am 10 Juni 2014, 18:00:28
Super :-). Woran lag es denn am Ende?
Nachdem ich das Ganze mit meinem Raspberry gemacht habe, musste ich erst noch eine angepasste Version vom avrdude installieren, da es mit der aus dem Raspbian-Repository nicht funktioniert. Und dann hatte ich das große Glück, eine Version zu erwischen, bei dem die GPIO-PINs im avrdude anders definiert waren, als scheinbar bei den meisten anderen Versionen. Dadurch konnte nach dem Flashen kein Reset gemacht werden und ja... wo kein Reset, da auch keine Erfolg. :-)
Ich werde auf alle Fälle das WIKI noch entsprechend anpassen, damit zukünftige Bastler nicht mehr darüber stolpern.

Zitat von: jab am 10 Juni 2014, 18:00:28
Ich habe den Code aufgenommen. Rebooten sollte er. Allerdings habe ich den gesamten FHEM Firmwareupdate Prozess noch nicht implementiert. Das muss ich die Tage mal machen. Sind ein paar Änderungen am Bootloader. Ich habe das bisher selber noch gar nicht mit FHEM getestet. Hole ich noch nach.
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.

Zitat von: jab am 10 Juni 2014, 18:00:28
Mit flash-ota aus hmland geht es bei mir hervorragend. Das war bisher mein Referenz Tool.
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? :-)

Zitat von: jab am 10 Juni 2014, 18:00:28
Ja genau so ist es. Der Aktor entscheidet, ob er reagiert oder nicht. Mit Festhalten beim Longpress gibt es möglicherweise noch Bugs. Wenn du da Probleme hast sag Bescheid. Es funktioniert mit meinen Originalaktoren, aber das sind nur Schalter. Leider habe ich keine HM Remote und daher wenig als Referenz.
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.
Greetz,
   Mr. P