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

mcfly71

Hallo Gemeinde,

ich hatte soeben ebenfalls ein Update gemacht, und es wieder per restore rückgängig gemacht.

Hat das Problem mit dem subtype etwas zu tun damit, dass nach dem Update immer nur
                   set_on oder set_off
als states existieren ???
Bei mir war dies nämlich so. Ansonsten würde ich vor einem nochmaligen Update erst einmal den Dateinamen
umbenennen, damit das dann auch mit den subtypes funktioniert.

VG
mcfly
- HMLAN / Raspberry auf hmmode
- Homematic

Y. Lee

Darf ich bitte nochmal um Hilfe bitten!

Ich habe nun die verschiedenen Vorschläge und Hinweise ausprobiert (oder zumindest das gemacht was ich verstanden habe). Anscheinend mach ich da noch irgendwas falsch, denn mein Aktor schaltet einfach nicht und ich bekomme folgende Fehlermeldung:

Unknown argument on, choose one of clear:readings,all clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk peerChan postEvent press regBulk regSet update:noArg

Der Sensor (also der Taster) funktioniert.

Was habe ich gemacht:

  • Ich habe die abgewandelte Datei "99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm" eingespielt.
  • Ich habe den subtype auf "remoteAndSwitch" gestellt.


Hier die gnaue Definiton die ich aktuell habe:

define Kitchen_Benchtop_Switch CUL_HM 13ED86
setuuid Kitchen_Benchtop_Switch 5c8cffd9-f33f-3ec5-f47e-88f6450ae54c35df
attr Kitchen_Benchtop_Switch IODev HMLAN1
attr Kitchen_Benchtop_Switch autoReadReg 4_reqStatus
attr Kitchen_Benchtop_Switch expert 2_raw
attr Kitchen_Benchtop_Switch firmware 1.5
attr Kitchen_Benchtop_Switch model HM-LC-Sw1PBU-FM-CustomFW
attr Kitchen_Benchtop_Switch room hidden
attr Kitchen_Benchtop_Switch serialNr NEQ0135990
attr Kitchen_Benchtop_Switch subType remoteAndSwitch
attr Kitchen_Benchtop_Switch webCmd getConfig:clear msgEvents

define Kitchen_Benchtop_Switch_On CUL_HM 13ED8601
setuuid Kitchen_Benchtop_Switch_On 5c8cffd9-f33f-3ec5-fdb5-a8062eaa9348ed4f
attr Kitchen_Benchtop_Switch_On model HM-LC-Sw1PBU-FM-CustomFW
attr Kitchen_Benchtop_Switch_On peerIDs 00000000,
attr Kitchen_Benchtop_Switch_On room hidden
define Kitchen_Benchtop_Switch_Off CUL_HM 13ED8602
setuuid Kitchen_Benchtop_Switch_Off 5c8cffd9-f33f-3ec5-da04-28dee46c2e5993eb
attr Kitchen_Benchtop_Switch_Off model HM-LC-Sw1PBU-FM-CustomFW
attr Kitchen_Benchtop_Switch_Off peerIDs 00000000,
attr Kitchen_Benchtop_Switch_Off room hidden

define Kitchen_Benchtop_Light CUL_HM 13ED8603
setuuid Kitchen_Benchtop_Light 5c8cffd9-f33f-3ec5-b52a-58f5d46e62824fd7
attr Kitchen_Benchtop_Light userattr Light_All_Structure Light_All_Structure_map structexclude
attr Kitchen_Benchtop_Light Light_All_Structure Light_All
attr Kitchen_Benchtop_Light model HM-LC-Sw1PBU-FM-CustomFW
attr Kitchen_Benchtop_Light peerIDs 00000000,
attr Kitchen_Benchtop_Light room Kitchen
attr Kitchen_Benchtop_Light subType remoteAndSwitch
attr Kitchen_Benchtop_Light webCmd statusRequest:toggle:on:off

define Kitchen_Benchtop_Power CUL_HM 13ED8604
setuuid Kitchen_Benchtop_Power 5c8cffd9-f33f-3ec5-e308-7885884d94bf48b2
attr Kitchen_Benchtop_Power model HM-LC-Sw1PBU-FM-CustomFW
attr Kitchen_Benchtop_Power peerIDs 00000000,
attr Kitchen_Benchtop_Power room hidden



Vielen Dank für eure Hilfe,
Y. Lee

sumsum

Zitat von: Y. Lee am 23 April 2019, 23:01:38

Was habe ich gemacht:

  • Ich habe die abgewandelte Datei "99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm" eingespielt.
  • Ich habe den subtype auf "remoteAndSwitch" gestellt.



