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

[KimKiesel]

Hallo nochmal,

eine kurze Frage habe ich noch zur Auswertung eines LongPress.

Ich möchte den Button 2 für zwei verschiedene Aktionen nutzen (ShortPress und LongPress). Dazu habe ich zwei notify definiert.
Im folgenden die jeweiligen DEF:

Short:

Code Auswählen Erweitern

wz_hm_btn_Licht2_2:Short.* {fhem "set wz_LichtAbendbeleuchtung ".((Value('wz_LichtAbendbeleuchtung') eq 'on')?'off':'on') }


Long:

Code Auswählen Erweitern

wz_hm_btn_Licht2_2:LongRelease.* {fhem "set wz_LichtSideboardrechts ".((Value('wz_LichtSideboardrechts') eq 'on')?'off':'on') }

Der Short funktioniert auch einwandfrei und toggelt die Abendbeleuchtung. Beim LongPress schaltet er aber immer doppelt, toggelt das Sideboard also zweimal direkt hintereinander, sodass in der Konsequenz überhaupt nichts passiert.

Im Logfile steht dann folgendes:

Code Auswählen Erweitern


2016.09.30 23:06:05 3: off_wz_LichtSideboardrechts return value: -1
2016.09.30 23:06:05 3: on_wz_LichtSideboardrechts return value: -1
sending systemCode[10110] unitCode[4] command[0]
sending systemCode[10110] unitCode[4] command[1]


Hier wird also einmal das off-Event getriggert und im Anschluss gleich wieder das on-Event und ich finde einfach den Fehler nicht .

Viele Grüße,

Maximilian

[knueppler]

HI
der Taster feuert beim Long-press vier Long-Events, zweimal press, zweimal release.
Am besten, Du loggest das mal in Deinem notify. Dann wird das klarer und Du kannst Deine regexp entsprechend anpassen.
Meiner Meinung nach gibt jeweils das zweite Event Rückschluss auf die Zeitdauer.
Ciao Christian



Gesendet von iPhone mit Tapatalk

[Otto123]

Am besten, Du loggest das mal in Deinem notify. Dann wird das klarer und Du kannst Deine regexp entsprechend anpassen.

Sehr einfach geht das auch mit dem Eventmonitor.

Gruß Otto

[knueppler]

Cool, wieder was gelernt, danke
Ciao Christian


Gesendet von iPhone mit Tapatalk

[KimKiesel]

Hallo zusammen,

vielen Dank für die Hilfe, jetzt tut es .

Der Tipp mit dem Event-Monitor ist wirklich gut. Das kannte ich auch noch nicht. FHEM bietet einfach zu viele Möglichkeiten .

Folgendes war im Protokoll zu lesen:

Code Auswählen Erweitern


2016-10-01 20:55:32 CUL_HM wz_hm_btn_Licht2_2 LongRelease 3-A240- (to nanoCUL)
2016-10-01 20:55:32 CUL_HM wz_hm_btn_Licht2_2 LongRelease 3_6 (to nanoCUL)
2016-10-01 20:55:32 CUL_HM wz_hm_btn_Licht2_2 trigDst_XXXXXX: noConfig
2016-10-01 20:55:32 CUL_HM wz_hm_btn_Licht2_2 trigger: Long_6
2016-10-01 20:55:32 CUL_HM wz_hm_btn_Licht2_2 trigger_cnt: 6
2016-10-01 20:55:32 CUL_HM wz_hm_sw_Licht2 battery: ok
2016-10-01 20:55:32 CUL_HM wz_hm_sw_Licht2 CMDs_done
2016-10-01 20:55:32 CUL_HM wz_hm_sw_Licht2 wz_hm_btn_Licht2_2 LongRelease 3-A240- (to nanoCUL)


Ehrlich gesagt hätte ich beim Release-Event gar nicht damit gerechnet, dass hier etwas gedoppelt wird, aber man lernt ja nie aus.

Jetzt lautet das notify auf:

Code Auswählen Erweitern

wz_hm_btn_Licht2_2:LongRelease.*_.* {fhem "set wz_LichtSideboardrechts ".((Value('wz_LichtSideboardrechts') eq 'on')?'off':'on') }

also noch mit "_" in der Bedingung und alles klappt prima.

Viele Grüße,

Maximilian

[KimKiesel]

Hallo zusammen,

nun, da mein HM_LC_Sw1PBU_FM dank eurer Firmware endlich so funktioniert, wie ich das gerne hätte, liegt der HM_LC_Sw2PBU_FM bei mir ungenutzt auf dem Schreibtisch  .

