FHEM Forum

Verschiedenes => Bastelecke => Thema gestartet von: papa am 02 April 2020, 09:37:44

Titel: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 02 April 2020, 09:37:44
Ich habe einen neuen Fensterdrehgriffkontakt erstellt. Dieser hat folgende "verbesserte" Eigenschaften:
Hardware:
  * CR2477 Batterie mit 1000 mAh
  * Reedkontakte durch TLE4913 ersetzt
  * Anschluß für einen Glasbruchmelder
  * ca. 20µA im Sleep
Software:
  * kontinuierliche Batterie-Messung, wenn Gerät aktiv (Messung unter Last)
  * kein Polling - voll Interrupt gesteuert
FHEM Integration - neues Gerät HB-Sec-RHS-3:
  * Batteriespannung wird mit dem Status übertragen
  * Low-Batterie-Wert ist mit Register setzbar

Der erste Prototyp läuft. Alle Daten sind im GitHub https://github.com/pa-pa/HB-Sec-RHS-3.git zu finden. Für den Sketch wird die neueste AskSin++ Version aus dem Master benötigt. In FHEM muss das AskSin++ Addon (https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/contrib/FHEM) installiert sein.

Derzeit gibt es nur die Version, bei welcher das Gehäuse am Fensterrahmen übersteht. Damit wird eine vom Griff unabhängige Fenster-Offen-Erkennung möglich. Dafür nehme ich den dritten TLE. Neben dem Rahmen wird dann noch eine Halterung mit Magnet angebracht (siehe Bild).
Eine alternative Platine, die nach unter geht, lässt sich sicherlich auch machen. Hat für mich persönlich derzeit aber keine Priorität. Da kann dann der 3te TLE für eine Sabotage-Erkennung genutzt werden.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rabehd am 02 April 2020, 11:14:27
nur so ein Gedanke: Wenn man da noch einen Glasbruchsensor dran bekäme...

Ansonsten Danke.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 02 April 2020, 12:15:14
Ich werde auf jeden Fall noch was an der Platine machen. Die Frage ist hier, wie ist ein Glasbruchsensor anzuschließen ? Ein paar freie Pins irgendwo rausführen, ist sicherlich kein Problem.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: herrmannj am 02 April 2020, 12:34:47
Moin,

halb ot: ich habe ja die https://www.amazon.de/Schellenberg-Funk-Alarmgriff-Alarmfunktion-Fensterstatus-Urlaubsfunktion/dp/B01E407U9K

Die sind vom rf protokoll halt Schei__e aber die Hardware ist da halt komplett. Die haben Erschütterungssensor und Glasbruch schon drin (plus Drehgriff reporting). Ich glaube die machen Glasbruck per Mikrofon. Unter Umsänden könnte man die Hardware als Basis und eine neue offene FW drüberbügeln. Das hatte ich mal vor, habe aber aus Zeitgründen nie was in der Richtung gemacht. Dazu kommt das ich das rf Protokoll zumindest soweit verstehe das es für einen POC gereicht hat, produktiv ist da noch ncihts draus geworden.

@Papa mir ist schon klar dass das vmtl nicht meinen Deinen Zielen deckungsgleich ist. Zumal ich von Deinen Entwicklungen die höchste Meinung habe. Ich wollte das nur mal hochbringen, vielleicht ergeben sich ja Synergien oder so.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rabehd am 02 April 2020, 12:38:25
Ich werde auf jeden Fall noch was an der Platine machen. Die Frage ist hier, wie ist ein Glasbruchsensor anzuschließen ? Ein paar freie Pins irgendwo rausführen, ist sicherlich kein Problem.

Da habe ich noch ein paar rumliegen. Man kann die Dinger anstelle des Reed-Kontaktes an die HM-Fenstersensoren löten. Ich habe es noch nicht eingebaut, da mir noch eine Testscheibe fehlt.
Ich glaube es gibt öffnende und schließende Kontakte. Die Dinger sind rein passiv.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 02 April 2020, 14:15:11
Mal kurz im Web gesucht. Bei Abus fündig geworden. https://www.abus.com/ger/Sicherheit-Zuhause/Alarmanlagen/Terxon-Draht-und-Hybridalarmanlage/Melder/Glasbruch-und-Erschuetterungsmelder/Potenzialfreier-Glasbruchmelder-weiss
Die haben einen potential-freien Schalter NC (Normaly Closed) drin. Der würde sich prinzipiell genauso anbinden lassen wie die TLEs.
Da es sowieso ein neues Gerät ist, würde man dann auch einen zweiten Kanal für die Alarmierung machen können.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Psi am 02 April 2020, 22:50:22
Ich möchte noch mal das Thema Heizkörper-Thermostat aufgreifen. Könnte man denn eine Direktverknüpfung herstellen?
Wie mir Jerome erklärt hat, wäre es vom Timing her unproblematisch da ohnehin ein BURST verwendet verwendet wird. Wie verhält sich das, wenn es kein Original-Gerät ist? DV werden ja eigentlich zwischen Kanälen erstellt also dürfte dem eig nichts im Wege stehen oder?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 02 April 2020, 23:25:25
Das ist kein Problem. Das Timing ist nur für die Übertragung der Temperatur wichtig. Die Fenter-Open-Nachricht wird mit Burst gesendet. Du kannst ja nicht wissen, wann der Regler wieder lauscht und genau dann das Fenster öffen ;-)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 April 2020, 20:59:58
Habe jetzt mal den Glasbruchmelder mit eingebaut. Dazu musste ich aber die gesamte Platine neu layouten. Die Bestückung aller SMD-Bauelemente ist jetzt komplett auf der Unterseite. Nur noch die Batteriehalterung, die Taster und LEDs sind oben.
Derzeit suche ich noch eine ordentliche Anschlußklemme für den Glasbruchmelder. Am besten SMT-Mount. Hat da jemand Vorschläge.
Da Gehäuse musste auch noch etwas angepasst werden, da ja nun die TLEs unten sind. Ich habe mal den ersten Beitrag angepasst.
Der Versuch, einer vertikalen "einfachen" Version sieht nocht nicht besonders gut aus. Ich möchte auf keine Fall länger als 10cm sein. Da passt dann aber unten nicht mehr viel auf die Platine. Wahrscheinlich muss das obere Loch noch weg. Das gibt dann noch extra Platz unten.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 03 April 2020, 21:20:45
Derzeit suche ich noch eine ordentliche Anschlußklemme für den Glasbruchmelder. Am besten SMT-Mount. Hat da jemand Vorschläge?
Zweipolig und im RM 2.0 oder kleiner? Ich schau mal, ich meine ich hätte irgendwo mal JST Steckverbinder in SMD verbaut ...

Gruß Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 April 2020, 21:49:27
Tja - schau mal, sowas kommt da dann ran. https://www.amazon.de/ABUS-Glasbruchmelder-passiv-GBM7300-56985/dp/B00DS1Z0K8?th=1
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 April 2020, 21:52:34
Hab jetzt nochmal ein wenig geschoben. Ich denke, eine alternative Version sollte auch möglich sein. Die Höhe ist exakt 10cm. Damit kann das auch günstig in China gefertigt werden.
Ich checke das mal nit ins Github ein. Fertig machen werde ich das aber erst mal nicht.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 04 April 2020, 11:32:33
Sieht doch gut aus. Ist auch sehr schön, das in einer Platine zu machen. So spart man sich das gefrickel mit den dünnen Kabeln zu den Reed Kontakten. Könnte man nicht für den ISP und Anschluss für den Glasbruchmelder so eine Doppe-Pfostenreihe nehmen aber mit Rastermaß 2 oder 1 (Als SMT)? Gerade bei dem ISP wäre es besser, damit man da auch rann kommt ohne die Platine jedes mal auszubauen. Oder eben diese Flachband Verbinder, das ist dann auch SMD aber da muss man sich eben ein Adapter basteln von dem Flachband auf was auch immer. Aber für den Glasbruchmelder ist das auch keine echte Option.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: pc1246 am 05 April 2020, 17:47:11
Wow
Das sieht mal gut aus! Jetzt komt wieder meine Frage, wo bekommt man ein vernuenftiges Gehaeuse her!? Das ist und bleibt das WAF-Kriterium.
Wie gut, dass ich meine noch nicht gebaut habe!
Gruss Christoph
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Psi am 05 April 2020, 18:16:23
Drucken? 😁Wenn die Platine da ist werde sicher einige Varianten entstehen, wie auch beim alten.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 05 April 2020, 19:09:05
Hallo papa,

Tja - schau mal, sowas kommt da dann ran. https://www.amazon.de/ABUS-Glasbruchmelder-passiv-GBM7300-56985/dp/B00DS1Z0K8?th=1
das kleinste, was ich mal verbaut habe war folgender Stecker:
Würth SMD connector 1.25 mm pitch, 3 pin
Conrad No.: 1088432-62 , Würth-No.: 653103131822
der zweipolige  müsste dann dieser hier (https://www.voelkner.de/products/686800/Wuerth-Elektronik-Einbau-Stiftleiste-Standard-WR-WTB-Polzahl-Gesamt-2-Rastermass-1.25mm-653102131822.html?offer=3e0cdf96154c581cc52f14ef63298268) sein.

Gruß Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 05 April 2020, 23:40:17
@PeMu - ich glaube das ist etwas zu klein.
@ext3 - habe mal die 2mm Doppelreihe drauf gemacht. Das sieht nicht schlecht aus. Aber nen passenden Stecker habe ich auch nicht gefunden :-(
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 06 April 2020, 07:46:54
Moin,

gibt es aber, muss man halt ein bissel feilen und basteln. Bei Segor kannste mal nach "FL 2x10-180G/RM2,0" suchen.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: pc1246 am 06 April 2020, 08:04:20
Drucken? 😁Wenn die Platine da ist werde sicher einige Varianten entstehen, wie auch beim alten.
Moin
Das ist mir klar, nur habe ich das Problem, das die Ergebnisse leider nicht dem entsprechen, was ich anbauen darf, und teilweise auch moechte.
Das was Papa da entworfen hat sieht total genial aus. Leider ist die Realitaet irgendwie weit davon entfernt. Und da die Dinger dann auch noch inHandnaehe sind, duerfen SIe bei einer Beruehrung nicht gleich Kampfspuren hinterlassen!
Gruss Christoph
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 06 April 2020, 08:34:20
Und da die Dinger dann auch noch inHandnaehe sind, duerfen SIe bei einer Beruehrung nicht gleich Kampfspuren hinterlassen!
Gruss Christoph

Wenn ich dich beruhigen darf, die originale HM Sensoren sehen bei mir schlimmer aus als die nachgebauten. Das Gehäuse von den Originalen ist schon schwarz gekratzt...

Aber wenn deine Gattin da so empfindlich ist, hast du mal ein Druck ausprobiert mit Resin? Die Drucker werden ja auch immer erschwinglicher und vielleicht hat hier schon jemand so ein Drucker. Das sollte dann nochmal einiges besser aussehen als mit FDM/FFF.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 06 April 2020, 08:37:04
Also mit dem Design habe ich gute Erfahrungen gemacht. Der abgelichtete Sensor ist seit ca. 2 Jahren im Einsatz.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 06 April 2020, 09:31:05
@PeMu2 - ich glaube das ist etwas zu klein.
Größer geht immmer  ;). Nächster Versuch mit einem JST PH 2.0 mm (auch SMD), siehe hier (https://www.reichelt.de/jst-stiftleiste-smd-90-1x2-polig-ph-jst-ph2p-st90s-p185067.html?&trstct=pol_1&nbc=1). Gibt es auch als through hole ...
Wenn das immer noch nicht reicht, geht es mit dem JST XH (https://www.reichelt.de/jst-stiftleiste-gerade-1x2-polig-xh-jst-xh2p-st-p185073.html?&trstct=pol_1&nbc=1) weiter, dann im RM 2,5 mm. Der könnte ggf. auch statt dem Jumper funktionieren.

Gruß Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 06 April 2020, 10:31:07
Die sehen gut aus. Der zweite ist wahrscheinlich sogar am besten geeignet, da man dann auch alternativ einfach einen 2,54 Pinheader bestücken kann.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: pc1246 am 06 April 2020, 13:05:52
Also mit dem Design habe ich gute Erfahrungen gemacht. Der abgelichtete Sensor ist seit ca. 2 Jahren im Einsatz.
Ok
Das sieht sehr gut aus. Wie hast Du das so hinbekommen? Nachtraeglich mit Aceton, oder Resin Drucker? (Geht ja eigentlich nicht, wenn schon zwei Jahre alt)
Mein Problem ist, dass ich keinen eigenen Drucker habe, und bisher alles eher sehr einfach gedruckt war, was ich so zu sehen bekommen habe.
Sprich Faeden hingen noch dran, leichte rillen zu erkennen, usw.
Gruss Christoph
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 06 April 2020, 15:19:36
Das ist ein stink normaler Anycubic i3 Mega mit PLA. Der Deckel ist hochkant stehend mit 0,1mm Schichthöhe gedruckt. Die Wandstärke ist mit 1,2mm ein vielfaches der Düsen von 0,4mm.
Wenn man ganz genau hinsieht, kann man auch Steifen/Rillen erkennen. Das läßt sich auch nicht vollständig vermeiden. Ist aber auf dem Bild nicht zu erkennen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 06 April 2020, 22:11:45
So, denke die Platine ist final. Habe jetzt den abgewinkelten JST XH genommen. Alles eingecheckt. Ich habe auch die BOM- und PNP-Dateien für JCLPCB-Assembly mit eingecheckt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 06 April 2020, 22:37:06
Jetzt doch wieder zu dem klobigen Teil gewechselt ;-)

Ich muss mir dann mal ein Gehäuse drucken, aber ich glaube bei meinen Fenstern passt das überall nicht rann. Ich habe zwischen den Fensterflügeln nur 5 mm Platz. Die stoßen dann bestimmt zusammen beide.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 06 April 2020, 23:00:47
Ja natürlich ;-)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Psi am 06 April 2020, 23:30:37
Hi,
ich hätte noch ein paar Fragen zur Schaltung:

1.) du hast 1MΩ PullUp genommen, diesen hohen Wert hast du gewählt um den Stromverbrauch möglichst gering zu halten?

2.) Du schreibst "Batterie-Messung unter Last" wofür du offensichtlich IrqInternalBatt nutzt.
Heißt also, dass du den VCC direkt am AVR misst wenn das Gerät wach ist. Aber wäre hier nicht nur _wach_ sondern _während des Sendes_ interessant, denn gerade hier bricht doch die Spannung ein oder?

3.) Bezüglich BI-Protection kam mal die Idee eines PullUps am CSN auf.
Vllt könnte Tom hier etwas zu sagen?!?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 07 April 2020, 08:20:34
1.) du hast 1MΩ PullUp genommen, diesen hohen Wert hast du gewählt um den Stromverbrauch möglichst gering zu halten?
Ja genau. Zumindest mit den TLE4913 funktioniert das super. Wie das für den Glasbuchsensor aussieht, kann ich nicht sagen. Wenn dort der Impulse zu klein wird, könnte es sein, dass das ein kleinerer Widerstand verwendet werden muss.
2.) Du schreibst "Batterie-Messung unter Last" wofür du offensichtlich IrqInternalBatt nutzt.
Heißt also, dass du den VCC direkt am AVR misst wenn das Gerät wach ist. Aber wäre hier nicht nur _wach_ sondern _während des Sendes_ interessant, denn gerade hier bricht doch die Spannung ein oder?
Genau das macht die neue Implementierung. Wenn das Geräte aus dem Sleep aufwacht, wird eine kontinuierliche Messung der internen VCC gestartet. Zusätzlich wird der ADC-Interrupt eingeschalten. Dieser wird nach jeder fertigen Messung aufgerufen und übernimmt den ermittelten Wert. Nur wenn der Wert kleiner als der aktuelle ist, wird er gespeichert. Die Messung wird erst gestoppt, wenn das Gerät wieder in den Sleep geht. Da das ganze ständig im Hintergrund abläuft, wird natürlich auch während des Sendens gemessen.
3.) Bezüglich BI-Protection kam mal die Idee eines PullUps am CSN auf.
Vllt könnte Tom hier etwas zu sagen?!?
Den Pullup kann man ja noch ohne Probleme einfügen. Hatte ich bisher nicht mit drauf.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tom Major am 07 April 2020, 16:38:32
der pull-up an /CS ist nicht wegen BI-Protection sondern um bei Parallelbenutzung der SPI (ISP) den cc1101 sauber zu deaktivieren.

IrqInternalBatt Konzept finde ich gut, papa, Daumen hoch.  :)
Das ergibt sicher eine viel bessere Batt.zustandseinschätzung als das bisherige azyklische Messen mit eigenem AskSinPP timer.
Für CR20xx Batterien sicher eine Verbesserung.

Für AA bzw. AAA im Bereich 800..2500 mAh halte ich den Strom durch das Senden als Belastung für ggf. zu gering, deswegen mache ich da gerne die "Echte Batteriespannungsmessung unter Last"
https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#messung-der-batteriespannung (https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#messung-der-batteriespannung)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 08 April 2020, 09:27:37
IrqInternalBatt Konzept finde ich gut, papa, Daumen hoch.  :)
Das ergibt sicher eine viel bessere Batt.zustandseinschätzung als das bisherige azyklische Messen mit eigenem AskSinPP timer.
Für CR20xx Batterien sicher eine Verbesserung.
Ich habe hier nen Testsystem mit einer (mit ganz neuen) CR2032 liegen, das meldet von Anfang an nur 2,4V.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 08 April 2020, 09:44:36
Ich hab mein original HM mal zerlegt, der spinnt manchmal vorne und hinten und ich weiß nicht warum. Aber hier mal ein Foto falls sich jemand mal für das Innenleben interessiert.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: pc1246 am 08 April 2020, 09:53:43
Ich hab mein original HM mal zerlegt, der spinnt manchmal vorne und hinten und ich weiß nicht warum. Aber hier mal ein Foto falls sich jemand mal für das Innenleben interessiert.
<OT>
Die sind doch auch bloed. Warum gab es den nie als Bausatz? Der HM-IP ist da wesentlich komplizierter von innen.
</OT>
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 08 April 2020, 13:36:37
Echt? Kannste mal Fotos schicken? Ich find das an sich ganz gut. Könnte man auch alles sehr einfach selber drucken. Schwachstelle sind natürlich die Kontakte...

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tom Major am 08 April 2020, 17:07:21
Ich habe hier nen Testsystem mit einer (mit ganz neuen) CR2032 liegen, das meldet von Anfang an nur 2,4V.

die CR2032 ist für die 35mA Sendestrom nicht besonders geeignet denke ich, da ist dann einfach Ri zu groß so dass es auf 2,4V zusammenbricht, wahrsch. auch noch Herstellerabhängig.

Hier sind ein paar Infos dazu
https://electronics.stackexchange.com/questions/234901/lithium-coin-cell-cr2032-battery-specifications (https://electronics.stackexchange.com/questions/234901/lithium-coin-cell-cr2032-battery-specifications)

ich würde wahrscheinlich so was wie dort erwähnt in Betracht ziehen:
Zitat
SiLabs recommends it for their BGM111 Bluetooth module too. To quote the datasheet: “Coin cell batteries cannot withstand high peak currents (e.g. higher than 15 mA). If the peak current exceeds 15 mA it’s recommended to place 47 - 100 µF capacitor in parallel with the coin cell battery to improve the battery life time.”

Die CR2477 bringt da sicher etwas Verbesserung aber auch dort könnte der Elko nützlich sein.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Prof. Dr. Peter Henning am 08 April 2020, 18:06:45
Ich steuere gerne auch Drucke in kleiner Anzahl bei.

LG

pah
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 08 April 2020, 19:47:54
Vorsicht - das Gehäuse für den abgerundeten Griff passt noch nicht ganz. Ich wollte die Maße noch änderbar in ein FreeCad-Sheet machen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fanavity am 08 April 2020, 22:16:30
Wird es noch ein anderes platinenlayout geben? Durch den überstand werde ich die leider an so gut wie keinem Fenster montieren können :( wie wird die Stellung des Griffs ermittelt ? Wieder mit reedkontakt oder anders?
Vielen Dank :)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 08 April 2020, 23:33:01
Hab gerade noch ein wenig mit dem schmalen Layout gespielt. Sieht so aus, als würde es funktionieren. Ist alles im Github eingecheckt.
Für den Rest siehe erster Beitrag.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: pc1246 am 09 April 2020, 08:11:43
Wird es noch ein anderes platinenlayout geben? Durch den überstand werde ich die leider an so gut wie keinem Fenster montieren können :( wie wird die Stellung des Griffs ermittelt ? Wieder mit reedkontakt oder anders?
Vielen Dank :)
Moin
Wie im ersten post geschrieben, wird das mit TLE4913 Hallsensoren gemacht. Diese sitzen als U1-U3 auf der Platine. Der U3 ist nur bei der grossen dran, und funktioniert als Tuer/Fenster offen Kontakt.
Also letzendlich Magnet an die Achse, Gehaeuse mit Platine drueber und fertig!
Gruss Christoph
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: pc1246 am 09 April 2020, 08:13:34
Echt? Kannste mal Fotos schicken? Ich find das an sich ganz gut. Könnte man auch alles sehr einfach selber drucken. Schwachstelle sind natürlich die Kontakte...

/Daniel
Moin
Ich schaue mal ob ich die Bauanleitung finde. Dann stell ich das mal hier rein.
Gruss Christoph
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 09 April 2020, 08:21:08
Wie im ersten post geschrieben, wird das mit TLE4913 Hallsensoren gemacht. Diese sitzen als U1-U3 auf der Platine. Der U3 ist nur bei der grossen dran, und funktioniert als Tuer/Fenster offen Kontakt.
Auf der schmalen Platine sind auch alle 3 drauf. Da kann man den Dritten für die Sabotage-Erkennung nutzen. Einfach nen Magneten in den Deckel kleben.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: pc1246 am 09 April 2020, 08:35:57
Moin
Sorry, das konnte ich nicht erkennen. Da sind mehrer Schriften uebereinander.
Gruss Christoph
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 09 April 2020, 10:04:48
Ja - die Beschriftungen habe ich gestern nicht mehr zurecht gerückt. Wollte eigentlich nur mal schnell sehen, ob sich die Platine so überhaupt routen läßt. Durch die großen Pads für den Batteriehalter ist es ganz schön eng.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: justme1968 am 09 April 2020, 10:13:33
auch wenn es noch viel zu früh ist...

falls jemand von der schmalen version welche produzieren und bestücken lässt: ich habe interesse an mindestens 5. könnten auch 15 werden.

die original HM-Sec-RHS preise sind ja inzwischen eine frechheit. zumal die dinger einige probleme machen. meine vorhandenen hatte ich vor einigen jahren noch für die hälfte gekauft.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rcmcronny am 09 April 2020, 10:26:47
Ich lese auch mit und würde wohl auch welche nehmen, falls jemand da was prodden läst :)

Ronny
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 09 April 2020, 13:49:58
Habe eben nochmal die Beschriftung für die schmale Variante glatt gezogen. Damit könnte man jetzt eine erste kleine Prototyp-Bestellung machen. Ich habe keine Ahnung, ob das alles so unter den Griff passt. Also wer es ausprobieren will - die Gerber-Files sind generiert und eingecheckt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: pc1246 am 09 April 2020, 15:17:29
auch wenn es noch viel zu früh ist...

falls jemand von der schmalen version welche produzieren und bestücken lässt: ich habe interesse an mindestens 5. könnten auch 15 werden.

die original HM-Sec-RHS preise sind ja inzwischen eine frechheit. zumal die dinger einige probleme machen. meine vorhandenen hatte ich vor einigen jahren noch für die hälfte gekauft.
Moin Andre
Also die waren schon immer unverschaemt teuer. Ich kann mich auch nicht erinnern, dass die unter €40,- waren. Beobachte das aber auch erst seit ~6 Jahren.
Ansonsten bin ich auch dabei, wenn auch das Gehaeuse immer noch mein groesstes Problem ist.
Mal sehen vielleicht wird es ja demnaechst was mit nem 3D Drucker.
Gruss und schoene Ostern
Bleibt gesund, Christoph
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: justme1968 am 09 April 2020, 15:28:48
ich habe meine damals für unter €30,- gekauft... ist aber schon eine weile her.

danke. und an alle zurück.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 09 April 2020, 23:05:29
Hab mal einen Entwurf für nen schmales Gehäuse gemacht. Die Befestigung für den Deckel fehlt noch.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: nanocosmos am 09 April 2020, 23:25:17
Herzlichen Dank für die Arbeit, die ihr hier leistet!
Ich würde ebenfalls mein Interesse an ein paar Sensoren bekunden. :)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 10 April 2020, 07:45:29
Hab mal einen Entwurf für nen schmales Gehäuse gemacht. Die Befestigung für den Deckel fehlt noch.

Ich würde den Deckel aber gerade lassen, so passt er für beide Fenstergriffe, rund und eckig.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 10 April 2020, 08:24:11
Ich würde den Deckel aber gerade lassen, so passt er für beide Fenstergriffe, rund und eckig.
Dann sieht man aber die Platine an den Seiten  :(
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 10 April 2020, 09:06:46
Achso mhh ok, da braucht man also noch nen sehr dünnen Deckel mhh
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Papaloewe am 10 April 2020, 10:00:49
Ich verfolge die Entwicklung schon sehr gespannt über eine geraume Zeit und denke das neue Design ist eine prima Verbesserung.

Könnte man die Minimal-Version nicht auch um 180° drehen und mit dem Überstand zur Glasseite montieren?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: justme1968 am 10 April 2020, 10:09:51
das wäre gar nicht so schlecht weil man dann mehr platz für die hand hätte.

aber ich glaube dir seitlichen abstände bzw.  die breite des fensterrahmens ist nicht genormt. bei mir gibt es im haus bestimmt 5-6 varianten. gut, das haus ist alt und wir haben beim umbau die fensteröffnungen nicht vereinheitlicht, aber selbst im besten fall müsste jeder seine eigen maße drucken.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 10 April 2020, 12:15:09
Könnte man die Minimal-Version nicht auch um 180° drehen und mit dem Überstand zur Glasseite montieren?
Drehen ist kein Problem. Die Positionen Offen/Zu/Angeklappt lassen sich entweder über die Regsiter entsprechend oder direkt im Sketch anpassen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 14 April 2020, 14:12:37
Wieder mal ein sehr geiles Projekt. Meinst du das lässt sich noch halbwegs gut mit der Hand löten oder brauchts da schon einen Reflow-Ofen?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 14 April 2020, 14:34:11
SMD ist alles 0805 - sollte also machbar sein.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 21 April 2020, 16:33:55
So - der Erste ist aufgebaut und funktioniert. Allerdings sind die Pads für den TLE etwas klein geraten und lassen sich nur mühsam per Hand löten. Habe ich schon mal im Layout etwas vergrößert.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Pfriemler am 21 April 2020, 17:24:18
"Oink, oink", macht der Pfriemler. Wie das Schwein, das ins Uhrwerk guckt.
Einfach nur g..l, Eure Arbeit hier.
Was ruft Ihr für einen fertigen Sensor auf? Ich würde mich dringend mit ein paar Teilen anschließen wollen, oder Bausatz mit Teilen (am besten schon geflasht). Löten könnte ich zur Not selbst. Aber die 3D-Drucke ...
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Esjay am 21 April 2020, 19:36:58
Ich habe 3 3D Drucker, und könnte Gehäuse drucken. Zum Selbstkosten Preis versteht sich. Könnte Schwarz und Weiß aus dem Stand anbieten. Bei anderen Farben müsste man schauen, dass sich genug Leute finden, um das Filament zu finanzieren!

Gruß Stephan
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 22 April 2020, 02:44:37
Hallo zusammen,

auch ich hätte Interesse an ein Paar fertig aufgebauten Sensoren.

Gruß
Alex
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: pc1246 am 22 April 2020, 08:41:18
Hmmmmm
Ich sehe schon die naechste Sammelbestellung. Wenn das man keine Probleme gibt! Bleibt nur die Frage nach Gehaeusefarbe und Bauform.
Ich uebrigens nicht!

Mal so ganz nebenbei dumm gefragt: Warum macht das der bekannte Hersteller mit dem Versandhaus hinten dran nicht eigentlich auch so? Die Mechanik im HmIP-SRH ist so aufwaendig. (Ach ich sollte ja mal ein Foto vom Bausatz posten!)
Gruss Christoph
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 22 April 2020, 08:56:51
Die Mechanik im HmIP-SRH ist so aufwaendig. (Ach ich sollte ja mal ein Foto vom Bausatz posten!)

Wieso? Also bei den alt HM Geräte finde ich das gut gelöst, und eben auch sehr energiesparend.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 22 April 2020, 09:43:50
Ich habe übrigens meine Platinen gleich bei JLCPCB bestücken lassen. Man kann dort eine Seite bestücken lassen - habe fast die komplette Rückseite (bis auf das Funkmodul und die TLEs - hatten sie nicht da) machen lassen. Hat für 30 Stück 62$ gekostet. Dabei war der größte Posten die ATMegas mit 1,50$ das Stück. Die benötigten Files sind mit im GitHub eingecheckt.

.... und nein - ich habe keine über  8)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 22 April 2020, 09:45:18
Ich habe übrigens meine Platinen gleich bei JLCPCB bestücken lassen. Man kann dort eine Seite bestücken lassen - habe fast die komplette Rückseite (bis auf das Funkmodul und die TLEs - hatten sie nicht da) machen lassen. Hat für 30 Stück 62$ gekostet. Dabei war der größte Posten die ATMegas mit 1,50$ das Stück. Die benötigten Files sind mit im GitHub eingecheckt.

.... und nein - ich habe keine über  8)

Das ist genau der richtige Weg. Vielen Dank dafür. Das wollte ich immer schon mal testen.
Planst du noch eine 2. Version der Platine mit größeren Pads?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 22 April 2020, 10:26:38
Ich habe die TLE-Pads schon größer gemacht. Mehr geht erst mal nicht, sonst müssen die Leiterbahnen neu gezogen werden.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 22 April 2020, 10:28:35
Ich hab es gerade im Git gesehen. Ich versuch mich mal an einer Bestellung der neuen Version bei JLCPCB.

Edit1:
Hab mal 15 Stück bestellt  ;D

Edit2:
Und schon sind sie in der Produktion  :)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 22 April 2020, 11:59:25
Ja - die sind schon schnell ...
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Loetkolben am 22 April 2020, 18:52:18
Ich lese bei diesem Thema auch schon von Anfang mit und würde mir auch gerne ein paar Platinen bestellen.
Wenn die auch noch (mehr oder weniger) fertig bestückt bestellt werden können, umso besser.
Obwohl Löten ist kein Problem und auch Gehäuse drucken ist für mich kein Thema.

Nur - wie funktioniert das ganze denn bei JLCPCB?  Und vor allem welche Daten brauchen die aus dem Git?
Könnte mir jemand auf die Sprünge helfen?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 22 April 2020, 18:55:27
Sind die Gerber Daten der schmalen Version auch aktuell? Weil das dicke passt bei mir leider nicht, ich würde aber ein paar Platinen der schmalen fertigen lassen.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 22 April 2020, 20:08:45
Nur - wie funktioniert das ganze denn bei JLCPCB?  Und vor allem welche Daten brauchen die aus dem Git?
Könnte mir jemand auf die Sprünge helfen?

