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

frank

Zitatjetzt habe ich doch noch was kurioses entdeckt:
1. relais und wz.lampe sind aus, strom ~ 0.
2. wz.lampe am wechselschalter eingeschaltet, strom 300, relais aus.
3. jetzt wz.lampe am aktor ausgeschaltet, relais an und strom bleibt bei über 300.

ich bin gerade total verwirrt.  ???

rätsel gelöst!  :)

über die strommessung kann man wahrscheinlich sogar erkennen, dass sich der C26 bald verabschiedet.

ich dachte zuerst an ein installationsproblem.
aber auch nach abklemmen des wechselschalters (anschlüsse 1 und 2 frei) zeigte current~300, wenn das relais im aktor angezogen war.
current=3 bei inaktivem relais.

nach dem tausch der leistungsplatine mit einer, die vor kurzem einen "frischen" C26 bekommen hat, funktioniert current wieder tadellos.

1. anschlüsse 1 und 2 frei:
a. relais inaktiv: current=0
b. relais aktiv: current=0

2. mit angeschlossenem wechsler und lampe:
a. current=0 in beiden möglichen kombinationen, wenn die angeschlossene lampe nicht leuchtet.
b. current~300 in beiden fällen, wenn die 10W led leuchtet.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Pfriemler

@papa: Werde ich mir mal ansehen, die Stromerkennung brauch ich nur in Einzelfällen, ist eh energetisch günstiger wenn man sie totlegt (200 mW gespart).

@frank:
Zuerst: siehe mein edit1 im Beitrag darüber - das Scheißding läuft doch jetzt tatsächlich einigermaßen ...

Zitat von: frank am 08 Juni 2020, 09:40:26
hast du eigentlich den ota-fähigen bootloader geflasht?
4k oder 8k?
Was VS/platformio da tut, entzieht sich mir etwas. Aber händisch habe ich nix gemacht. Vermutlich ist noch ein O-Bootloader drauf.

Zitatzur besseren bedienung des config tasters empfehle ich:
Das hatte ich schon gesucht, die Seitenzählung ist bei mir komplett anders. Danke. Werde ich mal einbauen, erscheint mir sehr sinnvoll.

Die zyklischen powermessages kommen ja jetzt endlich und regelmäßig und liefern sehr plausible Werte. Der je nach Sketch auf 5000 oder 2000 stehende Tuningwert ist bei mir auf 500 angepasst, eine 10W-LED liefert einen current von 6900 (ob das irgendeine plausible Einheit ist ... primär werden 64 mA gezogen, 7 gehen auf den Aktor, macht 57 mA für die Last. Faktor 121. hm...)

Power_Events kommen also und aktualisieren brav current im chn4. Anderes Format:
Zitat2020.06.08 10:37:15.245 0: HMUARTLGW HMUART recv: 01 05 01 00 23 msg: 8B 80 5E 29F2CA 1411AB 0000000000001ACC000000
1ACC = 6860 = passt.

Zitatwenn ja, muss sie das current reading in chn4 erzeugen.
das sollte in der parse funktion der pm datei geschehen.
Tut es ja alles, wie beschrieben und auch von mir vermutet.

Zitatgrundsätzlich könnte man auch mal einen serialmonitor an rx/tx der controler platine anschliessen.
bin aber unsicher, ob dazu erst ein debug-define freigeschaltet werden müsste.
Müsste. Ist aus.

Zitatunreachable sollte von chn4 kommen, da fhem ein statusrequest an chn3 und chn4 sendet, aber chn4 den befehl nicht kennt (meine fw).
Ich erinnere mich dunkel, dass Verkehrsrot das eingebaut haben wollte.

Zitatmit autoreadreg=0 sollten die requests verschwinden, denke ich.
Sowieso meine liebste Einstellung. Vor allem das ständige Rufen nach den definierten, aber in der Mottenkiste eingepackten Geräten muss man ja so unterbinden.

und dann zu Deinem gelösten Rätsel:
IDEE: Der OPV arbeitet eigentlich nach dem Linearregler, sollte also von einer schlechten Versorgung gar nicht viel mitbekommen. Ein aktives Relais belastet das Netzteil zusätzlich und erhöht den Ripple auf der 12V damit. Wenn das jetzt durch den Linearregler durchschlägt (weil der das nicht mehr ausregeln kann) gibt es einen Ripple auf den 3.3V, was den OPV und/oder den ADC im ATMega verwirren könnte.
Einen current von 1 oder 2 habe ich auch schon auf den kurzen Kabeln im Testaufbau - allerdings ist mein sense deutlich emfindlicher. (6900 vs 300 bei Dir).
btw. Ein defekter C26/C7 kann sich übrigens überraschend auch in einem verringerten Standby äußern. Dazu beim Dim1TPBU später mehr.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