Nimm die HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm wie in https://forum.fhem.de/index.php/topic,18071.msg326473.html#msg326473 beschrieben.
Wie stellst du den subType? Das hat bei mir nie funktioniert. Es gab immer eine Fehlermeldung. Nach den Schritten im Link waren subType und Model richtig ohne manuell was zu machen.

spi3845

Hallo,

ich versuche die alternative Firmware auf einem HM-LC-Sw1PBU-FM zu flashen. Die Links unter https://wiki.fhem.de/wiki/HM-LC-Sw1PBU-FM_Alternative_Firmware und https://wiki.fhem.de/wiki/HM-LC-Sw1PBU-FM_Alternative_Firmware_am_Raspi_bauen_u._flashen passen nicht mehr.

Hat jemand aktuelle Links, wo alle benötigten Dateien zu finden sind? Oder kann mir jemand eine funktionierende avrdude.conf zur Verfügung stellen?

Funktioniert avrdude in der aktuellen Version 6.3 aus dem Standardrepository von Raspbian Stretch (9.9) oder wird immer noch die alte Version 5.10-4 benötigt?

Update:
Ich habe auf Raspbian Stretch die alternative Firmware auf einem rpi 2B geflashed. Da nicht alle links der Anleitungen funktionieren, musste ich selber etwas rumbasteln, um die richtigen Einstellungen zu finden.

Ich habe gar nicht avrdude aus den Raspbian Repositories getestet, sondern selbst die Version 6.1 kompiliert. Vermutlich läuft es aber auch mit der Version aus dem Repository. Teste ich dann beim nächsten Aktor.

In der /etc/avrdude.conf habe ich folgende Einstellungen aufgenommen:
programmer
  id    = "linuxgpio";
  desc  = "Use the Linux sysfs interface to bitbang GPIO lines";
  type  = "linuxgpio";
  reset = 22;
  sck   = 11;
  mosi  = 10;
  miso  = 9;
  baudrate=100000;
;


Die Belegung auf dem rpi entspricht der BCM-Notation - es gibt noch mindestens zwei andere (z.B. Nummer des Pins des Anschlusses auf dem rpi) - die haben aber nicht funktioniert. Die Belegung gibt es hier https://pinout.xyz/

Die Pins des Anschlusses auf dem rpi sind dabei (wenn auf den rpi geschaut wird, er quer gehalten wird und die Anschlussleiste oben links ist, dann ist Pin 1 der unten links):

reset = 22; == rpi Pin 15
sck   = 11; == rpi Pin 23
mosi  = 10; == rpi Pin 19
miso  = 9; == rpi Pin 21
3,3V  == rpi Pin 1
GND == rpi Pin 6

Anbei noch ein Bild zum Anschluss.

Der Aufruf ist dann in der Form:
<Verzeichnis mit avrdude>/avrdude -p m328p -c linuxgpio -v -C /etc/avrdude.conf ...z. B.
<Verzeichnis mit avrdude>/avrdude -p m644p -c linuxgpio -v -C /etc/avrdude.conf -U lfuse:w:0xFD:m -U hfuse:w:0xD8:m -U lock:w:0x3F:m
<Verzeichnis mit avrdude>/avrdude -p m644p -c linuxgpio -v -C /etc/avrdude.conf -U flash:w:bootloader.hex
<Verzeichnis mit avrdude>/avrdude -p m644p -c linuxgpio -v -C /etc/avrdude.conf -U flash:w:firmware.hex


Update 2:
Nachdem ich den HM-LC-Sw1PBU-FM mit anderen Aktoren gepeered habe, ist mir aufgefallen, dass es nach Betätigen der zwei Taster des HM-LC-Sw1PBU-FM etwa 8 s gedauert hat, bis der andere Aktor geschaltet hat.
Ursache waren im HM-LC-Sw1PBU-FM bereits eingetragene Peerings bei Btn_01, Btn_02 und Sw_01. Das waren alles Zahlen der Form 20855703,21D62901,.... Nachdem ich sie alle mit peerBulk gelöscht habe, hat der Aktor sofort reagiert.

Habe auch den Fehler gefunden, warum sie bei mir eingetragen waren. In der Register.h habe ich am Ende #define firstLoad auskommentiert, um die Zentrale für das Pairing einzutragen. Ganz unten sind die Peerings und ich habe sie nicht entfernt...

Update 3:
Blöd, nachdem der Aktor stromlos und wieder einegschaltet wird, sind die Peering wieder da. Muss neu kompilieren...

spi3845

Noch eine Frage zu minImpulsLength:

ich habe eine LED-Lampe mit Bewegungsmelder an meinem Schalter hängen. Sw_02 würde ich dann nutzen, um Bewegungen anzuzeigen (Bewegungsmelder registriert Bewegung, Lampe geht an). Dazu muss ich aber mit minImpulsLength rumspielen, da der Bewegungsmelder ja auch Strom verbrät.

