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

dogexan

ZitatJa ist möglich. Einfach LONG_ACTION_TYPE auf INACTIVE stellen
Ich arbeite aber ausschließlich mit der CCU und Homematic.
Bin hier im Forum damals nur gelandet, weil es im Homematic Forum noch keine AskSin++-Ecke gab

Danke für die schnelle Antwort, werde bei Gelegenheit mich nochmal einlesen und deine Firmware probieren.  :D

scuba

Hallo,

ich hab bei mir einige HM-LC-Sw1PBU-FM mit der custom firmware von jabdoa laufen und bin diese Woche testweise auf die ts-culfw für meinen nanoCUL umgestiegen.
Soweit funktioniert beinahe alles prächtig.
Nur die Aktoren mit der custom firmware scheinen auf keinen Status Request zu antworten. Somit stehen die Channels in FHEM auf "unreachable"
Ein normales Get-Config bzw. schalten der Aktoren von FHEM funktioniert 1A. Sobald der Aktor geschalten hat ist auch der korrekte Status in FHEM ersichtlich.
Sobald ein erneuter status request abgesetzt wird ändert sich dieser aber wieder auf unreachable.

Hat jemand ähnliches beobachten können bzw. ist da was bekannt?

Hier ein Auszug aus meinem Log:

2020.01.16 16:12:31.879 3: CUL_HM set Deckenlicht_Arbeitszimmer_Sw_01 statusRequest                                                                                                         
2020.01.16 16:12:31.881 4: TSCUL_send:  nanoCUL_TS868_HM  114313                 As 0B 5B A001 123456 3DEAD2 030E                                                                           
2020.01.16 16:12:31.882 4: TSCUL_XmitDlyHM:  nanoCUL_TS868_HM  id:3DEAD2 rtoms:2342                                                                                                         
2020.01.16 16:12:32.146 4: TSCUL_Parse: nanoCUL_TS868_HM  114567 A F803 00152532 02 0B 5B A001 123456 3DEAD2 030E _CCAdly:8 _dhmSt:1656                                                     
2020.01.16 16:12:32.209 4: TSCUL_Parse: nanoCUL_TS868_HM  114629 A F803 00152800 01 0B 5B A001 123456 3DEAD2 030E _CCAdly:4 _dhmSt:1924                                                     
2020.01.16 16:12:32.480 4: TSCUL_Parse: nanoCUL_TS868_HM  114900 A F803 00153068 01 0B 5B A001 123456 3DEAD2 030E _CCAdly:4 _dhmSt:2192                                                     
2020.01.16 16:12:32.720 3: LogHist nanoCUL_TS868_HM:  100526 A F803 00138696 01 10 66 A001 123456 3DEAD2 03043DEAD20203 _CCAdly:4 _dhmSt:596                                               
2020.01.16 16:12:32.720 3: LogHist nanoCUL_TS868_HM:  100600 A F801 00138800 00 1A 66 A010 3DEAD2 123456 020200030004320564060007E8080009FF -48dB                                           
2020.01.16 16:12:32.721 3: LogHist nanoCUL_TS868_HM:  100721 A F803 00138896 01 0A 66 8002 123456 3DEAD2 00 _CCAdly:4 _dhmSt:96                                                             
2020.01.16 16:12:32.721 3: LogHist nanoCUL_TS868_HM:  101288 A F801 00139496 00 1A 66 A010 3DEAD2 123456 020A010B660C6682008300843285648600 -47.5dB                                         
2020.01.16 16:12:32.722 3: LogHist nanoCUL_TS868_HM:  101409 A F803 00139592 01 0A 66 8002 123456 3DEAD2 00 _CCAdly:4 _dhmSt:96                                                             
2020.01.16 16:12:32.722 3: LogHist nanoCUL_TS868_HM:  101992 A F801 00140192 00 18 67 A010 3DEAD2 123456 0287E8880089FF8A218B668C660000 -48dB                                               
2020.01.16 16:12:32.723 3: LogHist nanoCUL_TS868_HM:  102111 A F803 00140288 01 0A 67 8002 123456 3DEAD2 00 _CCAdly:4 _dhmSt:96                                                             
2020.01.16 16:12:32.723 3: LogHist nanoCUL_TS868_HM:  111362 A F801 00149552 00 14 25 805E 37AB6C 123456 0000000000000002000000 -68dB                                                       
2020.01.16 16:12:32.724 3: LogHist nanoCUL_TS868_HM:  111427 A F801 00149628 00 14 6E 805E 3DEAA4 123456 0000000000000001000000 -51.5dB                                                     
2020.01.16 16:12:32.724 3: LogHist nanoCUL_TS868_HM:  114256 A F801 00150876 00 14 5A 805E 3DEAD2 123456 000000000000001D000000 -47.5dB                                                     
2020.01.16 16:12:32.726 3: LogHist nanoCUL_TS868_HM:  114313                 As 0B 5B A001 123456 3DEAD2 030E                                                                               
2020.01.16 16:12:32.728 3: LogHist nanoCUL_TS868_HM:  114567 A F803 00152532 02 0B 5B A001 123456 3DEAD2 030E _CCAdly:8 _dhmSt:1656                                                         
2020.01.16 16:12:32.729 3: LogHist nanoCUL_TS868_HM:  114629 A F803 00152800 01 0B 5B A001 123456 3DEAD2 030E _CCAdly:4 _dhmSt:1924                                                         
2020.01.16 16:12:32.731 3: LogHist nanoCUL_TS868_HM:  114900 A F803 00153068 01 0B 5B A001 123456 3DEAD2 030E _CCAdly:4 _dhmSt:2192                                                         
2020.01.16 16:12:32.732 3: TSCUL_ParseTsHM: nanoCUL_TS868_HM HM repeat failed to 3DEAD2/Deckenlicht_Arbeitszimmer:  115141 A F809 00153332 00 0B 5B A001 123456 3DEAD2 030E _sfail _noAnsw 
2020.01.16 16:12:33.055 4: TSCUL_Parse: nanoCUL_TS868_HM  115471 A F801 00153668 00 14 F2 805E 37AB5C 123456 0000000000000000000000 -63.5dB                                                 
2020.01.16 16:12:34.225 4: TSCUL_XmitAwaitHMTo nanoCUL_TS868_HM: timeout - 3DEAD2                                                                                                           