Das würde ich gerne ändern und daher dachte ich, warum nicht die Firmware für dieses Modell anpassen, damit es sein volles Potenzial entfalten kann .

Ich bin zwar eigentlich vom Fach, aber C++ ist nicht gerade meine Stärke. Nichtsdestotrotz waren die Anpassungen relativ einfach, wenn ich nichts übersehen habe. Im Anhang dieses Beitrags habe ich die geänderte .ino angehängt (nur dort musste ich Änderungen vornehmen) und den Schaltplan des HM_LC_Sw2PBU_FM. Zusätzlich zum Vergleich noch den des HM_LC_Sw1PBU_FM, wenn es jemanden interessiert. Dort kann man schön sehen, dass die beiden genauso gleich aufgebaut sind, wie der Name es vermuten lässt .

Einzige Unterschiede beim HM_LC_Sw2PBU_FM:

• Keine Spannungserkennung mehr (PA0 nicht verbunden)
• Zweites Relais hängt an PD5 (das erste wie beim HM_LC_Sw1PBU_FM an PD4)

Vorteilhaft bei den Anpassungen war, dass auch beim HM_LC_Sw1PBU_FM schon zwei Channels für das reale und das virtuelle Relais definiert waren. Hier habe ich den virtuellen Channel einfach für das zweite reale Relais umfunktioniert. Dadurch musste ich an den HM-Definitionen keine Änderungen vornehmen.

Folgendes habe ich angepasst:

• Spannungserkennungslogik komplett entfernt
• zweiten Relais-Pin definiert
• setInternalRelay angepasst, sodass abhängig vom Channel beide Relais geschaltet werden
• relayState angepasst und die LED komplett tot gelegt

Der letzte Punkt ist so eigentlich nicht nötig, sonst hätte man sich den Status jedes Relais merken können und nur, wenn beide Relais aus sind, die LED deaktivieren. Aber mich stört die LED, da ich sie durch meinen Schalter hindurch sehen kann und ich auch so merke, wenn das Licht an ist . Außerdem wüsste man bei zwei Relais auch nicht, welches nun gerade an ist.

Ich würde mich freuen, wenn ihr mal kurz drüber schauen könntet. Kompilieren tut es, ich habe mich aber noch nicht getraut zu flashen  .


Viele Grüße,

Maximilian

[Homalix99]

Hallo Jan,
bin gerade auf den Artikel gestossen. Ich habe 3 HM-LC-Bl1PBU-FM (Rolladen-Aktoren) über fhem am laufen und hab mir recht umständlich in pearl ne Routine gebastelt, welche zwischen Rolladenbetätigung in fhem und Betätigung lokal am Aktor unterscheiden kann (geht mit Zeitstempeln, fkt aber nicht zuverlässig, deshalb wäre die Lösung eines FW-Patches genial.
Gibt es schon eine Lösung für den HM-LC-Bl1PBU-FM Aktor?

lg

Alex

[FEHMPiDi]

Hallo,

ich habe mir auch einen HM-LC-Sw1PBU-FM zugelegt und würde mir gern die alternative software draufladen.
Leider muss ich zugeben das ich damit etwas überfordert bin. Ich blicke irgendwie nicht durch was ich machen muss.
Muss ich die Anleitung im Wiki schritt für schritt durchgehen oder kann ich alles via OTA flashen ohne den Schalter aufzuschrauben?

Vielen Dank schon mal

[knueppler]

Hi
um den Bootliader zu flashen wirst Du nicht umhinkommen, den Schalter aufzuschrauben, also ja, genauso wie im Wiki beschrieben.
Ciao Christian


Gesendet von iPhone mit Tapatalk

[FEHMPiDi]

Ok, na dann versuch ich mal mein Glück.

Danke

Gesendet von meinem SM-G901F mit Tapatalk

[FEHMPiDi]

Hallo,

ich habe es nun mal versucht, bin jedoch noch nicht ganz durch.
Ich habe auch gleich einige Fragen.
1) Im Wiki steht beim Firmeware flashen soll man folgendes eingeben:

Code Auswählen Erweitern

avrdude -p m644 -c stk500v2 -P /dev/ttyUSB0 -U flash:w:bootloader_HM-LC-Sw1PBU-FM_8k.hex

Diese Datei bekomme ich aber beim Compilieren gar nicht. Ich habe nur diese hier:
Bootloader-AskSin-OTA-HM-LC-Sw1PBU-FM_8k.hex. Ist da ein Fehler im Wiki, oder habe ich eine falsche Datei?

