Fensterdrehgriffkontakt selber bauen

Begonnen von Kawaci, 02 Mai 2017, 08:31:59

Vorheriges Thema - Nächstes Thema

rvideobaer

Hallo,

ja, die lassen sich einfach herausziehen.

Gruß Rolf
Raspberry Pi 2, HM-Uart,1x HM-LC-Sw1PBU-FM, 1x HM-RC-2-PBU-FM,1x HM-LC-SW4-DR,1x HM-LC-Sw1-Pl-DN-R1,1x HM-TC-IT-WM-W-EU, 5x HM-CC-RT-DN und noch mehr

UweH

Moin,

um diesen Kontaktproblemen zukünftig aus dem Weg zu gehen, möchte ich nochmal für spätere Platinenrevisionen diese Steckbuchsen empfehlen. Die habe ich seit Jahren bei allen Projekten im Einsatz, bei denen ein SMD-ISP-Anschluß nötig ist.

Buchse:https://www.reichelt.de/Molex-Vielfachsteckverbinder/MOLEX-532610671/3/index.html?ACTION=3&GROUPID=7981&ARTICLE=186229&START=0&OFFSET=16&
Crimpkontakt:https://www.reichelt.de/Molex-Vielfachsteckverbinder/MOLEX-500798100/3/index.html?ACTION=3&GROUPID=7981&ARTICLE=186235&START=0&OFFSET=16&
Steckergehäuse:https://www.reichelt.de/Molex-Vielfachsteckverbinder/MOLEX-510210600/3/index.html?ACTION=3&GROUPID=7981&ARTICLE=186201&START=0&OFFSET=16&

Wie das auf der Platine aussehen kann, sieht man hier. Der Platz für die Buchse ist bestimmt vorhanden. Nachteil ist, dass jeder, der den Atmega brennen möchte, einen Stecker benötigt. Aber so hättet ihr einen standardisierten Stecker und nicht wie jetzt eine improvisierte Bastellösung.

Gruß
Uwe

Per

Ein einfache Stiftleiste reicht doch da. Die Programmer, die es für kleines Geld im Land des umgefallenen Reissackes gibt, haben doch auch nur die dafür passenden Buchsen.
Und wenn es wirklich eng wird, gibt es diese Stiftleisten in "eng" und/oder "kurz".

Wer Angst vor Kurzschlüssen hat, tauscht und macht ne Buchsenleiste dran. Mittels einer Steckerleiste als Adapter (sonst sind die Pins am Programmer offen) ist man auch wieder sicher und kompatibel.

UweH

Zitat von: Per am 08 Februar 2018, 11:56:13
Ein einfache Stiftleiste reicht doch da.
Wenn Platz ist, sicher. Und wenn Platz ist, nimmt man 6-polige oder 10-polige Wannenstecker mit Atmel-ISP-Standardbelegung. Damit jeder mit jedem Programmer drauf zugreifen kann. Aber hier ist kein Platz...

PeMue

Hallo,

ich habe bei meiner mapleCUx Platine eine 6-polige Stiftleiste im 1,27 mm Raster, das ist schön klein, gibt aber sicher Kontakt.

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

PeMue

#1040
Zitat von: joschi2009 am 28 Januar 2018, 17:44:02
Kerl, lass Dich nicht so hängen, der Tag hat 24 Stunden und es gibt ne menge Kaffee auf dieser Welt.  ;D ;D
Nicht quengeln, sondern das Wiki querlesen, ob alles soweit passt  8) 8) 8)
Btw. Kaffee ist mittlerweile alle  ;D

Welche openSCAD Version ist denn gerade aktuell? Sollte ich die auch noch verlinken?

Gruß PeMue

Edit:
@papa: Wenn ich das richtig verstanden habe, emuliert die neue Firmware einen HM-Sec-RHS-2 (ID=00C3), der seitens eq3 lazy config kann. Wenn man die ursprüngliche Firmware drauf hat, emuliert diese einen HM-Sec-RHS (ID=0030), der seitens eq3 lazy config nicht kann, mit dem Update von FHEM aber das ebenfalls kann. Daher auch der neue Bootloader mit der neuen Kennung. Korrekt?
Wenn ja, würde ich das Wiki entsprechend aktualisieren.
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

