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

mmattern

Zitat von: jab am 02 Juli 2014, 23:40:20
Moin,

ich bin im Augenblick viel Unterwegs. Eigentlich wollte ich noch mal irgendwann ein Usertreffen veranstalten. Im Raum Hannover ggf wenn Interesse besteht. Alternativ Ende des Jahres in Hamburg beim CCCC Congress.

Zu dem Buildproblemen: Ursprünglich ging es nur mit GCC 4.6. Die Probleme habe ich aber eigentlich gefixt. Aktuell nutze ich GCC auf Ubuntu 13.10 (4.8.1) und Ubuntu 14.04 (weiß gerade nicht genau). Im Bootloader sollte das eigentlich alles gehen. Muss ich mir sonst noch mal angucken.

Was für aktuelle Probleme gibt es denn? Können wir eine Liste machen? Gerne auch als Issues auf github dann kann man die besser tracken.


Gruß,
Jan

Hallo Jan,

vielen Dank für die Rückmeldung - ich habe ein Issue aufgemacht: https://github.com/jabdoa2/Asksin_OTA_Bootloader/issues/1

Ich werde mal ein Ubuntu-13.10-Virtualbox-Image ausprobieren zum Erzeugen des Bootloaders...

EDIT: Auch mit Ubuntu-13.10 das gleiche Fehlerbild (VirtualBox-Image von http://virtualboximages.com/Ubuntu+13.10+amd64+VirtualBox+VDI+Virtual+Appliance, darin git, arduino-core, avr-gcc installiert, git clone gemacht und dann make; habe das resultierende .hex-File mal angehängt, falls es hilft... es ist auf jeden Fall auf Byte-Ebene deutlich unterschiedlich von "deinem" funktionierenden...).

Viele Grüße
Michael

P.S.:
Und vielen Dank für deine ganze Arbeit und die super Idee, dieses Projekt aufzuziehen... ist auch eine super Basis für Homebrew-Devices...
2x Raspberry Pi, 2x HM-CFG-LAN, 2x HM-CFG-USB, 2x HM-ES-PMSw1-Pl, 3x HM-LC-BL1-FM, 10x HM-LC-Bl1PBU-FM, 6x HM-LC-Sw1PBU-FM-CustomFW, 2x HM-PB-2-WM55-2, 4x HM-PB-6-WM55, 2x HM-SEC-MDIR-2, 6x HM-SEC-RHS, 2x HM-SEC-WIN, 2x HM-Sys-sRP-Pl

Cyberman

Ich brauche bitte mal einen Anschub, sonst komme ich nicht mehr weiter.

Ich habe mir einen fabrikneuen HM-LC-Sw1PBU-FM besorgt, und zum flashen die 6 MP-Pins mit dem GPIO eines Raspberry verdrahtet. Danach mit den Files aus dieser Quelle https://owncloud.isengard.at/public.php?service=files&t=0df535e31ad6999664f0e84c95bd2ea5 den Bootloader eingespielt. Danach mit dem flash-ota Tool aus gleicher Quelle die Firmware (.eq3) eingespielt.

Die Logs von den Programmiervorgängen habe ich als Files angehängt, auf den ersten Blick scheint alles okay.

Ich bin nicht sicher, in welchem Zustand der Schalter nun ist.

Nach Power-On des Schalters finden sich im Log meines FHEM-Servers folgende Einträge:


2014.07.08 21:04:39 3: HMLAN1: Unknown code A14000010ABCDEF000000004B455130313233343536::-61:HMLAN1, help me!
2014.07.08 21:04:40 3: HMLAN1: Unknown code A0F4200CB2577F0ABCDEF105B11F81547::-57:HMLAN1, help me!


Anschließend reagiert der Schalter auf Wippendruck mit einem kurzen Aufleuchten der LED.
Beim Drücken der Config-Taste reagiert die LED nicht und es passiert scheinbar nichts.
Es gelingt mir nicht, den Schalter mit meiner HM-Zentrale zu pairen und ihm weitere Daten zu entlocken.

Hat jemand eine Idee, wie es nun weitergehen könnte?

mmattern

Zitat von: Cyberman am 08 Juli 2014, 21:37:51
Hat jemand eine Idee, wie es nun weitergehen könnte?

Hallo Cyberman,

eine Idee: löte doch mal die UART-Pins an und schaue, was auf dem Schalter passiert (dabei beachten, dass TX des Schalters an RX des RPi und vice versa gehört) - am besten flasht du eine Firmware mit Serial-Ausgabe, z.B. die hier: http://forum.fhem.de/index.php/topic,18071.msg178535.html#msg178535; probiere doch mal, dann das Pairing über die serielle Konsole zu starten und poste das Ergebnis hier; Pairing mit FHEM hat bei mir eigentlich immer nur über hmPairSerial funktioniert...

Viel Glück!
2x Raspberry Pi, 2x HM-CFG-LAN, 2x HM-CFG-USB, 2x HM-ES-PMSw1-Pl, 3x HM-LC-BL1-FM, 10x HM-LC-Bl1PBU-FM, 6x HM-LC-Sw1PBU-FM-CustomFW, 2x HM-PB-2-WM55-2, 4x HM-PB-6-WM55, 2x HM-SEC-MDIR-2, 6x HM-SEC-RHS, 2x HM-SEC-WIN, 2x HM-Sys-sRP-Pl

frank

2014.07.08 21:04:39 3: HMLAN1: Unknown code A14000010ABCDEF000000004B455130313233343536::-61:HMLAN1, help me!
2014.07.08 21:04:40 3: HMLAN1: Unknown code A0F4200CB2577F0ABCDEF105B11F81547::-57:HMLAN1, help me!

ist das 2577F0 dein hmlan? wenn das dein hmlan ist und der eine message an deinen schalter sendet, sollte das pairen eigentlich angefangen haben. ABCDEF ist jedenfalls der schalter. soweit eigentlich gut.
hast du auch die extra datei in den FHEM ordner kopiert und anschliessend reboot oder reload gemacht? ist autocreate an? die erste message ist die anlernmessage vom schalter, die 2. vom typ 00cb sieht mir nach einer message im zusammenhang mit firmwareupdate aus. seltsam. da sollte von fhem was anderes kommen.

gruss 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

Cyberman

Ja, 2577F0 ist mein HMLAN, und die 99_ASK-soundso.pm ist im FHEM Ordner, und ich habe sowohl ein reload dieser Datei als auch shutdown restart probiert. Das Bild ändert sich dadurch nicht.

Wie versetzt man den Schalter nach Herstellen der Stromzufuhr in den Anlernmodus, und was signalisiert die LED?

Gesendet von meinem Nexus 5 mit Tapatalk


frank

ZitatWie versetzt man den Schalter nach Herstellen der Stromzufuhr in den Anlernmodus, und was signalisiert die LED?
kurz drücken. led sagt quasi nichts. war aber die vorgängerversion bei mir. lange drücken reset.

aber wie gesagt, die anlernmessage war da. vielleicht ist dein fhem zu neu.
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

Cyberman

Nochmal FHEM neu gestartet, aber der Schalter wird nicht erkannt - trotz autocreate und geladenem Modul 99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm, abgelegt unter /opt/fhem/FHEM.

Der Schalter scheint jedoch zu leben, denn

- Nach Power On erscheint im Event Monitor:


2014-07-09 00:41:20 HMLAN HMLAN1 UNKNOWNCODE A14000010ABCDEF000000004B455130313233343536::-58:HMLAN1


- Danach erscheinen bei Betätigung der Wippe folgende Telegramm im Event Monitor:

Wippe oben betätigt


2014-07-09 00:41:47 HMLAN HMLAN1 UNKNOWNCODE A0B00A24029F26F0000000100::-62:HMLAN1
2014-07-09 00:41:48 HMLAN HMLAN1 UNKNOWNCODE A0B00A24029F26F0000000100::-62:HMLAN1
2014-07-09 00:41:49 HMLAN HMLAN1 UNKNOWNCODE A0B00A24029F26F0000000100::-61:HMLAN1


Wippe unten betätigt


2014-07-09 00:41:53 HMLAN HMLAN1 UNKNOWNCODE A0B01A24029F26F0000000200::-61:HMLAN1
2014-07-09 00:41:53 HMLAN HMLAN1 UNKNOWNCODE A0B01A24029F26F0000000200::-61:HMLAN1
2014-07-09 00:41:53 HMLAN HMLAN1 UNKNOWNCODE A0B01A24029F26F0000000200::-61:HMLAN1


Die Bytefolge 29F26F erkenne ich wieder, denn ich war schonmal etwas weiter. Hatte zuerst den Bootloader weggelassen, und die Firmware über Draht direkt geflasht. Danach erschien im Log
das neue Gerät CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_29F26F

Seitdem ich den Bootloader reingeflasht und die Firmware dann über OTA nachgeschoben habe, komme ich soweit nicht mehr.

frank

interessanter wäre, was beim drücken der anlerntaste passiert. du setzt deinen hmlan ja auch in den anlernmodus?
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

Cyberman

Anlernmodus in FHEM ist mit set HMLAN1 hmPairForSec 120 gesetzt.
Danach Power on am Schalter und Drücken der Anlerntaste. Es passiert schlicht gar nichts: Keine LED-Signalisierung, kein Datentelegramm im Event Monitor.
Der Schalter geht direkt in den zuvor beschriebenen Modus, schickt die eine Initialmeldung und reagiert dann auf Wippenbetätigung mit weiteren Telegrammen.

Somit erkennt er die Wippenbewegung, und funken tut er auch - komplett abgestürzt scheint er also nicht zu ein?

frank

resette den schalter mal, ca 5 sec drücken, danach nochmal drücxken. dann blinkt die led, glaub ich, dann anlernen.
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

Mr. P

Michael schrieb in einen seiner letzten Posts:
Zitat von: mmattern am 24 Juni 2014, 02:47:56
Eine mögliche Falle für das erste Pairing lauert auch noch darin, dass nicht immer alle Module geladen werden, sondern nur die nötigen... wenn man kein CustomFW-Device definiert hat, wird 99_Asksin..... .pm wohl nicht geladen, was dazu führt, dass das Device dann nicht richtig erkannt wird.
Also einfach eins definieren, bevor man das erste Mal pairt, damit das Asksin-Modul geladen wird...
Probier es einmal aus... vielleicht hilft es. ;-)
Greetz,
   Mr. P