frank

zu den registern:

device
explizit ist hier nur pairCentral
nach liste0 stellt die fw scheinbar noch 3 weitere register bytes 02/05/12 zur verfügung. diese müssten aber in der pm datei noch bekannt gemacht werden, so wie ich das in der pm datei für den universalsensor zb sehe.

zu den chn1-4 werden in der pm datei folgende register zugewiesen:

chn1/2
hier gibt es 3 chn register von liste1 (sign, dblPress, longPress), die ich verändern kann. wirkung unbekannt.

zusätzlich 2 peer register von liste4, falls gepeert (expectAes, peerNeedsBurst). änderbar und peerNeedsBurst funktioniert entsprechend auch.


chn3
liste1 stellt sign zur verfügung.
über peeren gibt es den registersatz für switches über liste3.

chn4
hier sehe ich nur eine liste1 mit 11 bytes ab adresse 82, aber keine expliziten register.
daher auch kein sign, macht sinn.
aber sehr seltsam diese liste, eventuell fehler in der fw.

nach hörensagen lässt sich der chn aber peeren und get regList zeigt auch die möglichen register.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Pfriemler

Im Device nur pairCentral? Das ist ja wie bei den Remote-Devices (bspw. 2-Kanal-Wandtaster). Da wird von hm.js zwar auch ein "Device" angeboten, aber es kommt eine Fehlermeldung "No register found! Use 'set ... getConfig' first to read the register". pairCentral ist ja so auch nicht zu setzen. Die Liste sollte leer sein und keinen Fehler werfen. Andere Baustelle.

Zitat von: frank am 08 Juni 2020, 12:51:02
chn1/2
hier gibt es 3 chn register von liste1 (sign, dblPress, longPress), die ich verändern kann. wirkung unbekannt.
die gehören zu jedem üblichen Remote (nicht aber bei geräteinternen Tastern sonst): dblPress (normal 0) legt ein Intervall fest, nachdem überhaupt erst ein Doppelklick in dieser Zeit zu einem short-Ereignis führt, einfache Tastendrücke werden dann ignoriert (keine Ahnung ob das überhaupt jemand nutzt?) - und longPress legt die Zeit fest, ab der ein Press als long identifiziert wird, alles kürzer ist ein Short. Interessant - da stehen bei mir hier 0.2 und 1 - demnach dürfte ein Einfachdruck gar nicht zum Event führen, tut es aber. Die Verzögerung bis die long-Events kommen, passt aber. Die repeats tröpfeln auch viel langsamer als bspw. beim PB-2.

Zitatzusätzlich 2 peer register von liste4, falls gepeert (expectAes, peerNeedsBurst). änderbar und peerNeedsBurst funktioniert entsprechend auch.
Danke für den Tipp. Erklärt vielleicht den beschriebenen Lag bei der Direktverknüpfung hier. Denn beim Perring mit dem vccu_Btn14 und dem chn3 (Sw_01), der im Button als peer "self03" auftaucht, wurde hier allen Ernstes peerNeedsBurst auf "on" gesetzt.

chn3  und chn4 kann ich bestätigen hier, es ware alles da was das Herz begehrt.

Habe frühestens morgen abend Zeit für mehr Versuche. Bis jetzt läuft alles, mal sehen ob ich ihn morgen wieder abgeschossen bekomme.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Pfriemler

So, jetzt verstehe ich die Welt nicht mehr. Oder anders: Ich weiß nicht, was ich jetzt besser gemacht habe, jedenfalls ist es so richtig, dass es funktioniert (laut meiner Sig) :-)
- peering per peerSmart von chn1 und chn2 mit chn3
- Korrektur der Jumptabelle auf dual peering -> Funktion wie default
- Deaktivierung von lgActionType in beiden Buttons -> langer Tastendruck schaltet Aktor nicht mehr und steht für anderes zur Verfügung.
- Peeren von chn1 und chn2 mit VCCU-Button (es kommen sonst keine Events mehr in FHEM an...?)
- Deaktivierung von peerNeedsBurst in beiden Buttons sowohl für den eingebauten Schalter als auch VCCU
Im Ergebnis funktioniert alles störungs- und sogar praktisch verzögerungsfrei, und auch die PowerEvents und die Schaltzustandserkennung funktionieren noch. Es werden auch keine vertauschten Stati mehr generiert - der Status des physischen Relais (angezogen) und des logischen Relais (Stromerkennung) stimmen bei jedweder Schaltaktion.
Jetzt fasse ich das Ding nicht mehr an - kein Bootloader, keine andere Firmware ... :-)