Die benötigten Dateien sind im "gerber" Verzeichnis. Für den Rest bitte beim jeweiligen Servicenabieter nachsehen.
z.B. https://support.jlcpcb.com/article/21-how-do-i-place-an-order
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 22 April 2020, 20:10:32
Sind die Gerber Daten der schmalen Version auch aktuell? Weil das dicke passt bei mir leider nicht, ich würde aber ein paar Platinen der schmalen fertigen lassen.
Die Gerber-Dateien sind aktuell. Ich habe aber keine Bestückungsdaten erstellt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fanavity am 22 April 2020, 22:01:06
Falls jemand eine bestückungsdatei für die schmale Variante erstellt würde ich mich sehr freuen wenn sie jemand teilen würde :)
Vielen Dank !
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Loetkolben am 23 April 2020, 06:50:30
Die benötigten Dateien sind im "gerber" Verzeichnis. Für den Rest bitte beim jeweiligen Servicenabieter nachsehen.
z.B. https://support.jlcpcb.com/article/21-how-do-i-place-an-order
OK - Danke.
Schaue ich mir an.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 23 April 2020, 07:49:41
Falls jemand eine bestückungsdatei für die schmale Variante erstellt würde ich mich sehr freuen wenn sie jemand teilen würde :)
Vielen Dank !

Für was brauchst du die bei der Handvoll Bauteile?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 23 April 2020, 08:03:46
Habe gestern Abend noch mal an der Verbindung Deckel zu Unterteil gefeilt. Alles wie immer aktuell im GitHub.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 24 April 2020, 10:55:57
Hallo

Plant vielleicht doch jemand eventuell eine Sammelbestellung vielleicht auch schon zumindest teilweise bestückt?
Ich hätte Interesse an jeweils 2  Stück in beiden Varianten.

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 24 April 2020, 11:16:06
Hallo

Plant vielleicht doch jemand eventuell eine Sammelbestellung vielleicht auch schon zumindest teilweise bestückt?
Ich hätte Interesse an jeweils 2  Stück in beiden Varianten.

Gruß Rolf

Ich denke nicht, dass sich eine Sammelbestellung lohnt. Mit den Daten aus Github kann man, die fast vollständig bestückten Platinen, gut bei JLCPCB selbst bestellen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 24 April 2020, 11:48:53
Ich habe mal die Bestückungsfiles auch für das schmale Layout ins GitHub gepackt. Aber ich habe das nicht selbst bestellt. Die Vorschau sah allerdings gut aus.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 24 April 2020, 13:13:54
Sag mal was sind denn Bestückungsfiles? Meinst du den Bestückungsplan oder die Bestellliste? Oder ist das was, damit man die vom Werk aus bestücken lassen kann, weil sowas habe ich noch nie gemacht, lohnt das denn preislich bei den paar Bauteilen?

/Daniel

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 24 April 2020, 13:20:24
Sag mal was sind denn Bestückungsfiles? Meinst du den Bestückungsplan oder die Bestellliste? Oder ist das was, damit man die vom Werk aus bestücken lassen kann, weil sowas habe ich noch nie gemacht, lohnt das denn preislich bei den paar Bauteilen?

/Daniel

Du kannst die Files bei JLCPCB mit hochladen und automatisch einseitig eine Platine bestücken lassen.
Ich habe es bei der breiten Version jetzt gemacht und komme auf Bestückungskostet für 15 Platinen von €38.50, also inklusive Atmega und Vogelfutter. Für den Preis tue ich mir das Löten des Atmega nicht an.
Lediglich die TLE, das Funkmodul und der Batteriehalter fehlen dann noch.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 24 April 2020, 13:22:25
Schau mal bei JLCPCB und mach mal ne Testorder. Da kannst Du auch Assembly aktivieren. Dann brauchst Du zusätzlich die BOM und das PickAndPlace-File. Sind beide als xlsx im "gerber" Verzsichnis im Github eingecheckt. Wenn Du Dich dann weiter durch den Prozess klickst, kriegst Du nen Preview und auch die Preise angezeigt. Muss halt jeder selbst entscheiden, wieviel das einem persönlich Wert ist.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 24 April 2020, 13:26:16
Hier mal noch ein Bild vom Testdruck des schmalen Gehäuse.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 24 April 2020, 15:25:02
Hallo,
tolles Projekt, ich hab zunehmend Probleme mit meinen HM-SEC-RHS Sensoren und würde die gerne mit denen hier ersetzen.

Ich habe eine Frage bezüglich der Integration der neuen Sensoren:
Mir ist nicht ganz klar ob ich die Sensoren direkt an die HomeMatic Heizkörper- bzw. Wandthermostate anlernen kann. Wie sieht es mit der HomeMatic Zentrale aus?

Ich hab vor einiger Zeit alles was HomeMatic angeht auf eine Raspberrymatic Installation ausgelagert und per hmccu an Fhem angebunden daher wäre eine direkte Integration in HomeMatic die einfachste Lösung,

Grüße
Sven
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 24 April 2020, 19:36:35
Der Sketch im GitHub läßt sich konfigurieren - das erste "#define RHS3". Ohne implementiert er einen HM-Sec-RHS-2. Mit "#define RHS3" wird  ein erweiteres Gerät HB-Sec-RHS-3 - dann mit Batteriemessung und wahrscheinlich noch Support für den Glasbruchsensor implementiert. Dafür ist ein Addon für die CCU und FHEM erforderlich.
Als HM-Sec-RHS-2 verhält er sich genau wie der Originale. Damit kann er einfach an die CCU oder was auch immer angelernt werden. Direktverknüpfungen sind mit beiden Varianten problemlos möglich.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Papaloewe am 25 April 2020, 14:00:49
Anbei Foto von den beiden Gehäusen mit eckigen Griffen:
Bei Bedarf kann ich die stl's gerne noch zur Verfügung stellen.
Die Gehäusedeckel sitzen jetzt perfekt, papa.

Gruß
Thomas
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 25 April 2020, 14:29:07
Na STL nicht aber FreeCAD, SCAD oder womit immer du das gemacht hast. Weil gerade Deckel muss man immer an den Drucker anpassen sonst sind die locker oder zu fest.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 25 April 2020, 19:22:59
Anbei Foto von den beiden Gehäusen mit eckigen Griffen:
Bei Bedarf kann ich die stl's gerne noch zur Verfügung stellen.
Die Gehäusedeckel sitzen jetzt perfekt, papa.
Ich kann das gerne mit in GitHub einchecken
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Papaloewe am 25 April 2020, 19:40:19
Hier kommt die Small-Version in eckig:
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 01 Mai 2020, 19:39:00
Hat jemand bitte noch die Abmessungen für den Magneten? Konnte leider bei github und hier nix finden.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 01 Mai 2020, 20:19:03
2mm Durchmesser - 1mm Höhe
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 02 Mai 2020, 10:45:28
Meine Platinen sind heute angekommen. Jetzt fehlen nur noch die TLE und der Batteriehalter.
So fertig bestückte Platinen sind schon was geiles.

Vielen Dank noch einmal.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Christoph am 02 Mai 2020, 13:26:06
Erstmal Danke an papa :)

Meine unbestückten Platinen müssten heute auch noch ankommen.

Bin auch noch auf der Suche nach dem TLE und dem Batteriehalter.
Hab beides bei digikey gefunden, aber der Batteriehalter ist erst ende des Monats lieferbar.
Kennt jemand ne alternative Bezugsquelle ?

Gruß Christoph
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 02 Mai 2020, 15:09:41
So fertig bestückte Platinen sind schon was geiles.

Was hast jetzt genau bezahlt komplett?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 02 Mai 2020, 19:45:29
Was hast jetzt genau bezahlt komplett?

55€ für 15 Platinen inklusive Bestückung, Versand und Zoll. Das einzige was fehlt sind die TLE, der Batteriehalter, die Buttons und der CC1101



Jetzt haben sie auch alle erfolgreich ihre Fuses und einen Bootloader.



An der CCU3 konnte ich einen Sensor bereits ohne Probleme anlernen. Fehlt zwar noch bisschen was an Elektronik aber die Kommunikation läuft immerhin schon einmal.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 02 Mai 2020, 22:16:22
Bin auch noch auf der Suche nach dem TLE und dem Batteriehalter.
Hab beides bei digikey gefunden, aber der Batteriehalter ist erst ende des Monats lieferbar.
Kennt jemand ne alternative Bezugsquelle ?
Ich habe alles in China bestellt.

TLE - https://de.aliexpress.com/item/32976875583.html
Batteriehalter - https://de.aliexpress.com/item/4000274412260.html
Taster - https://de.aliexpress.com/item/32698846968.html

Ist wahrscheinlich auch bis Ende des Monats da.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 02 Mai 2020, 22:21:36
An der CCU3 konnte ich einen Sensor bereits ohne Probleme anlernen. Fehlt zwar noch bisschen was an Elektronik aber die Kommunikation läuft immerhin schon einmal.
Welchen Modus hast Du benutzt - HM-Sec-RHS-2 ?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 03 Mai 2020, 10:24:40
Welchen Modus hast Du benutzt - HM-Sec-RHS-2 ?

Ja werde ihn wahrscheinlich als HM-SEC-RHS-2 nutzen, da ich alles über die CCU3 laufen habe.



Vielleicht als kleine Hilfe für die Inbetriebnahme:

Fuses setzen (USBasp):
avrdude -p m328p -P usb -c usbasp-clone -B 3 -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m
Bootloader:
https://raw.githubusercontent.com/pa-pa/AskSinPP/master/bootloader/avr/ATmegaBOOT_168_atmega328_pro_8MHz.hex
Bootloader flashen (USBasp):
avrdude -p m328p -P usb -c usbasp-clone -V -U flash:w:ATmegaBOOT_168_atmega328_pro_8MHz.hex
AsksinPP Bibliothek:
https://github.com/pa-pa/AskSinPP/tree/master
Sketch (FTDI):
https://github.com/pa-pa/HB-Sec-RHS-3/tree/master/Sketch
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 03 Mai 2020, 10:52:03
Vielleicht noch als kleine Verbesserung für den Magnethalter.
Ich würde die Aussparung für den Magneten etwa 0,2mm nach Innen versetzen. Dadurch bekommt man beim Druck eine durchgängige Außenwand. Ich denke die kleine Positionsänderung sollte keinen Unterschied für den TLE machen.

Links: original
Rechts: 0,2mm nach Innen versetzt

2,4mm Durchmesser für das Loch ist natürlich auch ganz schön groß, wenn der Magnet nur 2mm Durchmesser hat. Sie die Abmessungen des Magneten so ungenau oder brauchst du die Toleranz für deinen Drucker?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: nog76 am 03 Mai 2020, 11:13:16
2mm Durchmesser - 1mm Höhe

Was für Magnete sollte man verwenden (Neodym oder ganz einfache)?
Bzw. wo hast Du diese bestellt?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Mai 2020, 16:02:05
Vielleicht noch als kleine Verbesserung für den Magnethalter.
Ich würde die Aussparung für den Magneten etwa 0,2mm nach Innen versetzen. Dadurch bekommt man beim Druck eine durchgängige Außenwand. Ich denke die kleine Positionsänderung sollte keinen Unterschied für den TLE machen.
Ich hatte mit einem Prototyp Probleme, wenn der Magnet weiter innen war. Das kann sich ja jeder selbst ausprobieren.
2,4mm Durchmesser für das Loch ist natürlich auch ganz schön groß, wenn der Magnet nur 2mm Durchmesser hat. Sie die Abmessungen des Magneten so ungenau oder brauchst du die Toleranz für deinen Drucker?
Da ich den Magnet mit etwas Sekundenkleber einklebe, ist eine etwas größeres Loch einfacher :-)
Geht aber sicherlich auch kleiner.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Mai 2020, 16:04:27
Was für Magnete sollte man verwenden (Neodym oder ganz einfache)?
Bzw. wo hast Du diese bestellt?
Ich habe diese hier: https://www.amazon.de/First4magnets-F321-50-Neodym-Magneten-Packung-Durchmesser/dp/B007JTKHR6/ref=sr_1_5
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 03 Mai 2020, 16:05:03
Hallo,

im Modus - HM-Sec-RHS-2 wird da auch die zusätzliche Fenster offen Meldung ausgegeben?

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Mai 2020, 16:10:57
Es gibt immer nur eine "Fenster Offen" Meldung. Wenn allerdings der 3 Sensor-Pin in Sketch definiert ist, muss dieser auch geschlossen sein, damit die "Fenster Zu" Meldung kommt. Es muss also der Griff auf geschlossen stehen (Magnet am Griff muss oben stehen) und der seitliche Sensor muss am Magnet sein.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 03 Mai 2020, 16:16:07
Hallo,

und wie ist das dann in der gekippt Stellung?
Zur Zeit habe ich bei mir 2 Sensoren am Fenster 1x Drehgriff und einmal optisch. Da ich eine Jalousie habe die nur Funktioniert wenn das Fenster am Rahmen anliegt egal wie der Griff steht und ich würde das gerne über diesen 3. Kontakt lösen.

Gru0 Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Mai 2020, 16:29:05
Wenn der Griff auf gekippt steht - also Magnet unten - dann spielt der Zustand des 3. Sensors keine Rolle. Es ist dann immer gekippt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 03 Mai 2020, 16:32:48
Hallo,

Ok, also nicht optimal für mich, lässt sich das anders auswerten das der 3. Kontakt unabhängig angezeigt wird? Meinetwegen auch als Sabotagekontakt?

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Pfriemler am 03 Mai 2020, 19:02:05
Ich muss mal einwerfen, dass mich diese Art der Umsetzung auch nicht befriedigt.

Es wäre vielleicht überlegenswert, aus dem threeStateSensor einen fourStateSensor zu entwickeln.
Ein threestate hat ja 0,100,200 = closed,tilted,open im Angebot.
Meine Idee wäre 0,50,100,200 = closed,unlocked,tilted,open zu senden.
unlocked ist dabei ein Fenster, welches nicht verriegelt ist, aber am Rahmen anliegt. Ob der Griff auf "open" oder "tilted" steht, könnte dabei egal sein.

Drehgriffsensor RHS und Fensterkontakt SCo fasse ich bei mir in einem DOIF zusammen, dass neben den genannten vier Zuständen auch noch "burglary" kennt - das ist ein Fenstergriff auf "closed" bei offenem Fensterflügel. Das passiert meist, wenn jemand das Fenster mit einem Kuhfuß aufzuhebeln versucht.

Auch die Innensirene/Minialarmanlage kennt eine weitere vom 0/100/200-Schema abweichende innere Wertestufe für "teilscharf". Das wäre also keine neue Erfindung.

rvideobaer könnte seine Rolladen dann fahren lassen, solange der gesendete Wert unter 100 liegt (für peering interessant) bzw. "closed" oder "unlocked".

Nun?
 
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Mai 2020, 19:04:25
Sollte relativ einfach machbar sein. Lass mich mal ne Nacht drüber schlafen ;-)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Mai 2020, 19:06:01
Ok, also nicht optimal für mich, lässt sich das anders auswerten das der 3. Kontakt unabhängig angezeigt wird? Meinetwegen auch als Sabotagekontakt?
Du kannst den 3. Sensor direkt als Sabotage-Kontakt im Sketch definieren. Das geht ohne Probleme. Hatte ich aber auch schon am Anfang mal für die schmale Variante erwähnt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 03 Mai 2020, 19:22:09
Hallo,

damit werde ich mich näher beschäftigen wenn meine Platinen da sind. Der Vorschlag von Pfriemler klingt aber auch gut da er vielleicht die weitreichendsten Möglichkeiten zur Konfiguration bietet.

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Mai 2020, 19:45:27
Ich muss hier mal vor der chinesischen TLE4913 Quelle warnen. Ich habe mahr als 50% Ausschuß bei den Dingern. Die machen einfach nichts. Das ist absolut nervig  >:(
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 03 Mai 2020, 19:49:15
Hallo,

kann man das vor dem Einbau testen?

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 03 Mai 2020, 19:59:40
Ich muss hier mal vor der chinesischen TLE4913 Quelle warnen. Ich habe mahr als 50% Ausschuß bei den Dingern. Die machen einfach nichts. Das ist absolut nervig  >:(

Reagieren die TLE4913 garnicht oder liegt es am zu schwachen Magneten?

Ich habe meine TLE4913 bei einer anderen Quelle gekauft und werde hier berichten.
 

kann man das vor dem Einbau testen?

Sollte halbwegs gut möglich sein, einfach auf eine Platine auflegen und leicht andrücken. Das ganze sollte auch ohne anlöten funktionieren. 
Die Signale sind dann auf der Console sichtbar.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Mai 2020, 20:48:09
Die reagieren auf gar nichts. Ich habe noch eine Platine vom 1. Prototypen und pappe jeden da erst mal drauf. Da ist dann einfach eine LED dran, die leuchten muss, wenn der Magnet in die Nähe kommt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Mai 2020, 23:15:53
Ich muss mal einwerfen, dass mich diese Art der Umsetzung auch nicht befriedigt.
Es gibt halt wie immer unterschiedliche Anforderungen.
Meine Idee wäre 0,50,100,200 = closed,unlocked,tilted,open zu senden.
unlocked ist dabei ein Fenster, welches nicht verriegelt ist, aber am Rahmen anliegt. Ob der Griff auf "open" oder "tilted" steht, könnte dabei egal sein.
Ich habe im RHS-Sketch ein neues Define USE_FOUR_STATES eingeführt. Wenn das gesetzt ist, wird der "unlocked" State entsprechend Deinem Vorschlag unterstützt. Damit das funktioniert, ist sowohl die akteullest AskSin++ (4.1.5) und die aktuellen HMMsg.pm & HMConfig_AskSinPPCustom.pm erforderlich. Schaut Euch das ganze mal in Ruhe an, ob es so passt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 04 Mai 2020, 16:52:05
Kann es sein, dass aktuell die zyklischen Statusmeldungen nicht funktionieren?
Ich hatte heute einen Kommunikationserror in der CCU obwohl testweise

#define CYCLETIME seconds2ticks(60UL * 1)
gesetzt ist.

16:48:15.171 -> AskSin++ V4.1.3 (May  4 2020 15:45:06)
16:48:15.171 -> Address Space: 32 - 102
16:48:15.171 -> 00000000
16:48:15.171 -> Init Storage: CAFEBE97
16:48:15.449 -> CC init1
16:48:15.482 -> CC Version: 14
16:48:15.482 ->  - ready
16:48:15.482 -> Config Freq: 0x216512
16:48:15.482 -> Activate Cycle Msg
16:48:18.865 -> <- 0E 01 86 10 095634 000000 06 01 C8 00 00  - 3698
16:48:24.203 -> ignore 0F 72 86 10 37EF85 000000 0A B0 EB 0C 1B 00  - 8976
16:48:27.699 -> ignore 13 12 00 83 2200EE F00001 07 71 9E 88 14 31 5B 1A 83 4A  - 12492
16:48:35.917 ->  debounce
16:48:35.950 ->  pressed
16:48:36.087 ->  released
16:48:36.158 -> <- 1A 02 84 00 095634 000000 22 00 C3 70 61 70 61 32 32 32 31 31 31 80 01 01 00  - 15378
16:48:36.158 ->
16:48:36.193 -> -> 10 0C A0 01 00FFFF 095634 00 05 00 00 00 00 00  - 15415
16:48:36.301 -> <- 0A 0C 80 02 095634 00FFFF 00  - 15536
16:48:36.336 -> -> 13 15 A0 01 00FFFF 095634 00 08 02 01 0A 00 0B FF 0C FF  - 15579
16:48:36.483 -> <- 0A 15 80 02 095634 00FFFF 00  - 15697
16:48:36.521 -> -> 0B 1E A0 01 00FFFF 095634 00 06  - 15728
16:48:36.521 -> Activate Cycle Msg
16:48:36.628 -> <- 0A 1E 82 02 095634 00FFFF 00  - 15857
16:48:37.015 -> ignore 0F 66 86 10 227A4A 000000 0A 28 D8 10 00 40  - 16250
16:48:44.050 -> ignore 0C B3 86 5A 2711AF 000000 28 E4 32  - 2325

Im Arduino Log sieht man leider auch keine Messages.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 Mai 2020, 19:00:22
Mein Testsystem schickt fleißig Nachrichten. Hast Du gesicherte Übertragung deaktiviert bzw. mit AES übersetzt ?

Sonst musst Du natürlich die CYCLETIME auch weiterreichen - wo hast Du denn das Define her ? So müsste es gehen.

class RHSType : public ThreeStateDevice<Hal,ChannelType,1,RHSList0,CYCLETIME> {

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 04 Mai 2020, 19:33:13
Hallo,

habe heute meine 10 bestellten Platinen (Bestückt) bekommen 46,-Euro und beim Postboten nochmal 23,- Euro Zoll und Gebühren, schon heftig.
Warte jetzt noch auf den Rest an Bauteilen.

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 04 Mai 2020, 20:22:13
schon heftig.

definitiv, dafür würde ich lieber schnell selber löten. Wo hast du bestellt?

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Christoph am 04 Mai 2020, 20:24:45
Oder du hast wahrscheinlich die falsche Versandart ohne Zollabwicklung seitens jlcpcb gewählt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 04 Mai 2020, 20:29:23
Mein Testsystem schickt fleißig Nachrichten. Hast Du gesicherte Übertragung deaktiviert bzw. mit AES übersetzt ?

Sonst musst Du natürlich die CYCLETIME auch weiterreichen - wo hast Du denn das Define her ? So müsste es gehen.

class RHSType : public ThreeStateDevice<Hal,ChannelType,1,RHSList0,CYCLETIME> {

AES habe ich jetzt nirgendwo deaktiviert. In der CCU sehe ich das der Übertragungsmodus gesichert ist.

Das weiterreichen der CYCLETIME hat allerdings den gewünschten Erfolg gebracht. Jetzt sehe ich jede Minute ein Senden in der Console. Ich musste die CYCLETIME aber an 2 Stellen im Code übergeben:

#ifdef RHS3
  // send battery value
  #define CONTACT_STATE_WITH_BATTERY
#else
  #define BATTERY_LOW 22
  #define BATTERY_CRITICAL 19
  #define CYCLETIME seconds2ticks(60UL * 1)
#endif

...

class RHSType : public ThreeStateDevice<Hal,ChannelType,1,RHSList0,CYCLETIME> {
public:
  typedef ThreeStateDevice<Hal,ChannelType,1,RHSList0,CYCLETIME> TSDevice;

20:27:12.499 -> <- 0E 04 A2 10 095634 00FFFF 06 01 C8 00 39  - 31985
20:27:12.499 -> -> 11 04 A0 02 00FFFF 095634 04 26 08 83 35 28 1C 00  - 32122
20:27:12.499 -> waitAck: 01
20:28:11.854 -> <- 0E 05 A2 10 095634 00FFFF 06 01 C8 00 30  - 32651
20:28:11.854 -> -> 11 05 A0 02 00FFFF 095634 04 8C 1B 85 16 C1 DD 00  - 32788
20:28:11.854 -> waitAck: 01
20:29:11.568 -> <- 0E 06 A2 10 095634 00FFFF 06 01 C8 00 2F  - 33316
20:29:11.710 -> -> 11 06 A0 02 00FFFF 095634 04 87 2D 0E 50 62 32 00  - 33454
20:29:11.710 -> waitAck: 01
20:30:13.706 -> <- 0E 07 A2 10 095634 00FFFF 06 01 C8 00 32  - 33982
20:30:13.706 -> -> 11 07 A0 02 00FFFF 095634 04 8C 15 A6 EF 7E C2 00  - 34119
20:30:13.706 -> waitAck: 01
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 Mai 2020, 20:33:52
AES habe ich jetzt nirgendwo deaktiviert. In der CCU sehe ich das der Übertragungsmodus gesichert ist.
AES muss expliziet beim Übersetzen aktiviert werden. https://github.com/pa-pa/AskSinPP#enable-aes-support

Alternative ist der Übertragungsmodus bei der CCU auf ungesichert zu stellen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 Mai 2020, 20:36:23
habe heute meine 10 bestellten Platinen (Bestückt) bekommen 46,-Euro und beim Postboten nochmal 23,- Euro Zoll und Gebühren, schon heftig.
Warte jetzt noch auf den Rest an Bauteilen.
Hm - rund 70€ für 10 Stück ist irgendwie zu teuer. Ich habe für 30 Stück knapp 75€ + Versand + Zoll bezahlt. Waren insgesamt ca. 110€ - weil per DHL Express.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 04 Mai 2020, 20:58:49
Ich habe 55€ für 15 Stück bezahlt inklusive Bestückung und Versand mit EuroPacket:

Zitat
MERCHANDISE TOTAL:€44.64
SHIPPING CHARGE: €17.11
DISCOUNT:-€6.41
ORDER TOTAL:€55.34
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 04 Mai 2020, 21:35:31
Hallo,

DHL Express lässt sich das mit 12,50 Kapitalbereitstellungsprovision Fürstlich bezahlen.

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 05 Mai 2020, 18:24:26
So ich hab jetzt auch mal 5 bestellt bei jlcpcb mit Bestückung von der schmalen Variante. Ich hatte irgendwie ein Haufen Voucher auf meine Konto, ka wo die her kommen. Da bin ich ja mal gespannt.

Wie erstellt man die beiden Dateien die da benötigt werden für die Bestückung? Die Bezeichnung der Bauteile muss ja passen, aus welche Datenbank kommen die?

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 05 Mai 2020, 18:43:57
Die Part Numbers kommen von hier - https://jlcpcb.com/parts.
Habe in KiCad ein extra Attribute "LCSC Part #" angelegt und dort immer gleich das Passende eingetragen. Dann BOM Export und ein wenig nachbearbeiten. Wenn dieses Info später im Excel ist, können sie das automatisch matchen. Ist schon cool.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: UweH am 06 Mai 2020, 18:22:42
Die Part Numbers kommen von hier - https://jlcpcb.com/parts.
Habe in KiCad ein extra Attribute "LCSC Part #" angelegt und dort immer gleich das Passende eingetragen. Dann BOM Export und ein wenig nachbearbeiten. Wenn dieses Info später im Excel ist, können sie das automatisch matchen. Ist schon cool.

Kleiner Tipp zum BOM-Export: https://github.com/wokwi/kicad-jlcpcb-bom-plugin (https://github.com/wokwi/kicad-jlcpcb-bom-plugin). Da entfällt sogar das Nachbearbeiten.

Gruß
Uwe
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 06 Mai 2020, 18:45:34
AES muss expliziet beim Übersetzen aktiviert werden. https://github.com/pa-pa/AskSinPP#enable-aes-support

Alternative ist der Übertragungsmodus bei der CCU auf ungesichert zu stellen.

Ich muss jetzt nochmal blöd fragen weil ich wieder einen Kommunikationsfehler nach 24 Stunden hatte. Muss die Übertragung gesichert erfolgen oder nicht oder sollte es egal sein?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 06 Mai 2020, 19:12:52
Soweit ich weiss, aktiviert die CCU beim Pairen bei allen HM-SEC Geräten die gesicherte Übertragung/AES-Signierung. Alle AskSin++ Sketche haben per default kein AES aktiviert - da hierfür der Standard-Schlüssel benötigt wird. Ich will hier kein Risiko eingehen und diesen einfach so veröffentlichen. Der Standardschlüssel ist aber gut im Netz oder FHEM-Code zu finden. Alternativ zum Standard-Schlüssel kann auch der bekannte selbst gewählte Schlüssel verwendet werden. Dieser kann z.B. einfach an der VCCU bei FHEM abgelesen werden.
Um das AES im Sketch zu aktivieren, muss nach Anleitung (https://github.com/pa-pa/AskSinPP#enable-aes-support) vorgegangen werden.
Also wenn Du nichts im Code gemacht hast - muss Du an der CCU die gesicherte Übertragung abschalten. Dann sollten auch die Servicemeldungen weg sein.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 07 Mai 2020, 19:46:35
Hallo,

ich suche jemanden der mir 4 Gehäuse drucken würde. Ich würde mich sehr freuen wenn jemand die Möglichkeit hätte.

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 07 Mai 2020, 20:10:41
ich suche jemanden der mir 4 Gehäuse drucken würde. Ich würde mich sehr freuen wenn jemand die Möglichkeit hätte.

Möglichkeit habe ich, aber zeitlich ist es bei mir gerade etwas schlecht. Also falls sich kein anderer findet der gerade weiß aufgelegt hat und ehe Gehäuse druckt kann ich es gerne machen. Dann meld dich bitte nochmal direkt bei mir.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 11 Mai 2020, 15:15:05
Hallo,

ich habe heute einen der Drehgriffe (leider noch ohne TLE4913) in Betrieb genommen. Dabei wurde das Modell nicht erkannt und ein IO Device wurde auch nicht eingetragen, musste beides von Hand erledigen. HB-Sec-RHS-3 ist auch nicht auswählbar obwohl im Sketch definiert.

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 11 Mai 2020, 16:00:57
Hast Du das AskSin++ Addon aktualisiert und FHEM neu gestartet ?
https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/contrib/FHEM
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 11 Mai 2020, 16:50:45
Hallo,

ja habe ich installiert und Neustart.
Bei modelForce ist nur HM-SEC-RHS-2 auswählbar ich hatte angenommen das jetzt HM-SEC-RHS-3 möglich wäre.

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 11 Mai 2020, 17:02:25
Hallo,

habe das Gerät gerade noch einmal gelöscht und neu verbunden, wird jetzt als custom und HM-SEC-RHS-3 angezeigt.

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 14 Mai 2020, 10:51:41
Hat jemand bitte noch einmal die STL Files oder Sources für eckige Fenstergriffe?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 14 Mai 2020, 11:32:33
Hat jemand bitte noch einmal die STL Files oder Sources für eckige Fenstergriffe?
3 Seiten zurück https://forum.fhem.de/index.php/topic,109786.msg1046980.html#msg1046980
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 14 Mai 2020, 11:33:25
Hallo,

Vielen Dank aber ich hatte leider vergessen dazu zuschreiben, dass ich die für die andere Version neben dem Griff suche.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 14 Mai 2020, 11:37:41
Da gab es nur die Bilder  :o
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Papaloewe am 14 Mai 2020, 13:34:45
Ja, ich weiß, die bin ich schuldig.

Aber ich hatte nicht die aktuelle Version geändert, sondern nur die mit der schlechteren Deckelarretierung.

Ich versuche noch nachzureichen, sorry ;)

Thomas
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PSI69 am 15 Mai 2020, 08:21:50
Moin Moin @All!

Wieder einmal ein super Projekt! Da habe ich doch glatt wieder etwas zu fummeln...

Zwei Fragen haben sich mir noch gestellt:


Danke und Tschau,
Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 15 Mai 2020, 08:49:46
Quarz bestücke ich nicht. Habe den nur vorgesehen, falls jemand ein genaues Timing braucht. Dann kommt da ein 32,768kHz Quarz drauf. Der Sketch unterstützt das aber bisher nicht.
1 Woche mit CR2032 ist aber extrem kurz. Kann es sein, dass da irgendwas nicht ordentlich funktioniert ?
Ich erwarte mit CR2477 eine Laufzeit von 2-3 Jahren - bei wenigen Öffnungen pro Woche. Aber das wird sich erst mit der Zeit zeigen. Wird der "neue" RHS-3-Mode benutzt, wird bei jeder Nachrricht auch die Batteriespannung mit übertragen. Damit sieht man dann hoffenbtlich, wenn etwas nicht so läuft wie es soll. Ich habe bei den 20 installierten Kontakten Batteriespannungen zwischen 2,9 und 2,7 V nach dem Einschalten. Allerdings auch einen Ausreißer mit 2,4V - mal sehen wie lange der hält.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PSI69 am 15 Mai 2020, 09:00:38
Kann es sein, dass da irgendwas nicht ordentlich funktioniert ?
Tja, nur was - die machen beide (ich habe nur zwei) alles, was sie sollen... Ich finde eine Woche ja auch extrem kurz. Vielleicht ändert sich das ja mit der neuen Variante.

Die 'alten' haben unabhännig von einer Öffnung auch (nach meiner Erinnerung jetzt) einmal am Tag den Batteriestatus übertragen. Passiert das mit den 'neuen' auch?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 15 Mai 2020, 09:11:51
Die 'alten' haben unabhännig von einer Öffnung auch (nach meiner Erinnerung jetzt) einmal am Tag den Batteriestatus übertragen. Passiert das mit den 'neuen' auch?
Natürlich
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PSI69 am 15 Mai 2020, 09:33:32
Natürlich
:)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 21 Mai 2020, 03:09:23
Hallo zusammen,

als erstes mal vielen Dank für dieses super Projekt!
Damit habe ich erstmalig selbst Platinen fertigen lassen und habe mich auch an das Löten von SMD Bauteilen rangewagt (sind ja nur ein paar).
Dank gloobs Post #100 bin ich nun soweit dass der Bootloader geflasht ist.
Leider bin ich mir aber nicht sicher mit welchen Parametern ich den Sketch übersetzen soll.
Mit der Arduino IDE habe ich eine hex für einen Arduino nano (ATMega 328P) erstellen können, kann diese  aber nicht mit der IDE flashen.
Passt der Parameter Arduino nano, oder muss ich ein anderes wählen? Kann ich die hex jetzt einfach mit AVRdude mit folgenden Parametern flashen?

avrdude -p m328p -P usb -c USBasp -U flash:w:HB-SEC-RHS-3.ino.eightanaloginputs.hex

Danke und Gruß
Alex
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 25 Mai 2020, 14:26:06
Kann es sein, dass es ein kleines Layout-Problem auf der Platine gibt? Das Pad an U1 scheint keine Verbindung zur Masse zu haben.
Bei U2 sieht es besser aus.

Das Mapping der Zustände funktioniet doch auch nicht richtig oder?
Zwei unterschiedliche Pin Zustände sollten doch nicht die gleiche Position sein.
14:45:30.353 -> Pins: 101
14:45:30.353 -> Position: 2
14:45:32.854 -> Pins: 111
14:45:32.854 -> Position: 2

14:45:40.130 -> Pins: 011
14:45:40.130 -> Position: 3
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 25 Mai 2020, 14:47:50
Mist - das ist bestimmt beim Vergößern der Pads passiert. Da must Du wohl mit nem Klecks Lötzinn nachhelfen. Ich fixe das Layout später.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 25 Mai 2020, 14:51:45
Zwei unterschiedliche Pin Zustände sollten doch nicht die gleiche Position sein.

Wenn Du alle 3 TLEs verwendest - schon. Der seitliche macht, wenn offen, aus einen CLOSED ein OPEN. Welche Nummer das jetzt ist, habe ich nicht im Kopf.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 25 Mai 2020, 14:54:13
Wenn Du alle 3 TLEs verwendest - schon. Der seitliche macht, wenn offen, aus einen CLOSED ein OPEN. Welche Nummer das jetzt ist, habe ich nicht im Kopf.

Okay ich glaube ich muss mal auf die TLE warten. Das spielen mit den Jumper Kabeln funktioniert nicht so richtig   ;)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 25 Mai 2020, 16:17:47
Hallo,

könnte bitte jemand meine Frage oben beantworten?
Ich komme ab dem Punkt leider nicht weiter.

danke.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 25 Mai 2020, 16:21:22
Hallo,

@Nighthawk
Hast Du denn mal versucht es so zu flashen? Bzw warum geht es nicht in der IDE (Fehlermeldungen).

Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 25 Mai 2020, 16:33:44
Hallo,

könnte bitte jemand meine Frage oben beantworten?
Ich komme ab dem Punkt leider nicht weiter.

danke.

Arduino Nano ist schonmal falsch, du musst Arduino Pro Mini mit 3.3V auswählen.
Für den Anfang würde ich dir auch das Flashen per Arduino IDE empfehlen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 25 Mai 2020, 22:35:48
Ich habe jetzt eine fertige Firmware mit kurzer Anleitung ins Github eingecheckt.
https://github.com/pa-pa/HB-Sec-RHS-3/tree/master/firmware

Den GND-Fix habe ich auch eingecheckt - ist jetzt Platinenversion 1.2. Die Gerber-Files sind ebenfalls generiert.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 26 Mai 2020, 02:54:36
Danke für eure Rückmeldungen.

Das Flashen mit IDE scheiterte daran, dass die IDE den USBasp versucht hat über den serial port anzusprechen.
Ich versuche jetzt mal mit Pro Mini mit 3.3V zu kompilieren und mit avrdude zu flashen.

Wenn alle  Stricke reißen, flashe ich die fertige hex ;-) danke dafür!


Gruß Alex


Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 26 Mai 2020, 06:55:28
Danke für eure Rückmeldungen.

Das Flashen mit IDE scheiterte daran, dass die IDE den USBasp versucht hat über den serial port anzusprechen.
Ich versuche jetzt mal mit Pro Mini mit 3.3V zu kompilieren und mit avrdude zu flashen.

Wenn alle  Stricke reißen, flashe ich die fertige hex ;-) danke dafür!


Gruß Alex

Hast du nur den USBasp oder auch einen USB2Serial Adapter wie einen FTDI oder CP2104?
Gerade zum testen der Hardware lohnt sich meiner Meinung nach ein USB2Serial Adapter, weil man dann die Console nutzen kann um die Logausgaben zu sehen. Gerade in Hinblick auf fehlerhafte TLE lohnt sich das schon.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 26 Mai 2020, 07:58:52
Vielen Dank an Jerome.
Dank ihm können die Griffe jetzt auch in der CCU genutzt werden.

Folgendes Plugin ist notwendig und unterstützt damit die 4 States sowie die Batteriespannung:
https://github.com/jp112sdl/JP-HB-Devices-addon
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 26 Mai 2020, 09:50:18
Ich habe auch diverse USB 2Seriell Adapter, ich versuche es mal damit.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Papaloewe am 26 Mai 2020, 17:31:46
Anbei jetzt endlich die beiden stl-Files für die eckige Standard-Version.

Sorry für die Verspätung.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 26 Mai 2020, 17:50:04
Anbei jetzt endlich die beiden stl-Files für die eckige Standard-Version.

Sorry für die Verspätung.

Vielen Dank. Mit was hast du die denn erstellt? Magst du die Dateien zum bearbeiten bitte teilen?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Papaloewe am 26 Mai 2020, 18:07:38
Das hat mein Sohn mit Fusion gemacht (darum hat es auch so lange gedauert, Kinder halt  >:().

Welches Format kannst du denn verarbeiten?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 26 Mai 2020, 19:55:21
Anbei jetzt endlich die beiden stl-Files für die eckige Standard-Version.

Sorry für die Verspätung.

Das ist aber noch das vorletzte Design. Jetzt ist die Nut im Boden und es gibt eine extra Vertiefung zum Einrasten.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 26 Mai 2020, 20:29:42
Das hat mein Sohn mit Fusion gemacht (darum hat es auch so lange gedauert, Kinder halt  >:().

Welches Format kannst du denn verarbeiten?

Fusion wäre gut :)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 27 Mai 2020, 08:37:10
Hallo zusammen,

leider komme ich auch mit einem USB2Serial Adapter nicht weiter, ich bekomme einfach keine Kommunikation mit dem Sensor zustande.
Wie sollten die Einstellungen dafür aussehen?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 27 Mai 2020, 09:24:39
Hallo zusammen,

leider komme ich auch mit einem USB2Serial Adapter nicht weiter, ich bekomme einfach keine Kommunikation mit dem Sensor zustande.
Wie sollten die Einstellungen dafür aussehen?

Wie sieht denn die Console aus und das Log Fenster?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Papaloewe am 27 Mai 2020, 18:41:31
Fusion wäre gut :)

Ja, leider nur die erste Version von papa. Eine andere habe ich nicht.  :-X
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 28 Mai 2020, 02:42:52
Hallo gloob,

danke für die Antwort.
Leider bekomme ich die Serielle Kommunikation nicht hin, weder mit dem Serialmonitor der Arduino IDE, noch mit Putty.
Mittlerweile habe ich es hinbekommen mit dem USBasp zu flashen, wäre nur schön wenn ich iregndwie noch auf der konsole sehen könnte was mit dem Atmega so passiert.
So wie es aussieht habe ich bei all den Versuchen bereits 2 Atmegas gehimmelt, diese werden nicht mehr erkannt.
Gibt es für die beider noch irgendwelche Rettungsmöglichkeiten?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: tndx am 28 Mai 2020, 09:38:56
So wie es aussieht habe ich bei all den Versuchen bereits 2 Atmegas gehimmelt, diese werden nicht mehr erkannt.
Gibt es für die beider noch irgendwelche Rettungsmöglichkeiten?

Die Atmegas auslöten, mit HVPP resetten und wieder einlöten :) Wenn Du es nicht selber kannst, dann lohnt sich das nicht bei den Preisen... Aber bevor Du sie wegschmeisst, nehme ich sie gerne gegen Portoerstattung ;)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 29 Mai 2020, 09:44:37
Schade, leider ist bei der kleinen Platine auch der GND vom TLE nicht verbunden.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 29 Mai 2020, 21:50:13
Der ist mittels der Durchkontaktierung verbunden. KiCAD ist damit voll zufrieden.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 29 Mai 2020, 22:03:16
Der ist mittels der Durchkontaktierung verbunden. KiCAD ist damit voll zufrieden.