Danke und Lg

Christian

scuba

Nochmal zum Thema "Status Request":
Meine Tests haben gezeigt , dass dies kein Problem in Verbindung mit der ts-culfw ist. Auch mit aculfw oder der normalen culfw bekomme ich keine Antwort auf einen "Status Request" des Kanals.
Lediglich scheint mit der "[a-]culfw" das Ausbleiben einer Antwort verworfen zu werden und somit bleibt der Kanal auf seinem letzten Status stehen.

In der Asksin_HM_LC_Sw1PBU_FM.ino ist auch ersichtlich , dass die Funktion HM_Status_Request tatsächlich nichts macht....  ::)


void HM_Status_Request(uint8_t cnl, uint8_t *data, uint8_t len) {
// message from master to client while requesting the channel specific status
// client has to send an INFO_ACTUATOR_MESSAGE with the current status of the requested channel
// there is no payload; data[0] could be ignored
#if defined(RL_DBG)
Serial << F("\nxtStattus_Request; cnl: ") << pHex(cnl) << F(", data: ") << pHex(data,len) << "\n\n";
        #endif
//if (cnl == 3) rl[0].sendStatus(); // send the current status
}


Komisch, dass das bisher niemanden gestört zu haben scheint...
Mal schauen ob sich die Zeile einfach einkommentieren lässt oder ob es einen höheren Grund gibt warum das auskommentiert ist. ;-)


Verkehrsrot

Zitat von: scuba am 20 Januar 2020, 08:59:15
Nochmal zum Thema "Status Request":
Meine Tests haben gezeigt , dass dies kein Problem in Verbindung mit der ts-culfw ist. Auch mit aculfw oder der normalen culfw bekomme ich keine Antwort auf einen "Status Request" des Kanals.

Stimmt, bei mir liefert der Schalter an einem HMUARTLGW auf keine Antwort auf Status Request. FHEM fragt zyklisch an...

ucm73

Zitat
Komisch, dass das bisher niemanden gestört zu haben scheint...
Mal schauen ob sich die Zeile einfach einkommentieren lässt oder ob es einen höheren Grund gibt warum das auskommentiert ist. ;-)

Bei mir seit 5 Jahren so, am HM-CFG-LAN. Habe mich daran gewöhnt, nach einem FHEM Neustart, einmal die Taster auszulösen. ;)