papa

Zitat von: PeMue am 08 Februar 2018, 21:55:55
@papa: Wenn ich das richtig verstanden habe, emuliert die neue Firmware einen HM-Sec-RHS-2 (ID=00C3), der seitens eq3 lazy config kann. Wenn man die ursprüngliche Firmware drauf hat, emuliert diese einen HM-Sec-RHS (ID=0030), der seitens eq3 lazy config nicht kann, mit dem Update von FHEM aber das ebenfalls kann. Daher auch der neue Bootloader mit der neuen Kennung. Korrekt?
Wenn ja, würde ich das Wiki entsprechend aktualisieren.

Die Firmware ist für beide gleich. Allerdings kann offiziell nur der RHS-2 Lazy Config. FHEM macht es mit der derzeitigen Konfiguration aber auch für den RHS. Da die CCU aber wahrscheinlich nur beim RHS-2 Lazy Config macht, ist im Master jetzt 00C3 im Bootloader eingestellt.
Vielleicht muss ich mal nen extra Branch machen, auf den dann gelinkt werden kann. Dort könnte dann auch das fertig gebaute Hex und EQ3 File liegen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

PeMue

#1042
Hallo papa,

Zitat von: papa am 30 Januar 2018, 13:54:34
Soweit ich das jetzt sehe, sollte nun auch der alte "RHS" (ohne 2) Code mit LazyConfig funktionieren. Somit bräuchte kein Update eingespielt werden.

Zitat von: papa am 09 Februar 2018, 19:42:48
Die Firmware ist für beide gleich.
jetzt bin ich etwas verwirrt  :o

Anfangs dachte ich, ich bräuchte nur FHEM zu aktualisieren, dann kann der Sensor lazy config.

Mittlerweile meine ich, dass man man die ältere Firmware durch die aus Deinem Post auf S. 63 per OTA aktualisieren muss (bzw. FHEM auf aktuellen Stand haben muss), dann wird der Sensor als HM-Sec-RHS erkannt und kann (zumindest in FHEM) lazy config. Wenn man originale Hardware von eQ3 verwendet, sollte man den Bootloader tauschen, damit der Sensor als HM-Sec-RHS-2 erkannt wird.
Insofern ist das Wiki noch falsch, weil ich für HM-Sec-RHS auf die ältere Firmware verlinkt habe.

Passt das soweit?

Danke + Gruß

PeMue

PS: Kriegst Du irgendwie noch ein Register mit rein, das die "Unter"-Version der Firmware oder das Datum speichern kann? Die Versionsverwaltung ist ziemlich undurchsichtig  ???
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

papa

Zitat von: PeMue am 10 Februar 2018, 13:01:39
Anfangs dachte ich, ich bräuchte nur FHEM zu aktualisieren, dann kann der Sensor lazy config.

Mittlerweile meine ich, dass man man die ältere Firmware durch die aus Deinem Post auf S. 63 per OTA aktualisieren muss (bzw. FHEM auf aktuellen Stand haben muss), dann wird der Sensor als HM-Sec-RHS erkannt und kann (zumindest in FHEM) lazy config. Wenn man originale Hardware von eQ3 verwendet, sollte man den Bootloader tauschen, damit der Sensor als HM-Sec-RHS-2 erkannt wird.
Insofern ist das Wiki noch falsch, weil ich für HM-Sec-RHS auf die ältere Firmware verlinkt habe.

Passt das soweit?

Ja - das passt. Die neueste Firmware schadet ja nicht. Ich mach mal ein Firmwares-Git und spiele dort die aktuelle Version ein. Das können wir dann im Wiki linken. Damit bleit dann der Link immer gleich.

Zitat von: PeMue am 10 Februar 2018, 13:01:39
PS: Kriegst Du irgendwie noch ein Register mit rein, das die "Unter"-Version der Firmware oder das Datum speichern kann? Die Versionsverwaltung ist ziemlich undurchsichtig  ???