Stimmt, garnicht gesehen. Vielen Dank. Ich dachte schon ich muss hier auch basteln.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 30 Mai 2020, 07:36:59
Hallo zusammen,

ich habe es endlich hinbekommen einen Sensor zu flashen, leider bekomme ich von dem Sensor aber absolut kein Lebenszeichen. Die LEDs bleiben immer aus, Anlernen an die CCU funktioniert nicht und auch in der Konsole kommt leider nichts an.
Was mache ich falsch, bzw. wo könnte der Fehler liegen?

avrdude -p m328p -P usb -c usbasp -V -U flash:w:'/home/alex/Downloads/YUQ7660527.hex' -F

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "/home/alex/Downloads/YUQ7660527.hex"
avrdude: input file /home/alex/Downloads/YUQ7660527.hex auto detected as Intel Hex
avrdude: writing flash (32768 bytes):

Writing | ################################################## | 100% 31.25s

avrdude: 32768 bytes of flash written

avrdude: safemode: Fuses OK (E:FF, H:D0, L:E2)

avrdude done.  Thank you.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 30 Mai 2020, 21:13:17
Was hast Du genau geflasht ? Das ist eine unabdingbare Information, um Dir zu helfen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 31 Mai 2020, 06:02:14
Geflasht habe ich die durch die makeota.html erstellte Datei aus dem OTA Bootloader und der von dir kompilierter Firmware.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 31 Mai 2020, 09:08:53
Ok - Du sagt es blinkt nichts. Auch nach dem Anlegen der Spannung blinkt es nicht ? Der Bootloader läßt als erste Aktion eine LED 7x leuchten. Wenn das schon nicht geht, müssen wir uns mal Deinen Aufbau ansehen. LED richtig einglötet ?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 31 Mai 2020, 09:33:21
Hallo Papa,

richtig keine der LEDs blink oder leuctet, auch wenn ich einen der Taster drücke.
Die LEDs sind mit der Kathode (grüne Markierung) auf der Batterieseite eingelötet.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 31 Mai 2020, 13:33:38
Das ist falsch herum - die grüne Markierung muss zum Rand.
Hast Du den Rest bestücken lassen - oder selbst gemacht ? Mach mal ein ordentliches Foto von beiden Seiten.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 31 Mai 2020, 14:15:44
ich habe die schmale Variante bestellt und soweit wie möglich bestücken lassen.
Es fehlten noch ein paar Kondensatoren, ein Widerstand, die zwei LEDs, die Taster und die Batteriehalterung.
Die LED Pins habe ich gemessen und die Batterieseite lag gegen GND, daher bin ich davon ausgegangen, dass es so herum richtig ist.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 31 Mai 2020, 19:54:38
Ach die schmale - da muss ich erst mal schauen. Bin jetzt unterwegs.
Die habe ich nicht aufgebaut.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 01 Juni 2020, 08:17:36
Für die schmale Version ist das richtig.
Hast Du schon geprüft, ob die Batterie richtig Kontakt hat. Ich mache auf das große, rechteckige Pad immer etwas Lötzinn drauf. Alternativ könntest Du die Platine auch mal über den ISP-Anschluss mit SPannung versorgen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 01 Juni 2020, 10:05:09
spannung habe ich auch über den ISP bzw. auch über USB2Seriell Adapter dran gehabt, leider zuckt da nichts.
Könnte diese Meldung für das Problem verantwortlich sein?
avrdude: warning: cannot set sck period. please check for usbasp firmware update.Laut google muss ich die ISP Firmware aktualisieren, leider klappt es mit meinen arduino clones nicht, daher habe ich mir noch ein ISP bestellt, kosten ja hier nichts ;-)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 01 Juni 2020, 11:04:59
Nein - das sollte kein Problem sein.
Auf einen Kurzschluß hast Du ach schon mal geprüft ? So langsam fällt mir auch nichts mehr ein.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 01 Juni 2020, 12:30:36
Zeig doch bitte mal den Inhalt von der CMD beim flashen des Bootloaders, vielleicht hängt es da schon.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 01 Juni 2020, 13:59:48
Einen Kurzschluss kann ich nicht erkennen, auch nicht unter dem Microskop.

Ich dachte mit der makeota.html erstelle ich eine firmware die den Bootloader schon beinhaltet?

Das flashen wurde dann mit folgendem Kommando gestartet:
avrdude -p m328p -P usb -c usbasp -V -U flash:w:'/home/alex/Downloads/YUQ7660527.hex' -F
Der flashablauf ist in meinem Post #176  zu sehen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 01 Juni 2020, 14:04:02
Hast du es mal mit einem Standard-Arduino-Bootloader probiert? Was ist die Ausgabe der Arduino IDE wenn du einen Sketch flasht?
Wenn die OTA Firmware genutzt wird, kannst du leider die Arduino IDE nicht mehr nutzen um einen Sketch aufzuspielen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 01 Juni 2020, 14:32:12
Hallo gloob,

hier die Ausgabe von der Arduino IDE (leider ebenfalls ohne jede zucken der LEDs):

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/home/alex/Downloads/arduino-1.8.12-linux64/arduino-1.8.12/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/home/alex/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : usb
         Using Programmer              : usbasp
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : usbasp
         Description     : USBasp, http://www.fischl.de/usbasp/

avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "/tmp/arduino_build_995142/HB-SEC-RHS-3.ino.hex"
avrdude: writing flash (20150 bytes):

Writing | ################################################## | 100% 20.91s

avrdude: 20150 bytes of flash written
avrdude: verifying flash memory against /tmp/arduino_build_995142/HB-SEC-RHS-3.ino.hex:
avrdude: load data flash data from input file /tmp/arduino_build_995142/HB-SEC-RHS-3.ino.hex:
avrdude: input file /tmp/arduino_build_995142/HB-SEC-RHS-3.ino.hex contains 20150 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 10.27s

avrdude: verifying ...
avrdude: 20150 bytes of flash verified

avrdude done.  Thank you.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 01 Juni 2020, 16:05:28
Hast du mal probiert den Sketch über einen Serial Adapter zu flashen? Dann sieht man auch mal ob was auf der Console kommt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 02 Juni 2020, 01:08:55
Über Serialadapter klappt es leider gar nicht.

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/home/alex/Downloads/arduino-1.8.12-linux64/arduino-1.8.12/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/home/alex/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyUSB0
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude done.  Thank you.

Problem beim Hochladen auf das Board. Hilfestellung dazu unter http://www.arduino.cc/en/Guide/Troubleshooting#upload.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Juni 2020, 12:55:35
Hast Du auch vorher den Standard-Bootloader per ISP geflasht ?
https://github.com/pa-pa/AskSinPP/blob/master/bootloader/avr/ATmegaBOOT_168_atmega328_pro_8MHz.hex

Hast Du auch mal eine andere Platine versucht ? Manchmal ist halt irgendwo der Wurm drin - das lässt sich auch nur sehr schwer ohne Zugriff auf die Hardware analysieren.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 03 Juni 2020, 16:07:34
Habe ich eben probiert, leider ebenfalls ohne Erfolg.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 03 Juni 2020, 16:30:36
Habe ich eben probiert, leider ebenfalls ohne Erfolg.

Hast du noch eine andere Platine, an der du noch nichts zusätzlich aufgelötet hast?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 04 Juni 2020, 10:00:13
Habe ich heute geflasht, da funktioniert es, werde jetzt nach und nach die Bauteile auflöten und schauen wo das Problem dann liegt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Nighthawk am 05 Juni 2020, 15:20:04
So, Problem gefunden, die Taster waren leider Öfner und nicht schließer. Das kommt davon wenn man in einem Land bestellt wo man der Sprache nicht mächtig ist  ::)
Vielen Dank für die Unterstützung, der erste Sensor läuft jetzt.

Gruß
Alex
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 05 Juni 2020, 15:56:44
So, Problem gefunden, die Taster waren leider Öfner und nicht schließer. Das kommt davon wenn man in einem Land bestellt wo man der Sprache nicht mächtig ist  ::)
Also da wäre ich jetzt nie im Leben drauf gekommen.
Damit wäre dann auch die schmale Platine verifiziert.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 08 Juni 2020, 17:58:10
Danke @papa !!!
Ich hab meine 20 Stk heute von JLCPCB bestückt bekommen, hat super funktioniert, Batterien, Halter und Taster liegen auch schon hier, jetzt warte ich noch auf die TLEs.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 08 Juni 2020, 18:05:47
Danke @papa !!!
Ich hab meine 20 Stk heute von JLCPCB bestückt bekommen, hat super funktioniert, Batterien, Halter und Taster liegen auch schon hier, jetzt warte ich noch auf die TLEs.

Welche Version hast du denn bestellt? Die große hatte ein Problem im Bereich der TLE.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 08 Juni 2020, 18:24:13
von der großen habe ich 5 Stk (V1.2, schon korrigiert), von der kleinen 15 V1.1er bestellt.
Bin echt begeistert, wie einfach das geht und die fertigen Platinen sehen echt professionell aus.

Edit: Ähm, ich hab mir die großen V1.2er grad noch mal genauer angeschaut, die wirken recht dunkel, also keine großflächigen Masseflächen.
Die Durchkontaktierungen gehen irgendwie ins Leere.
Jetzt werde ich doch nervös. Könnt ihr das mal checken bitte:

Noch eine Kleinigkeit, C4 und C6 scheinen im Schaltbild in files/RHS_pdf vertauscht. Wenn man UE3 nicht bestückt, kann man C10, C6 und R6 weglassen, oder?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Christoph am 08 Juni 2020, 19:35:17
Sieht so aus als würden in V1.2 die ganzen Masseflächen fehlen. Sieht auch im Gerberviewer von JLCPCB leider nicht anders aus  :-\
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 08 Juni 2020, 20:12:57
Mist das sieht gar nicht gut aus - das kommt davon, wenn man schnell mal was anpasst. Scheinbar habe ich vor dem Generieren vergessen, die Masseflächen zu erzeugen :-(
Ist jetzt im GutHub gefixt - V1.3. Kann das bitte nochmal jemand reviewen? Danke.
Ich hoffe, es habe nicht zu viele diese Version bestellt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 08 Juni 2020, 20:16:59
Wenn man UE3 nicht bestückt, kann man C10, C6 und R6 weglassen, oder?
Ja - werden dann nicht gebraucht.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 08 Juni 2020, 21:05:51
OK, danke für die Bestätigung.
Mit Fädeldraht retten kann man wohl auch vergessen, da bestell ich lieber neue.
Die MCs runterzulöten wird mir wohl auch zu diffizil. Soll ich dir die 5 zum Ausschlachten zuschicken?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 08 Juni 2020, 21:45:20
Man da schaut man doch vorher drüber ;-) Aber erstaunlich, dass die da nicht gemeckert haben beim check. Naja die machen eben was man beauftragt ja ^^

Nur blöd weil du auch bestücken hast lassen, das ist etwas ärgerlich dann.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Papa Romeo am 08 Juni 2020, 23:21:47
..sowas passiert schon mal, wenn man Platinen entwickelt....da biste nicht der erste und einzige dem das passiert ist...

...schnell noch ne Änderung oder ein Fix..dazu etwas weggenommen oder ein Layer deaktiviert, damit man die Änderung
schneller und einfacher durchführen kann. Die Änderung dann schnell noch mal kontrolliert  :o dann aber vergessen die vorherigen
Wegnahmen rückgängig zu machen...naja..und das war´s dann..... :( :'(

...ich nehm die Dinger dann immer als Unterlegmaterial...statt Bierdeckel.... ;D ;D ;D ;D

LG

Papa Romeo
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 08 Juni 2020, 23:30:48
Untersetzer, Oder ein schickes Mobile. Da fällt mir bestimmt noch was ein.
Immerhin, aus Fehlern lernt man [emoji16]

Gesendet von meinem Mi 9T Pro mit Tapatalk

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 13 Juni 2020, 10:20:42
Ich hab jetzt nochmal welche von den großen bestellt, diesmal sah es im Gerber viewer gut aus  ::).

Batteriehalter und TLEs sind noch im Zulauf.
Leider hatt ich keine Taster 3x2 bestellt, da ich dachte die von den alten FDGKs passen, aber die sind zu groß.
Lieferzeit lt. Ali Ende Juli, das dauert mir zu lange.

Hat jemand einen Tipp für eine andere Bezugsquelle? Wo kauft ihr die Batterien?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 16 Juni 2020, 19:43:20
Heute sind TLEs und Batteriehalter gekommen und ich konnte die ersten drei kleinen erfolgreich aufbauen und pairen.  8)

Die großen sind fertig produziert und bereits in der Post, denke die kommen diese Woche noch, cool.
Da habe ich direkt Infineon TLEs draufmachen lassen, aber incl. Zoll und Versand hat der Spass dann auch 118.79$ gekostet für 20 Stk.
So ist das halt, wenn man Kinder hat, kaufe Zeit gegen Geld.  :-\

Bei den TLEs (auch aus Papas Quelle) habe ich den Eindruck, dass die schlecht Lötzinn annehmen und mechanisch recht labil sind/ die Beinchen recht schnell abplatzen.
Das kann aber auch an meiner Grobmotorik liegen  :P

Als Batterien habe ich jetzt mal Panasonic bestellt. Langzeiterfahrung gibt's wohl noch nicht!?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Christoph am 16 Juni 2020, 20:38:51
Bei den TLEs (auch aus Papas Quelle) habe ich den Eindruck, dass die schlecht Lötzinn annehmen und mechanisch recht labil sind/ die Beinchen recht schnell abplatzen.

Meine sind heute auch angekommen, mal schauen wieviel davon funktionieren  ;D

Falls jemand Batteriekontakte sucht, hab noch welche übrig ->PN
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 16 Juni 2020, 20:43:42
Heute sind TLEs und Batteriehalter gekommen und ich konnte die ersten drei kleinen erfolgreich aufbauen und pairen.  8)
Schön das es nun gleich funktioniert hat.
Die großen sind fertig produziert und bereits in der Post, denke die kommen diese Woche noch, cool.
Da habe ich direkt Infineon TLEs draufmachen lassen, aber incl. Zoll und Versand hat der Spass dann auch 118.79$ gekostet für 20 Stk.
So ist das halt, wenn man Kinder hat, kaufe Zeit gegen Geld.  :-\
Naja - 6$ das Stück sind doch eigentlich ganz i.O. Fehlt ja nur noch der Batteriehalter. Bei meiner Bestellung hatten sie keine TLEs da.
Bei den TLEs (auch aus Papas Quelle) habe ich den Eindruck, dass die schlecht Lötzinn annehmen und mechanisch recht labil sind/ die Beinchen recht schnell abplatzen.
Das kann aber auch an meiner Grobmotorik liegen  :P
Also ich hatte/habe mit den China-Teilen jede Menge Ärger. Da hat mehr als die Hälfte überhaupt nicht funktioniert. Dagegen die hier bestellten - kein einziger Problemfall.
Als Batterien habe ich jetzt mal Panasonic bestellt. Langzeiterfahrung gibt's wohl noch nicht!?
Ne noch nicht. Meine Ältesten laufen jetzt seit knapp einen Monat. Manche haben gleich mit 2.5V angefangen und sind jetzt bei 2.3V. Andere sind unverändert seit Start bei 2.9V. Auf jeden Fall wird bei mir die Batteriespannung aller mitgeloggt. Da sollte man gut sehen, wenn es Probleme gibt. Wahrscheinlich kann der Low-Bat-Wert auch noch weiter runter - ist derzeit bei 2.2V eingestellt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 16 Juni 2020, 20:56:01
Wo hast du denn deine nicht China TLE bestellt? Bin auch noch auf der Suche.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 16 Juni 2020, 23:44:31
Hier https://de.rs-online.com/web/c/halbleiter/sensor-ics/hall-effekt-sensor-ics/?searchTerm=tle4913&redirect-relevancy-data=636F3D3126696E3D4931384E53656172636847656E65726963266C753D6465266D6D3D6D61746368616C6C7061727469616C26706D3D5E5B5C707B4C7D5C707B4E647D2D2C2F255C2E5D2B2426706F3D31333326736E3D592673723D2673743D4B4559574F52445F53494E474C455F414C5048415F4E554D455249432673633D592677633D4E4F4E45267573743D746C6534393133267374613D746C653439313326&r=f&searchHistory=%7B%22enabled%22:true%7D
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 17 Juni 2020, 07:59:57
Naja - 6$ das Stück sind doch eigentlich ganz i.O. Fehlt ja nur noch der Batteriehalter. Bei meiner Bestellung hatten sie keine TLEs da
So gesehen auch wieder wahr.  8)
Bei den TLEs musste ich manuell auf Infineon umstellen (irgendwas an der Beschreibung hat nicht ganz gepasst, ich hoffe das funktioniert dann auch.
Auf jeden Fall wird bei mir die Batteriespannung aller mitgeloggt. Da sollte man gut sehen, wenn es Probleme gibt. Wahrscheinlich kann der Low-Bat-Wert auch noch weiter runter - ist derzeit bei 2.2V eingestellt.
Gut zu wissen, danke für die Rückmeldung!
Eine Frage noch: Wie kommst du an die Batteriespannung?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 17 Juni 2020, 09:33:00
So gesehen auch wieder wahr.  8)
Bei den TLEs musste ich manuell auf Infineon umstellen (irgendwas an der Beschreibung hat nicht ganz gepasst, ich hoffe das funktioniert dann auch.
Die waren damals nicht auf Lager
Gut zu wissen, danke für die Rückmeldung!
Eine Frage noch: Wie kommst du an die Batteriespannung?
Welchen Sketch benutzt Du ? Der HB-SEC-RHS-3 sendet immer die Spannung mit. Der Wert wird im batVoltage Reading angezeigt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 17 Juni 2020, 09:47:11
Ich hab heute mal noch einen Flash Adapter für die kleine Platine fertig gemacht. Wenn jemand Interesse hat, einfach Bescheid sagen und dann kann ich die Sourcen hochladen.

Ich habe die Dateien bei Thingiverse hochgeladen: https://www.thingiverse.com/thing:4526889
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 17 Juni 2020, 11:49:29
Der HB-SEC-RHS-3 sendet immer die Spannung mit. Der Wert wird im batVoltage Reading angezeigt.
Ich hab die .hex aus dem github mit makeota.htm gepatcht und geflasht, modelforce auf HM-SEC-RHS-2 wie bei meinen alten FDGKs, aber das Reading batVoltage gibt's bei mir nicht:
Internals:
   DEF        123456
   FUUID      5ee90848-f33f-c590-6a59-2bfbf248f2fa5e8b
   IODev      myHMUART
   LASTInputDev myHmUARTLGW
   MSGCNT     20
   NAME       HM_123456
   NOTIFYDEV  global
   NR         624
   NTFY_ORDER 50-HM_123456
   STATE      open
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:2D - t:10 s:12345 d:54321 0100000000
   mapleCUL1_MSGCNT 7
   mapleCUL1_RAWMSG A0E2D801012345659D5560100000000::-49.5:mapleCUL1
   mapleCUL1_RSSI -49.5
   mapleCUL1_TIME 2020-06-17 11:39:19
   myHMUART_MSGCNT 7
   myHMUART_RAWMSG 050100272D801012345659D5560100000000
   myHMUART_RSSI -39
   myHMUART_TIME 2020-06-17 11:39:19
   myHmUARTLGW_MSGCNT 6
   myHmUARTLGW_RAWMSG 050000512D801012345659D5560100000000
   myHmUARTLGW_RSSI -81
   myHmUARTLGW_TIME 2020-06-17 11:39:19
   protLastRcv 2020-06-17 11:39:19
   protRcv    7 last_at:2020-06-17 11:39:19
   protSnd    4 last_at:2020-06-17 11:39:19
   protState  CMDs_done
   rssi_at_mapleCUL1 cnt:7 min:-49.5 max:-44 avg:-48.64 lst:-49.5
   rssi_at_myHMUART cnt:7 min:-39 max:-33 avg:-38.14 lst:-39
   rssi_at_myHmUARTLGW cnt:6 min:-81 max:-81 avg:-81 lst:-81
   READINGS:
     2020-06-17 11:39:17   Activity        alive
     2020-06-17 11:39:17   D-firmware      1.0
     2020-06-17 11:39:17   D-serialNr      xxxxxx
     2020-06-17 11:39:18   PairedTo        0x000000
     2020-06-17 11:39:18   R-cyclicInfoMsg on
     2020-06-17 11:39:19   R-eventDlyTime  0 s
     2020-06-17 11:39:18   R-pairCentral   0x000000
     2020-06-17 11:39:19   R-sign          off
     2020-06-17 11:39:18   RegL_00.         00:00 09:01 0A:00 0B:00 0C:00 10:01 12:16 14:06
     2020-06-17 11:39:19   RegL_01.         00:00 08:00 20:6C 21:00 22:64
     2020-06-17 11:37:41   alive           yes
     2020-06-17 11:37:41   battery         ok
     2020-06-17 11:39:19   commState       CMDs_done
     2020-06-17 11:37:41   contact         open (to broadcast)
     2020-06-17 11:37:41   powerOn         2020-06-17 11:37:41
     2020-06-17 11:37:41   recentStateType info
     2020-06-17 11:37:41   sabotageError   off
     2020-06-17 11:37:41   state           open
     2020-06-16 20:03:15   trigDst_broadcast noConfig
     2020-06-16 20:03:15   trigger_cnt     27
   helper:
     HM_CMDNR   45
     PONtest    0
     cSnd       0159D5563E8B0301040000000001,0159D5563E8B030103
     cfgChkResult No regs found for:

HM_3E8B03 type:threeStateSensor -
list:peer register         :value
   0:      cyclicInfoMsg    :on
   0:      pairCentral      :0x000000
   0:      transmDevTryMax  :6
   1:      eventDlyTime     :0 s
   1:      ledOnTime        :0.5 s
   1:      msgRhsPosA       :closed
   1:      msgRhsPosB       :open
   1:      msgRhsPosC       :tilted
   1:      sign             :off
                       
                       

     mId        0030
     peerFriend peerAct,peerVirt
     peerIDsRaw ,00000000
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     20
     supp_Pair_Rep 0
     cmds:
       TmplKey    :no:1592386872.74341
       TmplTs     1592386872.74341
       cmdKey     :1:1:0::0030:01
       TmplCmds:
       cmdList:
         assignHmKey:
         clear:[readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
         deviceRename:newName
         fwUpdate:-filename- -bootTime- ...
         getConfig:
         getDevInfo:
         getRegRaw:[List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
         peerBulk:-peer1,peer2,...- [set|unset]
         peerChan:-btnNumber- -actChn- ... single [set|unset] [actor|remote|both]
         peerSmart:[Bad_Sensor1|Bad_Virtual|Eltern_Sensor1|Eltern_Virtual...]
         raw:data ...
         regBulk:-list-.-peer- -addr1:data1- -addr2:data2- ...
         regSet:[prep|exec] -regName- -value- ... [-peerChannel-]
         reset:
         sign:[on|off]
         tplDel:tmplt
         trgEventL:[-peer-] -condition-
         trgEventS:[-peer-] -condition-
         trgPressL:[-peer-]
         trgPressS:[-peer-]
         unpair:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +123456,00,00,00
       nextSend   1592386759.56013
       prefIO     
       rxt        2
       vccu       
       p:
         123456
         00
         00
         00
     mRssi:
       mNo        2D
       io:
         mapleCUL1:
           -49.5
           -49.5
         myHMUART:
           -31
           -31
         myHmUARTLGW:
           -81
           -81
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
     rssi:
       at_mapleCUL1:
         avg        -48.6428571428571
         cnt        7
         lst        -49.5
         max        -44
         min        -49.5
       at_myHMUART:
         avg        -38.1428571428571
         cnt        7
         lst        -39
         max        -33
         min        -39
       at_myHmUARTLGW:
         avg        -81
         cnt        6
         lst        -81
         max        -81
         min        -81
     shadowReg:
     tmpl:
   nb:
     cnt        2
Attributes:
   IODev      myHMUART
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-RHS-2
   modelForce HM-SEC-RHS-2
   peerIDs    00000000,
   room       CUL_HM
   serialNr   xxxxxx
   subType    threeStateSensor
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 17 Juni 2020, 11:56:43
Das modelforce muss weg. Dafür das Addon https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/contrib/FHEM installieren. Das ist ein neues Device HB-SEC-RHS-3.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 17 Juni 2020, 12:57:36
Ok, danke für die Hilfe.
Ich habs jetzt nochmal neu aus dem git geholt und beim 2. Anlauf hat er das korrekte model erkannt, warum auch immer.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 17 Juni 2020, 14:10:01
Sagt mal habe ich ne schlechte Charge von LEDs oder ist der Widerstand von 1,5k einfach mal zu hoche, oder soll das so? Mir ist das schon bei der 12 Tasten ePaper Fernbedienung aufgefallen, dass die LEDs einfach mal viel zu dunkel sind. Ich nehme jetzt 300 Ohm, dann sind die auch was heller. Kommt ja sonst gar nicht durch das Gehäuse durch.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 17 Juni 2020, 14:20:34
Kommt natürlcih immer drauf an wie dein Gehäuse aussieht? Wieviele Decklagen hast du? Welche Farbe? Loch für die LEDs?
Die LEDs die ich verbaut habe, sind eigentlich sehr hell und scheinen locker durch 2 Schichten weißes PLA/PETG durch.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 17 Juni 2020, 14:33:59
Das kommt auf die LEDs an. Hatte auch schon ne Charge Grüner, die fast gar nicht geleuchtet haben. Bei anderen muss man schon bald die Sonnenbrille rausholen  8)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 17 Juni 2020, 15:07:32
Mhh naja ich hab die von Reichelt. Aber da fließt so gut wie nichts bei 1,5k und 3,3V. Wenn 20mA fließen dann sind die auch sehr hell.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 17 Juni 2020, 16:52:21
Wie isn die Config der fertigen Hex? Ich hatte die jetzt mal auf die schmale Version aufgespielt und irgendwie war das Verhalten komisch. Anmeldung an CCU ging also mehr oder weniger als RHS XXX. Dann hatte ich den äußeren TLC eingelötet und der ging (LEDs senden und Status hat sich auf der CCU2 geändert), als ich dann den inneren eingelötet habe ging der aber dafür der anderen nicht mehr.

Ich werde die FW jetzt mal selber kompilieren als RHS2 Gerät. Hab den TLC schon getauscht aber das hat nichts gebracht. Von daher denke ich da eher an ein anderes Problem.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 17 Juni 2020, 19:04:00
Wie isn die Config der fertigen Hex?
Der ist mit 3 Sensoren. Du musst im Code SENS3_PIN auf 0 setzen. Dann werden nur die beiden Sensoren am Vierkant verwendet. Gegebenenfalls den 3. TLE als Sabotagepin definieren.
Ich kann auch mal die anderen Varianten als fertiges Hex zur Verfügung stellen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 17 Juni 2020, 20:04:30
Nö passt schon, ich kompiliere das eben selber, kein Thema. Hab nur gerade meinen ersten zusammengebaut und spiele mal ein bissel. Wenn dann alles läuft kann man sicherlich der Einfachheit halber fertige hex anbieten ja.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 17 Juni 2020, 20:26:20
Na jetzt klappt es auch mit den Einstellungen. Also da scheint meine TLE Charge von Ali aber zu funktionieren.

Dann werd ich jetzt mal ein Gehäuse basteln und dann das Teil dort anbauen wo jetzt ein defekter HM Sensor hängt.

Eins ist mir aufgefallen, nach dem Einlegen der Batterien zieht der erst mal ganz schön lange 20mA obwohl keine LED leuchtet, was ist der Grund dafür?

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 18 Juni 2020, 13:27:12
Hat schon jemand ein Gehäuse für die schmale Version gedruckt welches eckig ist und nicht für die runden Fenster Griffe?

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 18 Juni 2020, 13:44:55
Ja, ich hab schon einige gedruckt.
Link kennst du ja? https://forum.fhem.de/index.php/topic,109786.msg1046980.html#msg1046980
passen einwandfrei, auch die Magnethalter bei mir optimal dank papa !

Der DHL Kurier hat mir eben noch 20 Stk voll bestückte große vorbei gebracht. Mal sehen, ob ich heute abend noch einen flashen und in Betrieb nehmen kann  8)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 18 Juni 2020, 13:54:46
Eins ist mir aufgefallen, nach dem Einlegen der Batterien zieht der erst mal ganz schön lange 20mA obwohl keine LED leuchtet, was ist der Grund dafür?
Im setup() ist ein
  hal.activity.stayAwake(seconds2ticks(15)); drin. Damit bleibt er nach dem Einschalten erst mal 15 Sekunden auf Empfang.
Wie ist der Verbrauch sonst ? Ich habe nur ein Schätzeisen zum Messen  ::)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 18 Juni 2020, 20:50:25
Der DHL Kurier hat mir eben noch 20 Stk voll bestückte große vorbei gebracht. Mal sehen, ob ich heute abend noch einen flashen und in Betrieb nehmen kann  8)