mmattern

Zitat von: Cyberman am 09 Juli 2014, 01:11:59
Anlernmodus in FHEM ist mit set HMLAN1 hmPairForSec 120 gesetzt.

Probiere es mal mit hmPairSerial...

Du hattest geschrieben, dass das Device in FHEM schon angelegt war, nachdem du die Firmware direkt geflashed hattest... ist es immer noch angelegt oder hast du es wieder gelöscht?
Falls noch angelegt, kannst du auch dort vom Device aus das Pairing starten...

Falls nicht angelegt, kannst du es ja mal in die fhem.cfg eintragen - hier mal ein Device von mir - HMID ist hier 2A32E8, d.h. du müsstest alle 2A32E8 durch ABCDEF ersetzen:
define devLS.Kellertreppe CUL_HM 2A32E8
attr devLS.Kellertreppe IODev HMUSB
attr devLS.Kellertreppe autoReadReg 4_reqStatus
attr devLS.Kellertreppe expert 2_full
attr devLS.Kellertreppe firmware 1.5
attr devLS.Kellertreppe model HM-LC-Sw1PBU-FM-CustomFW
attr devLS.Kellertreppe room CUL_HM,Keller,EG,Licht
attr devLS.Kellertreppe serialNr KEQ0123456
attr devLS.Kellertreppe subType remoteAndSwitch
attr devLS.Kellertreppe webCmd getConfig:clear msgEvents
define FileLog_devLS.Kellertreppe FileLog ./log/devLS.Kellertreppe-%Y.log devLS.Kellertreppe
attr FileLog_devLS.Kellertreppe logtype text
attr FileLog_devLS.Kellertreppe room CUL_HM,Keller,EG,Licht
define btnLS.Kellertreppe.1 CUL_HM 2A32E801
attr btnLS.Kellertreppe.1 model HM-LC-Sw1PBU-FM-CustomFW
attr btnLS.Kellertreppe.1 peerIDs 00000000,2A32E804,
define btnLS.Kellertreppe.2 CUL_HM 2A32E802
attr btnLS.Kellertreppe.2 model HM-LC-Sw1PBU-FM-CustomFW
attr btnLS.Kellertreppe.2 peerIDs 00000000,2A32E804,
define LS_Leer.Kellertreppe CUL_HM 2A32E803
attr LS_Leer.Kellertreppe model HM-LC-Sw1PBU-FM-CustomFW
attr LS_Leer.Kellertreppe peerIDs 00000000,
attr LS_Leer.Kellertreppe room hidden
define LS.Kellertreppe CUL_HM 2A32E804
attr LS.Kellertreppe event-on-change-reading pct
attr LS.Kellertreppe model HM-LC-Sw1PBU-FM-CustomFW
attr LS.Kellertreppe peerIDs 00000000,2A32E801,2A32E802,
attr LS.Kellertreppe room CUL_HM,Keller,EG,Licht