Nachtrag: Nach dem Ablöten des Programmierkabels und dem finalen Zusammenbau des Aktors waren die Peers wieder von allein gelöscht und der Aktor zeigt ein seltsames Verhalten (ständiger Wechsel von Last/Nicht-Last). Die Bastelkiste gibt noch eine Platine her, aber mir ist jede Lust vergangen...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

JochenSi

Hey endlich eine Erfolgsmeldung bei mir,
nachdem ich bei mir zu Hause einen Schalter erfolgreich umprogrammiert habe wollte ich in einer anderen Wohnung das gleiche machen. Also hab ich den nächsten Schalter mit PlatformIO umprogrammiert und testweise in meine Steuerung eingebunden. Funktionierte auf Anhieb tadellos. Also zur anderen Wohnung, Schalter reset und einbinden..... Geht mal wieder nicht. RemoteAndSwitch nicht ausgewählt. Dann hier die PM nochmal runtergeladen https://forum.fhem.de/index.php/topic,18071.msg1061772.html#msg1061772, Rechte im Verzeichnis /opt/fhem/FHEM der Datei HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm auf chown fhem:dialout gestellt und fhem neugestartet. Leider klappte es immer noch nicht bis mir einfiel das ich bei mir zu Hause irgendwann mal
apt-get install libswitch-perl
ausführen sollte.
Gesagt getan schon funktioniert es nach einem Neustart von FHEM

AB1970

 Hallo,
es scheint ja hier doch noch einige zu geben, die die Schalter erfolgreich flashen können.
Nach welcher Anleitung macht ihr das denn?
In https://wiki.fhem.de/wiki/HM-LC-Sw1PBU-FM_Alternative_Firmware_am_Raspi_bauen_u._flashen sind die entscheidenen Links nicht mehraktiv.

Ich bin auf dem Raspberry Pi unterwegs (Linux Buster mit AVRDude 6.03). Habe mich daher durch den Thread gelesen und bin auf die Lösung von spi3845 gestoßen . Bekomme allerdings auch die gleichen Fehler wie spi3845.
@spi3845: Habe in dem Forum keine Antwort auf deine Probleme gesehen. Hast du inzwischen selber eine Lösung gefunden ?

Was ich brauche ist eigentlich nur der Longpress (nur falls ich einen anderen Weg Übersehen habe. )




Tobias

Hi,

ich habe hier noch eine Vorrichtung um die Platine ohne Löten erstmalig flashen zu können. Hatte ich mal aus dem Forum hier für 15€. Bei Interesse (15€ + Versand) bitte PM.
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

wires.io

Zitat von: wires.io am 23 Mai 2017, 11:28:47
Wäre das so?

Short Press
set HM_SCHALTERTX_Btn_01 regSet shActionType  jmpToTarget HM_SCHALTERRX_A_Sw_01
set HM_SCHALTERTX_Btn_01 regSet shSwJtOn      dlyOff      HM_SCHALTERRX_A_Sw_01
set HM_SCHALTERTX_Btn_01 regSet shSwJtOff     dlyOn       HM_SCHALTERRX_A_Sw_01
set HM_SCHALTERTX_Btn_01 regSet shSwJtDlyOn   on          HM_SCHALTERRX_A_Sw_01
set HM_SCHALTERTX_Btn_01 regSet shSwJtDlyOff  off         HM_SCHALTERRX_A_Sw_01


Long Pressset HM_SCHALTERTX_Btn_01 regSet lgActionType  jmpToTarget HM_SCHALTERRX_B_Sw_01
set HM_SCHALTERTX_Btn_01 regSet lgSwJtOn      dlyOff      HM_SCHALTERRX_B_Sw_01
set HM_SCHALTERTX_Btn_01 regSet lgSwJtOff     dlyOn       HM_SCHALTERRX_B_Sw_01
set HM_SCHALTERTX_Btn_01 regSet lgSwJtDlyOn   on          HM_SCHALTERRX_B_Sw_01
set HM_SCHALTERTX_Btn_01 regSet lgSwJtDlyOff  off         HM_SCHALTERRX_B_Sw_01


Habe das Thema endlich angegangen und festgestellt, das o.g. Register bei FHEM6 ungültig sind.

Hätte mir nun gedacht, dass es damit funktioniert, was aber leider nicht der Fall ist:

set HM_SCHALTERTX_Btn_01 regSet longPress 1.0 HM_SCHALTERRX_B_Sw_01

cannot calculate value. Please issue set HM_SCHALTERTX_Btn_01 getConfig first - invalid

Was läuft da schief?

wires.io