Der Erste ist geflasht und läuft wunschgemäß! Somit ist die V1.3 bestätigt, könnt ihr aus meiner Sicht bedenkenlos bestellen. Danke nochmal an papa
Wie habt ihr eigentlich die Magnete für den dritten TLE am Fensterrahmen (WAF kompatibel) befestigt?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 18 Juni 2020, 21:16:34
Damit bleibt er nach dem Einschalten erst mal 15 Sekunden auf Empfang.
Wie ist der Verbrauch sonst ? Ich habe nur ein Schätzeisen zum Messen  ::)

OK, dann macht das Sinn. Hatte nur Angst da hängt immer mal was. Stromverbrauch ist bei mir unter 1mA, Aber ich kann es ja mal mit meinem anderen Gerät messen. Und wenn die LEDs angehen ist es etwas höher da ich auch andere Widerstände benutzte. Ab 38 müssen die LEDs was heller sein damit ich die auch sehe ^^

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 18 Juni 2020, 21:22:09
Ja, ich hab schon einige gedruckt.
Link kennst du ja? https://forum.fhem.de/index.php/topic,109786.msg1046980.html#msg1046980
passen einwandfrei, auch die Magnethalter bei mir optimal dank papa !

Danke. Aber die Platine steht da ganz schön über oder? Kann man die nut da nicht ein bissel tiefer machen? Oder sind meine Platinen dicker?

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 19 Juni 2020, 07:58:21
Meine passen eigentlich sauber, wenn auch knapp.
Nur im Bereich vom Magnethalter ist der Axialaufbau im montierten Zustand eher ne Übergangspassung, was die Leiterbahn evtl. nicht lange mitmachen wird.
Ein paar Zehntel mehr Luft wäre aber natürlich unschädlich.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 19 Juni 2020, 08:24:35
Auch wenn es Euch nicht wirklich hilft - im FreeCAD Modell kann man die Werte für Bauteilhöhe und Leiterplattenstärke einstellen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 19 Juni 2020, 09:13:05
Das würde ich gerne machen wenn es denn mehr als nur ein STL für die Eckige Version gebe würde ^^
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 19 Juni 2020, 09:13:55
Meine passen eigentlich sauber, wenn auch knapp.
Nur im Bereich vom Magnethalter ist der Axialaufbau im montierten Zustand eher ne Übergangspassung, was die Leiterbahn evtl. nicht lange mitmachen wird.
Ein paar Zehntel mehr Luft wäre aber natürlich unschädlich.

Hähh die steh doch auch total über?!? Wenn man den Fenstergriff anschraubt quetscht man die total zusammen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 19 Juni 2020, 09:26:29
Hähh die steh doch auch total über?!? Wenn man den Fenstergriff anschraubt quetscht man die total zusammen.
Ach so meinst du das. Ja, der Druck der Verschraubung geht über die Platine.
Ein FreeCad Modell gibts im Repository nur für die runde Version...
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 19 Juni 2020, 09:52:50
Ja wäre schön wenn jemand mal die freecad Version für das eckige bereitstellen könnte, dann kann ich das anpassen. So fit bin ich mit Freecad leider noch nicht. Ich nehme sonst nur OpenSCAD.

danke.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 19 Juni 2020, 09:54:51
Habe eine Modification eingecheckt. Wenn Ihr mit der runden Grundplatte leben könnte, gibt es jetzt zumindest einen eckigen Deckel. Der Radius für die Ecken kann im Parameter-Sheet eingestellt werden.

Update: Grundplatte jetzt auch für die eckige Variante
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 19 Juni 2020, 11:12:18
Danke für die eckige Version. Ich kenne Freecad leider gar nicht, mache alles private mit Fusion360.
Das Problem, das Daniel entdeckt hat, scheint immer noch vorhanden zu sein. Die Platine ist 1.6mm dick, es gibt im Modell eine Durchdringung.

Bei der großen Version klemmt der Magnethalter / durchdringt sich mit der Platine. Das Gehäuse ist dort niedriger wie die Platine.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 19 Juni 2020, 11:20:49
Bitte einfach den entsprechenden Parameter im Parameter-Sheet anpassen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 19 Juni 2020, 11:39:47
Ich hab noch eine Version für die eckige Version in Fusion erstellt. Aktuell fehlt noch der Deckel und ich würde die Platine gerne noch 0,2mm tiefer setzen und einen Spacer zwischen Platine und Drehgriff setzen. Hab sonst ein bisschen die Befürchtung, dass der Griff über die Platine kratzt beim drehen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 19 Juni 2020, 14:47:56
Bitte einfach den entsprechenden Parameter im Parameter-Sheet anpassen.
Das hab ich noch geschafft, aber es ändert sich nix. Bin anscheinen zu blöd für freecad  :P
Ich schreib das mal als iges raus und mach im Fusion weiter...
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 19 Juni 2020, 15:09:39
Ja ich stell mich auch etwas glatt an, aber egal, ich zieh mir mal ein paar Youtube Videos rein und dann geht das. Mit den Variablen finde ich nämlich ganz gut, das kannte ich bisher nur von OpenSCAD.

/Danielo
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 19 Juni 2020, 15:18:23
Das hab ich noch geschafft, aber es ändert sich nix. Bin anscheinen zu blöd für freecad  :P
Im Part Design:
- im Modell auf Parameter gehen -> rechte Maustaste: zeige Kalkulationstabelle
- Wert ändern
- zurück im Modell (RHS_3_small) ändert sich was
Das schaffe sogar ich  :o :o :o

Gruß Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 19 Juni 2020, 15:21:41
Ahja, ändert sich leider in die falsche Richtung. Soweit war ich auch...
Aber Danke, Peter! Ich werd's noch hinkriegen, dauert halt, die Einarbeitung
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 19 Juni 2020, 15:30:03
Ahja, ändert sich leider in die falsche Richtung.
Diesen Eindruck hatte ich irgendwie auch  ??? Ich würde jetzt einfach mal jeden Parameter mal einzeln verstellen und schauen, was so passiert ...

Gruß Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 19 Juni 2020, 15:45:49
NEIN - auf keine Fall die enzelnen Parameter ändern. Die sind zu großen teilen voneinander abhängig.

Siehe Bilderstrecke, wie der Parameter zu ändern ist
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 19 Juni 2020, 15:59:36
Habe das schmale Gehäuse jetzt mit 1,6mm Platinendicke eingecheckt.
Meine Platinen sind nur 1mm dick - deshalb war auch das Gehäuse entsprechend designed.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 19 Juni 2020, 19:45:09
NEIN - auf keine Fall die enzelnen Parameter ändern. Die sind zu großen teilen voneinander abhängig.

Siehe Bilderstrecke, wie der Parameter zu ändern ist
Danke für die 1.6er Version und die Erklärung mit 1mm Platinen!

Auf deinen Bildern hab ich gesehen, dass du die Version 1.8 einsetzt, was ich heute aktuell heruntergeladen und installiert hatte, war ne 1.7er Version!?
Neue Version installiert und es funktioniert. So einfach :)

Was auch schick ist im Vergleich zu den meisten anderen 3D Programmen: Es gibt bei freecad (rechts unten) verschiedene Voreinstellungen für die Mausnavigation.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 20 Juni 2020, 11:44:51
Ja die Version passt jetzt super! Aber ehrlich gesagt bleibe ich glaube bei der CR2032. Die halten bei mir locker 1 Jahr durch und das Gehäuse ist so um einiges kleiner als wie es jetzt ist.

Übrigens der Verschluß des Deckels ist ja mal genial! Finde ich echt gut gelöst, eine prima Idee mit den Schienen und Noppen.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 20 Juni 2020, 14:32:02
Ja die Version passt jetzt super! Aber ehrlich gesagt bleibe ich glaube bei der CR2032. Die halten bei mir locker 1 Jahr durch und das Gehäuse ist so um einiges kleiner als wie es jetzt ist.
Bin mir nicht sicher, ob die CR2032 hier reichen werden. Die TLE's werden dauerhaft gepowert. Und über den 1MOhm geht auch ein bisschen was, wenn der TLE durchsteuert. Ich würde mindestens eine CR2450 nehmen. Die wäre dann auch schon ca. 3mm tiefer.

Übrigens der Verschluß des Deckels ist ja mal genial! Finde ich echt gut gelöst, eine prima Idee mit den Schienen und Noppen.
Tja - da waren auch einige Entwicklungsstufen dazwischen. Mittlerweile bin ich auch ganz zufrieden.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 20 Juni 2020, 16:00:35
Hab übrigens mal gemessen, schmale Version mit 2 TLEs:

Beim Senden sind das 25 mA aber bei mir etwas mehr wegen der LEDs, ohne LEDs sind es 21,23 mA bei 3,3V

Ohne Magnet sind es:
14µA bei 3,3V und 13µA bei 3V im Mittel.

Mit Magnet auf einem der beiden TLE sind es:
16µA bei 3V im Mittel.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 21 Juni 2020, 10:20:33
Ich habe gestern stundenlang versucht, in Freecad ein paar kleine Änderungen zu machen.
Dann entnervt aufgegeben und das Teil in Fusion in einer Stunde neu gezeichnet.

neue Features:
- Freiraum für den Magnethalter
- Nut für die Antenne
- für 1.6mm Platinendicke
- passend für Zweinoppen Deckel aus dem früheren Link https://forum.fhem.de/index.php/topic,109786.msg1046980.html#msg1046980 (davon hatte ich schon 20 Stk hierliegen)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 21 Juni 2020, 10:29:03
Ach jetzt habe ich verstanden, was Du mit dem Magnethalter-Problem meintest. Habe die Vertiefung jetzt breiter gemacht.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 21 Juni 2020, 18:23:27
Ich habe gestern stundenlang versucht, in Freecad ein paar kleine Änderungen zu machen.
Dann entnervt aufgegeben ...
FreeCAD und Du werden vermutlich keine Freunde mehr  :o

Gruß Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 21 Juni 2020, 21:13:06
Nabend,

kann mir mal bitte jemand den HM default AES Key zukommen lassen?

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 22 Juni 2020, 10:01:37
FreeCAD und Du werden vermutlich keine Freunde mehr  :o
Ja, da hst du wohl recht.

Zuletzt bin ich bei Freecad daran gescheitert, einen body zu aktivieren, um einen Schnitt reinextrudieren zu können (für Antenne und Magnethalter). Der Menupunkt fehlt bei mir, doppelklick funktioniert auch nicht...
Außerdem gab's einen Spalt im oberen Teil, da wo die Vollrundung angesetzt ist. Den konnte ich auch nicht reparieren.

Aber so komplex ist die Geometrie ja nicht, das ist ja schnell neu gemalt. Ich habe beruflich viel Erfahrung mit Creo, privat setz ich auf Fusion360
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 22 Juni 2020, 10:54:33
Zuletzt bin ich bei Freecad daran gescheitert, einen body zu aktivieren, um einen Schnitt reinextrudieren zu können (für Antenne und Magnethalter). Der Menupunkt fehlt bei mir, doppelklick funktioniert auch nicht...
Hattest Du auch FreeCAD im Modus Part Design (siehe Bild)?

Gruß Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 22 Juni 2020, 10:58:23
Hattest Du auch FreeCAD im Modus Part Design (siehe Bild)?
Ja, hatte ich
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 28 Juni 2020, 16:26:03
Ich habe einige 3D gedruckte Gehäuse gemäß  https://forum.fhem.de/index.php/topic,109786.msg1046980.html#msg1046980 zu verschenken (gg. Versandkosten)
Die Teile sind aus PLA und für die 1mm dicken Platinen. Daher habe ich neue für meine 1.6mm Platinen gedruckt.
Die zwei mit Deckel sind meine ersten Iterationen  der 3 Noppenversion, aber noch ohne den Freischnitt für die Magnethalter, --> muss selbst freigedremelt werden.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 28 Juni 2020, 21:37:00
Hallo,

ist das rot oder eher braun? Ich habe zwar leicht rötlich/braune Fenster, aber rot würde sich vermutlich beißen - und da könnte ich ziemlichen Ärger mit dem WAF bekommen  ;).

Gruß Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 29 Juni 2020, 15:04:16
Ähm, naja es ist Brot  ;D

auf den Bildern in der direkten Sonne erscheint es rötlicher als in Natura. Aber für meinen Geschmack ist die Farbe auch nicht ideal (meiner Frau war es braun genug  :P ).
Es ist halt nur schwierig, genau den gewünschten Farbton zu bekommen, zumal die Hersteller oft auch keinen Farbcode angeben.

Maßgeblich sind aber v.a. die Deckel, die sieht man wirklich. Alles andere ist ja weitgehend verdeckt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 05 Juli 2020, 00:06:21
Guten Abend,
ich bin zufällig auf dieses Thema aufmerksam geworden. An unserem Haus haben wir einige Fenster, um die 25-30 Stück. Die Fenstersensoren von HM direkt werden da etwas teuer, daher ist dieses Projekt eine gute Lösung. Vom "Basteln" scheue ich generell nicht zurück. Zwei drei fragen hätte ich da aber noch.

Laufen die Sensoren denn auch unter bsp. einem nanoCUL / NeumannCUN? Den habe ich bei mir bereits am laufen mit ein paar HomeMatic Geräten.?

Dann habe ich noch nie bei JLCPCB bestellt, die Platinen Bestellen an sich scheint nicht schwer, einfach die Gerber Datein im .zip hochladen, den rest erkennt die Seite ja schon von Selbst, auch der Preis ist klasse, nur bei der Bestückung welche Sie anbieten tuhe ich mir etwas schwer... Die BOM Datei habe ich noch im Gerber Ordner gefunden, nur wo finde ich die andere CPL Datei welche Benötigt wird? Kann ich denn bei JLCPCB auch nur immer eine Seite bestücken lassen oder auch beide?

Und, neben dem Batteriehalter, Taster und dem TLE wird auch noch das Sendemodul CC1101 benötigt, sehe ich da richtig?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 05 Juli 2020, 17:54:27
Hallo zusammen,

Ich würde mich bei einer Bestellung auch mit 15 Stück beteiligen.

Bzw. übernehme ich die Sammelbestellung auch gerne, bei Interesse bitte PN.

Möchte aber nur die schmale Variante in Auftrag geben.

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 05 Juli 2020, 18:49:40
Hallo zusammen,

Ich würde mich bei einer Bestellung auch mit 15 Stück beteiligen.

Bzw. übernehme ich die Sammelbestellung auch gerne, bei Interesse bitte PN.

Möchte aber nur die schmale Variante in Auftrag geben.
Hab dir mal ne Nachricht zukommen lassen, hoffe die ist angekommen, mein Postausgang hier im Forum ist komischerweise leer  ???
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 05 Juli 2020, 20:14:36
Hab dir mal ne Nachricht zukommen lassen, hoffe die ist angekommen, mein Postausgang hier im Forum ist komischerweise leer  ???
Du musst im Profil den Haken setzen, damit die Mail archiviert wird.

Gruß Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 07 Juli 2020, 16:46:38
Ich habe ja nun schon 20 Kontakte für einige Wochen am laufen. Dabei scheine ich sehr unterschiedlich gute Batterien erwischt zu haben. Bei einem Kontakt ist die gemeldete Spannung nur noch 2,1V - bei anderen immer noch 2,8V. Ich habe den problematischen Kontakt dann mit einem zusätzlichen 330µF Elko ausgestattet. Nun werden wieder 2,8V angezeigt. Daraufhin habe ich noch ein paar weitere Kontakte mit 330µF und 100µF Elkos ausgestattet. Bei allen ist die gemessene Spannung mindestens um 0,4-0,5 V gestiegen. Einen Unterschied zwischen 330µF und 100µF konnte ich nicht feststellen. Ich denke, es macht Sinn auf der Platine einen Elko oder Kerko vorzusehen, der die Lastspitzen abfedert. Ich bin mir nur noch nicht sicher, welche Größe am besten ist.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 07 Juli 2020, 19:24:35
Ich würde ja fast sagen, dass 10uF auch reichen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 07 Juli 2020, 19:41:34
Ist das jetzt eher eine Vermutung - oder Erfahrungswerte ? Wie kann man das ordentlich ermitteln ?
10µF könnte man ja gut als Kerko auf die Unterseite packen. Ein Elko oder Tantal muss eher auf die Oberseite.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 07 Juli 2020, 19:59:25
Ich benutze 10uF immer bei den ESPs, die sind ja auch recht hungrig. Du könntest es aber auch berechnen. Dazu müsste man den Peak mit einem Oszi natürlich mal messen ja.