Das kann ich machen - aber es wird sich nicht so einfach abfragen lassen, da ja das Register nicht offiziell bekannt ist.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

PeMue

RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

meddie

Hallo zusammen,

ich habe meinen ersten DGK ca. 2 Tage im Einsatz und als ich voller Stolz meiner Frau dieses Wunder vorführen wollte, stellte ich fest dass nichts mehr geht. Die Batterie war komplett leer. Einsatzdauer ca. 48 Stunden.
Naja neue Batterie rein, gleiches wieder heute nach ca 2 Tagen den Griff gedreht die LED ging nur kurz an und das wars dann, die Batterie wieder leer.
Ich verstehe gerade nicht warum, habt Ihr ein Tipp für mich?
Bei mir steht in der geschlossen Position der Magnet bei einem Reedkontakt ist das so korrekt, oder zeiht der Atmega dann permanen Strom sollte im Ruhezustand der Magnet nicht besser in der Zwischen Position sein?
Danke
VG Eddie

joschi2009

Zitat von: meddie am 13 Februar 2018, 00:56:20
Die Batterie war komplett leer. Einsatzdauer ca. 48 Stunden.
Naja neue Batterie rein, gleiches wieder heute nach ca 2 Tagen den Griff gedreht die LED ging nur kurz an und das wars dann, die Batterie wieder leer.
Ich verstehe gerade nicht warum, habt Ihr ein Tipp für mich?

Spontan fallen mir 4 mögliche Ursachen ein:

1. schlechte Funkverbindung und der FDGK versucht permanent Daten zu senden. (der RSSI-Wert ist größer 80)
2. schlechte Verbindung an den Batteriepolen was dazu führt, dass der FDGK andauernd einen Neustart durchführt (im Log tauchen Unmengen von Daten des FDGK auf)
3. minderwertige Batterie (normalerweise haben solche Batterien eine Kapazität von rund 220 mAh)
4. Falsch gelötete Platine, zum Beispiel einen x-beliebigen Kondensator mit einem 1k Widerstand vertauscht, das Teil würde wohl funktionieren aber nach 2 Tagen den Betrieb einstellen (mal den Widerstandswert zwischen GND und VCC ohne Batterie messen)

ZitatBei mir steht in der geschlossen Position der Magnet bei einem Reedkontakt ist das so korrekt, oder zeiht der Atmega dann permanen Strom sollte im Ruhezustand der Magnet nicht besser in der Zwischen Position sein?

zu 1. ja, zu 2. nein zu 3. hätte Vor- und Nachteile

VG

joschi2009

meddie

Zitat von: joschi2009 am 13 Februar 2018, 02:58:30
Spontan fallen mir 4 mögliche Ursachen ein:
1. schlechte Funkverbindung und der FDGK versucht permanent Daten zu senden. (der RSSI-Wert ist größer 80)
2. schlechte Verbindung an den Batteriepolen was dazu führt, dass der FDGK andauernd einen Neustart durchführt (im Log tauchen Unmengen von Daten des FDGK auf)
3. minderwertige Batterie (normalerweise haben solche Batterien eine Kapazität von rund 220 mAh)
4. Falsch gelötete Platine, zum Beispiel einen x-beliebigen Kondensator mit einem 1k Widerstand vertauscht, das Teil würde wohl funktionieren aber nach 2 Tagen den Betrieb einstellen (mal den Widerstandswert zwischen GND und VCC ohne Batterie messen)

Hallo Joshi2009,
danke für deine Tipps!

Die Verbindung würde ich fast ausschließen denn das Fenster ist ca. 2 Meter Luftlinie vom HM LAN Adapter entfernt, direkte Sicht ohne irgendetwas dazwischen.
für die Batterie möchte ich meine Hand nicht ins Feuer legen, denn es ist zwar eine Grundig aber ist schon so ein Billigset mit 4 oder 5  Stück im Pack gewesen. Welche würdest Du empfehlen?
Kontakte, hmm ich weiß nicht, die Batterie sitzt schon sehr fest und geht auch relativ schwer rein, also der Druck der Kontakte auf die Batterie ist schon stark, ob das die Leitfähigkeit verbessert weiß ich nicht. Kann man das irgendwie messen?
Die Platine werde ich mal checken, aber ich denke dass hier eher alles richtig sein sollte.