Viel Glück!
2x Raspberry Pi, 2x HM-CFG-LAN, 2x HM-CFG-USB, 2x HM-ES-PMSw1-Pl, 3x HM-LC-BL1-FM, 10x HM-LC-Bl1PBU-FM, 6x HM-LC-Sw1PBU-FM-CustomFW, 2x HM-PB-2-WM55-2, 4x HM-PB-6-WM55, 2x HM-SEC-MDIR-2, 6x HM-SEC-RHS, 2x HM-SEC-WIN, 2x HM-Sys-sRP-Pl

mmattern

Zitat von: Cyberman am 09 Juli 2014, 00:53:42
Die Bytefolge 29F26F erkenne ich wieder, denn ich war schonmal etwas weiter. Hatte zuerst den Bootloader weggelassen, und die Firmware über Draht direkt geflasht. Danach erschien im Log
das neue Gerät CUL_HM_HM_LC_Sw1PBU_FM_CustomFW_29F26F

29F26F ist offenbar die HMID deines Schalters... aber er sendet nicht an deine Zentrale, sondern an Broadcast - die Folge 00 00 00 nach 29F26F ist  die Broadcast-Adresse... m.W. tut der Schalter das, wenn er keine pairCentral gespeichert hat...
2x Raspberry Pi, 2x HM-CFG-LAN, 2x HM-CFG-USB, 2x HM-ES-PMSw1-Pl, 3x HM-LC-BL1-FM, 10x HM-LC-Bl1PBU-FM, 6x HM-LC-Sw1PBU-FM-CustomFW, 2x HM-PB-2-WM55-2, 4x HM-PB-6-WM55, 2x HM-SEC-MDIR-2, 6x HM-SEC-RHS, 2x HM-SEC-WIN, 2x HM-Sys-sRP-Pl