Muss ich jedesmal die Firmware neu flashen oder kann man minImpulsLength auch anders setzen (z. B. per Reading)?
Habe schon überlegt current auszulesen und ab einem Schwellwert einen dummy zu schalten, um mir das ständige Neuflashen zu sparen...

2. Frage: gibt es einen Zusammenhang zwischen current bei Sw_02 und dem Schwellwert minImpulsLength? Also ist z.B. der Wert current bei Sw_02 der Schwellwert * 10, der bei minImpulsLength einzustellen wäre, um ein/aus zu erkennen? Also z.B. bei current=300 (Lampe ist aus und Sw_02 soll off sein) den Wert minImpulsLength auf etwas mehr als 3000 setzen?

Update:
Mittels

devStateIcon {if (ReadingsVal("eg_LichtFlur_Aussenlicht_Sw_2","current",0) > 500){'.*:fa_thumbs_up_alt'}else{'.*:fa_thumbs_down_alt'}}

kann ich bei einem Schwellwert von current=500 unterschiedliche Zustände visualisieren lassen. Muss also nicht neu kompilieren, um den Zustand korrekt zu erkennen.

Die Frage bleibt aber: gibt es einen Zusammenhang zwischen current und minImpulsLength oder sind die voneinander unabhängig?

spi3845

Kann mir hier jemand bei helfen?

Auf einem rpi2 mit Raspbian Stretch baue ich Bootloader und Firmware. Avrdude und srecord habe ich selber kompiliert. Das Bauen von Bootloader (8k) und Firmware fuktioniert.

Beim Flashen per avrdude kann ich die Fuses richtig setzen und die Firmware schreiben. Wenn ich den Bootloader flashe, bekomme ich folgenden Fehler:

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0xfffe
         0xff != 0x1c
avrdude: verification error; content mismatch

avrdude: safemode: lfuse reads as FD
avrdude: safemode: hfuse reads as D8
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK (E:FD, H:D8, L:FD)


Wenn ich den Bootloader aus https://forum.fhem.de/index.php/topic,18071.msg156761.html#msg156761 flashe, klappt es. Irgend etwas scheint beim Bauen schief zu laufen. Hat jemand eine Idee?