Und Kerko mhh ka, die sind ESR technisch nicht so gut oder? Da würde ich schon eher ein LowESR nehmen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 08 Juli 2020, 12:54:26
Hab hier (https://nurazur.wordpress.com/2020/02/23/mit-kondensator-die-batterielebensdauer-verlangern/) mal was interessantes zum Thema CR2032 & Kondensator gefunden. Das läßt sich sicherlich auch auf die CR2477 übertragen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 08 Juli 2020, 13:39:46
Genau, müsste man mal messen was unser Setup so verbraucht ja. Aber bei dir ist es ja mehr das Problem der Batteriemessung und nicht das er nicht mehr sendet oder? Also müsstest du das ja darauf abgleichen was an Strom bei der Messung fließt wenn du diese "Messung unter Last" benutzt...

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 09 Juli 2020, 09:42:40
Hallo,

ich habe noch 5 Platinen der Breiten Version Teilbestückt übrig.
https://forum.fhem.de/index.php/topic,112766.0.html (https://forum.fhem.de/index.php/topic,112766.0.html)

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 09 Juli 2020, 12:16:12
Genau, müsste man mal messen was unser Setup so verbraucht ja. Aber bei dir ist es ja mehr das Problem der Batteriemessung und nicht das er nicht mehr sendet oder? Also müsstest du das ja darauf abgleichen was an Strom bei der Messung fließt wenn du diese "Messung unter Last" benutzt...
Die Batteriemessung findet durchgehend, IRQ-driven im Hintergrund statt (außer im Sleep). Damit wird natürlich auch die Spannung beim Senden - also unter realistischer Last - gemessen. Es wird der kleinste jemals ermittelte Wert als aktueller Batteriewert verwendet.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 09 Juli 2020, 13:01:59
Naja die realistische Last zum Batterie messen wäre wenn er sendet und die LEDs leuchten und nicht mit irgend einem Widerstandsnetzwerk aber gut das ist ein anderes Thema.

Haste es den mit 10µF nochmal versucht was er da sagt?

/Daniel

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 09 Juli 2020, 13:20:32
Aber genau so wird es doch gemacht. Wenn die CPU aufwacht, wird die kontinuierliche Batteriemessung (AD-Wandlung) gestartet. Immer wenn eine Messung fertig ist, wird der Wert per Interrupt übernommen, wenn er kleiner als der zuletzt gültige ist. Bevor die CPU wieder schlafen geht, wird die Messung gestoppt. Damit werden während der gesamten Wachphase die Spannungswerte ermittelt - über die interne VCC Messung.
Hatte nur 330µ und 100µ da. Der oben verlinkte Blog kommt auch auf 330µ für nen Tiny mit RFM69.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 09 Juli 2020, 20:21:04
Achso na das habe ich mir so genau nicht angesehen, ich hab hier nur Schaltungen wo irgend welche Lastwiderstände zur Messung verbaut wurden. Das finde ich dann eher ungeeignet. Ich würd das erst mal mit 10 oder 100 probieren und wenn die Batterie sich dem Ende neigt und das Sendemodul zusammenbricht beim Senden dann würde ich noch versuchen ein 330er ran zu klemmen ob das noch was bringt.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 14 Juli 2020, 11:09:54
Hi,

würde vielleicht mit einer mir bei meiner Erstbestellung bei jlcpcb helfen? (am besten vielleicht per PM, um hier nicht vollzuspamen) - ich hab noch nie PCB (und erst recht nicht bestückt) bestellt und will keinen Fehler machen
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 15 Juli 2020, 15:59:06
Vielen Dank für die Hilfe - hab jetzt meine erste Bestellung gestätigt.

Eine Frage: Hat jemand die TLE in China geordert und kann mir welche verkaufen?

Ich hab noch Batteriehalter vom alten Drehgriff-Sensor. Passt der auch? Ist ja eine andere Battterie, oder?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 15 Juli 2020, 19:52:22
Hallo Kai,
Was heißt „altem“ Sensor? Meinst du die erste Version hier aus dem
Beitrag? Wenn ja, das sind die selben Halter.

Die TLEs habe ich bei JLC Bestücken lassen (2 Stück für die Small Variante) den dritten muss ich selbst dann drauf machen, da werde ich mir aus China noch welche bestellen müssen, dazu aber mal ne frage an die Leute die die Small Variante einsetzen, wo ist denn für den dritten TLE der Magnet bei euch verbaut? Der ist doch dafür zuständig um zu erkennen ob das Fenster nun offen steht oder nicht, richtig?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 15 Juli 2020, 19:57:55
Hallo Kai,
Was heißt „altem“ Sensor? Meinst du die erste Version hier aus dem
Beitrag? Wenn ja, das sind die selben Halter.


ich meine die Halter von der ursprünglichen ersten Version des Sensors mit Reed Kontakte
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 15 Juli 2020, 20:06:26
Die Halter sind größer - ich habe diese hier (https://www.aliexpress.com/item/50pcs-lot-High-Quality-Precision-Stamping-SMT-SMD-Coin-Cell-CR2477-Battery-Holder-CR2477-Battery-Retainer/4000274412260.html)
Du kannst natürlich auch probieren, wie lange eine CR2032 durchhält. Die Halter für eine CR2032 sollte auch auf die Pads passen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 15 Juli 2020, 20:09:24
Ich habe jetzt alle Kontakte mit 330µF bzw. 100µF Kondensatoren ausgestattet. Jetzt werden seit Tagen stabile Spannungen von 2,7 - 2,8V angezeigt. Es empfiehlt sich auf jeden Fall so einen Kondensator nachzurüsten. Ich werde die Tage mal den Schaltplan und das Platinenlayout entsprechend anpassen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 15 Juli 2020, 20:29:50
Meeeh :) grade heute hab ich Platinen geordert ;D
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 15 Juli 2020, 21:55:40
Falls jemand noch eine große Platine über hat, bitte bei mir melden.

Hab die einzige die ich hatte wohl beim flashen gehimmelt  >:(

Oder ist da noch was zu retten?

C:\Users\Asus>avrdude -p m328p -P usb -c usbasp -B 10 -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0xFF:m -U lock:w:0xFF:m -F

avrdude: set SCK frequency to 93750 Hz
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x743430
avrdude: Expected signature for ATmega328P is 1E 95 0F

avrdude done.  Thank you.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 16 Juli 2020, 02:10:23
Falls jemand noch eine große Platine über hat, bitte bei mir melden.

Hab die einzige die ich hatte wohl beim flashen gehimmelt  >:(
Schau mal in der FHEM Facebook Gruppe, da hat jemand zu viele bestellt und will diese los werden

https://www.facebook.com/groups/FHEM.Home.Automation/?ref=share (https://www.facebook.com/groups/FHEM.Home.Automation/?ref=share)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 16 Juli 2020, 19:24:42
Wäre nett, wenn hier mal jemand eine genaue flash Anleitung verfassen könnte, ich leg nämlich keinen gesteigerten Wert darauf, die neuen Platinen wieder zu brutzeln  :D
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 16 Juli 2020, 20:25:00
https://asksinpp.de/Grundlagen/02_software.html#ota-firmware-updates
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 16 Juli 2020, 20:36:28
https://asksinpp.de/Grundlagen/02_software.html#ota-firmware-updates
Das war aufschlussreich!

Danke!
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 17 Juli 2020, 15:51:20
Am 6.7. bei AliExpress und JLCPCB die Teile bestellt, heute überrascht gewesen das die Teile von AliExpress schon da sind  ;D jetzt muss ich nur noch auf die Platinen warten  ::)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: co010 am 17 Juli 2020, 20:50:00
Hallo,
Hat jemand von euch noch überbestände von je 10 Stück TLEs und Taster übrig für dieses Projekt ?

gerne per PN

Gruß Robert
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 21 Juli 2020, 20:15:22
Nochmal ne Frage an die Firmware Experten.

Ich kann mir doch auch den Sketch aus dem Github mit der Arduino IDE anpassen, (zwei oder drei TLE‘s usw), dann die Datei als .hex exportieren, und dann mit dem OTA Bootloader mithilfe der make-ota.html versehen und diese dann mittels avr auf die Platine flashen.

Alternativ erst den Bootloader drauf und mittels Arduino IDE die .ino anpassen und mit dem Befehl „upload with programmer“ auf die Platine schreiben.

Korrekt?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 22 Juli 2020, 18:19:20
Mal so ne frage, jetzt wo alle Bauteile da sind... Den Bootloader spiele ich mit dem IPS Programmer drauf (dafür kann ich doch entweder die PINs/PADs an der Seite oder die oben wo eigentlich die Stiftleiste drauf kommt nutzen, richtig?), für die Firmware selbst, benötige ich da die CCU oder geht das auch anderweitig?  :o
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 23 Juli 2020, 08:00:48
Ich komme ehrlich gesagt nicht so ganz weiter.

Habe jetzt erfolgreich den bootloader geflasht und dann folgenden sketch hochgeladen.


//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2020-03-29 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------

// define this to implement new RHS3 device
#define RHS3
// send extra state 50 if sensor 3 is open
// #define USE_FOUR_STATES
// define this to read the device id, serial and device type from bootloader section
// #define USE_OTA_BOOTLOADER
// #define NDEBUG

#ifdef RHS3
  // send battery value
  #define CONTACT_STATE_WITH_BATTERY
#else
  #define BATTERY_LOW 22
  #define BATTERY_CRITICAL 19
#endif

// 24 0030 4D455130323134373633 80 910101

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>

#include <Register.h>
#include <ContactState.h>

// we use a Pro Mini
// Arduino pin for the LED
// D4 == PIN 4 on Pro Mini
#define LED1_PIN 4
#define LED2_PIN 5
// Arduino pin for the config button
// B0 == PIN 8 on Pro Mini
#define CONFIG_BUTTON_PIN 8

#define SENS1_PIN 14
#define SENS2_PIN 15
#define SENS3_PIN 0   // use third sensor for extra open/close detection
#define SABOTAGE_PIN 0 // 16

// number of available peers per channel
#define PEERS_PER_CHANNEL 10

// all library classes are placed in the namespace 'as'
using namespace as;

// define all device properties
#ifdef RHS3
const struct DeviceInfo PROGMEM devinfo = {
    {0xa9,0xb8,0xc7},       // Device ID
    "papaa9b8c7",           // Device Serial
    {0xF2,0x09},            // Device Model
    0x10,                   // Firmware Version
    as::DeviceType::ThreeStateSensor, // Device Type
    {0x01,0x00}             // Info Bytes
};
#else
const struct DeviceInfo PROGMEM devinfo = {
    {0x09,0x56,0x34},       // Device ID
    "papa222111",           // Device Serial
    {0x00,0xC3},            // Device Model
    0x22,                   // Firmware Version
    as::DeviceType::ThreeStateSensor, // Device Type
    {0x01,0x00}             // Info Bytes
};
#endif

/**
 * Configure the used hardware
 */
typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef DualStatusLed<LED2_PIN,LED1_PIN> LedType;
typedef AskSin<LedType,IrqInternalBatt,RadioType> Hal;
Hal hal;

#ifdef RHS3
  DEFREGISTER(Reg0,DREG_CYCLICINFOMSG,MASTERID_REGS,DREG_TRANSMITTRYMAX,DREG_SABOTAGEMSG,DREG_LOWBATLIMIT)
#else
  DEFREGISTER(Reg0,DREG_CYCLICINFOMSG,MASTERID_REGS,DREG_TRANSMITTRYMAX,DREG_SABOTAGEMSG)
#endif
class RHSList0 : public RegList0<Reg0> {
public:
  RHSList0(uint16_t addr) : RegList0<Reg0>(addr) {}
  void defaults () {
    clear();
    cycleInfoMsg(true);
    transmitDevTryMax(6);
    sabotageMsg(true);
#ifdef RHS3
    lowBatLimit(22); // default low bat 2.2V
#endif
  }
};

DEFREGISTER(Reg1,CREG_AES_ACTIVE,CREG_MSGFORPOS,CREG_EVENTDELAYTIME,CREG_LEDONTIME)
class RHSList1 : public RegList1<Reg1> {
public:
  RHSList1 (uint16_t addr) : RegList1<Reg1>(addr) {}
  void defaults () {
    clear();
    msgForPosA(1); // CLOSED
    msgForPosB(2); // OPEN
    msgForPosC(3); // TILTED
    // aesActive(false);
    // eventDelaytime(0);
    ledOntime(100);
    transmitTryMax(6);
  }
};

class TLEPosition : public Position {
  uint8_t posmap[4] = {State::PosB,State::PosA,State::PosC,State::PosB};
  uint8_t pin1, pin2, pin3;
public:
  TLEPosition () : pin1(0), pin2(0), pin3(0) {}
  void init (uint8_t p1,uint8_t p2,uint8_t p3=0) {
    pin1 = p1;
    pin2 = p2;
    pin3 = p3;
    pinMode(p1,INPUT);
    pinMode(p2,INPUT);
    if( p3!=0 ) pinMode(p3,INPUT);
  }
  void init (uint8_t p1,uint8_t p2,uint8_t p3,const uint8_t* pmap) {
    init(p1, p2, p3);
    memcpy(posmap,pmap,4);
  }
  void measure (__attribute__((unused)) bool async=false) {
    // read sensor states
    uint8_t s1 = digitalRead(pin1);
    uint8_t s2 = digitalRead(pin2);
    uint8_t s3 =  (pin3 != 0) ? digitalRead(pin3) : LOW;
    DPRINT("Pins: ");DDEC(s1);DDEC(s2);DDECLN(s3);
    uint8_t pinstate = s2 << 1 | s1;
    _position = posmap[pinstate & 0x03];
#ifndef USE_FOUR_STATES
    if( _position == State::PosA && s3 == HIGH) {
      _position = State::PosB;
    }
#endif
  }
#ifdef USE_FOUR_STATES
  uint8_t remap (uint8_t state) {
    uint8_t s3 =  (pin3 != 0) ? digitalRead(pin3) : LOW;
    if( state >= 100 && s3 == LOW ) {
      return 50;
    }
    return state;
  }
#endif
  // disable polling
  uint32_t interval () { return 0; }
};

template <class HALTYPE,class List0Type,class List1Type,class List4Type,int PEERCOUNT>
class ThreePinChannel : public StateGenericChannel<TLEPosition,HALTYPE,List0Type,List1Type,List4Type,PEERCOUNT> {
public:
  typedef StateGenericChannel<TLEPosition,HALTYPE,List0Type,List1Type,List4Type,PEERCOUNT> BaseChannel;

  ThreePinChannel () : BaseChannel() {};
  ~ThreePinChannel () {}

  void init (uint8_t pin1,uint8_t pin2,uint8_t pin3,uint8_t sabpin,const uint8_t* pmap) {
    BaseChannel::possens.init(pin1,pin2,pin3,pmap);
    BaseChannel::init(sabpin);
  }

  void init (uint8_t pin1,uint8_t pin2,uint8_t pin3,uint8_t sabpin) {
    BaseChannel::possens.init(pin1,pin2,pin3);
    BaseChannel::init(sabpin);
  }

  uint32_t interval () { return BaseChannel::possens.interval(); }

};

typedef ThreePinChannel<Hal,RHSList0,RHSList1,DefList4,PEERS_PER_CHANNEL> ChannelType;


class RHSType : public ThreeStateDevice<Hal,ChannelType,1,RHSList0> {
public:
  typedef ThreeStateDevice<Hal,ChannelType,1,RHSList0> TSDevice;
  RHSType(const DeviceInfo& info,uint16_t addr) : TSDevice(info,addr) {}
  virtual ~RHSType () {}

  virtual void configChanged () {
    TSDevice::configChanged();
    // set battery low/critical values
#ifdef RHS3
    battery().low(getList0().lowBatLimit());
    battery().critical(getList0().lowBatLimit()-3);
#else
    battery().low(BATTERY_LOW);
    battery().critical(BATTERY_CRITICAL);
#endif
  }
};

RHSType sdev(devinfo,0x20);
ConfigButton<RHSType> cfgBtn(sdev);

void funcISR () {
  // we simply activate the alarm
  Alarm& a = sdev.channel(1);
  sysclock.cancel(a);
  sysclock.add(a);
}

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  sdev.init(hal);
  hal.battery.init(seconds2ticks(60UL*60),sysclock);
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);
  sdev.channel(1).init(SENS1_PIN,SENS2_PIN,SENS3_PIN,SABOTAGE_PIN);
  sdev.initDone();

  if( sdev.channel(1).interval() == 0 ) {
    // enable ISR - polling disabled
    contactISR(SENS1_PIN,funcISR);
    contactISR(SENS2_PIN,funcISR);
    if( SENS3_PIN != 0 ) {
      contactISR(SENS3_PIN,funcISR);
    }
    if( SABOTAGE_PIN != 0 ) {
      contactISR(SABOTAGE_PIN,funcISR);
    }
  }
  hal.activity.stayAwake(seconds2ticks(15));
  // wait for valid battery value
  while( hal.battery.current() == 0 ) ;
  // send initial state
  sdev.channel(1).changed(true);
}

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    // deep discharge protection
    // if we drop below critical battery level - switch off all and sleep forever
    if( hal.battery.critical() ) {
      // this call will never return
      hal.sleepForever();
    }
    // if nothing to do - go sleep
    hal.sleep<>();
  }
}

In FHEM die Erweiterung installiert und neu gestartet, und das device gepairt. Sieht nun so aus:

Readings
D-firmware

1.0

2020-07-23 07:49:51
D-serialNr

papaa9b8c7

2020-07-23 07:49:51
PairedTo

0xXXXXXX

2020-07-23 07:50:00
R-pairCentral

0xXXXXXX

2020-07-23 07:50:00
RegL_00.

00:00 09:01 0A:16 0B:9E 0C:8E 10:01 12:16 14:06

2020-07-23 07:50:00
commState

CMDs_done

2020-07-23 07:50:28
trigger_cnt

3

2020-07-23 07:50:28

Es wird also kein state übermittelt.

Hab ich das falsch kompiliert?


Nächste Frage, sobald das CC1101 angeschlossen ist, kann ich den atmega nicht mehr programmieren, erst wenn ich das Teil wieder ablöte.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 23 Juli 2020, 08:07:16
Mal so ne frage, jetzt wo alle Bauteile da sind... Den Bootloader spiele ich mit dem IPS Programmer drauf (dafür kann ich doch entweder die PINs/PADs an der Seite oder die oben wo eigentlich die Stiftleiste drauf kommt nutzen, richtig?), für die Firmware selbst, benötige ich da die CCU oder geht das auch anderweitig?  :o
Ich verstehe Deine Frage nicht. Hier mal ein paar Links:
https://forum.fhem.de/index.php/topic,109786.msg1049812.html#msg1049812
https://asksinpp.de/Grundlagen/02_software.html
https://asksinpp.de/Grundlagen/04-isp.html
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 23 Juli 2020, 08:10:39
Habe jetzt erfolgreich den bootloader geflasht und dann folgenden sketch hochgeladen.

Welchen Bootloader ?

Hab ich das falsch kompiliert?
Hast Du denn was am Sketch verändert ? Was kommt auf der seriellen Console ?
Bitte auch mal ein "richtiges" List des Devices aus FHEM.

Nächste Frage, sobald das CC1101 angeschlossen ist, kann ich den atmega nicht mehr programmieren, erst wenn ich das Teil wieder ablöte.
Das ist komisch. Welche Platine hast Du ? Vielleicht mal ein Bild vom Ausbau posten.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 23 Juli 2020, 08:18:52
Welchen Bootloader ?
Hast Du denn was am Sketch verändert ? Was kommt auf der seriellen Console ?
Bitte auch mal ein "richtiges" List des Devices aus FHEM.

Anfängerfehler, pm ins falsche Verzeichnis. :'(

Läuft jetzt in FHEM und erkennt alle Zustände!


Zitat
Das ist komisch. Welche Platine hast Du ? Vielleicht mal ein Bild vom Ausbau posten.

Platine ist RHS-3 V1.1

Musste auch meinen USBasp auf 5V Jumpern, sonst bekam ich den atmega nicht beschrieben. Da 5V aber zuviel fürs CC1101 sind, hab ich erst geflasht und dann gelötet. Um erstmal nen Anfang zu bekommen habe ich die FW aus dem Github geflasht. Als ich dann die von mir kompilierte flashen wollte, ging das erst nachdem ich das Funkmodul wieder abgelötet hatte.


Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 25 Juli 2020, 22:30:10
Hab da nochmal ne Frage zur firmware.

Ich habe jetzt 10 Sensoren aufgebaut und mit der OTA geflasht. Funktioniert einwandfrei.

Jetzt hab ich noch 5 "große" Platinen bestückt bestellt und erhalten. Hab alle 3 TLE´s bestücken lassen.

Einen von denen wollte ich als normalen RHS-3 flashen, es kommt aber kein vernünftiges Signal aus dem Sensor, obwohl ich Sensor_Pin_3 auf 0 gesetzt hab.

Erst wenn ich ihn als 4 state Sensor kompiliere und flashe, geht er einwandfrei.

Muss ich, wenn der 3. TLE nicht benötigt wird, diesen ablöten?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 26 Juli 2020, 20:38:41
Nein - sollte nicht nötig sein. Und Du hast sicher?
#define SENS3_PIN 0
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 26 Juli 2020, 21:54:17
Jepp, definitiv.

Habe die zwar mit OTA Bootloader kompiliert, aber das sollte ja kein Problem sein.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 27 Juli 2020, 08:05:34
Hab da nochmal ne Frage zur firmware.

Ich habe jetzt 10 Sensoren aufgebaut und mit der OTA geflasht. Funktioniert einwandfrei.

Jetzt hab ich noch 5 "große" Platinen bestückt bestellt und erhalten. Hab alle 3 TLE´s bestücken lassen.

Einen von denen wollte ich als normalen RHS-3 flashen, es kommt aber kein vernünftiges Signal aus dem Sensor, obwohl ich Sensor_Pin_3 auf 0 gesetzt hab.

Erst wenn ich ihn als 4 state Sensor kompiliere und flashe, geht er einwandfrei.

Muss ich, wenn der 3. TLE nicht benötigt wird, diesen ablöten?

Ein kleiner chinesischer TLE war defekt  ::)

Ausgetauscht.......Läuft  :D
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 27 Juli 2020, 08:22:59
Das ist aber noch das vorletzte Design. Jetzt ist die Nut im Boden und es gibt eine extra Vertiefung zum Einrasten.



Hat sich jemand mittlerweile die Mühe gemacht, ein Gehäuse für die große Platine in eckig zu machen?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 29 Juli 2020, 20:20:54
Hab aus dem Projekt noch 30 Taster, 20 Batteriehalter und 10 Magneten übrig.

Am liebsten würde ich das alles gegen ein schmale Teilbestückte Platine tauschen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Christoph am 29 Juli 2020, 21:27:32
Hab mich jetzt lange genug mit den China TLEs rumgeärgert und dann doch originale bei RS bestellt.  :-X
Die funktionieren problemlos   ;D
Falls noch jemand welche braucht -> PN

Gruß Christoph
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 30 Juli 2020, 07:58:24


Ich habe einen schmalen Sensor hier, der sendet als state immer nur 127.

Ließ sich ohne Probleme flashen, aber egal ob per OTA oder "normalem bootloader" und dann per Sketch upload, immer das gleiche verhalten.

Es blinkt auch keine LED, wenn och mit einem Magneten über die TLE´s gehe. Nur nach einem Reset blinkt genau einmal die grüne LED bei Kontakt mit dem Magneten, sendet dann 127 und macht wieder nichts.

Hab schon das CC1101 sowie beide TLE´s getauscht, bleibt unverändert.

Ist zwar nur mein Reserve Sensor, aber vielleicht bekommt man den ja trotzdem in Gang.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: tndx am 02 August 2020, 14:08:47
Hi papa,

ich würde demnächst Platinen bestellen. Meinst Du, Du kriegst noch zeitnah die Kondensatoren ergänzt?  ;)

Geht zur Not auch ohne, aber schöner wäre es.

Danke im Voraus!
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Lucky2k12 am 02 August 2020, 14:12:16
Ich habe einige 3D gedruckte Gehäuse gemäß  https://forum.fhem.de/index.php/topic,109786.msg1046980.html#msg1046980 zu verschenken (gg. Versandkosten)
Die Teile sind aus PLA und für die 1mm dicken Platinen. Daher habe ich neue für meine 1.6mm Platinen gedruckt.
Die zwei mit Deckel sind meine ersten Iterationen  der 3 Noppenversion, aber noch ohne den Freischnitt für die Magnethalter, --> muss selbst freigedremelt werden.
Hier noch ein Bild am Fenster, wie die Farbe bei mir aussieht:
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 02 August 2020, 19:36:02
ich würde demnächst Platinen bestellen. Meinst Du, Du kriegst noch zeitnah die Kondensatoren ergänzt?  ;)
Geht zur Not auch ohne, aber schöner wäre es.
Nicht in den nächsten Wochen. Weiss auch noch nicht, wo der bei der schmalen Variante hin soll. Bei der breiten Variante wollte ich Pads für SMD & THT Elkos neben der Antenne vorsehen. Kann dann jeder bestücken, wie er will.
Das kriegt aber bestimmt auch jemand anders hin  ;)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: tndx am 03 August 2020, 14:18:48
Was sind denn die kleinsmöglichen Größen und welche Arten kommen denn überhaupt in Frage? 100µF und 4-6V sollte ja passen, oder?

Auf die Schnelle habe ich Elkos 5x11 mm gefunden, wäre dafür noch Platz im Gehäuse der schmalen Variante?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 15 August 2020, 13:17:39
Ich habe welche in 100uF 50V, auch etwa 5x11mm, die passen noch locker neben die Batterie.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 15 August 2020, 17:49:36
Hi,

ich drucke grade den Halter für die breite Version mit den STL Files aus dem Repository. Gibt es noch aktuellere/verbesserte Gehäuse? Ich druck den erstmal um zu schauen, ob die Breite/Abstände passen. Was mir noch fehlt ist der Magnethalter für den Rahmen, der in #1 erwähnt wurde. Ich habe irgendwie keine STL gefunden, auf die ich aufbauen könnte

Edit:

In der FreeCad Datei sind alle Sachen
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 25 August 2020, 16:30:40
Hallo papa,

kann es sein, dass auf der kleinen Platine der serielle Anschluss P6 fehlt? Ich schau mir gerade die Platine in KiCAD an.
Hast Du alle Bauteile genommen und P6 dann wieder runtergeworfen? Ansonsten würde ich für beide Versionen unterschiedliche Schaltpläne machen, auf der kleinen ist ja Tx auf der Seite mit drauf.

Danke + Gruß

Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 25 August 2020, 21:26:43
Ja - das hat nicht gepasst.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 29 August 2020, 20:41:32
Ich habe gestern stundenlang versucht, in Freecad ein paar kleine Änderungen zu machen.
Dann entnervt aufgegeben und das Teil in Fusion in einer Stunde neu gezeichnet.

neue Features:
- Freiraum für den Magnethalter
- Nut für die Antenne
- für 1.6mm Platinendicke
- passend für Zweinoppen Deckel aus dem früheren Link https://forum.fhem.de/index.php/topic,109786.msg1046980.html#msg1046980 (davon hatte ich schon 20 Stk hierliegen)

Hi Lucky,

ich muss dich mal direkt ansprechen, weil ich mich ein wenig schwer tue bei Änderungen an deinem Modell. Kannst Du vielleicht auch eine runde Version (oben abgerundet) davon machen für einen Drei Noppen Deckel, der auch abgerundet ist und dessen STL hier schon rumfliegt? Dein Gehäuse passt perfekt zu meinen Platinen, aber der zwei Noppen Deckel passt aufgrund meiner Runden Griffe gar nicht :-/ Die Versionen, die hier für angerundete Griffe herumschwieren passen gar nicht für meine 1.6mm Platine

Hab es auch schon versucht in Fusion und Inventor selber zu machen, da sind meine Skills aber zu gering für. Reicht grade für einen eigenen Magnethalter  ???

Tausend Dank
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 29 August 2020, 21:53:18
Das ist doch mit eingecheckt - RHS_3_small.FCStd. Das Platinendicke habe ich doch schon auf 1.6mm geändert. Einfach DeckelR im FreeCAD auswählen und File->Export. Das gleicht mit BodenR.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 30 August 2020, 08:37:42
Das ist doch mit eingecheckt - RHS_3_small.FCStd. Das Platinendicke habe ich doch schon auf 1.6mm geändert. Einfach DeckelR im FreeCAD auswählen und File->Export. Das gleicht mit BodenR.

Hi papa,

in der FreeCad Datei hatte ich natürlich auch schon geschaut - das ist aber imo nur die eckige Version. Ich muss zugeben, ich kenn mich mit FreeCad nicht aus, aber exportiert habe ich schon den Magnethalter für die breite Version. Das geht also. Jetzt fehlt mir nur noch Small in Rund. Bestimmt kann man das in FreeCad auch leicht in Rund ändern, zumindest gibt es da ja "Linien", nur steh ich ein wenig auf Kriegsfuß mit FreeCad :-)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 30 August 2020, 09:56:39
Also ich habe jetzt wirklich keine Lust hier eine Dokumentation für FreeCAD zu schreiben. Es gibt genug Tutorials im Netz, welche die grundlegende Bedienung erklären. Wie ich schon im vorherigen Beitrag geschrieben habe, muss DeckelR und BodenR exportiert werden.
Das Projekt ist mit eckig eingecheckt (siehe eckig.png). Auf der linken Seite sind die einzelnen Objekte zu sehen. Hier kann mit der Spacetaste die Sichtbarkeit gewechselt werden. Also bitte die eckigen Objekte ausblenden und die runden Objekte einblenden (siehe rund.png) bzw. nach STL exportieren.
Das Model lässte sich durch verschiedene Parameter an die eigenen Bedürfnisse anpassen. Dazu auf Parameter doppel klicken. Es öffnet sich dann eine Tabelle, welche die einstellbaren Werte enthält (parameter.png). Diese können einfach angepasst werden. Die Objekte werden dann automatisch angepasst.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 30 August 2020, 09:58:51
Also ich habe jetzt wirklich keine Lust hier eine Dokumentation für FreeCAD zu schreiben. Es gibt genug Tutorials im Netz, welche die grundlegende Bedienung erklären. Wie ich schon im vorherigen Beitrag geschrieben habe, muss DeckelR und BodenR exportiert werden.
Das Projekt ist mit eckig eingecheckt (siehe eckig.png). Auf der linken Seite sind die einzelnen Objekte zu sehen. Hier kann mit der Spacetaste die Sichtbarkeit gewechselt werden. Also bitte die eckigen Objekte ausblenden und die runden Objekte einblenden (siehe rund.png) bzw. nach STL exportieren.
Das Model lässte sich durch verschiedene Parameter an die eigenen Bedürfnisse anpassen. Dazu auf Parameter doppel klicken. Es öffnet sich dann eine Tabelle, welche die einstellbaren Werte enthält (parameter.png). Diese können einfach angepasst werden. Die Objekte werden dann automatisch angepasst.

Sorry, es tut mir leid und du hast recht. Ich hätte mich vorher ein wenig schlauer machen müssen. Danke für deine Erklärungen - ich such auch mal ein Tutorial und wühl mich durch. Nichts für ungut

Edit: Das ist ja wirklich einfach - hätte ich auch wirklich selber drauf kommen können. Hat geklappt und ich benutze ein wenig den Kopf mit der Wand  :o
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 14 September 2020, 09:16:39
Falls jemand Interesse hat. Ich hab noch 4 von der breiten Version übrig (3 teil und eins Vollbestückt) --> https://forum.fhem.de/index.php/topic,114213.0.html
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Steffih276 am 20 September 2020, 22:42:05
Was sind denn die kleinsmöglichen Größen und welche Arten kommen denn überhaupt in Frage? 100µF und 4-6V sollte ja passen, oder?

Auf die Schnelle habe ich Elkos 5x11 mm gefunden, wäre dafür noch Platz im Gehäuse der schmalen Variante?


Hallo,
Ich finde das Mal wieder ein super Projekt und möchte das nun auch nachbauen.
Bzgl der Elkos: passt diese Version für die schmale Version? Ich gehe Mal davon aus, das es sinnvoll ist die ebenfalls zu verbauen und nicht auf der letzten Schaltplan Version im github aufzusetzen? Gibt es dafür schon irgendwo einen aktualisierten Schaltplan und Bestückungsplan?

Danke sehr & liebe Grüße
Steffi
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 21 September 2020, 07:41:04
Bzgl der Elkos: passt diese Version für die schmale Version? Ich gehe Mal davon aus, das es sinnvoll ist die ebenfalls zu verbauen und nicht auf der letzten Schaltplan Version im github aufzusetzen? Gibt es dafür schon irgendwo einen aktualisierten Schaltplan und Bestückungsplan?

Platinenlayout ist meines Wissens nach noch nicht aktualisiert, die empfohlenen Elkos beziehenn sich auf die klassische Variante, nicht auf das SMD Format.

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 21 September 2020, 09:57:33
Das Layout ist nicht geändert. Ich habe keine Idee, wo der Elko noch Platz hat.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 30 September 2020, 23:28:28
Hallo,

da die Heizperiode wieder losgegangen ist hat sich bei mir ein Problem herausgestellt.
Mein Wandthermostat reagiert nicht korrekt auf den Fensterkontakt. Fenster offen wird erkannt und die Temperatur wird gesenkt. Aber beim schließen des Fensters bleibt die Temperatur abgesenkt trotz "contact closed (to WT_Bad)". An meinen Heizkörper Thermostaten funktioniert alles. Ich habe den Fensterkontakt auch schon ausgetauscht. Gleiches Ergebnis. Thermostat zurückgesetzt auch keine Änderung.

Kann es sein das die Wandthermostate da etwas anders sind?

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 01 Oktober 2020, 12:22:38
Mit nem Wandthermostat habe ich es noch nicht probiert. Aber ich habe jede Menge mit Heizkörperthermostaten laufen. Und die alte Fensterdrehgriff-Software hat super mit Wandthermostate funktioniert. Hat sich eigentlich auch nichts geändert.
Ich sag mal mutig - es ist das Wandthermostat.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 04 Oktober 2020, 20:03:19
Hallo,

ich habe jetzt nocheinmal getestet. Mit einem Optischen Fensterkontakt funktioniert alles, mit dem alten Drehgriffkonntakt hat es auch geklappt nur mit den Neuen Zickt das Thermostat herum.

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 Oktober 2020, 22:05:43
Kannst Du mal die Nachrichten des alten und des neuen aufzeichnen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 04 Oktober 2020, 22:20:52
Hallo,

wie bitte mache ich das? ich habe so etwas noch nicht gemacht.

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 05 Oktober 2020, 09:51:35
Am liebsten wären mir die Messages von der seriellen Console des Sensors oder eines "extra Sensors".
Oder halt mit FHEM - https://wiki.fhem.de/wiki/Homematic_Nachrichten_sniffen
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 13 Oktober 2020, 12:32:53
Hallo Leute,

mal eine andere Frage: Wie macht ihr das denn mit den Dachfenster? Wie überwacht ihr die? Oder macht ihr das eher mit dem optischen Sensor von Homematic?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 13 Oktober 2020, 13:16:37
Da gab es im Homematic Forum auch gerade was zu https://homematic-forum.de/forum/viewtopic.php?f=76&t=60493
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 13 Oktober 2020, 13:18:40
Da gab es im Homematic Forum auch gerade was zu https://homematic-forum.de/forum/viewtopic.php?f=76&t=60493

Ah cool - wo Du dich überall rumtreibst  :P ;D ;D ;D  Vielen Dank fürs hinweisen - ich schau es mir mal an
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 19 November 2020, 19:04:12
Hallo,

Leider bekomme ich es immer noch nicht hin das das Fenster öffnen sicher vom Thermostat erkannt wird. Sowohl Wand als auch Heizkörperthermostat.

Ich habe einen Reserve Kontakt genommen und mit HT verbunden dann die serielle Konsole in betrieb genommen, und das dabei als Ausgabe erhalten

Pins: 011
<- 0D 02 A2 41 6A962F 190465 01 00 64 20  - 15069
-> 0A 02 81 02 190465 6A962F 00  - 15206
waitAck: 01
Pins: 001
<- 0D 03 A2 41 6A962F 190465 01 01 C8 1E  - 15329
-> 0A 03 81 02 190465 6A962F 00  - 15464
waitAck: 01
-> 10 03 A0 01 190465 6A962F 00 04 00 00 00 00 00  - 15702
<- 1A 03 80 10 6A962F 190465 02 09 01 0A 19 0B 04 0C 65 14 06 10 01 12 16 00 00  - 15841
-> 10 04 A0 01 190465 6A962F 01 04 00 00 00 00 01  - 15986
<- 14 04 80 10 6A962F 190465 02 08 00 20 6C 21 00 22 64 00 00  - 16123
-> 0B 05 A0 01 190465 6A962F 01 03  - 16271
<- 0E 05 80 10 6A962F 190465 01 00 00 00 00  - 16398
Pins: 011
<- 0D 04 A2 41 6A962F 190465 01 02 64 1E  - 16939
-> 0A 04 81 02 190465 6A962F 00  - 17074
waitAck: 01
Pins: 111
<- 0D 05 A2 41 6A962F 190465 01 03 C8 1E  - 17315
-> 0A 05 81 02 190465 6A962F 00  - 17451
waitAck: 01
Pins: 101
<- 0D 06 A2 41 6A962F 190465 01 04 00 1E  - 17987
-> 0A 06 81 02 190465 6A962F 00  - 18124
waitAck: 01
Pins: 111
<- 0D 07 A2 41 6A962F 190465 01 05 C8 1E  - 18659
-> 0A 07 81 02 190465 6A962F 00  - 18794
waitAck: 01
Pins: 011
<- 0D 08 A2 41 6A962F 190465 01 06 64 1E  - 19329
-> 0A 08 81 02 190465 6A962F 00  - 19466
waitAck: 01
Pins: 111
<- 0D 09 A2 41 6A962F 190465 01 07 C8 1E  - 19998
-> 0A 09 81 02 190465 6A962F 00  - 20135
waitAck: 01
ignore 0F B8 86 10 3CF528 000000 0A 58 D0 0C 00 00  - 20385
Pins: 101
<- 0D 0A A2 41 6A962F 190465 01 08 00 1E  - 20668
-> 0A 0A 81 02 190465 6A962F 00  - 20805
waitAck: 01
Pins: 111
<- 0D 0B A2 41 6A962F 190465 01 09 C8 1E  - 21338
-> 0A 0B 81 02 190465 6A962F 00  - 21475
waitAck: 01
ignore 0A B8 80 02 190465 00AC60 00  - 21606
 debounce
 pressed
 released
<- 1A 0C 80 00 6A962F 190465 10 F2 09 48 45 51 34 37 30 38 34 38 39 80 01 01 00  - 22030