Danke VG Eddie

PeMue

Hallo Eddie,

Zitat von: meddie am 13 Februar 2018, 12:14:59
Kann man das irgendwie messen?
miss einfach mal die Spannung der Batterie vor dem Einbau, dann baust Du die Batterie ein und misst an GND bzw. 3,3 V auf der Platine. Wenn die Differenz zu groß ist, hast Du ggf. Kontaktprobleme.

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

oli82

Hi.
Habe gestern einen weiteren Sensor in Betrieb genommen und ein seltsames Verhalten.
Zum Einen meldet der Sensor, er wäre mit 5C7F49 gepairt.
Ändern kann ich das nicht und auch keine Register setzen.
Im Log sieht das dann wie folgt aus:
2018-02-14_21:06:32 HM_0CA345 trigDst_5C7F49: noConfig
2018-02-14_21:06:32 HM_0CA345 trigger_cnt: 10
2018-02-14_21:06:40 HM_0CA345 Activity: alive
2018-02-14_21:06:40 HM_0CA345 D-firmware: 2.2
2018-02-14_21:06:40 HM_0CA345 D-serialNr: NTMV0C2BUW
2018-02-14_21:06:41 HM_0CA345 R-cyclicInfoMsg: on
2018-02-14_21:06:41 HM_0CA345 R-pairCentral: 0x5C7F49
2018-02-14_21:06:41 HM_0CA345 R-eventDlyTime: 0 s
2018-02-14_21:06:41 HM_0CA345 R-sign: on
2018-02-15_10:08:11 HM_0CA345 battery: ok
2018-02-15_10:08:11 HM_0CA345 contact: open (to 5C7F49)
2018-02-15_10:08:11 HM_0CA345 open
2018-02-15_10:08:11 HM_0CA345 trigDst_5C7F49: noConfig
2018-02-15_10:08:11 HM_0CA345 trigger_cnt: 11
2018-02-15_10:08:22 HM_0CA345 battery: ok
2018-02-15_10:08:22 HM_0CA345 contact: closed (to 5C7F49)
2018-02-15_10:08:22 HM_0CA345 closed
2018-02-15_10:08:22 HM_0CA345 trigDst_5C7F49: noConfig
2018-02-15_10:08:22 HM_0CA345 trigger_cnt: 12

Der Fhem Log meldet mir bei Setzen von Registern:
2018.02.14 21:02:29 4: CUL_HM HM_0CA345 dupe: dont process
2018.02.14 21:02:29 4: CUL_HM HM_0CA345 dupe: dont process
2018.02.14 21:02:37 5: CUL_HM HM_0CA345 protEvent:CMDs_processing... pending:2
2018.02.14 21:02:37 4: CUL_HM HM_0CA345 dupe: dont process
2018.02.14 21:02:38 4: CUL_HM HM_0CA345 dupe: dont process
2018.02.14 21:02:38 5: CUL_HM HM_0CA345 protEvent:CMDs_processing... pending:1
2018.02.14 21:02:38 4: CUL_HM HM_0CA345 dupe: dont process
2018.02.14 21:02:38 4: CUL_HM HM_0CA345 dupe: dont process
2018.02.14 21:02:38 5: CUL_HM HM_0CA345 protEvent:CMDs_processing... pending:0
2018.02.14 21:02:38 4: CUL_HM HM_0CA345 dupe: dont process
2018.02.14 21:02:38 4: CUL_HM HM_0CA345 dupe: dont process
2018.02.14 21:02:39 5: CUL_HM HM_0CA345 protEvent:CMDs_done
2018.02.14 21:02:39 4: CUL_HM HM_0CA345 dupe: dont process

Zwei andere Sensoren funktionieren ohne Probleme mit der gleichen Software (jedoch andere ID)
Danke für die Hilfe