Update:
Mit dem Parameter -V kann ich bei avrdude den Fehler unterdrücken, aber das ist ja nicht Sinn der Sache. Die Firmware ist drauf, aber obwohl sie modifiziert ist (https://forum.fhem.de/index.php/topic,18071.msg275891.html#msg275891), funktioniert das Bootmenü nicht per langen Druck auf den Configtaster. Ansonsten läuft der Taster mit der alternativen Firmware. OTA hat bisher nicht funktioniert, da kommt in fhem immer der Fehler "notInBootloader", aber das ist vermutlich dem nicht richtig geflashten Bootloader geschuldet.

knueppler

Hallo zusammen,

eben mal wieder nach sehr langer Zeit (März) einen Update gemacht.
Nun bekomme ich bei den Switchchannels nur noch short_press und long_press für On/Off.
Bin wieder zurück auf die März-Version, bei der ich nur 10_CUL_HM nachladen muss.
Einer ne Idee?
Update:  -> habe eben nochmal geschaut, ich werde das ausprobieren, was sumsum ein paar Posts vorher für ein sehr ähnliches Fehlerbild empfohlen hat und mich wieder melden.
Uodate2: -> hat funktioniert, Frage erledigt

Danke Christian

ucm73

Hallo!
Beim testen mit dem AskSin Analyzer ist mir aufgefallen, dass meine beiden modifizierten Aktoren dauerhaft Informationen "rausfeuern".
Laut dem Analyser soll es sich um ein "Power_Event" handeln.
Firmwareversion ist 1.5. Kann das irgend jemand bestätigen?
Wie kann man es unterbinden?
Besten Dank
Alexander

frank

ja, ca alle 20s wird zb der strom aktualisiert. 
kannst ja die fw anpassen.
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

ucm73

Ich habe mir AskSin.h und Register.h angesehen.
Ich sehe es nicht, hilf mir bitte auf die Sprünge.

frank

Zitat von: ucm73 am 21 Oktober 2019, 20:01:49
Ich habe mir AskSin.h und Register.h angesehen.
Ich sehe es nicht, hilf mir bitte auf die Sprünge.
ich weiss es nicht.

ich würde folgendes versuchen:
vermutlich wird in der ino datei in zeile 136 das event gesendet. daher würde ich die zeit in zeile 65

const uint8_t sendSensorIntervalSec = 150;

vergrössern, eventuell erst einmal verdoppeln.
allerdings verstehe ich gerade nicht, wieso mit den aktuellen werten ein interval von ca 20 sek erreicht wird.

also auf eigene gefahr. 
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

FEHMPiDi

Hallo,

ich habe nach langer Zeit gemerkt das ich noch einen HM_LC_Sw1PBU_FM rumliegen habe und würde da gern die alternative Firmware aufspielen. Leider funktionieren die Anleitungen im www nicht mehr und auch im Wiki nicht. Ich arbeite auf WIN10 mit der IDE 1.8.10.
Beim Kompilieren kommt folgende Fehlermeldung:
C:\Program Files (x86)\Arduino\arduino-builder -dump-prefs -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -hardware C:\Users\becke\AppData\Local\Arduino15\packages -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -tools C:\Users\becke\AppData\Local\Arduino15\packages -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\becke\OneDrive\Dokumente\Arduino\libraries -fqbn=Jabduino_1:jabduino:atmega644a -ide-version=10810 -build-path C:\Users\becke\AppData\Local\Temp\arduino_build_684806 -warnings=default -build-cache C:\Users\becke\AppData\Local\Temp\arduino_cache_167986 -prefs=build.warn_data_percentage=75 -verbose C:\Users\becke\OneDrive\Dokumente\Arduino\libraries\Asksin_HM_LC_Sw1PBU_FM\Asksin_HM_LC_Sw1PBU_FM.ino
C:\Program Files (x86)\Arduino\arduino-builder -compile -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -hardware C:\Users\becke\AppData\Local\Arduino15\packages -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -tools C:\Users\becke\AppData\Local\Arduino15\packages -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\becke\OneDrive\Dokumente\Arduino\libraries -fqbn=Jabduino_1:jabduino:atmega644a -ide-version=10810 -build-path C:\Users\becke\AppData\Local\Temp\arduino_build_684806 -warnings=default -build-cache C:\Users\becke\AppData\Local\Temp\arduino_cache_167986 -prefs=build.warn_data_percentage=75 -verbose C:\Users\becke\OneDrive\Dokumente\Arduino\libraries\Asksin_HM_LC_Sw1PBU_FM\Asksin_HM_LC_Sw1PBU_FM.ino
Using board 'atmega644a' from platform in folder: C:\Program
Using core 'arduino' from platform in folder: C:\Program
Warning: Board Jabduino_1:jabduino:atmega644a doesn't define a 'build.board' preference. Auto-set to: JABDUINO_ATMEGA644A
Warning: Board Jabduino_1:jabduino:atmega644 doesn't define a 'build.board' preference. Auto-set to: JABDUINO_ATMEGA644
Detecting libraries used...
Das Muster recipe.preproc.macros fehlt

Fehler beim Kompilieren für das Board Jabduino ATmega644A.


Kann mir jemand helfen wie ich die entsprechende Firmware und OTA Bootloader kompilieren kann?

Danke im Voraus
FHEM5.7@RaspPi.3|NanoCUL868-HM|NanoCUL868-Max|SDuino|DS18B20|1xHM-Sen-MDIR-WM55|   
2xHM-LC-Sw1PBU-FM|HM-LC-SW4-DR|I2C_MCP23017|2xMAX-ShutterContact|11xHM-LC-Bl1PBU-FM|CTW600|VCONTROL|1xHM-Sen-MDIR-O|2xMilight

Verkehrsrot

Zitat von: sumsum am 23 April 2019, 23:38:43
Nimm die HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm wie in https://forum.fhem.de/index.php/topic,18071.msg326473.html#msg326473 beschrieben.

Nach befolgen dieser Anleitung ist mein reparierter Schalter (C26 defekt, nach Austausch Schalter wieder okay) wieder online und lässt sich über fhem bedienen. Danke für die Hinweise hier! Das hätte ich sonst nie hingekriegt.

Es bleibt aber noch eine Kleinigkeit, ich sehe nun diese Fehler im Log nach Neustart des fhem servers:

2019.12.31 18:24:57 1: PERL WARNING: Subroutine CUL_HM_ParseremoteAndSwitch redefined at ./FHEM/HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm line 125, <$fh> line 86.
2019.12.31 18:24:57 1: PERL WARNING: Subroutine CUL_HM_ParseremoteAndSwitch redefined at ./FHEM/HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm line 229, <$fh> line 86.
2019.12.31 18:24:57 3: additional HM config file loaded: ./FHEM/HMConfig_HM_LC_Sw1PBU_FM_CustomFW.pm


Ignorieren? Oder bekommt man das irgendwie sauber weg?

frank

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

Verkehrsrot

Nein, das hatte ich zuerst übersehen und ergab noch andere Fehler, jetzt ist aber nur noch die HMConfig Datei in /fhem/FHEM