ignore 0A C0 80 02 190465 00AC60 00  - 22048
ignore 0F B5 86 10 3CF49C 000000 0A A0 DD 0C 00 00  - 22161
-> 10 34 A0 01 190465 6A962F 01 01 3C F5 28 03 03  - 22198
<- 0F 34 80 02 6A962F 190465 01 01 C8 00 5E 1E  - 22325
-> 10 35 A0 01 190465 6A962F 00 04 00 00 00 00 00  - 22472
<- 1A 35 80 10 6A962F 190465 02 09 01 0A 19 0B 04 0C 65 14 06 10 01 12 16 00 00  - 22616
-> 10 36 A0 01 190465 6A962F 01 04 00 00 00 00 01  - 22763
<- 14 36 80 10 6A962F 190465 02 08 00 20 6C 21 00 22 64 00 00  - 22900
-> 0B 37 A0 01 190465 6A962F 01 03  - 23046
<- 12 37 80 10 6A962F 190465 01 3C F5 28 03 00 00 00 00  - 23179
-> 10 38 A0 01 190465 6A962F 01 04 3C F5 28 03 04  - 23384
<- 0E 38 80 10 6A962F 190465 02 01 00 00 00  - 23515
ignore 0C C1 A2 41 00AC60 190465 04 8B 00  - 32212
ignore 0A C1 80 02 190465 00AC60 00  - 32337
ignore 0C 6B 84 70 3F1DA3 000000 00 EB 30  - 36999
 debounce
 released
<- 1A 0D 80 00 6A962F 190465 10 F2 09 48 45 51 34 37 30 38 34 38 39 80 01 01 00  - 42076

ignore 0C CA A2 41 00AC60 190465 04 94 00  - 51955
ignore 0A CA 80 02 190465 00AC60 00  - 52078
 debounce
 pressed
 released
<- 1A 0E 80 00 6A962F 190465 10 F2 09 48 45 51 34 37 30 38 34 38 39 80 01 01 00  - 62130

ignore 0C CC A2 41 00AC60 190465 04 96 00  - 71010
ignore 0A CC 80 02 190465 00AC60 00  - 71135
ignore 0C 6C 86 5A 3F1DA3 000000 B8 EB 30  - 74860
ignore 16 CD A2 5F 00AC60 190465 00 00 26 00 00 00 00 00 09 6A 00 00 00  - 76582
ignore 0A CD 80 02 190465 00AC60 00  - 76695
AskSin++ V4.1.5 (Nov 19 2020 16:33:07)
Address Space: 32 - 103
CC init1
CC Version: 14
 - ready
Pins: 111
Activate Cycle Msg
<- 0F 01 A2 10 6A962F 190465 06 01 C8 00 00 22  - 3409
-> 0A 01 81 02 190465 6A962F 00  - 3545
waitAck: 01
ignore 0A CF 80 02 190465 00AC60 00  - 9760
ignore 0C 6C 84 70 3F1DA3 000000 00 EB 30  - 13174
 debounce
 pressed
 released
<- 1A 02 80 00 6A962F 190465 10 F2 09 48 45 51 34 37 30 38 34 38 39 80 01 01 00  - 15087

-> 10 2A A0 01 190465 6A962F 00 04 00 00 00 00 00  - 15316
<- 1A 2A 80 10 6A962F 190465 02 09 01 0A 19 0B 04 0C 65 14 06 10 01 12 16 00 00  - 15454
-> 10 2B A0 01 190465 6A962F 01 04 00 00 00 00 01  - 15601
<- 14 2B 80 10 6A962F 190465 02 08 00 20 6C 21 00 22 64 00 00  - 15738
-> 0B 2C A0 01 190465 6A962F 01 03  - 15884
<- 12 2C 80 10 6A962F 190465 01 3C F5 28 03 00 00 00 00  - 16015
-> 0B 2C A0 01 190465 6A962F 01 03  - 16465
<- 12 2C 80 10 6A962F 190465 01 3C F5 28 03 00 00 00 00  - 16605
ignore 0A D0 80 02 190465 00AC60 00  - 16879
ignore 0D DD A6 10 57CE6F 190465 06 03 58 00  - 20480
ignore 0A DD 80 02 190465 57CE6F 00  - 20602
Pins: 011
<- 0D 03 A2 41 6A962F 3CF528 01 00 64 1D  - 20692
-> 09 3B A1 12 190465 6A962F  - 20828
-> 09 3B A1 12 190465 6A962F  - 21168
-> 09 3B A1 12 190465 6A962F  - 21477
waitAck: 00
<- 0D 03 A2 41 6A962F 3CF528 01 00 64 1D  - 21618
-> 0D DD 80 02 190465 57CE6F 01 01 58 00  - 21770
waitAck: 00
<- 0D 03 A2 41 6A962F 3CF528 01 00 64 1D  - 22534
waitAck: 00
<- 0D 03 A2 41 6A962F 3CF528 01 00 64 1D  - 23443
-> 09 0E A1 12 190465 6A962F  - 23580
-> 09 0E A1 12 190465 6A962F  - 23861
-> 09 0E A1 12 190465 6A962F  - 24141
waitAck: 00
<- 0D 03 A2 41 6A962F 3CF528 01 00 64 1D  - 24369
waitAck: 00
<- 0D 03 A2 41 6A962F 3CF528 01 00 64 1D  - 25278
-> 09 1B A1 12 190465 6A962F  - 25415
-> 09 1B A1 12 190465 6A962F  - 25696
-> 09 1B A1 12 190465 6A962F  - 25759
-> 09 1B A1 12 190465 6A962F  - 26056
waitAck: 00
Pins: 111
<- 0D 04 A2 41 6A962F 3CF528 01 01 C8 1D  - 26214
-> 0C D1 A2 41 00AC60 190465 04 9A 00  - 27062
waitAck: 00
<- 0D 04 A2 41 6A962F 3CF528 01 01 C8 1D  - 27129
-> 0A D1 80 02 190465 00AC60 00  - 27179
-> 09 4F A1 12 190465 6A962F  - 27256
-> 09 4F A1 12 190465 6A962F  - 27611
-> 09 4F A1 12 190465 6A962F  - 27963
waitAck: 00
<- 0D 04 A2 41 6A962F 3CF528 01 01 C8 1D  - 28061
-> 09 58 A1 12 190465 6A962F  - 28198
-> 09 58 A1 12 190465 6A962F  - 28508
-> 09 58 A1 12 190465 6A962F  - 28848
waitAck: 00
<- 0D 04 A2 41 6A962F 3CF528 01 01 C8 1D  - 28987
-> 09 30 A1 12 190465 6A962F  - 29429
waitAck: 00
<- 0D 04 A2 41 6A962F 3CF528 01 01 C8 1D  - 29904
-> 09 5E A1 12 190465 6A962F  - 30042
-> 09 5E A1 12 190465 6A962F  - 30408
-> 09 5E A1 12 190465 6A962F  - 30720
waitAck: 00
<- 0D 04 A2 41 6A962F 3CF528 01 01 C8 1D  - 30830
-> 09 63 A1 12 190465 6A962F  - 30967
-> 09 63 A1 12 190465 6A962F  - 31248
-> 09 63 A1 12 190465 6A962F  - 31557
waitAck: 00
Pins: 011
<- 0D 05 A2 41 6A962F 3CF528 01 02 64 1D  - 35127
-> 09 5E A1 12 190465 6A962F  - 35262
-> 09 5C A1 12 190465 6A962F  - 35559
-> 09 5E A1 12 190465 6A962F  - 35622
-> 09 5C A1 12 190465 6A962F  - 35846
-> 09 5E A1 12 190465 6A962F  - 35923
waitAck: 00
<- 0D 05 A2 41 6A962F 3CF528 01 02 64 1D  - 36063
waitAck: 00
<- 0D 05 A2 41 6A962F 3CF528 01 02 64 1D  - 36972
-> 09 48 A1 12 190465 6A962F  - 37109
-> 09 48 A1 12 190465 6A962F  - 37406
-> 09 3A A1 12 190465 6A962F  - 37455
-> 09 48 A1 12 190465 6A962F  - 37736
-> 09 3A A1 12 190465 6A962F  - 37771
waitAck: 00
<- 0D 05 A2 41 6A962F 3CF528 01 02 64 1D  - 37910
waitAck: 00
<- 0D 05 A2 41 6A962F 3CF528 01 02 64 1D  - 38819
-> 09 11 A1 12 190465 6A962F  - 38957
-> 09 11 A1 12 190465 6A962F  - 39297
-> 09 3F A1 12 190465 6A962F  - 39329
waitAck: 00
<- 0D 05 A2 41 6A962F 3CF528 01 02 64 1D  - 39747
waitAck: 00
Pins: 111
<- 0D 06 A2 41 6A962F 3CF528 01 03 C8 1D  - 40658
-> 09 0C A1 12 190465 6A962F  - 40796
-> 09 0C A1 12 190465 6A962F  - 41134
-> 09 0C A1 12 190465 6A962F  - 41416
waitAck: 00
<- 0D 06 A2 41 6A962F 3CF528 01 03 C8 1D  - 41584
waitAck: 00
<- 0D 06 A2 41 6A962F 3CF528 01 03 C8 1D  - 42493
-> 09 37 A1 12 190465 6A962F  - 42631
-> 09 37 A1 12 190465 6A962F  - 42956
-> 09 37 A1 12 190465 6A962F  - 43251
waitAck: 00
<- 0D 06 A2 41 6A962F 3CF528 01 03 C8 1D  - 43421
-> 0C DF A2 41 00AC60 190465 04 A7 00  - 43513
-> 0A DF 80 02 190465 00AC60 00  - 43636
waitAck: 00
<- 0D 06 A2 41 6A962F 3CF528 01 03 C8 1D  - 44343
-> 09 5C A1 12 190465 6A962F  - 44478
-> 09 5C A1 12 190465 6A962F  - 44761
-> 09 5C A1 12 190465 6A962F  - 45084
waitAck: 00
<- 0D 06 A2 41 6A962F 3CF528 01 03 C8 1D  - 45268
waitAck: 00
Pins: 101
<- 0D 07 A2 41 6A962F 3CF528 01 04 00 1D  - 46186
-> 09 52 A1 12 190465 6A962F  - 46321
-> 09 52 A1 12 190465 6A962F  - 46618
-> 09 13 A1 12 190465 6A962F  - 46665
-> 09 52 A1 12 190465 6A962F  - 46919
-> 09 13 A1 12 190465 6A962F  - 47026
waitAck: 00
<- 0D 07 A2 41 6A962F 3CF528 01 04 00 1D  - 47122
waitAck: 00
<- 0D 07 A2 41 6A962F 3CF528 01 04 00 1D  - 48031
-> 09 14 A1 12 190465 6A962F  - 48168
-> 09 14 A1 12 190465 6A962F  - 48449
-> 09 22 A1 12 190465 6A962F  - 48484
-> 09 14 A1 12 190465 6A962F  - 48736
-> 09 22 A1 12 190465 6A962F  - 48785
waitAck: 00
<- 0D 07 A2 41 6A962F 3CF528 01 04 00 1D  - 48969
waitAck: 00
<- 0D 07 A2 41 6A962F 3CF528 01 04 00 1D  - 49879
-> 09 5E A1 12 190465 6A962F  - 50014
-> 09 5E A1 12 190465 6A962F  - 50339
-> 09 0D A1 12 190465 6A962F  - 50374
-> 0F B7 86 10 3CF49C 000000 0A A0 DD 0C 00 00  - 50468
-> 09 5E A1 12 190465 6A962F  - 50663
-> 09 0D A1 12 190465 6A962F  - 50681
waitAck: 00
<- 0D 07 A2 41 6A962F 3CF528 01 04 00 1D  - 50823
waitAck: 00
Pins: 111
<- 0D 08 A2 41 6A962F 3CF528 01 05 C8 1D  - 51734
-> 09 5F A1 12 190465 6A962F  - 51871
-> 09 5F A1 12 190465 6A962F  - 52209
-> 09 5A A1 12 190465 6A962F  - 52520
-> 09 5F A1 12 190465 6A962F  - 52570
waitAck: 00
<- 0D 08 A2 41 6A962F 3CF528 01 05 C8 1D  - 52666
waitAck: 00
<- 0D 08 A2 41 6A962F 3CF528 01 05 C8 1D  - 53575
-> 09 3B A1 12 190465 6A962F  - 53712
-> 09 3B A1 12 190465 6A962F  - 54036
-> 09 3B A1 12 190465 6A962F  - 54405
waitAck: 00
<- 0D 08 A2 41 6A962F 3CF528 01 05 C8 1D  - 54503
waitAck: 00
<- 0D 08 A2 41 6A962F 3CF528 01 05 C8 1D  - 55410
-> 09 57 A1 12 190465 6A962F  - 55547
-> 09 57 A1 12 190465 6A962F  - 55873
-> 0C E4 A2 41 00AC60 190465 04 AC 00  - 55994
-> 0A E4 80 02 190465 00AC60 00  - 56160
-> 09 13 A1 12 190465 6A962F  - 56238
waitAck: 00
<- 0D 08 A2 41 6A962F 3CF528 01 05 C8 1D  - 56350
waitAck: 00
Pins: 101
<- 0D 09 A2 41 6A962F 3CF528 01 06 00 1D  - 57264
-> 09 04 A1 12 190465 6A962F  - 57401
-> 09 1F A1 12 190465 6A962F  - 57739
-> 09 04 A1 12 190465 6A962F  - 57759
-> 09 04 A1 12 190465 6A962F  - 58040
waitAck: 00
<- 0D 09 A2 41 6A962F 3CF528 01 06 00 1D  - 58195
-> 0F A5 86 10 3CF522 000000 0A 60 9D C7 00 00  - 58464
waitAck: 00
<- 0D 09 A2 41 6A962F 3CF528 01 06 00 1D  - 59111
-> 09 0F A1 12 190465 6A962F  - 59248
-> 09 0F A1 12 190465 6A962F  - 59602
-> 09 0F A1 12 190465 6A962F  - 59940
waitAck: 00
<- 0D 09 A2 41 6A962F 3CF528 01 06 00 1D  - 60039
-> 09 18 A1 12 190465 6A962F  - 60174
-> 09 18 A1 12 190465 6A962F  - 60456
-> 09 18 A1 12 190465 6A962F  - 60823
waitAck: 00
<- 0D 09 A2 41 6A962F 3CF528 01 06 00 1D  - 60964
-> 09 16 A1 12 190465 6A962F  - 61100
-> 09 16 A1 12 190465 6A962F  - 61411
-> 09 16 A1 12 190465 6A962F  - 61706
waitAck: 00
<- 0D 09 A2 41 6A962F 3CF528 01 06 00 1D  - 61890
waitAck: 00
Pins: 111
<- 0D 0A A2 41 6A962F 3CF528 01 07 C8 1D  - 62810
-> 09 1B A1 12 190465 6A962F  - 62945
-> 09 44 A1 12 190465 6A962F  - 63270
-> 0C EE A2 41 00AC60 190465 04 B5 00  - 63379
-> 0A EE 80 02 190465 00AC60 00  - 63557
waitAck: 00
<- 0D 0A A2 41 6A962F 3CF528 01 07 C8 1D  - 63741
waitAck: 00
<- 0D 0A A2 41 6A962F 3CF528 01 07 C8 1D  - 64651
-> 09 2E A1 12 190465 6A962F  - 64788
-> 09 2E A1 12 190465 6A962F  - 65097
-> 09 2E A1 12 190465 6A962F  - 65394
waitAck: 00
<- 0D 0A A2 41 6A962F 3CF528 01 07 C8 1D  - 65579
waitAck: 00
<- 0D 0A A2 41 6A962F 3CF528 01 07 C8 1D  - 66488
-> 09 1A A1 12 190465 6A962F  - 66623
-> 09 1A A1 12 190465 6A962F  - 66963
-> 09 1A A1 12 190465 6A962F  - 67301
waitAck: 00
<- 0D 0A A2 41 6A962F 3CF528 01 07 C8 1D  - 67414
waitAck: 00
Pins: 101
<- 0D 0B A2 41 6A962F 3CF528 01 08 00 1D  - 68329
-> 09 19 A1 12 190465 6A962F  - 68464
-> 09 19 A1 12 190465 6A962F  - 68790
-> 09 19 A1 12 190465 6A962F  - 69113
waitAck: 00
<- 0D 0B A2 41 6A962F 3CF528 01 08 00 1D  - 69255
waitAck: 00
<- 0D 0B A2 41 6A962F 3CF528 01 08 00 1D  - 70164
-> 09 3F A1 12 190465 6A962F  - 70299
-> 09 3F A1 12 190465 6A962F  - 70668
-> 09 3F A1 12 190465 6A962F  - 71022
waitAck: 00
<- 0D 0B A2 41 6A962F 3CF528 01 08 00 1D  - 71090
waitAck: 00
<- 0D 0B A2 41 6A962F 3CF528 01 08 00 1D  - 71999
-> 09 42 A1 12 190465 6A962F  - 72134
-> 09 42 A1 12 190465 6A962F  - 72503
-> 09 42 A1 12 190465 6A962F  - 72798
waitAck: 00
<- 0D 0B A2 41 6A962F 3CF528 01 08 00 1D  - 72925
waitAck: 00
Pins: 111
<- 0D 0C A2 41 6A962F 3CF528 01 09 C8 1D  - 73840
-> 09 14 A1 12 190465 6A962F  - 73975
-> 09 24 A1 12 190465 6A962F  - 74256
-> 09 14 A1 12 190465 6A962F  - 74582
waitAck: 00
<- 0D 0C A2 41 6A962F 3CF528 01 09 C8 1D  - 74766
waitAck: 00
<- 0D 0C A2 41 6A962F 3CF528 01 09 C8 1D  - 75675
-> 09 14 A1 12 190465 6A962F  - 75810
-> 09 14 A1 12 190465 6A962F  - 76179
-> 09 14 A1 12 190465 6A962F  - 76474
waitAck: 00
<- 0D 0C A2 41 6A962F 3CF528 01 09 C8 1D  - 76601
waitAck: 00
<- 0D 0C A2 41 6A962F 3CF528 01 09 C8 1D  - 77510
-> 09 01 A1 12 190465 6A962F  - 77645
-> 09 01 A1 12 190465 6A962F  - 78000
-> 09 01 A1 12 190465 6A962F  - 78295
waitAck: 00
<- 0D 0C A2 41 6A962F 3CF528 01 09 C8 1D  - 78436
-> 09 29 A1 12 190465 6A962F  - 78573
-> 09 29 A1 12 190465 6A962F  - 78911
-> 09 29 A1 12 190465 6A962F  - 79206
waitAck: 00
Pins: 101
<- 0D 0D A2 41 6A962F 3CF528 01 0A 00 1D  - 79370
-> 09 09 A1 12 190465 6A962F  - 79507
-> 0C F7 A2 41 00AC60 190465 04 BC 00  - 79599
-> 0A F7 80 02 190465 00AC60 00  - 79779
-> 09 09 A1 12 190465 6A962F  - 79800
-> 09 4D A1 12 190465 6A962F  - 79863
-> 09 09 A1 12 190465 6A962F  - 80173
-> 09 4D A1 12 190465 6A962F  - 80222
waitAck: 00
<- 0D 0D A2 41 6A962F 3CF528 01 0A 00 1D  - 80318
waitAck: 00
<- 0D 0D A2 41 6A962F 3CF528 01 0A 00 1D  - 81227
-> 09 5A A1 12 190465 6A962F  - 81364
-> 09 5A A1 12 190465 6A962F  - 81676
-> 09 5A A1 12 190465 6A962F  - 81985
waitAck: 00
<- 0D 0D A2 41 6A962F 3CF528 01 0A 00 1D  - 82155
waitAck: 00
<- 0D 0D A2 41 6A962F 3CF528 01 0A 00 1D  - 83064
-> 09 19 A1 12 190465 6A962F  - 83200
-> 09 19 A1 12 190465 6A962F  - 83539
-> 09 19 A1 12 190465 6A962F  - 83877
waitAck: 00
<- 0D 0D A2 41 6A962F 3CF528 01 0A 00 1D  - 83990
-> 16 F8 A2 5F 00AC60 190465 00 00 26 00 00 00 00 00 09 4C 00 00 00  - 84566
-> 0A F8 80 02 190465 00AC60 00  - 84672
waitAck: 00
Pins: 001
<- 0D 0E A2 41 6A962F 3CF528 01 0B C8 1D  - 84920
-> 09 51 A1 12 190465 6A962F  - 85057
-> 09 51 A1 12 190465 6A962F  - 85338
-> 09 38 A1 12 190465 6A962F  - 85430
-> 09 51 A1 12 190465 6A962F  - 85653
-> 09 38 A1 12 190465 6A962F  - 85760
waitAck: 00
<- 0D 0E A2 41 6A962F 3CF528 01 0B C8 1D  - 85858
waitAck: 00
<- 0D 0E A2 41 6A962F 3CF528 01 0B C8 1D  - 86767
-> 09 06 A1 12 190465 6A962F  - 86902
-> 09 06 A1 12 190465 6A962F  - 87257
-> 09 06 A1 12 190465 6A962F  - 87554
waitAck: 00
<- 0D 0E A2 41 6A962F 3CF528 01 0B C8 1D  - 87693
-> 0C FA A2 41 00AC60 190465 04 BE 00  - 88221
-> 0A FA 80 02 190465 00AC60 00  - 88344
waitAck: 00
<- 0D 0E A2 41 6A962F 3CF528 01 0B C8 1D  - 88614
-> 09 20 A1 12 190465 6A962F  - 88752
-> 09 26 A1 12 190465 6A962F  - 89032
-> 09 20 A1 12 190465 6A962F  - 89110
-> 09 26 A1 12 190465 6A962F  - 89333
-> 09 20 A1 12 190465 6A962F  - 89456
waitAck: 00
<- 0D 0E A2 41 6A962F 3CF528 01 0B C8 1D  - 89552
waitAck: 00
Pins: 011
<- 0D 0F A2 41 6A962F 3CF528 01 0C 64 1D  - 90466
-> 09 30 A1 12 190465 6A962F  - 90601
-> 09 30 A1 12 190465 6A962F  - 90927
-> 09 10 A1 12 190465 6A962F  - 91222
-> 09 30 A1 12 190465 6A962F  - 91256
waitAck: 00
<- 0D 0F A2 41 6A962F 3CF528 01 0C 64 1D  - 91398
waitAck: 00
<- 0D 0F A2 41 6A962F 3CF528 01 0C 64 1D  - 92307
-> 09 5F A1 12 190465 6A962F  - 92442
-> 09 5F A1 12 190465 6A962F  - 92739
-> 09 5F A1 12 190465 6A962F  - 93020
waitAck: 00
<- 0D 0F A2 41 6A962F 3CF528 01 0C 64 1D  - 93233
-> 09 19 A1 12 190465 6A962F  - 93370
-> 09 19 A1 12 190465 6A962F  - 93636
-> 09 19 A1 12 190465 6A962F  - 94005
waitAck: 00
<- 0D 0F A2 41 6A962F 3CF528 01 0C 64 1D  - 94160
-> 09 62 A1 12 190465 6A962F  - 94296
-> 09 62 A1 12 190465 6A962F  - 94650
-> 09 62 A1 12 190465 6A962F  - 94947
waitAck: 00
<- 0D 0F A2 41 6A962F 3CF528 01 0C 64 1D  - 95086
waitAck: 00

waren ein paar versuche.

Ich kann da leider nichts herauslesen.

Auch habe ich versucht den Kontakt als RHS 2 zu flashen wenn ich die mache zeigt er nur noch gekippt und offen an. Geschlossen reagiert nicht mehr.
Zurück geflasht geht es wieder.

Ich hoffe mir kann hier geholfen werden.
Wenn noch angaben benötigt werden...

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 19 November 2020, 19:10:26
Sieht irgendwie komisch aus. Es wird ein SensorEvent an 3CF528 geschickt. Die Antwort kommt aber von 190465 (FHEM ?) und wird ignoriert -> waitAck: 00

Pins: 011
<- 0D 03 A2 41 6A962F 3CF528 01 00 64 1D  - 20692
-> 09 3B A1 12 190465 6A962F  - 20828
-> 09 3B A1 12 190465 6A962F  - 21168
-> 09 3B A1 12 190465 6A962F  - 21477
waitAck: 00

Kannst Du mal Lists von den beteidigten Geräten posten.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 19 November 2020, 19:12:55
Hallo Leute,

habt Ihr auch manchmal das Problem, das der Zustand "Fenster geschlossen" = Magnet unten nicht erkannt wird? Ich hab hier ein Fenster, da ist das der Fall - Trockenübung uneingebaut geht ohne Probleme, nur eingebaut erkennt er nicht, wenn der Magnet unten ist. Fenstergriffe und Gehäuseausdrucke sind alle gleich
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 19 November 2020, 19:26:21
Hallo,

hier die Lists des HT und des FK

Internals:
   DEF        3CF528
   FUUID      5c5ade8d-f33f-0fd2-66f8-1dcb5bf3f4b94f96
   IODev      myHmUARTLGW
   LASTInputDev myHmUARTLGW
   MSGCNT     22698
   NAME       HT_Kinderzimmer
   NOTIFYDEV  global
   NR         64
   NTFY_ORDER 50-HT_Kinderzimmer
   OSMC_HmUART_MSGCNT 7450
   OSMC_HmUART_RAWMSG 05000043C786103CF5280000000A48E60C0000
   OSMC_HmUART_RSSI -67
   OSMC_HmUART_TIME 2020-11-19 19:22:01
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HT_Kinderzimmer_Weather
   channel_02 HT_Kinderzimmer_Climate
   channel_03 HT_Kinderzimmer_WindowRec
   channel_04 HT_Kinderzimmer_Clima
   channel_05 HT_Kinderzimmer_ClimaTeam
   channel_06 HT_Kinderzimmer_remote
   lastMsg    No:C7 - t:10 s:3CF528 d:000000 0A48E60C0000
   myHmUARTLGW_MSGCNT 7629
   myHmUARTLGW_RAWMSG 0500002DC786103CF5280000000A48E60C0000
   myHmUARTLGW_RSSI -45
   myHmUARTLGW_TIME 2020-11-19 19:22:01
   myHmUART_MSGCNT 7619
   myHmUART_RAWMSG 0500003FC786103CF5280000000A48E60C0000
   myHmUART_RSSI -63
   myHmUART_TIME 2020-11-19 19:22:01
   protCondBurst forced_off
   protLastRcv 2020-11-19 19:22:01
   protRcv    7650 last_at:2020-11-19 19:22:01
   protSnd    194 last_at:2020-11-19 18:48:42
   protSndB   5 last_at:2020-11-19 18:45:18
   protState  CMDs_done
   rssi_at_OSMC_HmUART cnt:7450 min:-89 max:-63 avg:-73.35 lst:-67
   rssi_at_myHmUART cnt:7619 min:-86 max:-51 avg:-60.73 lst:-63
   rssi_at_myHmUARTLGW cnt:7629 min:-82 max:-42 avg:-47.63 lst:-45
   rssi_myHmUARTLGW cnt:2 min:-46 max:-46 avg:-46 lst:-46
   READINGS:
     2020-11-06 15:48:28   Activity        alive
     2020-11-19 18:48:41   CommandAccepted yes
     from archivexx        D-firmware      1.4
     from archivexx        D-serialNr      MEQ0798213
     2020-11-19 18:45:19   PairedTo        0x190465
     2020-10-12 20:51:10   R-backOnTime    10 s
     2020-10-12 20:51:10   R-burstRx       on
     2020-10-12 20:51:10   R-cyclicInfoMsg on
     2020-10-12 20:51:10   R-cyclicInfoMsgDis 0
     2020-10-12 20:51:10   R-pairCentral   0x190465
     2020-11-19 18:45:19   RegL_00.         00:00 01:01 02:01 09:01 0A:19 0B:04 0C:65 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00
     2020-11-19 19:05:21   RegL_07.       
     2020-11-19 19:22:01   actuator        0
     2020-11-19 19:22:01   battery         ok
     2020-11-19 19:22:01   batteryLevel    2.7
     2020-11-19 18:48:43   cfgState        ok
     2020-11-19 18:48:43   commState       CMDs_done
     2020-11-19 19:22:01   desired-temp    9.0
     2020-11-19 19:22:01   measured-temp   23.0
     2020-11-19 19:22:01   motorErr        ok
     2020-10-28 22:15:10   powerOn         2020-10-28 22:15:10
     2020-10-28 22:15:10   recentStateType info
     2020-11-19 18:48:43   state           CMDs_done
     2020-11-19 17:37:59   time-request    -
   helper:
     HM_CMDNR   199
     cSnd       011904653CF52803046A962F0103,011904653CF52803046A962F0107
     mId        0095
     peerFriend
     peerOpt    -:thermostat
     regLst     0
     rxType     140
     supp_Pair_Rep 0
     tmplChg    0
     ack:
     cmds:
       TmplKey    :1604673526.78473:1604673528.13813
       TmplTs     1604673528.13813
       cmdKey     0:1:0::HT_Kinderzimmer:0095:01:
       cmdLst:
         assignHmKey noArg
         burstXmit  noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
         inhibit    [(on|{off})]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2-...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         sysTime    noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +3CF528,00,00,00
       nextSend   1605810121.68925
       prefIO     
       rxt        2
       vccu       vccu
       p:
         3CF528
         00
         00
         00
     mRssi:
       mNo        C7
       io:
         OSMC_HmUART:
           -67
           -67
         myHmUART:
           -63
           -63
         myHmUARTLGW:
           -37
           -37
     prt:
       awake      0
       bErr       0
       brstWu     1
       sProc      0
       sleeping   1
       try        1
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       dev        1
       prs        1
     rssi:
       at_OSMC_HmUART:
         avg        -73.3557046979863
         cnt        7450
         lst        -67
         max        -63
         min        -89
       at_myHmUART:
         avg        -60.7330358314739
         cnt        7619
         lst        -63
         max        -51
         min        -86
       at_myHmUARTLGW:
         avg        -47.637567177874
         cnt        7629
         lst        -45
         max        -42
         min        -82
       myHmUARTLGW:
         avg        -46
         cnt        2
         lst        -46
         max        -46
         min        -46
     shRegW:
       07         04
     shadowReg:
     tmpl:
Attributes:
   IOgrp      vccu
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   burstAccess 0_off
   event-on-change-reading .*
   expert     defReg,rawReg
   firmware   1.4
   icon       hm-cc-rt-dn
   model      HM-CC-RT-DN
   room       CUL_HM,Heizung/Fenster
   serialNr   MEQ0798213
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit

