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

[mmattern]

Das habe ich probiert, bislang ohne Erfolg. Ich bin nicht sicher, ob ich die richtige Serialnr verwende.
Laut Firmware-Doku soll der Schalter auf KEQ0123456 hören. In FHEM sehe ich den Schalter mit PairSerial=PS0000002. Aber mit keiner der beiden Nummern gelingt mir ein Pairing. In den Readings des Schalters bleibt es stets bei Paired To 0x0, was wohl die Datentelegramme mit dem Broadcast erklärt.

Die Firmware unter https://owncloud.isengard.at/public.php?service=files&t=0df535e31ad6999664f0e84c95bd2ea5 hat auf jeden Fall KEQ0123456... Wenn dann bei dir in FHEM noch PS0000002 steht, solltest du das ändern...

[Pairing] ... wie mache ich das? Vom Device aus?

Du kannst in FHEM auf der Seite des Devices unter "set" "pair" auswählen... das müsste ebenfalls den Pairing-Vorgang auslösen... vorher hmPairSerial am HMLAN auslösen mit der richtigen Serial...

Aber Mr. P hat schon einen Punkt - Firmware selbst bauen und darin (im File Register.h direkt vor der Zeile

Code Auswählen Erweitern

static void mainSettings(uint16_t *regPtr, uint16_t *peerPtr) { #firstLoad definieren sowie dann ein paar Zeilen weiter unten die pairCentral setzen funktioniert ganz sicher!

Weiter oben im Thread (http://forum.fhem.de/index.php/topic,18071.msg179182.html#msg179182) habe ich ein paar Punkte zusammengefasst, über die man beim Selbstbauen  stolpern könnte...

Viel Erfolg!

[Cyberman]

Du kannst in FHEM auf der Seite des Devices unter "set" "pair" auswählen... das müsste ebenfalls den Pairing-Vorgang auslösen...

Dabei erhalte ich folgende Fehlermeldung:

Code Auswählen Erweitern

serialNr is not set

Vorher habe ich beim Schalter

Code Auswählen Erweitern

attr SerialNr KEQ0123456
gesetzt.

[mmattern]

Dabei erhalte ich folgende Fehlermeldung:

Code Auswählen Erweitern

serialNr is not set

Vorher habe ich beim Schalter

Code Auswählen Erweitern

attr SerialNr KEQ0123456
gesetzt.

Ok, genau das hatte ich auch mal - das Device spuckt diese Meldung aus, wenn es intern die "pairCentral" nicht gesetzt hat... das ist z.B. "heilbar" über die von Mr. P genannte #firstLoad-Methode...

Probiere mal die FW im Anhang - vorher Device aus FHEM löschen.

Die Firmware enthält ein Device mit Serial KEQ0123456, pairCentral 2577F0 (dein HMLAN) und HMID 2A32EA...

[unimatrix]

hatte ja das Problem, dass sobald ein Button mit dem internen Aktor gepeert war, dass dann der Tastendruck nicht mehr gesendet wurde.

Daraufhin habe ich dann den hmlan als peer eingetragen, was ja geht, und auch funktionierte, aber zu verzögerungen führte.

Als unsaubere Lösung habe ich nun erstmal eingebaut, dass, auch wenn es Peers gibt, immer an Broadcast gesendet wird (die entsprechende Bedingung in send_peer_poll() in Asksin.cpp habe ich einfach entfernt.

Löst zumindest mein unmittelbares Problem und ich kann jetzt in FHEM auch zusätzlich auf die Tastendrücke reagieren....

[Cyberman]

Ich bin nun weitergekommen, vielen Dank für die helfenden Beiträge hier!

Die auf meine HMID gepatchte Firmware habe ich (noch) nicht eingespielt, das Pairing ist mir nun doch auf dem regulären Weg gelungen:
Stromzufuhr des Schalters unterbrochen und kurz nach dem Wiedereinschalten die Config-Taste gedrückt, damit klappte nun das Pairing.
Seltsamerweise ist als SerialNr PS00000002 eingetragen. Ich hatte hier eigentlich KEQ0123456 erwartet. Bin gespannt, wie ich das Problem löse, wenn ich mehr als einen Schalter integrieren will (folgt noch).

Nun will ich aber erstmal die angepeilte Wechselschaltung fertig realisieren.

Code Auswählen Erweitern


Readings
CommandAccepted yes 2014-07-11 21:04:51
D-firmware 1.5 2014-07-11 21:04:45
D-serialNr PS00000002 2014-07-11 21:04:45
PairedTo 0x2577F0 2014-07-11 21:06:02
R-pairCentral 0x2577F0 2014-07-11 21:04:51
RegL_00: 02:01 05:00 0A:25 0B:77 0C:F0 12:00 00:00 2014-07-11 21:06:02
state CMDs_done 2014-07-11 21:06:14


Bei der Arbeit mit dem Schalter auf dem Schreibtisch ist mir aufgefallen, dass er nach einiger Betriebsdauer ziemlich warm wird. Eventuell lag das aber daran, dass er die ganze Zeit im Broadcast-Modus war.

[frank]

KEQ0123456 im bootloader eingetragen. kannst du zum flashen über wintool nutzen.
PS00000002 sollte aus der fw kommen. kannst du vor dem kompilieren zb auf die originale sn des schalters ändern.

gruss frank

[unimatrix]

Der Schalter wird eigentlich nur warm, wenn der 230V-Teil dran ist...das merkt man tatsächlich auch wenn das Ding in der Wand ist. Das ist auch schon bei den alten HM-Aktoren so. Die Stromaufnahme im Standby ist nicht gerade berauschend. Liegt natürlich auch an den minimalistischen "Netzteilen".

[Bennemannc]

Hallo,

die geben doch > 0,5W im Standby an. Da dürfte eigentlich nichts "warm" werden. Im eingeschaltetem Zustand ist das natürlich mehr, weil das Relais auch Strom braucht.
Mir ist beim Original noch nichts dergleichen aufgefallen.

Gruß Christoph

[Cyberman]

So weit alles gut, Schalter läuft. Aber wie programmiere ich ihn nun für die Wechselschaltung?

Durch die Self01/Self02 Peerings blicke ich noch nicht durch, es ist schwierig die Informationen zu sammeln und zu verstehen.

[unimatrix]

Hallo Cyberman.

angenommen dein Schalter heißt

mSchalter, dann hast du neben diesem Device die Kanäle

mSchalter_Btn_01
mSchalter_Btn_02
mSchalter_Sw_01
mSchalter_Sw_02

so wird es von CUL_HM.pm angelegt.  (bzw. kann natürlich beliebig umbenannt werden)

der Sw_01 (Kanal 3 des Aktors) ist der virtuellen Kana. Wenn man den einschaltet, brennt das Licht, er berücksichtigt also einen ggf. schon bestehenden Stromfluss. Wenn man den Ausschaltet, geht das Licht aus, wenn es nicht schon aus war. Er zeigt weiterhin an, ob das Licht gerade an oder aus ist.

der Sw_02 ist das Relais und funktioniert so , wie die HM-eigene Firmware vorher auch funktioniert hat. Relais an/aus. Den braucht man also "eigentlich nicht".

Wenn du nun deinen Schalter mit dem internen Taster bedienen willst (was ja wohl so sein dürfte) wäre die einfachste Möglichkeit

set mSchalter_Btn_01 peerChan 0 mSchalter_Sw_01 dual set

das erzeugt automatisch ein Peering zwischen deinen beiden internen Tastern und dem Kanal 3. Damit sollte der Schalter eigentlich schon funktionieren (wobei ich jetzt nicht weiß, welches Standardregisterset geladen wird)

Falls nicht, dann setze im Device das Register intKeysVisible auf "visib" und mache ein getConfig auf Kanal 3. dort siehst du dann die Listen der Peers und siehst, was dort ein Tastendruck bewirkt. In den Jump Targets (z.B . R-self01-shSwJtDlyOff) usw. muss dann bei dem Button, mit dem du AUSschalten willst überall OFF stehen, und bei dem anderen Button entsprechend On.

Noch einfacher wäre es, falls vorhanden, ein Registerset von einem schon wie gewünscht konfigurierten Schalter (das kann auch einer mit Standard-FW sein) zu kopieren. Das geht mit dem Modul hminfo.

VG

[unimatrix]

gibt es neue Erkenntnisse zum Bauen des Bootloaders?

Ich möchte gerne am Anfang des Bootloaders den Watchdog ausschalten. Damit ich in die Applikation eine Reset-Funktion einbauen kann mit Hilfe des Watchdogs. Ziel wäre es, den Bootloader per FHEM Befehl anzuspringen so dass der Schalter nicht stromlos gemacht werden muss.

Ohne das Ausschalten im Bootloader käme es wohl zu einer Reset-Loop.

Alternativ könnte man ggf. den Bootloader einfach anspringen. Aber an welcher Adresse startet der? bei 0x0000... liegt ja die Hauptanwendung.

[Cyberman]

der Sw_01 (Kanal 3 des Aktors) ist der virtuellen Kana
der Sw_02 ist das Relais und funktioniert so ,

Ist es nicht umgekehrt?
Hier https://github.com/jabdoa2/Asksin_HM_LC_Sw1PBU_FM steht

Actor channel for internal relay (channel 3)
Virtual Actor channel for double-throw switch/Wechselschalter (channel 4)

[Cyberman]

Falls nicht, dann setze im Device das Register intKeysVisible auf "visib" und mache ein getConfig auf Kanal 3. dort siehst du dann die Listen der Peers und siehst, was dort ein Tastendruck bewirkt. In den Jump Targets (z.B . R-self01-shSwJtDlyOff) usw. muss dann bei dem Button, mit dem du AUSschalten willst überall OFF stehen, und bei dem anderen Button entsprechend On.

Puuh, da blicke ich immer noch nicht durch. Gibt es irgendwo eine Beschreibung dieser Register-Settings?
Ich habe meine mal ausgelistet, siehe Anhang.

Den Peer-Befehl habe ich eingegeben, aber leider reagiert der Taster nur mit der unteren Wippe und schaltet dann ein.

[unimatrix]

Das ist ganz gut dokumentiert in

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

ab Seite 72 Mitte wird es für dich interessant. Es lohnt sich, da einmal durchzusteigen und dann ist es auch logisch. Nach dem Verständnis erkennt man die Vielzahl der Möglichkeiten.

In deinem RTF sehe ich dass z.B.

R-self01-shActionType   off

steht.

Das bedeutet, dass dein Button 1 (der nach "oben") deaktiviert ist für diesen Peer und somit keine Funktion hat.

Setze dies auf "jmpToTarget"

und dann noch die folgenden auf "on"

R-self01-shSwJtDlyOff   
R-self01-shSwJtDlyOn   
R-self01-shSwJtOff   
R-self01-shSwJtOn   

für Button 2 das selbe, aber eben nicht "on" sondern off. Bzw. Im Moment ist dein Button 2 ein Einschalter, und du hast keinen Ausschalter.

Natürlich kann man es auch anders nutzen. Z.b. einen Button als Toggle und den anderen Button für etwas völlig anderes. Das ist ja das schöne, dass dies bei der CustomFW möglich ist.

[Cyberman]

Das ist ganz gut dokumentiert in
http://fhem.de/Heimautomatisierung-mit-fhem.pdf
ab Seite 72 Mitte wird es für dich interessant. Es lohnt sich, da einmal durchzusteigen und dann ist es auch logisch. Nach dem Verständnis erkennt man die Vielzahl der Möglichkeiten.

Danke für den Hinweis. Diese Dokumentation hatte ich mir sogar schon ausgedruckt, konnte aber mit dem hinteren Teil bisher nicht viel anfangen.
Aber nun habe ich es verstanden: Die Aktoren arbeiten mit Zustandsmaschinen, und man muss die Zustandsübergänge programmieren. Dann macht der Schalter auch was. Aaaah! 

Und siehe da: Schon funktioniert's!