Verkehrsrot

Zitat von: jp112sdl am 06 Januar 2020, 15:06:57
Ja soweit ist das schon klar. Hab die Firmware vor ner Weile auf Grundlage der AskSinPP-Lib mal neu gestrickt.
https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples/HB-LC-Sw1PBU-FM

Ich habe mir den Code mal angeschaut. Sehe ich das richtig: Da ist nicht (wie in der "Original" Alternativ-Firmware) die Funktion der Stromflussmessung enthalten, mit der ein Wechselschalter emuliert werden kann?

jp112sdl

Zitat von: Verkehrsrot am 25 Januar 2020, 21:52:30
Ich habe mir den Code mal angeschaut. Sehe ich das richtig: Da ist nicht (wie in der "Original" Alternativ-Firmware) die Funktion der Stromflussmessung enthalten, mit der ein Wechselschalter emuliert werden kann?
Nein, ist da nicht drin

MonsterDesKrümels

Zitat von: Verkehrsrot am 17 Januar 2020, 19:57:15
Bei mir ist ein neues Problem aufgetaucht: Der Schalter hat aus irgendeinem Grund seinen type "remoteandswitch" verloren und steht wieder auf "virtual".

Manuelles reload von HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm führt zu Fehler
Infolgedessen ist der Schalter wieder ein subtype "virtual" und lässt sich nicht mehr über HM-Zentrale steuern.

Kann mir jemand helfen, das zu reparieren?
gleiche Problem aber mit CUL Stick

scuba

Zitat von: Verkehrsrot am 25 Januar 2020, 16:12:16
Stimmt, bei mir liefert der Schalter an einem HMUARTLGW auf keine Antwort auf Status Request. FHEM fragt zyklisch an...

Danke für eure Antwort, bin leider noch nicht dazu die Änderung in der FW auszuprobieren... melde mich natürlich wenns hier neue Erkenntnisse gibt

Verkehrsrot

Inzwischen habe ich geschafft, meinen Schalter neu zu programmieren. Nur den Bootloader habe ich nicht zum laufen gebracht, schade, jetzt muss ich bei Änderungen wieder löten :-(

Könnte man den Schwellwert für die Spannung konfigurierbar machen über ein Register, so dass man ihn mit fhem per regSet setzen kann? Das wäre nützlich. In Zeiten von LED-Beleuchtung ist es wichtig.

Verkehrsrot

Ich habe für die Schaltersoftware eine Toolchain für Platformio erstellt:

https://github.com/cyberman54/HM_LC_Sw1PBU_FM

Damit sind Build und Upload viel einfacher. Nach Installation von Platformio ist es nur noch 1 Mausklick.

Ich musste ich in der Software einiges umbauen, um Compilerfehler und -warnungen zu eliminieren.
Außerdem ist jetzt die Status Request Funktion aktiv, es wird der Status des Relais rückgemeldet.

Hoffe es funktioniert ansonsten noch alles. Bei mir klappt es bisher.

Leider habe ich es für den OTA Bootloader noch nicht geschafft, die Software auf Platformio zu heben. Jede Menge Compilerfehler... :-(

scuba

Zitat von: Verkehrsrot am 02 Februar 2020, 15:09:02
Außerdem ist jetzt die Status Request Funktion aktiv, es wird der Status des Relais rückgemeldet.

8) Spitze! war ausser der auskomentierten Zeile noch was zu ändern?


Verkehrsrot

Zitat von: scuba am 03 Februar 2020, 16:03:30
8) Spitze! war ausser der auskomentierten Zeile noch was zu ändern?

Jein. Ich habe die Zeile aktiviert, aber zusätzlich die Wirksamkeit auf Kanal 4 (das virtuelle Relais) erweitet, damit auch daran gerichtete Status Requests beantwortet werden. Habe seitdem im fhem log keine Meldungen mehr zu fehlgeschlagenen Status Requests. Irgendwelche Seiteneffekte habe ich bisher nicht.

JochenSi