Cyberman

Zitat von: mmattern am 09 Juli 2014, 09:58:36
Probiere es mal mit hmPairSerial...

Das habe ich probiert, bislang ohne Erfolg. Ich bin nicht sicher, ob ich die richtige Serialnr verwende.
Laut Firmware-Doku soll der Schalter auf KEQ0123456 hören. In FHEM sehe ich den Schalter mit PairSerial=PS0000002. Aber mit keiner der beiden Nummern gelingt mir ein Pairing. In den Readings des Schalters bleibt es stets bei Paired To 0x0, was wohl die Datentelegramme mit dem Broadcast erklärt.


Readings
D-firmware 1.5
PairedTo 0x0
R-pairCentral 0x0
RegL_00: 02:00 05:00 0A:00 0B:00 0C:00 12:00 00:00
state CMDs_done


Trotzdem lässt sich der Schalter aus FHEM steuern, er reagiert auf Schaltbefehle.

Zitat von: mmattern am 09 Juli 2014, 09:58:36
Du hattest geschrieben, dass das Device in FHEM schon angelegt war, nachdem du die Firmware direkt geflashed hattest... ist es immer noch angelegt oder hast du es wieder gelöscht?

Ich habe den Code noch und kann ihn in der fhem.cfg wieder reaktivieren. Aber...

Zitat von: mmattern am 09 Juli 2014, 09:58:36
Falls noch angelegt, kannst du auch dort vom Device aus das Pairing starten...

... wie mache ich das? Vom Device aus?


Mr. P

Zitat von: Cyberman am 10 Juli 2014, 11:38:55
Trotzdem lässt sich der Schalter aus FHEM steuern, er reagiert auf Schaltbefehle.
Ja, das habe ich auch bereits angemerkt. Habe zwar noch nicht probiert, wie der Schalter reagiert, wenn erst einmal mit einer Zentrale gepairt wurde. Aber solange er Broadcast sendet, kann er von überall aus getriggert werden.

Wegen dem Pairing hatte ich auch erst Erfolg, als ich mir die Firmware selbst gebaut und 'firstLoad' in der Register.h aktiviert hatte.
Dadurch versucht der Schalter von sich aus bei jedem Mal "einschalten" sich mit der ebenfalls in der Register.h hinterlegten Zentrale zu pairen und das hat bei mir dann auf Anhieb geklappt.
Ich befürchte, da gibt es wohl zZ ein Problem mit dem Anlernknopf des Schalters bei der alternativen Firmware.
Greetz,
   Mr. P