Internals:
   CFGFN     
   DEF        6A962F
   FUUID      5fb573df-f33f-0fd2-9326-cf5d04e7f20d685d
   IODev      OSMC_HmUART
   LASTInputDev myHmUARTLGW
   MSGCNT     560
   NAME       HM_6A962F
   NOTIFYDEV  global
   NR         194852
   OSMC_HmUART_MSGCNT 149
   OSMC_HmUART_RAWMSG 0500005713A2416A962F3CF5280110641D
   OSMC_HmUART_RSSI -87
   OSMC_HmUART_TIME 2020-11-19 19:18:28
   STATE      tilted
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:13 - t:41 s:6A962F d:3CF528 0110641D
   myHmUARTLGW_MSGCNT 197
   myHmUARTLGW_RAWMSG 0500005013A2416A962F3CF5280110641D
   myHmUARTLGW_RSSI -80
   myHmUARTLGW_TIME 2020-11-19 19:18:28
   myHmUART_MSGCNT 214
   myHmUART_RAWMSG 0500004713A2416A962F3CF5280110641D
   myHmUART_RSSI -71
   myHmUART_TIME 2020-11-19 19:18:27
   peerList   HT_Kinderzimmer_WindowRec,
   protCmdPend 3 CMDs pending
   protLastRcv 2020-11-19 19:18:23
   protRcv    122 last_at:2020-11-19 19:18:23
   protResnd  4 last_at:2020-11-19 18:47:28
   protSnd    100 last_at:2020-11-19 18:47:23
   protState  CMDs_pending
   rssi_OSMC_HmUART cnt:1 min:-94 max:-94 avg:-94 lst:-94
   rssi_at_OSMC_HmUART cnt:149 min:-89 max:-64 avg:-82.69 lst:-87
   rssi_at_myHmUART cnt:215 min:-84 max:-47 avg:-65.53 lst:-71
   rssi_at_myHmUARTLGW cnt:197 min:-96 max:-59 avg:-82.1 lst:-80
   READINGS:
     2020-11-19 18:44:47   CommandAccepted yes
     2020-11-19 18:47:17   D-firmware      1.0
     2020-11-19 18:47:17   D-serialNr      HEQ4708489
     2020-11-19 18:47:17   PairedTo        0x190465
     2020-11-19 19:05:21   RegL_04.HT_Kinderzimmer_WindowRec
     2020-11-19 16:33:30   alive           yes
     2020-11-19 19:18:23   batVoltage      2.9
     2020-11-19 19:18:23   battery         ok
     2020-11-19 18:47:48   cfgState        RegMiss
     2020-11-19 18:47:28   commState       CMDs_pending
     2020-11-19 19:18:23   contact         tilted (to HT_Kinderzimmer)
     2020-11-19 18:47:22   peerList        HT_Kinderzimmer_WindowRec,
     2020-11-19 18:47:02   powerOn         2020-11-19 18:47:02
     2020-11-19 18:47:02   recentStateType info
     2020-11-19 18:47:02   sabotageError   off
     2020-11-19 19:18:23   state           tilted
     2020-11-19 19:18:23   trigger_cnt     16
   cmdStack:
     ++A0011904656A962F01043CF5280304
     ++A0011904656A962F00040000000000
     ++A0011904656A962F01040000000001
     ++A0011904656A962F0103
   helper:
     HM_CMDNR   19
     PONtest    0
     cSnd       011904656A962F01043CF5280304,011904656A962F01043CF5280304
     getCfgList all
     getCfgListNo ,4
     mId        F209
     peerFriend peerAct,peerVirt
     peerIDsRaw ,3CF52803,00000000
     peerOpt    4:custom
     regLst     0,1,4p
     rxType     20
     supp_Pair_Rep 0
     ack:
     cfgChk:
       idRc01     RegL_00.,RegL_01.,RegL_04.HT_Kinderzimmer_WindowRec
     cmds:
       TmplKey    HT_Kinderzimmer_WindowRec,:1604673526.78473:1605808042.59933
       TmplTs     1605808042.59933
       cmdKey     1:1:0::HM_6A962F:F209:01:HT_Kinderzimmer_WindowRec,
       cmdLst:
         assignHmKey noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerChan   0 -actChn- [({single})] [({set}|unset)] [actor|remote|both]
         peerSmart  -peerOpt-
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2-...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         sign       [(on|{off})]
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         tplSet_HT_Kinderzimmer_WindowRec -tplPeer-
         trgEventL  -peer- -condition-
         trgEventS  -peer- -condition-
         trgPressL  [(-peer-|{all})]
         trgPressS  [(-peer-|{all})]
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       HT_Kinderzimmer_WindowRec
         peerOpt    remove_HT_Kinderzimmer_WindowRec,1_Advent,2_Advent,3_Advent,4_Advent,Audio_Video,HB_4Fach_Leiste_Sw_01,HB_4Fach_Leiste_Sw_02,HB_4Fach_Leiste_Sw_03,HB_OBI_01,HB_ZwStecker_01,HB_ZwStecker_02,HM_273415,HM_4Fach_2_Sw_01,HM_4Fach_2_Sw_02,HM_4Fach_2_Sw_03,HM_4Fach_2_Sw_04,HM_4Fach_Sw_01,HM_4Fach_Sw_02,HM_4Fach_Sw_03,HM_4Fach_Sw_04,HM_8Fach_Sw_02,HM_8Fach_Sw_03,HM_8Fach_Sw_06,HM_8Fach_Sw_07,HM_Batt_01,HM_Batt_02,HM_Batt_Kerze,HM_Dim1_Dim,HM_Dim1_Dim_V_01,HM_Dim1_Dim_V_02,HM_Dim3_Dim,HM_Dim3_Dim_V_01,HM_Dim3_Dim_V_02,HM_Jalusie_Kueche,HM_PW_Stecker_02_Sw,HM_Power_Trockner_Sw,HM_Pwr_Blitz_01_Sw,HM_Pwr_Go_01_Sw,HM_Pwr_Go_02_Sw,HM_S_Kueche,HM_Stehlampe_Sw_01,HM_Stehlampe_Sw_02,HT_Flur_WindowRec,HT_Flur_remote,HT_Kinderzimmer_remote,HT_Schlafzimmer_WindowRec,HT_Schlafzimmer_remote,HT_Wohnzimmer_WindowRec,HT_Wohnzimmer_remote,LichtWohnzimmer_S1,Markise,Steckdose_Kizi,WT_Bad_WindowRec,WT_Bad_remote,vccu_Btn1,vccu_Btn2
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       newChn     +6A962F,02,00,00
       nextSend   1605809908.45196
       prefIO     
       rxt        2
       vccu       vccu
       p:
         6A962F
         00
         00
         00
     mRssi:
       mNo        13
       io:
         OSMC_HmUART:
           -85
           -85
         myHmUART:
           -71
           -71
         myHmUARTLGW:
           -80
           -80
     prt:
       bErr       0
       sProc      2
       sleeping   0
       wuReSent   3
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
     rssi:
       OSMC_HmUART:
         avg        -94
         cnt        1
         lst        -94
         max        -94
         min        -94
       at_OSMC_HmUART:
         avg        -82.6979865771812
         cnt        149
         lst        -87
         max        -64
         min        -89
       at_myHmUART:
         avg        -65.5395348837209
         cnt        215
         lst        -71
         max        -47
         min        -84
       at_myHmUARTLGW:
         avg        -82.1065989847716
         cnt        197
         lst        -80
         max        -59
         min        -96
     shadowReg:
     tmpl:
Attributes:
   IOgrp      vccu
   autoReadReg 4_reqStatus
   expert     rawReg
   firmware   1.0
   model      HB-Sec-RHS-3
   peerIDs    00000000,3CF52803,
   room       CUL_HM,Heizung/Fenster
   serialNr   HEQ4708489
   subType    custom
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 19 November 2020, 21:01:57
Hm - der HB-Sec-RHS-3 hat noch pending Cmds. Kannst DU auch mal ein List vom HT_Kinderzimmer_WindowRec machen.
Den FreqTest hast DU laufen lassen ?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 19 November 2020, 21:54:49
Hallo,

Internals:
   DEF        3CF52803
   FUUID      5c5ade8d-f33f-0fd2-3155-b261e3b8ff4f9e31
   NAME       HT_Kinderzimmer_WindowRec
   NOTIFYDEV  global
   NR         67
   NTFY_ORDER 50-HT_Kinderzimmer_WindowRec
   STATE      last:HM_6A962F:200
   TYPE       CUL_HM
   chanNo     03
   device     HT_Kinderzimmer
   peerList   HM_6A962F,
   READINGS:
     2020-11-19 15:07:17   R-sign          off
     2020-11-19 21:50:17   RegL_01.         00:00 08:00
     2020-11-19 21:50:17   RegL_03.HM_6A962F_chn-01  00:00 04:32
     2020-11-19 21:50:18   RegL_07.HM_6A962F_chn-01  00:00 05:18
     2020-11-19 21:50:18   cfgState        ok
     2020-11-19 21:50:17   peerList        HM_6A962F,
     2020-11-19 21:50:17   state           unknown
     2020-11-19 19:40:46   trigLast        HM_6A962F:200
     2020-11-19 16:51:47   trig_FK_KinderzimmerNeu 0_12
     2020-11-19 19:40:46   trig_HM_6A962F  200_17
   helper:
     peerFriend peerSens,peerVirt
     peerIDsRaw ,6A962F01,00000000
     peerOpt    3:thermostat,7p:thermostat
     regLst     1,3p,7p
     tmplChg    0
     cmds:
       TmplKey    HM_6A962F,:1604673526.78473:1604673528.1386
       TmplTs     1604673528.1386
       cmdKey     1:0:0::HT_Kinderzimmer:0095:03:HM_6A962F,
       cmdLst:
         burstXmit  noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         eventL     -peer- -cond-
         eventS     -peer- -cond-
         getConfig  noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
         inhibit    [(on|{off})]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerSmart  -peerOpt-
         press      [(long|{short})] [(-peer-|{self03})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         pressL     [(-peer-|{self03})]
         pressS     [(-peer-|{self03})]
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2-...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         sign       [(on|{off})]
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         tplSet_HM_6A962F -tplPeer-
       lst:
         condition  slider,0,1,255
         peer       HM_6A962F
         peerOpt    remove_HM_6A962F,FK_Bad,FK_BadNeu,FK_Balkon,FK_KinderzimmerNeu,FK_KuecheNeu,FK_Kueche_Jalusie,FK_SchlafzimmerNeu,HM_Bewegung_Btn_01,HM_Bewegung_Btn_02,HM_Bewegung_Motion,HM_Displ_Remote_Btn_01,HM_Displ_Remote_Btn_02,HM_Displ_Remote_Btn_03,HM_Displ_Remote_Btn_04,HM_Displ_Remote_Btn_05,HM_Displ_Remote_Btn_06,HM_Displ_Remote_Btn_07,HM_Displ_Remote_Btn_08,HM_Displ_Remote_Btn_09,HM_Displ_Remote_Btn_10,HM_Displ_Remote_Btn_11,HM_Displ_Remote_Btn_12,HM_Displ_Remote_Btn_13,HM_Displ_Remote_Btn_14,HM_Displ_Remote_Btn_15,HM_Displ_Remote_Btn_16,HM_Displ_Remote_Btn_17,HM_Displ_Remote_Btn_18,HM_Displ_Remote_Btn_19,HM_Displ_Remote_Btn_20,HM_PW_Stecker_02_SenF,HM_PW_Stecker_02_SenI,HM_PW_Stecker_02_SenPwr,HM_PW_Stecker_02_SenU,HM_Power_Trockner_SenF,HM_Power_Trockner_SenI,HM_Power_Trockner_SenPwr,HM_Power_Trockner_SenU,HM_Pwr_Blitz_01_SenF,HM_Pwr_Blitz_01_SenI,HM_Pwr_Blitz_01_SenPwr,HM_Pwr_Blitz_01_SenU,HM_Pwr_Go_01_SenF,HM_Pwr_Go_01_SenI,HM_Pwr_Go_01_SenPwr,HM_Pwr_Go_01_SenU,HM_Pwr_Go_02_SenF,HM_Pwr_Go_02_SenI,HM_Pwr_Go_02_SenPwr,HM_Pwr_Go_02_SenU,HM_Remote_Btn_01,HM_Remote_Btn_02,HM_Remote_Btn_03,HM_Remote_Btn_04,HM_Remote_Btn_05,HM_Remote_Btn_06,HM_Remote_Btn_07,HM_Remote_Btn_08,HM_Remote_Btn_09,HM_Remote_Btn_10,HM_Remote_Btn_11,HM_Remote_Btn_12,LichtWohnzimmer_S2_Btn_01,LichtWohnzimmer_S2_Btn_02,Schalter_Markise_Btn_01,Schalter_Markise_Btn_02,vccu_Btn1,vccu_Btn2
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     prt:
       brstWu     1
     regCollect:
     role:
       chn        1
     shadowReg:
     tmpl:
Attributes:
   model      HM-CC-RT-DN
   peerIDs    00000000,6A962F01,
   stateFormat last:trigLast

FreqTest weis ich jetzt garnicht. Da das Anlernen ohne Probleme geht habe ich jetzt nicht darüber nachgedacht.

Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: frank am 19 November 2020, 22:16:26
bei deinen hauptdevices fehlt attr IODev.
hminfo configCheck sollte das auch bemängeln.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 19 November 2020, 22:21:53
FreqTest weis ich jetzt garnicht. Da das Anlernen ohne Probleme geht habe ich jetzt nicht darüber nachgedacht.
FreqTest kann nie schaden. Kann sein, dass der RHS Dein HT nicht "hört".
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 20 November 2020, 18:38:34
Hallo,

habe jetzt den FreqTest ausgeführt und wieder die RHS Firmware geflasht. Bis jetzt kann ich keinen Unterschied feststellen, weiterhin nur sporadische Umschaltung des HT.

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 20 November 2020, 19:15:51
Hab mir gerade nochmal den Log von oben angesehen. So wie es aussieht, versucht FHEM noch Konfigdaten zu lesen/schreiben. Das stört dann die Kommunikation mit dem HT.
Bitte mal den Configtaster am RHS-3 kurz drücken, bis die "Pending CMDs" weg sind.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 20 November 2020, 19:25:08
Hallo,

habe ich gemacht hat aber auch nichts geholfen.
Ich habe jetzt nochmal einen von den alten FK (HM-SEC-RHS-2) herausgeholt funktionierte sofort.
Deshalb wollte ich den neuen ja auch mal anders flashen nicht als RHS-3, aber das funktioniert nicht, dann geht der Kontakt für geschlossen nicht mehr.

Gruß Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 20 November 2020, 19:52:46
Also ich benutzte jeweils 3 RHS-3 mit einen Heizungsthermostat. Das geht super.
Hast Du die aktuelle Version der
https://github.com/pa-pa/AskSinPP/blob/master/examples/custom/contrib/FHEM/HMConfig_AskSinPPCustom.pm
installiert ?
Habe im September erst das PeerNeedsBurst eingepflegt. Das wird für den HT unbedingt gebraucht.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: rvideobaer am 22 November 2020, 19:47:53
Hallo,

So ich habe jetzt die Datei upgedated und peernedburst auf on gesetzt, scheint jetzt erst einmal zu funktionieren. Ich werde das noch eine weile testen und mich dann noch einmal melden.

Erst einmal Danke Rolf
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: killah78 am 24 November 2020, 18:34:05
Hi, habe mir gerade einen Fensterkontakt zusammengebaut und funktioniert auch soweit gut.
Beim Testen habe ich geglaubt, dass die TLEs kaputt sind, aber in der Standardeinstellung im Sketch müssen ja U1 und U3 geschlossen sein, um closed zu senden.
Habs verstanden und funktionert. :-)

Jetzt möchte ich aber den 4state Sketch OTA flashen und habe Probleme die eq3 Datei zu erstellen.
Das Script prepota gibt mir eine MEldung:
"./prepota.sh: Zeile 58: ((: == 0 : Syntax Fehler: Operator erwartet. (Fehlerverursachendes Zeichen ist \"== 0 \")."
Ich nutze ein Debian.
Was könnte ich hier falsch machen?
Dank und Gruss
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 24 November 2020, 19:37:07
Versuche mal das Script mit
bash ./prepota.sh xxx.hexaufzurufen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: killah78 am 24 November 2020, 19:58:29
Leider der gleiche Fehler.
Eine eq3 Datei wird aber erzeugt. Aber ist die dann korrekt?
Zum Verständnis: die Eingabedatei für prepota ist der Sketch inklusive des eingefügten Bootloaders per makeota, ist das korrekt?

PS: Habe rausgefunden, woran es liegt. In der Hexdatei ist die letzte Zeile eine Leerzeile. Wenn ich die rausnehme, kommt kein Fehler mehr.

Nochmal edit: Die Leerzeile kommt durch das Einfügen des Bootloaders per makeota. Leite ich daraus ab, dass ich einfach nur den kompilierten Sketch für prepota verwenden soll? :-)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 24 November 2020, 21:44:18
Ja - prepota.sh wid nur mit dem "einfachen" HEX aufgerufen. Damit hat man dann eine Datei, die per OTA das Gerät aktualisieren kann.
makeota.sh - oder bester makeota.html - erzeuget das initiale HEX, das per ISP geflasht werden muss. Danach ist der OTA-Bootloader aktiv und es kann per OTA aktualisiert werden.
Bitte nicht vergessen in Sketch "USE_OTA_BOOTLOADER" zu definieren. Sonst stimmen die Gerätedaten (Model, ID, Serial) nicht.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: killah78 am 25 November 2020, 09:38:54
So, nochmal versucht. Die in Arduino kompilierte Hex (zum Standard geändert: 4 state und Version erhöht) erfolgreich per prepota.sh in eine eq3 umgewandelt. Diesmal auch ohne eine Fehlermeldung.
Aber das nächste Problem wartet. Ich will das unter Linux mit einem HMUSBCFG2 per flash-ota senden.
Fehlermeldung: ./flash-ota -f /tmp/HB.eq3 -s JUS3188297
HomeMatic OTA flasher version 0.103-git

Reading firmware from /tmp/HB.eq3...
Firmware file not valid!

Jemand ne Idee?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 25 November 2020, 11:15:09
Spontan nicht
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: killah78 am 25 November 2020, 15:53:10
Ich habe es jetzt auf den "alten" oder alternativen Weg gemacht mit srec_cat und bin2eq3. Diese Daten konnte ich dann erfolgreich per OTA flashen.
Der Dateiinhalt war komplett unterschiedlich. In der korrekten eq3 ist nur eine Zeile enthalten und keine Leerzeichen.
Die über das Script erstellte hatte diese aber. Schein also bei mir irgendwie nicht funktioniert zu haben.
Aber letztlich erfolgreich geflashed.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 25 November 2020, 16:27:34
Das ist ja blöd - ich hatte extra das Shell-Script gemacht, um die binary Files mal irgendwann wegzuwerfen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: killah78 am 25 November 2020, 16:52:20
Falls du es irgendwie nachvollziehen möchtest, habe ich die Dateien mal angehangen. Das ursprüngliche hex und die fehlerhafte sowie korrekte eq3.
Gruss
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 30 November 2020, 15:01:46
Hallo zusammen,

ich habe eine Platine HB-Sec-RHS-3 small v1.1.
Ist das korrekt, dass ich bei der small Version U3, C10 und R6 weglassen kann, da hier auf dem Fensterrahmen ein Magnet sein muss, um auch wirklich zu erkennen, dass das Fenster geöffnet ist (und nicht nur der Griff gedreht ist)?
Gibt es Infos zur notwendigen Antennenlänge (83 mm - Leiterbahnlänge?)? Wenn nicht, messe ich mal mit dem nanoVNA durch ...
Wofür sind (in der BOM) die Bauteile >C14, >L1, IC3, etc.? Ich vermute mal, C14 ist der Pufferkondensator an der Batterie, der Rest ist eine aufgelöste Bauweise des CC1101 Moduls?

Danke für ein paar klärende Hinweise.

Gruß Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 30 November 2020, 16:46:36
Ja - der 3. TLE braucht nicht bestückt zu werden. In der Software dann SENS3_PIN auf 0 definieren.

Du hast die falsche BOM - der Smalle ist in "gerber_small".
Die BOM im "gerber" Verzeichnis ist schon für die V2.0 - mit integriertem CC1101. Dann gibt es keine Probleme mit der Frquenz mehr. Die ersten Testplatinen sind schon da - allerdings klappt die Abschaltung des Funkmodules per Mosfet noch nicht. Da wird es sicherlich nochmal Änderungen geben - oder ich schmeisse das wieder runter. Das Funkmodul tut aber sehr gut :-)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 30 November 2020, 17:00:23
Du hast die falsche BOM - der Smalle ist in "gerber_small".
Ich hab's befürchtet  :o, danke für den Hinweis.
[klugsch....]
Ich denke, auch in der small (https://github.com/pa-pa/HB-Sec-RHS-3/raw/master/gerber_small/BOM_RHS_3.xlsx) Version sind R7 und C13 zuviel, ich habe sie zumindest auf dem Layout v1.1 nicht gefunden.
Aber ggf. sollte ich meine Brille putzen  8) 8) 8)
[/klugsch....]

Gruß Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PS915 am 04 Dezember 2020, 10:29:52
Ich würde gerne beide Gerber-Files bei Seeedstudio bestellen.
Dafür benötige ich die genauen Maße in Millimeter.

@papa
Wärst du so nett und könntest mir die Maße für beide gerber files nennen? Ich habe bereits die Files in Kicad geöffnet, jedoch kann ich die Board-Outlines nicht korrekt messen, das sich das Measure-Tool immer am Grid orientiert!

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 Dezember 2020, 13:28:22
Das Grid läßt sich beliebig einstellen.

Achtung: Bei der "normalen" Version der Platine bin ich gerade am experimentieren. Dort kann das Funkmodul jetzt auch "selbst" bestückt werden. Damit sollen dann die Probleme mit den fehlerhaften CC1101 Modulen der Vergangenheit angehören. Meine Samples funktionieren damit super - die Frquenz passt.
Außerdem habe ich dort 2 Mosfets zum Abschalten der TLEs und des Funkmodules drauf. Das funktioniert aber irgendwie nicht richtig. Die sollten derzeit ignoriert werden. Einfach nicht bestücken und den Jumper zu lassen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tom Major am 04 Dezember 2020, 23:59:49
Außerdem habe ich dort 2 Mosfets zum Abschalten der TLEs und des Funkmodules drauf. Das funktioniert aber irgendwie nicht richtig. Die sollten derzeit ignoriert werden. Einfach nicht bestücken und den Jumper zu lassen.

@papa Liegen die Probleme beim Abschalten in HW oder SW?
Die HW dafür sollte ja recht übersichtlich sein, ich habe hier ein Bsp. für das Funkmodul abschalten, hatte ich früher schon beim RFM22 im Einsatz.
https://github.com/TomMajor/SmartHome/tree/master/Info/Babbling%20Idiot%20Protection#ma%C3%9Fnahmen--konzepte---stand-fr%C3%BChjahr-2018 (https://github.com/TomMajor/SmartHome/tree/master/Info/Babbling%20Idiot%20Protection#ma%C3%9Fnahmen--konzepte---stand-fr%C3%BChjahr-2018)

Man muss nur darauf achten, alle AVR IO zum Funkmodul auf entweder Low oder besser Input ohne pullup zu legen wenn man es über den Mosfet abschaltet da sonst unerwünschte und auch unerlaubte Querströme fließen können.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 05 Dezember 2020, 22:59:14
Hm - weiss noch nicht. Die HW habe ich im Prinzip genau so. Nur einen Si2305 und 10k Pullup.
Wahrscheinlich eher ein SW Problem - hatte auch noch keine Zeit, das mal genauer zu untersuchen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: killah78 am 27 Dezember 2020, 20:58:47
Hi,
ich weiss nicht, ob ich es irgendwo übersehen habe, ich suche das Gehäuse in groß in eckig.
Für das Small Gehäuse sind beide Varianten in der FreeCad Datein drin. Für das große Gehäuse habe ich nur Rund gefunden.
Kann mir da jemand beim Finden helfen?
Danke und Gruss
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: on-off-on am 27 Dezember 2020, 22:05:16
@killah78
Auf Seite 22 sind die Details zum Gehäusen zu finden.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 28 Dezember 2020, 12:00:00
@papa Liegen die Probleme beim Abschalten in HW oder SW?
Die HW dafür sollte ja recht übersichtlich sein, ich habe hier ein Bsp. für das Funkmodul abschalten, hatte ich früher schon beim RFM22 im Einsatz.
https://github.com/TomMajor/SmartHome/tree/master/Info/Babbling%20Idiot%20Protection#ma%C3%9Fnahmen--konzepte---stand-fr%C3%BChjahr-2018 (https://github.com/TomMajor/SmartHome/tree/master/Info/Babbling%20Idiot%20Protection#ma%C3%9Fnahmen--konzepte---stand-fr%C3%BChjahr-2018)

Man muss nur darauf achten, alle AVR IO zum Funkmodul auf entweder Low oder besser Input ohne pullup zu legen wenn man es über den Mosfet abschaltet da sonst unerwünschte und auch unerlaubte Querströme fließen können.
Hm - habe jetzt mal gemessen. Durchgeschalten habe ich nur knapp 1,8V am CC1101. Es funktioniert so auch nicht zuverlässig. Werde mal deinen Mosfet bestellen und testen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tom Major am 28 Dezember 2020, 14:21:42
Hm - habe jetzt mal gemessen. Durchgeschalten habe ich nur knapp 1,8V am CC1101. Es funktioniert so auch nicht zuverlässig. Werde mal deinen Mosfet bestellen und testen.

Hmm, das klingt definitiv zu wenig. Welchen Typ genau hast du denn eingesetzt?
ich habe bei der Auswahl Si2365 auf niedriges RDsOn und niedrige GS Threshold voltage geachtet.

Edit: Sehe gerade du hast ja oben den Si2305 geschieben. Sieht auf den ersten Blick auch ok aus, ab 1,5V Vgs sollte der voll durchsteuern.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 28 Dezember 2020, 19:33:03
Hmm, das klingt definitiv zu wenig. Welchen Typ genau hast du denn eingesetzt?
ich habe bei der Auswahl Si2365 auf niedriges RDsOn und niedrige GS Threshold voltage geachtet.

Edit: Sehe gerade du hast ja oben den Si2305 geschieben. Sieht auf den ersten Blick auch ok aus, ab 1,5V Vgs sollte der voll durchsteuern.
Tja - hab auch schon den Pullup von 10k auf 100k (wie bei Dir) erhöht. Hat nichts gebracht. Im Prinzip fehlt bei mir noch der CS-Pullup und die Diode. Kann es daran liegen ?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tom Major am 28 Dezember 2020, 23:57:35
Tja - hab auch schon den Pullup von 10k auf 100k (wie bei Dir) erhöht. Hat nichts gebracht. Im Prinzip fehlt bei mir noch der CS-Pullup und die Diode. Kann es daran liegen ?

Am CS-Pullup kann es m.E. nicht liegen das es mit dem Mosfet nicht geht, denn mache ich nur immer default rein wenn sich mehrere die SPI teilen, also beim AVR noch der Programmer.

Die Diode kann ich nicht 100% erklären. Als Jerome und ich vor 2 Jahren uns über einige eQ3 Original Schaltpläne von Batteriegeräten ausgetauscht haben fiel diese Diode bei einigen auf. Meine Theorie ist das ev. eQ3 Probleme mit BI bei Kunden bei leeren Batt. hatte und das der CC1101 dann aufhört wenn der CS wieder an High ist, ist aber nur eine Vermutung, sonst habe ich keine Erklärung.

Du könntest deinen Si2365 auch erst mal separat testen. Gate auf Low, dann müssen sich doch die 3V am Drain einstellen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 02 Januar 2021, 20:32:47
Guten Abend zusammen und ein Frohes und gesundes neues Jahr,
ich wollte die letzen Tage des "Urlaubes" nochmal nutzen, um die Fensterdrehgriffsensoren bereit zu machen, welche schon gut ein halbes Jahr hier darauf warten. Ich wollte heute mich an das flashen "trauen". Ich habe die Platine bzw dessen Pins mit dem USB AVR ISP-Programmer verbunden. Dann habe ich unter Windows mit dem Programm AVRDUDESS die Firmware geflsht, ist das so korrekt (verlaufen) wie im Screenshot zu sehen?

Zuvor hatte ich, mittels der makeota die Firmware erstellt, heraus kam eine XYZ....hex Datei, diese habe ich dann auf den Atmega geflasht. Oder hätte da eine andere Datei drauf gemusst?

Dann wollte ich zum nächsten Schritt, die Firmware für die CCU vorbereiten (ich nutze RaspberryMatic als CCU). Auch wie in der Beschreibung mittels der preota.sh und der XYZ....hex die .eq3 (und noch eine .hex) erstellt.
Versuche ich diese (.eq3 Datei) nun auf die CCU (Einstellung > Firmware > Geräte-Firmware > Neu) hochzuladen, bekomme ich immer die Meldung "Fehler: Ist das eine gültige Firmwaredatei?"

Was mache ich da falsch? Oder habe ich mich total verrant?

Bzgl. der Firmware habe ich eben gesehen, das das eine .tar.gz sein muss. MUSS denn da eine info und changelog.txt dabei sein?

