Autor Thema: Neue Firmware für HM_LC_Sw1PBU_FM mit getrenntem Aktor, Taster + Wechselschalter  (Gelesen 515848 mal)

Offline dogexan

  • Full Member
  • ***
  • Beiträge: 138
Zitat
Ja 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

Offline scuba

  • Jr. Member
  • **
  • Beiträge: 81
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

Offline scuba

  • Jr. Member
  • **
  • Beiträge: 81
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. ;-)


Offline Verkehrsrot

  • New Member
  • *
  • Beiträge: 41
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...

Offline ucm73

  • Jr. Member
  • **
  • Beiträge: 50
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. ;)

Offline Verkehrsrot

  • New Member
  • *
  • Beiträge: 41
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

  • Gast
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

Offline MonsterDesKrümels

  • New Member
  • *
  • Beiträge: 10
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

Offline scuba

  • Jr. Member
  • **
  • Beiträge: 81
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

Offline Verkehrsrot

  • New Member
  • *
  • Beiträge: 41
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.

Offline Verkehrsrot

  • New Member
  • *
  • Beiträge: 41
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... :-(

Offline scuba

  • Jr. Member
  • **
  • Beiträge: 81
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?


Offline Verkehrsrot

  • New Member
  • *
  • Beiträge: 41
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.

Offline JochenSi

  • New Member
  • *
  • Beiträge: 19
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