Jetzt wollte ich die Firmeware per OTA flashen und scheitere beim Erstellen des EQ3 files. Ich bekomme folgende Fehlermeldung:

Code Auswählen Erweitern

root@raspberrypi:~/hmcfgusb# php hex2eq3.php --inFile Asksin_HM_LC_Sw1PBU_FM.cpp.hex --outFile HM_LC_Sw1PBU_FM.eq3 --spmPageSize 256 --hexEndAddress 0xDFFE --ou                       tFormat eq3 --withCrcCheck --pathTo-srec_cat /usr/bin/srec_cat
unknown "-Cyclic_Redundancy_Check_16_Little_Endian" option
Usage: srec_cat [ <option>... ] <filename>...
       srec_cat -Help
       srec_cat -VERSion
       srec_cat -LICense
Could not open tmpfile.tmp

Im Forum hier steht, das man sich die aktuellere Version der srecord installieren muss.
Haecksler hatte das gleiche Problem, aber leider nicht beschrieben wie er es gelöst hat.
Ich kenne mich da mit Linux leider gar nicht aus und weiß nicht wie ich ohne apt-get etwas installieren kann.

Ich würde mich daher freuen wenn mir jemand helfen kann

Danke

[FEHMPiDi]

So, jetzt habe ich es hinbekommen den EQ3 File zu erstellen und hänge schon wieder.

Bisher habe ich alles wie um 21:50 beschrieben gemacht.
Also, Fuses gesetzt und Bootloader (zumindest die Daei die ich habe) geflasht.
Kabel abgelötet und wieder zusammengebaut und in die Steckdose gesteckt. Jetzt hat mein Schalter folgendes Blinkverhalten:
1x lang --> 2x extrem kruz --> lange Pause --> und wieder von Vorn
Ist das richtig?

Wie kann ich denn jetzt die FW per OTA flashen?
Ich habe betreibe Fhem mit einem NanoCUL aber in Fhem sehe ich den Schalter doch gar nicht mehr, wie kann ich dann flashen?

Danke schon mal

[knueppler]

Hi,

ich bin mir nicht ganz sicher, ob der Bootloader korrekt geflashed wurde, probier mal, wie im WIKI beschrieben, die verschiedenen Optionen des Boot-Menus aufzurufen.
Klar, dass Du den noch nicht in FHEM siehst, es ist doch gar keine Firmware mehr drauf, sondern nur noch der Bootloader, wenn überhaupt. Du musst die Firmware ja erst flashen. Wie das geht, steht auch im WIKI.
Ich mache das bspw. mit einem HM-CFG-USB-2 und da ist das Kommando

Code Auswählen Erweitern

flash-ota -f <Firmwaredatei im eq3-Format> -s <SerialNr>.
Grundsätzlich empfiehlt es sich, das Ding erst dann wieder einzubauen, wenn alles funktioniert.
Zum Funktionstest und einbinden in FHEM reicht die Steuerplatine, Strom bekommt sie ja von dem PI, sprich, man lässt alle Kabel angelötet und kann dann ggf. erneut flashen oder sich das mit dem OTA sparen und die Firmware direkt via Kabel flashen.

Ciao Christian

[DerBodo]

Ich habe mit 2 Schaltern und der Custom Firmware folgendes Problem.
Sobald ein Paar Schaltaktionen über FHEM oder die Tasten am Schalter ausgeführt wurden, scheint dieser zu "hängen".

Weder Schaltkommandos via FHEM noch über die Tasten werden angenommen.
Ich habe die Firmware schon mal mit dem "nötigsten" neu gebaut - heisst ich habe folgende Sachen angepasst:

- HMID des Schalters
- Seriennummer
- Currentwert für den Stromsensor (500 statt 5000)

Was kann ich noch testen/tun um den Schalter zuverlässig zu machen?

Danke !

[knueppler]

Hi

hängen kenne ich nicht,, nur manchmal wird der State off nicht an FHEM gesendet, warum auch immer, timedOn ist dann running. Habe ich über ein notify auf current gefixed.
Was mir noch einfällt, hast Du FIRSTRUN - oder so ähnlich - definiert? Dann werden in dem vorhandenen Code auch Peers gesetzt, die Du sicherlich nicht hast. Die versucht der Schalter dann zu erreichen und macht erst nach einem Timeout weiter. Die Peers kannst Du zwar in den Registern via FHEM löschen, aber wenn der Schalter bootet, sind sie wieder da....
Am besten aus dem Code werfen.
Ciao Christian


Gesendet von iPhone mit Tapatalk