Ich habe mich auch schon hier (https://asksinpp.de/Grundlagen/02_software.html#ota-firmware-updates) eingelesen, und soweit wie verstanden umgesetzt  :o

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 02 Januar 2021, 22:07:37
Zuvor hatte ich, mittels der makeota die Firmware erstellt, heraus kam eine XYZ....hex Datei, diese habe ich dann auf den Atmega geflasht. Oder hätte da eine andere Datei drauf gemusst?
Das ist korrekt und sollte einen funktionierenden Kontakt ergeben - zumindest wenn auch mit USE_OTA_BOOTLOADER übersetzt wurde.
Bzgl. der Firmware habe ich eben gesehen, das das eine .tar.gz sein muss. MUSS denn da eine info und changelog.txt dabei sein?
Bei der CCU bin ich raus.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 02 Januar 2021, 22:28:21
Vorrausgesetzt der Flashvorgang auf den Atmega war erfolgreich, wie müssten sich denn die LEDs auf der Platine verhalten wenn ich Spannung anlege bzw die Batterie einlege? Aktuell passiert mit den LEDs gar nichts...

@papa hast du noch die FreeCad Datei für die Small Variante in rund? Im Github ist nur die Eckige zu finden...
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 02 Januar 2021, 22:46:04
Ich meine es leuchten kurz beide LED‘s und dann blinkt die grüne 7x.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 02 Januar 2021, 22:57:13
Das ist die Ausgabe vom Flash-Programm, bis auf die Warnung mit dem sck period sehe ich da keine fehler... Passiert jedoch nichts wenn ich Spannung anlege...  :-\
JCV1146167.hex: 32.531 / 32.768 Bytes (99,28%)
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
>>>: avrdude -u -c usbasp -p m328p -P usb -B 2.0 -V -U flash:w:"S:\Projekte\HM_Fensterdrehgriffsensor\Flashvorgang\JCV1146167.hex":a
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
>>>: avrdude -u -c usbasp -p m328p -P usb -B 2.0 -V -U flash:w:"S:\Projekte\HM_Fensterdrehgriffsensor\Flashvorgang\JCV1146167.hex":a

avrdude.exe: set SCK frequency to 375000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: set SCK frequency to 375000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: reading input file "S:\Projekte\HM_Fensterdrehgriffsensor\Flashvorgang\JCV1146167.hex"
avrdude.exe: input file S:\Projekte\HM_Fensterdrehgriffsensor\Flashvorgang\JCV1146167.hex auto detected as Intel Hex
avrdude.exe: writing flash (32768 bytes):

Writing | ################################################## | 100% 7.33s

avrdude.exe: 32768 bytes of flash written

avrdude.exe done.  Thank you.

EDIT: Ich habe eben nochmal eine weitere Platine zusammen gelötet und geflasht. Wenn ich da nun Spannung anlege, blinkt D1 (die rote LED) 7x Schnell hinter einander, kurze Pause und dann noch einmal kurz.
Dann gehe ich in HomeMatic auf Gerät Anlernen, drücke den Config Button, dann blinkt die rote LED 20x, wird jedoch nicht angelernt...

Der Schritt mit dem Firmware in die CCU hochladen, muss der denn zwingend zum Anlernen gemacht werden oder dient dieser nur zum späteren Updaten des Gerätes?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 02 Januar 2021, 23:16:30
Was für einen Programmer nutzt du denn?

Ich hatte anfänglich einen USBASP Programmer für ein paar Euro aus der Bucht. Der hat nur Probleme gemacht, d.h. ich hatte auch keine Fehler beim flashen, es hat aber nicht wirklich geklappt. Hab mich dann damit beholfen und eine externe Spannungsversorgung gebastelt und konnte dann alle flashen. Mittlerweile nutze ich den Diamex Programmer, wesentlich entspannter :-)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 02 Januar 2021, 23:35:20
Vorrausgesetzt der Flashvorgang auf den Atmega war erfolgreich, wie müssten sich denn die LEDs auf der Platine verhalten wenn ich Spannung anlege bzw die Batterie einlege? Aktuell passiert mit den LEDs gar nichts...
Hm - das ist komisch. Es müsste zumindest der Bootloader 7x blinken.
@papa hast du noch die FreeCad Datei für die Small Variante in rund? Im Github ist nur die Eckige zu finden...
https://forum.fhem.de/index.php/topic,109786.msg1081861.html#msg1081861
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 03 Januar 2021, 00:02:14
Wie gesagt, nach dem zweiten Flashvorgang blinkt nun die rote LED nach dem zuschalten der Spannungsversorgung 7x schnell.
In der tat nutze ich einen "günstigen" Programmer, mal vor vielen Jahren bei Amazon gekauft, damit auch schon einiges geflasht vor Jahren, also de funktionier eigentlich...
Nur anlernen lässt sich das ganze aktuell nicht an der CCU / RaspberryMatic...
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Januar 2021, 00:03:54
Hast Du auch ein
#define USE_OTA_BOOTLOADERin Sketch ?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 03 Januar 2021, 12:37:11
Hast Du auch ein
#define USE_OTA_BOOTLOADERin Sketch ?
Nein, hatte ich nicht...  ::)
Ich habe jetzt die HB-SEC-RHS-3.ino mittels Arduino IDE geöffnet, dort die // vor dem #define USE_OTA_BOOTLOADER entfernt.
Als Board habe ich den Arudino UNO gewählt
Dann über Sketch > Binärdatei exportieren, dann die entstandene HB-SEC-RHS-3.ino.standard.hex mittels der makeota.html den Bootloader erzeugt und drauf geflasht... Soweit richtig?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Januar 2021, 15:34:42
Bis auf das Board -ja. Das muss auf Pro Mini stehen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 03 Januar 2021, 16:58:45
Ja das hatte ich eben nochmal geändert, danke.

Danach dann noch paar fragen:
- Wenn ich den dritten Kontakt, bsp für den Glasbruchsensor nicht nutzen möchte, was muss im Sketch außer "// #define SENS3_PIN 16" noch angepasst werden? Denn nur mit dem bekomme ich eine Fehlermeldung
'SENS3_PIN' was not declared in this scope- Wenn ich dies dann auskommentiert habe, nutze ich im makeota.html dann als Device HM-SEC-RHS-2 ? > Die erstellte .hex mit der Firmware und Bootloader flashe ich dann auf die Platine mittels ISP Programmer, mehr kommt da nicht drauf...?
- Für das .tar.gz für die CCU, welche .hex (Firmware) nutze ich da dann für die prepota.sh? Die aus dem Sketch oder die mit dem Bootloader? Ich vermute erstere...
- Zu der info Datei für die CCU, im Sketch steht die Firmwareversion auf  0x10, wäre dann die info Datei so korrekt? Typ Resultiert aus der Dezimalzahl von 00C3 für den HM-SEC-RHS-2...
TypeCode=195
Name=HB-SEC-RHS-2
CCUFirmwareVersionMin=2.27.0
CCU3FirmwareVersionMin=3.27.0
FirmwareVersion=1.0

Wenn ich das ganze hier mal ans laufen bekommen habe, werde ich das ganze mal versuchen für "Laien" wie mich zu dokumentieren, wenn gestattet  :D
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 03 Januar 2021, 17:06:03
Ja das hatte ich eben nochmal geändert, danke.

Danach dann noch paar fragen:
- Wenn ich den dritten Kontakt, bsp für den Glasbruchsensor nicht nutzen möchte, was muss im Sketch außer "// #define SENS3_PIN 16" noch angepasst werden? Denn nur mit dem bekomme ich eine Fehlermeldung
'SENS3_PIN' was not declared in this scope- Wenn ich dies dann auskommentiert habe, nutze ich im makeota.html dann als Device HM-SEC-RHS-2 ? > Die erstellte .hex mit der Firmware und Bootloader flashe ich dann auf die Platine mittels ISP Programmer, mehr kommt da nicht drauf...?
- Für das .tar.gz für die CCU, welche .hex (Firmware) nutze ich da dann für die prepota.sh? Die aus dem Sketch oder die mit dem Bootloader? Ich vermute erstere...
- Zu der info Datei für die CCU, im Sketch steht die Firmwareversion auf  0x10, wäre dann die info Datei so korrekt? Typ Resultiert aus der Dezimalzahl von 00C3 für den HM-SEC-RHS-2...
TypeCode=195
Name=HB-SEC-RHS-2
CCUFirmwareVersionMin=2.27.0
CCU3FirmwareVersionMin=3.27.0
FirmwareVersion=1.0

Wenn ich das ganze hier mal ans laufen bekommen habe, werde ich das ganze mal versuchen für "Laien" wie mich zu dokumentieren, wenn gestattet  :D


Frage in die Runde: Hat wer das Modul unter RaspberryMatic am laufen? Müssen dazu noch weitere änderungen gemacht werden? Denn so will die "CCU" das nicht erkennen / lernt es nicht an...
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Januar 2021, 17:33:57
SENS_PIN3 muss auf 0, wenn er nicht genutzt werden soll. Du musst im makeota.html das gleiche setzten wie im Sketch. Wenn Du mit #define RHS3 übersetzt, muss im makeota.html auch der HM-Sec-RHS-3 eingestellt werden. Wenn das Define auskommentiert ist, ist der HM-Sec-RHS-2 zu verwenden.
Das Hex vom makeota.html mit ISP flashen reicht.

Bessere Doku ist immer gut.

Wie gesagt, bei der CCU bin ich leider raus.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 03 Januar 2021, 18:01:18
Okkeey, heißt, wenn ich den zusätlichen Kontakt nicht nutzen möchte, dann setze ich im Sketch
// #define RHS3sowiwe
#define SENS3_PIN 0Und wähle dann in der maketota den RHS-2 aus...?

Was meinst Du mit
Du musst im makeota.html das gleiche setzten wie im Sketch.
Meinst Du damit aus dem Sketch die Zeilen
// define all device properties
#ifdef RHS3
const struct DeviceInfo PROGMEM devinfo = {
    {0xa9,0xb8,0xc7},       // Device ID
    "papaa9b8c7",           // Device Serial
    {0xF2,0x09},            // Device Model
    0x10,                   // Firmware Version
    as::DeviceType::ThreeStateSensor, // Device Type
    {0x01,0x00}             // Info Bytes
};
#else
const struct DeviceInfo PROGMEM devinfo = {
    {0x09,0x56,0x34},       // Device ID
    "papa222111",           // Device Serial
    {0x00,0xC3},            // Device Model
    0x22,                   // Firmware Version
    as::DeviceType::ThreeStateSensor, // Device Type
    {0x01,0x00}             // Info Bytes
};
#endif
In meinem Fall dann sicher der untere Teil wenn ich das als RHS-2 nutze? Doch wie bzw welche Daten gebe ich da in der makeota ein?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Januar 2021, 21:08:34
Lass es uns anders herum machen - was willst Du bauen. Ich sage, was Du wo setzen musst.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 03 Januar 2021, 21:15:29
Na ich wollte den Fensterdrehgriffkontakt "normal" nutzen erst mal. Heißt einfach die Stellung von geschlossen, gekippt oder geöffnet, anzeigen lassen, was ja der sinn deiner Sache ist, den zusätlichen Kontakt für den Glassbruchsensor erst mal nicht, auf U3 ist auch kein TLE verbaut... Den Quarz habe ich auf der Platine z.b nicht verbaut, da du mal meintet der ist nicht notwendig...

Bsp. die makeota im Screenshot, wie gebe ich das im Sketch ein? Heißt aber auch, das ich für jeden Sensor die Daten erneut im Sketch eingeben muss, oder? Auch die "00C3" unter Device Model - a 4 digit hex number wird vorausgefüllt sobald ich den RHS-2 auswähle...

By the way: Wenn jemand 3D Gedruckte gehäuse benötigt, bin neuerdings im Besitz eines 3D Druckers, habe bis jetzt gute Erfahrungen gemacht mit dem Gehäuse im Druck. Habe auch die höhe etwas angepasst damit die Platine nicht so vom Griff gequetscht wird...

EDIT: Mir ist eben noch eingefallen  ::) Ich habe am FHEM Server noch den NeumannCUL dran, mit dem müsste ich den Sensor ja auch direkt in FHEM einbinden können, oder?  ???
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Januar 2021, 21:55:54
Für den RHS-2 mit 2 TLEs muss folgendes gesetzt werden

// #define RHS3
#define USE_OTA_BOOTLOADER
#define SENS3_PIN 0

Die Werte im makeota.html sehen gut aus. Für jedes Gerät, muss eine neue HMID & Serial vergeben werden. Das geht einfach mit dem "Random" Button. Das Hexfile ist für alle das selbe.

Hoffe, das ist verständlich.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 03 Januar 2021, 22:07:16
Ja das ist verständlich, die Änderungen habe ich ja auch im Sketch gemacht. Nach dem Export habe ich dann zwei Datein.
- HB-SEC-RHS-3.ino.with_bootloader.eightanaloginputs.hex
- HB-SEC-RHS-3.ino.eightanaloginputs.hex

Für die makeota nehme ich immer die zweite, ist das so richtig?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Januar 2021, 22:14:26
Ja - die ohne Bootloader
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 03 Januar 2021, 22:34:12
Also, ich habe die Bootloader Datei nun auf zwei verschiedene Platinen geflasht, versucht an drei Bridges (RaspberryMatic, NeumannCUL (in FHEM) und noch einen nanuCUL (in einer anderen FHEM instanz)) versucht anzulernen, es klappt mit beiden einfach nicht...
Ich bin ja jemand der gerne was lernt und eigentlich nicht so schnell aufgibt, aber langsam zweifel ich an mir, was einfach falsch ist an der sache...  :-\
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Januar 2021, 22:43:48
Kannst Du mal nen FTDI-Adapter anschliessen und die Ausgaben der seriellen Konsole aufzeichnen. Mal sehen was da an Debug-Ausgaben kommt.

Vielleicht hilft das hier: https://asksinpp.de/Grundlagen/02_software.html
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 03 Januar 2021, 23:10:18
Habe mir mal HTherm runtergeladen, der Monitor in der Arduino IDE will nicht so... Als ausgabe kommt das wie im Screenshot, die Baudrate habe ich auf 57600 gesetzt, das habe ich aus einem Abschnitt der Doku so entnommen...
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tom Major am 03 Januar 2021, 23:28:46
Hast du in der Arduino IDE den Pro Mini auf 8MHz eingestellt?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 04 Januar 2021, 01:01:44
Ja, Prozessor steht auf ATmega 328P (3,3V, 8Mhz)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 04 Januar 2021, 12:55:01
Ich habe eben nochmal eine Platine zusammen gebaut und diese geflasht. Da zeigt sich folgendes Szenario nach dem Einschalten:
Rote LED blink 7x Schnell, danach kurze Pause, dann gehen beide LEDs nochmal für 2-3 Sekunden an, jedoch lässt sich auch das nicht anlernen  :-\ :(
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 Januar 2021, 12:59:41
Das ist schon mal richtig. Was hast Du für CC1101 Module ? Oft funken diese leider nicht auf der richtigen Frequenz.
Siehe Infos und Lösung dazu: https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 04 Januar 2021, 13:05:12
Die CC1101 Module welche ich habe sind diese: https://a.aliexpress.com/_mKjJFqd
Sollten laut deinem Link die „richtigen“ sein

Wie ist denn die korrekte Reihenfolge beim anlernen? Erst auf der „Bridge“ den Kopplunsmodusstarten und dann am RHS wie weiter machen?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 Januar 2021, 13:33:20
Auf den Config-Taster drücken.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 04 Januar 2021, 18:20:36
Das möchte er so auch nicht...
Ich werde später mal einen CC1101 aus einem alten nanoCUL von mir ausbauen, der funktioniert nämlich, dann werde ich mal schauen...
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 Januar 2021, 22:39:12
Zeigt die Konsole was ordentliches an ?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 Januar 2021, 22:43:10
Du könntest deinen Si2365 auch erst mal separat testen. Gate auf Low, dann müssen sich doch die 3V am Drain einstellen.
Das ist alles irgendwie komisch. Wenn ich das Gate mit einem Jumper auf LOW ziehe, bootet die Firmware ganz normal. Nehme ich den Jumper weg und benutzte D6, hängt sich die CPU auf, sobald ich D6 auf LOW stelle. Habe auch schon mal 100R in die Leitung von D6 zum Gate gemacht. Das hat aber auch nichts gebracht.
So langsam gebe ich auf - habe auch nicht wirklich Zeit. Wahrscheinlich lohnt der ganze Aufwand zum Abschalten eh nicht.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tom Major am 04 Januar 2021, 22:55:22
Ja, Prozessor steht auf ATmega 328P (3,3V, 8Mhz)

Hmm, ich dachte nur da der Bootldr eine ordentliche serielle Ausgabe hat, die App aber nicht kann es nicht an HW, Fuses usw. liegen sondern die App hat ein Problem beim Compilieren oder in der Nachbehandlung des hex files.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tom Major am 04 Januar 2021, 23:00:09
Das ist alles irgendwie komisch. Wenn ich das Gate mit einem Jumper auf LOW ziehe, bootet die Firmware ganz normal. Nehme ich den Jumper weg und benutzte D6, hängt sich die CPU auf, sobald ich D6 auf LOW stelle. Habe auch schon mal 100R in die Leitung von D6 zum Gate gemacht. Das hat aber auch nichts gebracht.
So langsam gebe ich auf - habe auch nicht wirklich Zeit. Wahrscheinlich lohnt der ganze Aufwand zum Abschalten eh nicht.

Wartest du ein paar ms nach D6 Low bevor du den CC1101 benutzt?

Das Thema Abschalten hatten wir übrigens gerade im orangen Forum wegen den RWE/Innogy Geräten.
https://homematic-forum.de/forum/viewtopic.php?f=76&t=64099&sid=499821411c4712531c5b98672992db2b&start=10#p631959 (https://homematic-forum.de/forum/viewtopic.php?f=76&t=64099&sid=499821411c4712531c5b98672992db2b&start=10#p631959)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 Januar 2021, 23:06:29
Wartest du ein paar ms nach D6 Low bevor du den CC1101 benutzt?
Im Prinzip ja - aber er kommt nicht über das digitalWrite(6,LOW).
Das Thema Abschalten hatten wir übrigens gerade im orangen Forum wegen den RWE/Innogy Geräten.
https://homematic-forum.de/forum/viewtopic.php?f=76&t=64099&sid=499821411c4712531c5b98672992db2b&start=10#p631959 (https://homematic-forum.de/forum/viewtopic.php?f=76&t=64099&sid=499821411c4712531c5b98672992db2b&start=10#p631959)
Ja - habe ich gesehen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tom Major am 04 Januar 2021, 23:12:03
Im Prinzip ja - aber er kommt nicht über das digitalWrite(6,LOW).Ja - habe ich gesehen.

Ach so, genau bei D6 Low passiert es schon?
Wenn du mir den aktuellen Stand schickst könnte ich das mal bei Gelegenheit testen bzw. mit dem Oszi mal einen Blick draufwerfen.
Benutzt du zum Test schon die CR2032 und passiert das auch mit einer ordentliche Versorgung?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 04 Januar 2021, 23:45:29
Zeigt die Konsole was ordentliches an ?
Nein, die Konsole Zeit in der Arduino IDE gar nichts an, bleibt einfach weiß...
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 05 Januar 2021, 07:29:38
Also, ich habe die Bootloader Datei nun auf zwei verschiedene Platinen geflasht, versucht an drei Bridges (RaspberryMatic, NeumannCUL (in FHEM) und noch einen nanuCUL (in einer anderen FHEM instanz)) versucht anzulernen, es klappt mit beiden einfach nicht...
Ich bin ja jemand der gerne was lernt und eigentlich nicht so schnell aufgibt, aber langsam zweifel ich an mir, was einfach falsch ist an der sache...  :-\

Wenn du magst, steck mal einen von dir zusammen gebauten FDK in die Post, dann möchte ich dir den gerne flashen um auszuschließen, ob es an deiner Hardware liegt.

Ich bin aber nach wie vor der Meinung, das der Atmega auf dem Board nicht mit genug Spannung zum flashen versorgt wird. Wie sieht deine Spannungsversorgung aus? Nur eingelegte Batterie? Das kann zu wenig sein.
Ich selber hatte bereits mehrere Atmega auf meinen bestückten Platinen die ich erst vernünftig flashen konnte, als mehr Spannung anlag.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 05 Januar 2021, 10:09:23
Dein Angebot würde ich in der Tat einmal annehmen, ich schicke dir dazu mal eine Nachricht.

Bzgl. Der Spannung, da habe ich ehrlich gesagt nur den ISP Programmer dran, keine Batterie o.ä... sollte ich da mal extern was zu steuern? Dann aber 3 oder 5V? Denn der ISP liefert ja über den USB 5V...
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 05 Januar 2021, 11:27:59
Ach so, genau bei D6 Low passiert es schon?
Wenn du mir den aktuellen Stand schickst könnte ich das mal bei Gelegenheit testen bzw. mit dem Oszi mal einen Blick draufwerfen.
Benutzt du zum Test schon die CR2032 und passiert das auch mit einer ordentliche Versorgung?
Das werde ich in der Tat machen. ich mach Dir mal nen Board fertig, welches noch alles Original hat und schmeiß das in die Post.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 05 Januar 2021, 23:34:39
Guten Abend ihr,

Was mir aber eben eingefallen ist, kann das Ganze eventuell auch an der Antenne liegen, ich habe aktuell die Originale bzw beigelegte Antenne der CC1101 an dem Ant. Lötauge montiert, wie lang muss denn eigentlich dir Antenne sein?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 12 Januar 2021, 21:59:59
Guten Abend zusammen,
ich bin es mal wieder, diesmal mit guten Nachrichten. Ich hatte ja zwei Platinen zum Überprüfen zu Dirk geschickt, er hatte mir nochmal sehr geholten was das flashen angeht, auch den USBasp habe ich entsorgt und mir einen von DIAMDEX geholt, das lief dann auf anhieb, nachdem ich das ganze Syszem doch etwas verstanden habe  ::) ;D
Ich habe jetzt aktuell 11 FDK installiert. Diese habe ich über einen CUL an der VCCU an FHEM angemeldet. Was mir aber aufgefallen ist heute, (ist jetzt denke ich mal kein Fehler der FDK seblst) ich kann weitere HM Geräte bzw die FDK anlernen, ohne die VCCU in den "hmPairForSec" zu setzen  :-\
Ich habe ja auch noch RaspberryMatic für einige HMIP Geräte am laufen. Dort wurd mir auch der "DutyCycle" angezeigt, dieser liegt seit dem Einbinden der ganzen FDK auf 0%...
Ich habe eben mal den CUL abgezogen um zu gucken ob das was ändert. Hat jemand eine Idee woran das liegen könnte?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Flole am 14 Februar 2021, 22:22:45
Ich habe gerade einmal die Datei RHS_3.kicad_pcb aus dem GitHub Repository in Altium's Online-Viewer angeschaut und dort sieht es so aus als ob der Kondensator C3 nur einseitig verbunden ist. Die Masseverbindung scheint zu fehlen. Ist das in der Realität bzw. auf den produzierten PCBs auch so?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 14 Februar 2021, 22:32:38
Meine Bestellung hat funktioniert. Allerding geht die Abschaltung des CC1101 und der TLE nicht richtig. Du brauchst Q1 & Q2 nicht bestücken, sondern unbedingt die Jumper (JP1 & JP2) geschlossen lassen. Danngeht alles ohne Probleme.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Flole am 14 Februar 2021, 22:43:32
Da hab ich den Dateinamen falsch kopiert.... Ich hatte die Datei RHS_3_Simple.kicad_pcb geladen und nicht die "normale"... Auf der normalen scheint es zu passen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: killah78 am 29 April 2021, 21:32:17
Hast du rausgefunden, woran es lag? Habe auch so ein Exemplar und verhält sich so wie von dir beschrieben.

Ich habe einen schmalen Sensor hier, der sendet als state immer nur 127.

Ließ sich ohne Probleme flashen, aber egal ob per OTA oder "normalem bootloader" und dann per Sketch upload, immer das gleiche verhalten.

Es blinkt auch keine LED, wenn och mit einem Magneten über die TLE´s gehe. Nur nach einem Reset blinkt genau einmal die grüne LED bei Kontakt mit dem Magneten, sendet dann 127 und macht wieder nichts.

Hab schon das CC1101 sowie beide TLE´s getauscht, bleibt unverändert.

Ist zwar nur mein Reserve Sensor, aber vielleicht bekommt man den ja trotzdem in Gang.

Edit: Hmmh. Nachdem ich mal seriell mitlese, sehe ich, dass zumindest ein TLE kaputt ist. Erklärt das Verhalten aber noch nicht. Ich sehe, dass das Radio Nachrichten sendet (an Adresse 000000) und dies kommt auch in FHEM an, aber er empfängt keine Antworten. Vermutlich sendet er daher auch keinen Pinstatus, weil er noch auf eine "initiale Antwort" wartet? Kann sowas sein, dass ein "sterbender TLE" das Radio beschädigt? Der TLE hat mal funktioniert.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Alexxx2005 am 30 April 2021, 19:10:20
Hallo,

was für einen Wert hat eigentlich das Quarz Y1 ?

Grüße Alex
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 30 April 2021, 22:08:49
Da ist ein 32kHz vorgesehen. Wird aber nicht benutzt. Also einfach nicht bestücken.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: eki am 18 Juli 2021, 11:52:32
Kann es sein, dass in der Positionierungsliste für die Bestückung für die schmale Version der CC1101 fehlt? Oder muss man den Funkchip bei der schmalen Variante grundsätzlich selbst bestücken?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 18 Juli 2021, 22:38:00
Die schmale Version gibt es nur mit "Standard"-CC1101-Modul.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: eki am 04 August 2021, 11:46:21
Ich habe mir jetzt auch mal die Platinen mit Bestückung bestellt. Mein Verständnis zur Programmierung ist folgendes (bitte korrigiert mich, falls ich da was falsch verstehe):

1. Der auf den Platinen befindliche ATMEGA328P-A Chip hat noch keinen Bootloader, den muss ich per ISP aufspielen, dazu brauche ich z.B. den USBasp Programmierer.
2. Nachdem der Bootloader drauf ist, kann ich den Sketch aufspielen, dazu brauche ich meinen FTDI Programmierer.
3. Danach kann dann auch per OTA neue Firmware geflashed werden.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 04 August 2021, 13:18:45
1. Der auf den Platinen befindliche ATMEGA328P-A Chip hat noch keinen Bootloader, den muss ich per ISP aufspielen, dazu brauche ich z.B. den USBasp Programmierer.
2. Nachdem der Bootloader drauf ist, kann ich den Sketch aufspielen, dazu brauche ich meinen FTDI Programmierer.
3. Danach kann dann auch per OTA neue Firmware geflashed werden.
Du kannst auch folgende Reihenfolge nehmen:
1. Du generierst Dir einen Sketch mit integriertem OTA Bootloader und spielst ihn per ISP auf.
2. Die weiteren Versionen (ohne Bootloader) flashst Du per OTA (im EQ3 Format).

Gruß Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 04 August 2021, 17:35:24
Ich habe mir jetzt auch mal die Platinen mit Bestückung bestellt.

Hallo eki,

darf ich mal fragen wo du die mit der Bestückung zusammen bestellt hast, habe nämlich auch Interesse an den Türgriffkontakten aber bei SMD-Löten bin ich raus. Deswegen finde ich die Idee die fertig bestückt zu bestellen super.

Gruß Markus
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 04 August 2021, 17:57:07
Für bestückte Platinen habe ich sehr gute Erfahrungen mit JLCPCB gemacht.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Prof. Dr. Peter Henning am 04 August 2021, 19:37:31
Hat irgendjemand schon eine 3D-Druck-Lösung für DIESE Anordnung des FG?

Griffbasis also zu 50% "eingebaut", das ist auch nicht änderbar.

Außerdem suche ich auch nach einer Quelle für fertig bestückte Platinen. Mache ich normalerweise durchaus gerne selbst - aber im Moment fehlt mir die Zeit komplett.

LG

pah
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 04 August 2021, 20:11:34
Hat irgendjemand schon eine 3D-Druck-Lösung für DIESE Anordnung des FG?

Griffbasis also zu 50% "eingebaut", das ist auch nicht änderbar.

Außerdem suche ich auch nach einer Quelle für fertig bestückte Platinen. Mache ich normalerweise durchaus gerne selbst - aber im Moment fehlt mir die Zeit komplett.

LG

pah

Wie gesagt, JLCPCB ist für mich die erste Adresse.

...und das hier kommt dem von dir gesuchten recht nahe  :)

STL ist im Post #91 und #256
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Prof. Dr. Peter Henning am 04 August 2021, 21:12:42
Zum Bild: Schön wärs. Isses aber nicht - das Gehäuse müsste eben seitlich versetzt sein :-(

LG

pah

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: eki am 04 August 2021, 22:00:44
Ich habe auch JLCPCB für die Platinen und die Bestückung genutzt. Die hatten zwar die TLEs leider nicht vorrätig und die Bestückung habe ich auch nur auf einer Seite gemacht (die auf der der ATMEGA ist), ein bisschen SMD Löten ist also schon noch nötig, dafür ging es trotz aktuellem Lieferchaos erstaunlich schnell (7 Tage).

Für den halb verdeckten Türgriff reicht meines Erachtens ein angepasstes Gehäuse nicht, da müsste man möglicherweise auch was an den Platinen machen, weil ja die Löcher für die Schrauben und den Vierkant wahrscheinlich auch nicht passen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 August 2021, 23:11:41
Hallo PAH

könnte das hier funktionieren ?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Prof. Dr. Peter Henning am 05 August 2021, 09:09:32
Das sollte gehen. Denn die Löcher und Schrauben sind natürlich normgerecht - nur eben nach oben und unten ist das Ding "eingemauert".

Edit: Ich verstehe den Workflow von JLCPCB noch nicht. Ist das wirklich so, dass ich dort eine kleine Anzahl von FDG-Platinen (sagen wir mal 3 Stück) komplett bestückt bestellen kann, und wenn ja, was kostet der Spaß?


LG

pah
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: eki am 05 August 2021, 13:34:18
Zitat
Edit: Ich verstehe den Workflow von JLCPCB noch nicht. Ist das wirklich so, dass ich dort eine kleine Anzahl von FDG-Platinen (sagen wir mal 3 Stück) komplett bestückt bestellen kann, und wenn ja, was kostet der Spaß?

In etwa (Minimalanzahl der Platinen ist allerdings 5). Man lädt die Gerber Files hoch (gezippt), um die Platine zu definieren. Zum Bestücken braucht man die beiden Excel files (sind auch im Gerber Ordner, eines für die Stückliste und eines für die Platzierung). Dann macht die Webplattform Vorschläge zu den Bauteilen, das kann man dann noch mal checken (eventuell sind Teile nicht verfügbar, wie bei mir die TLEs, dann muss man die weglassen und später selbst bestücken). Dann läuft noch ein interner Check bei JLCPCB, falls da Probleme erkannt werden, bekommt man eine email (war bei mir so, weil die C11 und C12 wie in der Stückliste angegeben wohl nicht auf die Platine passen, das ist aber bei der breiten Variante eventuell anders). Danach geht es los und ein paar Tage später hat man die Dinger.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Prof. Dr. Peter Henning am 05 August 2021, 15:20:18
OK, prima, danke.

Ich schlage vor, daraus einen Wiki-Eintrag zu machen. Ich möchte wetten, dass das bei ganz vielen Forumsmitgliedern auf Resonanz stößt.
Wenn wir dann noch eine Forumsecke für komplette Projekte definieren, mit der Ablage der entsprechenden Dateien, könnte das in hohem Maße zur Verbreitung der selbst entworfenen Hardware beitragen.

LG

pah
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: tndx am 05 August 2021, 16:30:47
Hier ist ein Beispiel:

https://github.com/Asselhead/Bestellanleitung-JLCPCB-SMT-Service (https://github.com/Asselhead/Bestellanleitung-JLCPCB-SMT-Service)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 05 August 2021, 20:35:45
Ich schlage vor, daraus einen Wiki-Eintrag zu machen. Ich möchte wetten, dass das bei ganz vielen Forumsmitgliedern auf Resonanz stößt.
Wenn wir dann noch eine Forumsecke für komplette Projekte definieren, mit der Ablage der entsprechenden Dateien, könnte das in hohem Maße zur Verbreitung der selbst entworfenen Hardware beitragen.
Tja - die Doku ist immer so eine Sache. Da reicht die Zeit meist leider nicht, um das gut zu machen. Manchmal würde ich mich auch freuen, wenn ich nochmal irgendwo nachlesen könnte, was ich da verbrochen habe ;-)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: KurtK am 05 August 2021, 20:40:13
Meine Platinen sind nach 7 Tagen Lieferzeit von JLCPCP angekommen.
Nun stellt sich mir noch eine Frage.

Die Platine ist ja für eine 2x5 2mm Stiftleiste zum flashen ausgelegt. Weiß jemand ob es ein Adapterkabel auf die Standard ISP10 Stecker mit 2,54mm fertig zu kaufen gibt oder ist hier noch ein wenig basteln angesagt?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Papa Romeo am 05 August 2021, 21:17:07
Tja - die Doku ist immer so eine Sache. Da reicht die Zeit meist leider nicht, um das gut zu machen. Manchmal würde ich mich auch freuen, wenn ich nochmal irgendwo nachlesen könnte, was ich da verbrochen habe ;-)

... da hast du wohl recht. Und dann bleibt es ja meistens nicht nur bei einem Projekt ...  ???

LG
Papa Romeo
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 05 August 2021, 21:53:19
Meine Platinen sind nach 7 Tagen Lieferzeit von JLCPCP angekommen.
Nun stellt sich mir noch eine Frage.

Die Platine ist ja für eine 2x5 2mm Stiftleiste zum flashen ausgelegt. Weiß jemand ob es ein Adapterkabel auf die Standard ISP10 Stecker mit 2,54mm fertig zu kaufen gibt oder ist hier noch ein wenig basteln angesagt?
Adapter sollte z.B. dieser
https://shop.myavr.de/index.php?sp=article.sp.php&artID=100075
gehen - kann man sich aber auch einfach selber löten.