Zur Erläuterung: ich möchte per Direktverknüpfung HM_LC_Sw1PBU_FM Custom Firmware Schalter verbinden. Für Short Press und eine Zweier-Verbindung geht das einwandfrei. Die Frage ist bloß, ob ich auch Long Press verwenden kann, um einen dritten Schalter anzusteuern.

Bsp.: Schalter im Erdgeschoss
- Short Press unten - schaltet selber an/aus
- Short Press oben - schaltet ersten Stock an/aus
- Long Press unten - schaltet Keller an/aus

Pfriemler

Zitat von: wires.io am 23 Oktober 2020, 12:50:57
Habe das Thema endlich angegangen und festgestellt, das o.g. Register bei FHEM6 ungültig sind.
Wer sagt das?

Zitatcannot calculate value. Please issue set HM_SCHALTERTX_Btn_01 getConfig first - invalid
Was läuft da schief?
Wie würdest Du die Fehlermeldung übersetzen?
"kann Werte nicht berechnen. Bitte zuerst (Befehl) "set HM_SCHALTERTX_Btn_01 getConfig" abschicken - ungültiger Befehl".

Auf richtig deutsch: FHEM benötigt zur Registerberechnung vor dem Schreiben einen aktuellen Datensatz vom Gerät. Manche der Register werden als Flags in Bytes geschrieben, dazu müssen die restlichen Bits bekannt sein.

Und "regSet longPress" ... ich kenne kein Register mit diesem Namen. Du warst vorher schon auf dem richtigen Dampfer.

edit nach franks (wie immer sehr zutreffendendem Einwand): Natürlich sind die Register im Aktor zu setzen. Ich war mal davon ausgegangen, dass man sich zumindest erst mal die Registerliste des Gerätes angesehen hatte, in welchem man Register setzen möchte.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

wires.io

Zitat von: Pfriemler am 23 Oktober 2020, 20:12:41
Wer sagt das?
FHEM sagt das:
lgActionType failed: supported register are dblPress expectAES longPress pairCentral peerNeedsBurst sign

Zitat von: Pfriemler am 23 Oktober 2020, 20:12:41
Wie würdest Du die Fehlermeldung übersetzen?
"kann Werte nicht berechnen. Bitte zuerst (Befehl) "set HM_SCHALTERTX_Btn_01 getConfig" abschicken - ungültiger Befehl".

Auf richtig deutsch: FHEM benötigt zur Registerberechnung vor dem Schreiben einen aktuellen Datensatz vom Gerät. Manche der Register werden als Flags in Bytes geschrieben, dazu müssen die restlichen Bits bekannt sein.

Und "regSet longPress" ... ich kenne kein Register mit diesem Namen. Du warst vorher schon auf dem richtigen Dampfer.

S.o.

frank

die register finden sich immer im aktor.
also der externe aktor.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

wires.io

Ich habe "HM_123456" (Model: HM-LC-Sw1PBU-FM-CustomFW) und dem zugeordnet:
- HM_123456_Btn_01
- HM_123456_Btn_02
- HM_123456_Sw_01
- HM_123456_Sw_02

Wie sage ich HM_123456_Btn_02, dass per Long Press HM_123458_Sw_01 geschaltet werden soll? Etwa so?


set HM_123456 regSet lgActionType  jmpToTarget HM_123458_Sw_01
set HM_123456 regSet lgSwJtOn      dlyOff      HM_123458_Sw_01
set HM_123456 regSet lgSwJtOff     dlyOn       HM_123458_Sw_01
set HM_123456 regSet lgSwJtDlyOn   on          HM_123458_Sw_01
set HM_123456 regSet lgSwJtDlyOff  off         HM_123458_Sw_01


Oder meinst Du mit Aktor den _Sw?

frank

grundsätzlich ist das vorgehen immer identisch.

1. button-channel mit aktor-channel peeren.
am einfachsten über detailseite mit "set peerSmart" zusammen klicken.
=> nun kommunizieren die devices direkt ohne fhem.
ausserdem wird bereits im aktorchannel ein default-verhalten "aktiviert".

2. aktor-channel konfigurieren.
im aktor wird das verhalten auf die trigger der buttons festgelegt.
short trigger und long trigger kann man für jeden "peer" unterschiedlich behandeln.
wenn das default-verhalten nicht gewünscht ist, muss mann die registersätze entsprechend anpassen.
=> "set aktorchannel regSet value buttonchannel"

3. konfigurieren über templates.
fhem stellt unterschiedliche templates für bestimmte verhaltensweisen des aktors bereit. mit einem cmd wird ein ganzer registersatz gesetzt.
unter "set tplSet..." sind die verfügbaren templates zu finden.

4. mit dem webui hm.js, link in meiner signatur, kann man register und templates ziehmlich einfach ändern und zuweisen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html