Hallo zusammen,
nachdem ich ca ein Jahr lang keine Lust mehr auf meine Fehler hatte hab ich mich heute doch nochmal ran gesetzt.
So wie ich die Anleitungen verstanden habe, hab ich den Schalter geflasht und kann ihn mit der VCCU pairen.
Leider kann ich den SubType remoteAndSwitch nicht in der Drop down Liste finden. Also hab ich mir gedacht das das Modul ./FHEM/HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm wohl nicht gestartet wurde und hab es mit reload nochmal laden wollen. Daraufhin kommt folgende Fehlermeldung:
2020.02.16 12:26:16 1: Error loading file: ./FHEM/HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm:
Can't locate Switch.pm in @INC (you may need to install the Switch module) (@INC contains: . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM) at ./FHEM/HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm line 6, <$fh> line 99.
BEGIN failed--compilation aborted at ./FHEM/HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm line 6, <$fh> line 99.


Daraufhin hab ich was mit Google gesucht und den Hinweis bekommen man soll doch "apt-get install libswitch-perl" ausführen. Gesagt getan aber jetzt kommt in FHEM folgende Warnung:
2020.02.16 13:07:09 1: PERL WARNING: Subroutine CUL_HM_ParseremoteAndSwitch redefined at ./FHEM/HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm line 21.
Nun weiß ich echt nicht mehr weiter. Ich kann die Subroutine in ./FHEM/HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm an Zeile 21 finden. Nur was sagt mir das?
Grüße Jochen

PS: Das FHEM System ist ca. einen Monat alt und läuft auf einem RPI4 -Buster

Pfriemler

Seit Monaten Schweigen im Walde. Komisch.
Also die Fehlermeldung kommt doch praktisch bei jedem Reload einer .pm.
Die Fehlermeldung hatte ich heute auch, aber nach dem libswitch-perl war Ruhe.

Melde mich aber wegen was anderem. Helft mir doch mal auf die Sprünge.
Ich hab Verkehrsrots Arbeit heute mal nachverfolgt:
- Visual Studio, Platformio-Plugin, Git ...
- habe es geschafft einen Arduino Nano als ISP-Programmer zu verwenden
- "Upload via Programmer" klappte nachhaltig nicht, aber mit "...set Fuses" und danach nur Upload Firmware dann doch
- zwei Versuche - einmal mit CCU-ID (meine FHEM-Zentrale), einmal 000000
- die spezielle .pm habe ich nach der obigen Fehlermeldung und dem Nachinstallieren offenbar geladen bekommen:
Zitat2020.06.06 18:48:34 3: additional HM config file loaded: ./FHEM/HMConfig_AskSinPPCustom.pm
Die geflashte Platine sendet eine korrekte Info-Meldung. Ich bekomme in FHEM über autocreate ein HM_Gerät mit der .hmID "F0A9", sie sendet alle 20-30s ein Telegramm (PowerEvent vermute ich mal), sie sendet short- und Long-Trigger (allerdings egal welchen Button man drückt) ... jeder Sendeversuch wird mehrfach wiederholt, ich sehe das dann im EventMonitor wie auch im Display meines AskSinAnalyzers.

Ich habe etliche Versuche unternommen, das Gerät immer mal wieder gelöscht, FHEM neu gestartet, Anlernen und somit autocreate versucht - ich komme nicht weiter als bis zu einem CUL_HM-Gerät, das sowohl die korrekte hmID F0A9, eine Firmware 1.7, die korrekte hinterlegte serialNr, aber eben keine Kanäle oder irgendwas dergleichen anlegt. Idiotischerweise wird dabei nichts über die VCCU angelegt, das Gerät bekommt ein zwar definiertes, aber längst nicht mehr aktives IO-Gerät als IOdev zugewiesen (aber nix von IOgrp).
Das Anlernen klappt aber nach einem Löschen nicht mehr, aber die "undefined_xxxxxx"-Readings in der VCCU werden bei jedem Sendevorgang aktualisiert.

Der config-Button ist aber anscheinend funktionslos geworden, seine Betätigung wird zwar mit einem kurzen Blitzen der LED signalisiert. Aber weder hmPairForSec noch hmPairSerial funktionieren, es gibt null Reaktion auf dem Funk.

Wie zum Donnergrummel nochmal kriege ich das Scheißding jetzt einfach mal in FHEM definiert? Ich werde den Verdacht nicht los, dass die in diesem Jahr vollzogenen zahlreichen Änderungen in CUL_HM den Mechanismus des Anlernens von alternativen HM-Geräten nachhaltig kaputtgelegt haben. Ich kann ja auch keine manuelle Def mehr machen, weil weder model noch subType händisch noch zu setzen gehen.

Any hints, folks?
"Ä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 ..."