HM Dashbutton

Begonnen von joschi2009, 16 Juli 2017, 19:30:54

Vorheriges Thema - Nächstes Thema

joschi2009

Hallo,

hier nun eine HM-Dashbutton Variante.

Im Prinzip eine Einkanal Fernbedienung in der Optik eines Dashbutton.

Teile:

Papas HM_CR2032 Modul mit seiner HM-RC-4 Firmware.
3d-Druck Gehäuse mit Platinenaufnahme und Microtaster.
Microtaster.

Zeitbedarf:

3d-Druck ca.1 Stunde
Zusammenbau 15 min.

Kosten:

Platine ca. 6-8€
Kleinteile und Druck ca. 50ct


Edit 23.07.2017: Links eingefügt
Edit 04.08.2017: Design überarbeitet

papa

Coole Sache. Ich mach die Tage mal ne HM-RC-P1 Firmware.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

betateilchen

Zitat von: joschi2009 am 16 Juli 2017, 19:30:54
Papas HM_CR2032 Modul mit seiner HM-RC-4 Firmware.

gibts dazu irgendwo mehr Infos? Die Forumsuche hat nix ergeben.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

joschi2009

Zitat von: betateilchen am 23 Juli 2017, 14:53:01
gibts dazu irgendwo mehr Infos? Die Forumsuche hat nix ergeben.

sorry, mein Fehler, habe die Links im ersten Beitrag eingefügt.

Wzut

@joschi2009, schön schön, so ein Teil wäre toll als Ersatz für den kleinen Intertechno Handsender als Garagentoröffner.
Zwei Fragen : hast du den auch mit OpenSCAD erstellt und wenn ja würdest du die Dateien auch wieder zur Verfügung stellen ?
Wie wird der Deckel gehalten ? Nur Klemmung ?
Beim Griffkontakt geht das mit meinen Putz Vandalen gerade so, aber wenn das Ding am Schlüsselbund hängt wie lange bleibt da der Deckel an Ort und Stelle ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

joschi2009

@Wzut
Im Moment noch mit reiner Klemmtechnik. Ich wollte noch etwas an der Optik arbeiten, werde ich die nächsten Tage tun. Die Datei kannst du gerne per Mail haben.

papa

Habe eben eine HM-RC-P1 Firmware unter examples ins Repository eingecheckt. Damit geht nun auch eine echte 1-Tasten-Fernbedienung.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

joschi2009


Wzut

Zitat von: papa am 22 Juli 2017, 22:59:42
Ich mach die Tage mal ne HM-RC-P1 Firmware.
Naive Frage : warum bzw. wo liegt der Vorteil gegenüber der 4 Kanal FB ?
Ich hätte jetzt ganz simpel sogar die FW der Fensterdrehgriffe genommen und hätte dann noch den Vorteil jeden Tag eine Statusmeldung zu bekommen. Oder gibt das dann eventuell Probleme beim direkten Verbinden mit anderen HM Geräten ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

papa

So hast Du keine "toten" Channels im System. Von der 4-Kanal-FB geht ja nur der erste Kanal.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Wzut

OK, bei der Fernbedienung verstehe ich es, aber wenn man die FW der Fensterdrehgriffe nimmt gibt es auch keine toten Channels da doch nur den Status open/close verwendet wird. Achja und gleich noch ne OT Frage : Ich will das Ding mal auf dem Steckbrett mit einem nackten AtMega und einem CC1101 aus einem alten MAX Thermostat aufbauen. Kann ich da den 32kHz Quarz weglassen da ich  dann mit 3,3V Festspannung arbeite ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

papa

Ja - kannst Du weglassen. Der 32kHz Quarz wird bisher von keiner Firmware benutzt.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Wzut

Zitat von: joschi2009 am 16 Juli 2017, 19:30:54
Edit 04.08.2017: Design überarbeitet
Das geht ja völlig unter im Edit .... schaut aber sehr schön aus.

@papa, was ich auch noch nicht verstanden habe beim Bootloader erstellen , auf deiner GitHub Seite schreibst du :
ZitatThe first step is to create a bootloader with the specific device data

    Device Type - 2 Byte Hex
    Device ID - 3 Byte Hex
und in der makeota.html steht :
Device Type - a 4 digit hex number:
HM ID - a 6 digit hex number:

Wo finde ich denn die passenden Werte jeweils zu Device Type und Device ID ?
und bei HM ID soll ich meine eigene HM ID eintragen ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

papa

#13
Zitat von: Wzut am 05 August 2017, 12:24:35
@papa, was ich auch noch nicht verstanden habe beim Bootloader erstellen , auf deiner GitHub Seite schreibst du : und in der makeota.html steht :
Device Type - a 4 digit hex number:
HM ID - a 6 digit hex number:

Wo finde ich denn die passenden Werte jeweils zu Device Type und Device ID ?
und bei HM ID soll ich meine eigene HM ID eintragen ?

Ist doch das selbe. 2 Byte sind 4 Hex-Zeichen bzw. 3 Byte sind 6 Hex-Zeichen. Das werden mehr oder weniger nur Informatiker wissen. Deshalb steht in der HTML-Seite die Anzahl der Zeichen. Der HM-RC-P1 hat den Type 0x00,0x1a - 001a. Ich hänge die Firmware hier mal an.

Edit: Den Typ nochmal korrigiert.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Wzut

#14
ja ok, ich hatte mich in der Eile auch schlecht ausgedrückt. Es ging mir primär nicht um zwei gleich vier sondern um die unterschiedlichen Bezeichnungen bzw. woher man die Info bekommt welche Werte einzutragen sind ( Das es beim FDGK 0300 sind hattest du geschrieben) :)
Ich habe nun den Bootloader damit erstellt geflashed und deine HM-RC-P1 übertragen. Das neue Device meldet sich allerdings als

   firmware   1.1
   model      HM-LC-SW2-SM
   subType    switch
   

und legt zwei Channels an. Im Channel 1 sehe ich beim High/Low Wechsel von A0 Short & Longpress, der Channel 2  hat immer den state unreachable.
Was kann da schief gelaufen sein ?

Edit : in der HM-RC-P1.ino finde ich
#define DEVICE_MODEL 0x00,0x1a
und in der HM-LC-SWX-SM.ino
#define HM_LC_SW2_SM 0x00,0x0a
wäre demnach auf der HTML Seite nicht 000a einzugeben sondern 001a ?

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher