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
Zitat 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.

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
Zitat von: papa am 03 April 2020, 20:59:58
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,

Zitat 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
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
Zitat von: Psi am 05 April 2020, 18:16:23
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
Zitat von: pc1246 am 06 April 2020, 08:04: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
Zitat von: papa am 05 April 2020, 23:40:17
@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
Zitat 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.
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
Zitat von: Psi am 06 April 2020, 23:30:37
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.
Zitat von: Psi am 06 April 2020, 23:30:37
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.
Zitat von: Psi am 06 April 2020, 23:30:37
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
Zitat von: Tom Major am 07 April 2020, 16:38:32
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
Zitat 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.
<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
Zitat von: papa am 08 April 2020, 09:27:37
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:
ZitatSiLabs 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
Zitat 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 :)
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
Zitat 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
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
Zitat von: pc1246 am 09 April 2020, 08:11:43
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
Zitat 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.
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
Zitat 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.

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
Zitat von: ext23 am 10 April 2020, 07:45:29
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
Zitat von: Papaloewe am 10 April 2020, 10:00:49
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
Zitat von: pc1246 am 22 April 2020, 08:41:18
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
Zitat 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)

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
Zitat von: Loetkolben am 22 April 2020, 18:52:18
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
Zitat 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.
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
Zitat von: papa am 22 April 2020, 20:08:45
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
Zitat 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 !

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
Zitat 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

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
Zitat 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

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
Zitat 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.
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
Zitat von: gloob am 02 Mai 2020, 10:45:28
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
Zitat von: ext23 am 02 Mai 2020, 15:09:41
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
Zitat von: Christoph am 02 Mai 2020, 13:26:06
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
Zitat von: gloob am 02 Mai 2020, 19:45:29
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
Zitat von: papa am 02 Mai 2020, 22:21:36
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
Zitat von: papa am 01 Mai 2020, 20:19:03
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
Zitat 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.
Ich hatte mit einem Prototyp Probleme, wenn der Magnet weiter innen war. Das kann sich ja jeder selbst ausprobieren.
Zitat von: gloob am 03 Mai 2020, 10:52:03
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
Zitat von: nog76 am 03 Mai 2020, 11:13:16
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
Zitat von: rvideobaer am 03 Mai 2020, 16:32:48
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
Zitat 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  >:(

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

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

Zitat von: rvideobaer am 03 Mai 2020, 19:49:15

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
Zitat von: Pfriemler am 03 Mai 2020, 19:02:05
Ich muss mal einwerfen, dass mich diese Art der Umsetzung auch nicht befriedigt.
Es gibt halt wie immer unterschiedliche Anforderungen.
Zitat von: Pfriemler am 03 Mai 2020, 19:02:05
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
Zitat von: rvideobaer am 04 Mai 2020, 19:33: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
Zitat 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> {


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
Zitat von: gloob am 04 Mai 2020, 20:29:23
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
Zitat von: rvideobaer am 04 Mai 2020, 19:33:13
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:

ZitatMERCHANDISE 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
Zitat 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.

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
Zitat von: papa am 04 Mai 2020, 20:33:52
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
Zitat von: rvideobaer am 07 Mai 2020, 19:46:35
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
Zitat von: gloob am 14 Mai 2020, 10:51:41
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
Zitat von: papa am 15 Mai 2020, 08:49:46
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
Zitat von: PSI69 am 15 Mai 2020, 09:00:38
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
Zitat von: papa am 15 Mai 2020, 09:11:51
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
Zitat von: gloob am 25 Mai 2020, 14:26:06
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
Zitat von: papa am 25 Mai 2020, 14:51:45
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
Zitat 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.

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
Zitat 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

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
Zitat 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.

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
Zitat 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.

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
Zitat 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?

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
Zitat 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?

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
Zitat von: gloob am 26 Mai 2020, 20:29:42
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
Zitat von: Nighthawk am 28 Mai 2020, 02:42:52
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
Zitat von: papa am 29 Mai 2020, 21:50:13
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
Zitat von: Nighthawk am 03 Juni 2020, 16:07:34
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
Zitat 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  ::)
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
Zitat 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.

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
Zitat von: Lucky2k12 am 08 Juni 2020, 18:24:13
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
Zitat von: Lucky2k12 am 16 Juni 2020, 19:43:20
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
Zitat 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)
Schön das es nun gleich funktioniert hat.
Zitat von: Lucky2k12 am 16 Juni 2020, 19:43:20
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.
Zitat von: Lucky2k12 am 16 Juni 2020, 19:43:20
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.
Zitat von: Lucky2k12 am 16 Juni 2020, 19:43:20
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
Zitat von: papa am 16 Juni 2020, 20:43:42
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.
Zitat von: papa am 16 Juni 2020, 20:43:42
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
Zitat von: Lucky2k12 am 17 Juni 2020, 07:59:57
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
Zitat von: Lucky2k12 am 17 Juni 2020, 07:59:57
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
Zitat von: papa am 17 Juni 2020, 09:33:00
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
Zitat von: ext23 am 17 Juni 2020, 16:52:21
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
Zitat von: ext23 am 17 Juni 2020, 20:26:20
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
Zitat von: Lucky2k12 am 18 Juni 2020, 13:44:55
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
Zitat von: papa am 18 Juni 2020, 13:54:46
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
Zitat 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 !

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
Zitat 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.

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
Zitat von: ext23 am 19 Juni 2020, 09:13:55
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
Zitat von: papa am 19 Juni 2020, 11:20:49
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
Zitat von: Lucky2k12 am 19 Juni 2020, 14:47:56
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
Zitat von: Lucky2k12 am 19 Juni 2020, 15:21:41
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
Zitat 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
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
Zitat 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.
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.

Zitat von: ext23 am 20 Juni 2020, 11:44:51
Ü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
Zitat 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 ...
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
Zitat von: PeMue am 21 Juni 2020, 18:23:27
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
Zitat von: Lucky2k12 am 22 Juni 2020, 10:01:37
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
Zitat von: PeMue am 22 Juni 2020, 10:54:33
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
Zitat 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.
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
Zitat von: Fillip am 05 Juli 2020, 18:49:40
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
Zitat 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...
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
Zitat 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.


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
Zitat 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  >:(
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
Zitat 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
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
Zitat von: Feinfinger am 23 Juli 2020, 08:00:48
Habe jetzt erfolgreich den bootloader geflasht und dann folgenden sketch hochgeladen.

Welchen Bootloader ?

Zitat von: Feinfinger am 23 Juli 2020, 08:00:48
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.

Zitat von: Feinfinger am 23 Juli 2020, 08:00:48
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
Zitat von: papa am 23 Juli 2020, 08:10:39
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!


ZitatDas 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
Zitat 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?

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
Zitat von: papa am 26 Mai 2020, 19:55:21
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
Zitat 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.
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
Zitat von: tndx am 02 August 2020, 14:08:47
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
Zitat 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)

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
Zitat 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.

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
Zitat 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.

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
Zitat 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?


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
Zitat von: Steffih276 am 20 September 2020, 22:42:05
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
Zitat 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

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
Zitat von: rvideobaer am 19 November 2020, 21:54:49
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.hex
aufzurufen.
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
Zitat von: papa am 30 November 2020, 16:46:36
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
Zitat von: papa am 04 Dezember 2020, 13:28:22
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
Zitat von: Tom Major am 04 Dezember 2020, 23:59:49
@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
Zitat von: papa am 28 Dezember 2020, 12:00:00
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
Zitat von: Tom Major am 28 Dezember 2020, 14:21:42
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
Zitat von: papa am 28 Dezember 2020, 19:33:03
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
Zitat von: Fillip am 02 Januar 2021, 20:32:47
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.
Zitat von: Fillip am 02 Januar 2021, 20:32:47
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
Zitat 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...
Hm - das ist komisch. Es müsste zumindest der Bootloader 7x blinken.
Zitat von: Fillip am 02 Januar 2021, 22:28:21
@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_BOOTLOADER
in Sketch ?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 03 Januar 2021, 12:37:11
Zitat von: papa am 03 Januar 2021, 00:03:54
Hast Du auch ein
#define USE_OTA_BOOTLOADER
in 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 RHS3
sowiwe
#define SENS3_PIN 0
Und wähle dann in der maketota den RHS-2 aus...?

Was meinst Du mit
Zitat von: papa am 03 Januar 2021, 17:33:57
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
Zitat von: Tom Major am 28 Dezember 2020, 23:57:35
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
Zitat von: Fillip am 04 Januar 2021, 01:01:44
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
Zitat von: papa am 04 Januar 2021, 22:43:10
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
Zitat von: Tom Major am 04 Januar 2021, 23:00:09
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).
Zitat von: Tom Major am 04 Januar 2021, 23:00:09
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
Zitat von: papa am 04 Januar 2021, 23:06:29
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
Zitat von: papa am 04 Januar 2021, 22:39:12
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
Zitat 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...  :-\

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
Zitat von: Tom Major am 04 Januar 2021, 23:12:03
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.
Zitat 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.

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
Zitat von: eki am 04 August 2021, 11:46:21
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
Zitat von: eki am 04 August 2021, 11:46:21
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
Zitat 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

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
ZitatEdit: 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
Zitat von: Prof. Dr. Peter Henning am 05 August 2021, 15:20:18
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
Zitat von: papa am 05 August 2021, 20:35:45
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
Zitat 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?
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.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Maxel am 06 August 2021, 18:01:55
Hallo,

ich habe mir die Bodenplatte mit der Abdeckung an diesen Fenstergriff angepasst. Dazu die Antenne versenkt und die Drehscheibe vergrößert und das Vierkantloch auf 7 mm reduziert und die  Bohrung für den Magneten Ø2mm nach außen gerückt, damit der Sensor ihn sicher erfasst.

Gruß Maxel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Esjay am 06 August 2021, 22:05:13
Zitat 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.

Wo hast du die übrigen Bauteile noch bestellt?

Da kommt ja noch ein bisschen was drauf.

Grüße
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Flole am 07 August 2021, 01:01:51
Hallo,

ich habe mir nun auch mal den ersten zusammengelötet. Funktioniert (natürlich) nicht. Ich habe zuerst die Hex-Datei aus dem Github-Repo genommen und dann mit der html Datei angepasst, das ganze dann geflasht. Ergebnis: Rote LED Blinkt 7 mal, dann leuchten beide LEDs, ich drücke "config" und die grüne LED leuchtet dauer. Nächster Versuch um eine leere Batterie auszuschließen war ein 3V Labornetzteil: Selbes Ergebnis.

Also habe ich mir gedacht kompiliere ich es selbst, dort ein ähnliches Ergebnis nur das grün und rot blinken während des pairing-versuchs. Funktionieren tut es aber in keinem Fall, auch wenn ich die Geräte direkt an die Zentrale halte (da sollte eigentlich immer noch irgendein Signal rüberkommen, auch wenn die Antenne total verstimmt ist).

Auf der seriellen Schnittstelle kommt (in beiden Fällen) sowas schönes raus:
<\n>
AskSin OTA Bootloader V0.7.0<\n>
<\n>
Start App<\n>
As???k?<2>???r??(?]<22>?7?&?? 0????4?JC?????ss???ce'???-?NfHh<\r><1>i?ZWj<\n>
C(??rsZ?K?1?C??K??a?^C!???? 1?j<\n>
P,W???? C?,??Ms?C?<- 0<20>???86?0??S<21>A2????00??<2>?1 (<2>?? 0<2>?<18>? ????1?? de?+??e<\r>? p?Y??d<\r>? ?Y???ed??<K?<\n>
<1>02??<2>?? C?<21><5>I 0?????102???<2>?*?4&??<2>34?9 ?<19>?? 3?39?6??<2>?? 0???<2>?-?ML&??<\r>?


Gibt es irgendwo eine Übersicht über die LED "blinkcodes"? Was möchte es mir sagen? Warum kommt auf der UART plötzlich nur Blödsinn?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 07 August 2021, 09:05:18
Das ist schon eigenartig - der Bootloader startet korrekt. Aber dannach kommt nur noch Schrott.
So richtig erklären kann ich mir das nicht. Das HEX aus dem Repository funktioniert auf jeden Fall.

Hast Du die Platine selbst bestückt oder komplett fertigen lassen ?
Wie hast Du das HEX geflasht.
Welche Arduino Version/Einstellungen hast Du verwendet?
Kannst Du mal ein Bild vom AVR machen - vielleicht ist das ein falscher.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: KurtK am 07 August 2021, 09:36:58
Zitat von: Esjay am 06 August 2021, 22:05:13
Wo hast du die übrigen Bauteile noch bestellt?

Da kommt ja noch ein bisschen was drauf.

Grüße

Ich hab meine übrigen Teile alle bei Aliexpress bestellt. Ab 5€ Bestellwert bieten die mittlerweile auch einen kombinierten Versand an, sprich man bekommt nicht mehr jeden kleinen Umschlag von jedem Händler einzeln geschickt, sondern alles gesammelt in einem Paket. Lieferzeit war ca. 2 Wochen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Esjay am 07 August 2021, 10:10:01
Zitat von: KurtK am 07 August 2021, 09:36:58
Ich hab meine übrigen Teile alle bei Aliexpress bestellt. Ab 5€ Bestellwert bieten die mittlerweile auch einen kombinierten Versand an, sprich man bekommt nicht mehr jeden kleinen Umschlag von jedem Händler einzeln geschickt, sondern alles gesammelt in einem Paket. Lieferzeit war ca. 2 Wochen.

Wäre es möglich eine Liste der Links zusammen zu stellen?

Grüße
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: KurtK am 07 August 2021, 10:33:30
Habe auf die schnelle mal eben die Bestellung rasugesucht. Gebe aber keine Garantie auf Richtigkeit oder Qualität, da ich die Platinen noch nicht zuende bestückt habe.
(Kurzer Nachtrag: Habe die erste Platine gebaut und alle Bauteile funktionieren. Nur bei den Funkmodulen musste ich vorher den FrequenzSketch laufen lassen.)

Batteriehalter:
https://de.aliexpress.com/item/4000274412260.html (https://de.aliexpress.com/item/4000274412260.html)

LEDs:
https://de.aliexpress.com/item/32288211535.html (https://de.aliexpress.com/item/32288211535.html)

Hall-Sensoren:
https://de.aliexpress.com/item/4001321271460.html (https://de.aliexpress.com/item/4001321271460.html)

Widerstand 1MOhm:
https://de.aliexpress.com/item/32858225842.html (https://de.aliexpress.com/item/32858225842.html)

CC1101:
https://de.aliexpress.com/item/32630602112.html (https://de.aliexpress.com/item/32630602112.html)

Kondensatoren 10nF, 9pF, 10 pF :
https://de.aliexpress.com/item/32964553793.html (https://de.aliexpress.com/item/32964553793.html)

Taster:
https://de.aliexpress.com/item/32698846968.html (https://de.aliexpress.com/item/32698846968.html)

Bei der Steckerleiste habe ich leider nicht aufgepasst und diese in 2x5 2,54mm anstatt 2mm bestellt. Hier habe ich über die Bucht schnell welche nachbestellt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Flole am 07 August 2021, 13:27:10
Zitat von: papa am 07 August 2021, 09:05:18
Hast Du die Platine selbst bestückt oder komplett fertigen lassen ?
Selbst bestückt
Zitat von: papa am 07 August 2021, 09:05:18
Wie hast Du das HEX geflasht.
Mit einem STK-500 Programmiergerät, auch das verifizieren habe ich genutzt und es wurde genau das geflasht was geflasht werden sollte (oder zumindest wurde das zurückgelesen was geflasht werden sollte)
Zitat von: papa am 07 August 2021, 09:05:18
Welche Arduino Version/Einstellungen hast Du verwendet?
Für das flashen habe ich avrdude verwendet, wenn das mit dem fertigen hex-File Funktioniert dann bekomme ich den Rest auch irgendwie hin, daran sollte es nicht scheitern.... Nur habe ich da genau dasselbe Problem
Zitat von: papa am 07 August 2021, 09:05:18
Kannst Du mal ein Bild vom AVR machen - vielleicht ist das ein falscher.
Man kann das Label auf Bildern nicht erkennen. Hab aber das Label mal abgetippt:
ZitatMega328P
U-TH
Die letzten beiden Zeilen konnte ich nicht entziffern, dürfte aber auch nicht so wichtig sein.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Flole am 07 August 2021, 16:52:21
Kleines Update: Die voreingestellte Baud-Rate ist wohl nicht ganz optimal. Da gibt es immerhin 3.5% Fehlerrate, das ist viel zu viel bei längeren Nachrichten. 19200 funktioniert besser, da sehe ich jetzt auch was. Man könnte auch noch doppelt so schnell werden, alles andere ist aber meiner Meinung nach nicht sinnvoll weil die Fehlerrate zu hoch wird. Nun werde ich mal schauen was beim Pairing passiert und warum das nicht will.

Der Start (mit Pairing-Versuch) sieht so aus:
AskSin++ v5.0.0 (Aug  7 2021 16:50:36)<\r><\n>
Address Space: 32 - 93<\r><\n>
CC init1<\r><\n>
CC Version: 14<\r><\n>
- ready<\r><\n>
Pins: 110<\r><\n>
Activate Cycle Msg<\r><\n>
<- 0F 01 86 10 FFFFFF 000000 06 01 C8 00 00 1A  - 2635<\r><\n>
debounce<\r><\n>
pressed<\r><\n>
released<\r><\n>
<- 1A 02 84 00 FFFFFF 000000 10 FF FF FF FF FF FF FF FF FF FF FF FF 80 01 01 00  - 4513<\r><\n>
<\r><\n>


Kleiner Nachtrag: Frequenztest laufen lassen, funktioniert alles jetzt. Nun kann ich mich um das kleine extra was ich integriert habe kümmern: Ein DS18B20 Temperaturfühler. Mal schauen wie ich den am besten in die Software integriert bekomme.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: KurtK am 09 August 2021, 12:01:46
Zitat von: papa am 05 August 2021, 21:53:19
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.
Habe bei myAVR mal nachgefragt. Das von dir verlinkte Kit hat leider auch 2,54mm Rastermaß auf beiden Seiten.

Musste eh noch bei Aliexpress bestellen, sodass ich mir dort jetzt passende Stecker bestellt habe und mir ein Kabel zusammenbaue. Wenn jemand noch Interesse an einem Kabel von 2*5 2mm auf 2*5 2,54mm hat, für Ersattung der Versandkosten kann ich noch ein paar Kabel bauen, da es die Stecker nur als 10er Pack gab.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Flole am 10 August 2021, 17:14:25
Ich habe nun versucht ein neuen Parameter für das Sendeintervall des Temperaturfühlers angelegt und dafür das Reg0 so verändert:


#ifdef RHS3
  DEFREGISTER(Reg0,DREG_CYCLICINFOMSG,MASTERID_REGS,DREG_TRANSMITTRYMAX,DREG_SABOTAGEMSG,DREG_LOWBATLIMIT, 0x21, 0x22)
#else
  DEFREGISTER(Reg0,DREG_CYCLICINFOMSG,MASTERID_REGS,DREG_TRANSMITTRYMAX,DREG_SABOTAGEMSG, 0x21, 0x22)
#endif
class RHSList0 : public RegList0<Reg0> {
public:
  RHSList0(uint16_t addr) : RegList0<Reg0>(addr) {}
  bool Sendeintervall(uint16_t value) const {
      return this->writeRegister(0x21, (value >> 8) & 0xff) && this->writeRegister(0x22, value & 0xff);
  }
  uint16_t Sendeintervall() const {
      return (this->readRegister(0x21, 0) << 8) + this->readRegister(0x22, 0);
  }
  void defaults () {
    clear();
    cycleInfoMsg(true);
    transmitDevTryMax(6);
    sabotageMsg(true);
#ifdef RHS3
    lowBatLimit(22); // default low bat 2.2V
#endif
    Sendeintervall(3600);
  }
};


Muss ich nun die Klasse TLEPosition kopieren und hier measure und interval anpassen sodass interval das oben angegebene Sendeintervall zurückgibt und measure dann misst? Aber wo kann ich denn dann den gemessenen Wert an die Zentrale senden? Und wie muss ich meine zweite TLEPosition Klasse denn dann "einbinden" sodass sie auch referenziert bzw. benutzt wird?

Insgesamt scheint es irgendwie wenig bis gar keine Dokumentation dazu zu geben wie die Library benutzt werden soll/muss, oder ich habe die noch nicht gefunden.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 10 August 2021, 21:16:21
Nur ne kurze Antwort - weil keine Zeit.

Doku ist schlecht - siehe oben

Wenn Du neue Register in ein Gerät einführen willst, muss auch das entsprechende Gerät im Addin für FHEM angepasst werden. Das ist aber auch nicht dokumentiert - bevor Du fragst ;-) Sollte aber aus dem existierenden Sachen zu sehen sein. Du solltest bei Änderungen dann ein neues Gerät mit eigener HMID anlegen.

Welches Sendeinterval willst Du eigentlich anpassen ? Der Fensterkontakt sendet doch immer bei Änderung bzw. alle 20 Stunden den aktuellen Status.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Flole am 10 August 2021, 21:36:15
Das Addin anpassen ist easy, kein Problem.

Ich habe einen DS18B20 Temperaturfühler zusätzlich eingebaut, der muss natürlich ausgelesen und gesendet werden (ich weiß, Addin wieder anpassen um die Datenpunkte zu bekommen ;) ). Das Interval in dem das passiert wollte ich konfigurierbar machen, dafür das Sendeintervall.
Was ich jetzt nicht sehe/verstehe: Wie mache ich nun eine Klasse um den DS18B20 auszulesen bzw. binde die ein? Ich dachte daran die TLEPosition zu kopieren, measure() misst dann die Temperatur (und speichert die wo genau hin?) und interval() gibt das oben eingestellte Interval zurück.

Nur wenn ich jetzt die Klasse kopiere und sie temperatureSensor nenne, wie integriere ich das dann hier wo die TLEPosition referenziert wird (oder wo muss das eigentlich hin?):
  typedef StateGenericChannel<TLEPosition,HALTYPE,List0Type,List1Type,List4Type,PEERCOUNT> BaseChannel;

Einfach die Klasse kopieren und umbenennen wird wohl kaum ausreichend sein, das muss doch irgendwo noch angegeben werden das es die auch noch gibt. Oder nehme ich dafür einfach die aktuelle measure-Methode, erweitere die und gebe anstelle von 0 beim interval() mein gewünschtes interval zurück? Aber auch da die Frage/das Problem: Wo muss die Temperatur hin geschrieben werden sodass sie auch übermittelt wird?

Alternativ gibt es ja schon das hier, aber auch das zu integrieren ist wohl nicht einfacher: https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor-Blitz/Arduino/HB-UNI-Sensor-Blitz/Sens_DS18X20.h
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 10 August 2021, 21:54:39
Quick and dirty ....

Du tauscht die Batteriesensor-Implementierung gegen das Auslesen des TempSensors - Methode current()

https://github.com/pa-pa/HB-Sec-RHS-3/blob/53a1b1d96bb82608659d733a3342fa49a77e5fc7/Sketch/HB-SEC-RHS-3/HB-SEC-RHS-3.ino#L81

Dann änderst Du das Sendeinterval für die zyklischen Nachrrichten im Template

https://github.com/pa-pa/AskSinPP/blob/711842f791a5365f8a928596fca4ab7af4155dd8/ContactState.h#L202


Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Flole am 10 August 2021, 22:27:15
Dann verliere ich ja die Batteriespannung, nicht gut ;)

Das später nochmal bei 25 Sensoren zu ändern und die Firmware dann OTA zu korrigieren ist bestimmt auch alles andere als lustig. Ist es denn so kompliziert da eben einen neuen Datenpunkt zu erzeugen, oder gar einfach noch einen neuen Channel? Kann ich nicht gleichzeitig den ThreePinChannel und einen WeatherChannel irgendwie haben? Das ThreeStateDevice hat doch auch einen ChannelCount parameter, nur wie kriege ich den zweiten channel da rein? Dem kann ich ja nur einen ChannelType übergeben.....

Oder aber wenn ich sowieso einen dirty-fix mache: Im trigger vom EventSender in der ContactState.h die Temperatur auslesen und noch appenden und das interval dann einfach im TLEPosition zurückgeben?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tom Major am 10 August 2021, 23:52:40
Eventuell hilft msg.append(), um extra Daten anzuhängen.
Das nutze ich hier beim custom Wassermelder für die Batt.spannung, die das Original-Gerät HM-Sec-WDS-2 nicht hat:
https://github.com/TomMajor/SmartHome/blob/master/HB-Sec-WDS-2/Arduino/HB-Sec-WDS-2/HB-Sec-WDS-2.ino#L89 (https://github.com/TomMajor/SmartHome/blob/master/HB-Sec-WDS-2/Arduino/HB-Sec-WDS-2/HB-Sec-WDS-2.ino#L89)
Also in measure() die Temp. holen, an die msg appenden und natürlich das AddOn für die geänderte Msg. anpassen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 11 August 2021, 09:24:22
Zitat von: Flole am 10 August 2021, 22:27:15
Dann verliere ich ja die Batteriespannung, nicht gut ;)

Das später nochmal bei 25 Sensoren zu ändern und die Firmware dann OTA zu korrigieren ist bestimmt auch alles andere als lustig. Ist es denn so kompliziert da eben einen neuen Datenpunkt zu erzeugen, oder gar einfach noch einen neuen Channel? Kann ich nicht gleichzeitig den ThreePinChannel und einen WeatherChannel irgendwie haben? Das ThreeStateDevice hat doch auch einen ChannelCount parameter, nur wie kriege ich den zweiten channel da rein? Dem kann ich ja nur einen ChannelType übergeben.....
Für unterschiedliche Channel brauchst Du ein VirtBaseChannel - da ist an alles virtual und kann unterschiedlich implementiert werden - braucht aber auch mehr Speicher.

https://github.com/pa-pa/AskSinPP/blob/711842f791a5365f8a928596fca4ab7af4155dd8/Channel.h#L361

Am besten Du schaust Dir mal den HB-SW2-SENS an - da sind 2 SwitchChannel und ein StateChannel.

https://github.com/pa-pa/AskSinPP/blob/711842f791a5365f8a928596fca4ab7af4155dd8/examples/custom/HB-SW2-SENS/HB-SW2-SENS.ino#L76

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Flole am 11 August 2021, 15:14:48
Speicher habe ich genug, habe das jetzt mal ausprobiert und sehe im Prinzip nur 2 Probleme (erstmal ;) ):

Im WeatherChannel muss ich irgendwie an dev kommen, aktuell habe ich es so gemacht aber muss es noch initialisieren, wo/wie mache ich das?

class WeatherChannel : public Channel<Hal, WeatherList1, EmptyList, List4, PEERS_PER_CHANNEL, RHSList0>, public Alarm {

    WeatherEventMsg msg;
    int16_t         temp;
    uint16_t        millis;
    WeatherChannel& dev;
    ::OneWire       _oneWire;

public:
    WeatherChannel() : Channel(), Alarm(5), temp(0), millis(0), _oneWire(0) {}
    virtual ~WeatherChannel() {}


    // here we do the measurement
    void measure() {
        DPRINT("Measure...\n");

        _oneWire.reset();
        _oneWire.write(0xCC);    // Select entire BUS
        _oneWire.write(0x44);    // start conversion, use ds.write(0x44,1) with parasite power on at the end

        for(int i = 0; i < 800; i++)
            delayMicroseconds(1000);

        _oneWire.reset();
        _oneWire.write(0xCC);    // Select entire BUS
        _oneWire.write(0xBE);    // Read Scratchpad

        uint8_t data[9];
        for (uint8_t i = 0; i < 9; i++) {    // we need 9 bytes
            data[i] = _oneWire.read();
        }

        if (OneWire::crc8(data, 8) == data[8]) {
            int16_t raw = (data[1] << 8) | data[0];

            if ((raw * 10) / 16 != 850) {
                temp = (raw * 10) / 16;
                DPRINT("T = " + String(temp) + "\n");
            }
            else {
                DPRINT("T INVALID!\n");
            }
        } else {
            DPRINT("DS CRC INVALID!\n");
        }

    }

    virtual void trigger(__attribute__((unused)) AlarmClock& clock) {
        uint8_t msgcnt = device().nextcount();
        // reactivate for next measure
        tick = delay();
        clock.add(*this);
        measure();
        msg.init(msgcnt, temp);
        if (msgcnt % 20 == 1) device().sendPeerEvent(msg, *this); else device().broadcastEvent(msg, *this);
    }

    uint32_t delay() {
        uint16_t _txMindelay = 180;
        _txMindelay = dev.getList1().Sendeintervall();
        if (_txMindelay == 0) _txMindelay = 180;
        return seconds2ticks(_txMindelay);
    }

    void init(int pin) {
        _oneWire.begin(pin);
    }

    void setup(Device<Hal, RHSList0>* dev, uint8_t number, uint16_t addr) {
        Channel::setup(dev, number, addr);
        sysclock.add(*this);
    }

    uint8_t status() const {
        return 0;
    }

    uint8_t flags() const {
        return 0;
    }
};

Vermutlich muss ich sowas ähnliches tun wie

    WeatherChannel(WeatherChannel& d) : Channel(), Alarm(5), temp(0), millis(0), dev(d), _oneWire(0) {}

aber so bekomme ich

Channel.h: 410:18: error: no matching function for call to 'WeatherChannel::WeatherChannel()
   VirtChannel () {}
HB-SEC-RHS-3.ino:246: note  candidate  WeatherChannel  WeatherChannel(WeatherChannel&)
     WeatherChannel(WeatherChannel& d) *: Channel(), Alarm(5), temp(0), millis(0), dev(d), _oneWire(0) {}
   ^~~~~~~~~~~~~~
HB-SEC-RHS-3.ino:246: note    candidate expects 1 argument, 0 provided


Warum ist im configChanged der cycleInfoMsg-Teil auskommentiert?
virtual void configChanged() {
        if ( /*this->getList0().cycleInfoMsg() ==*/ true) {
            DPRINTLN("Activate Cycle Msg");
            sysclock.cancel(cycle);
            cycle.set(CYCLETIME);
            sysclock.add(cycle);
        }
        else {
            DPRINTLN("Deactivate Cycle Msg");
            sysclock.cancel(cycle);
        }
    }

Sieht soweit doch eigentlich richtig aus und als ob das sinnvoll wäre das mit reinzunehmen? Und muss ich von dem configChanged aus noch irgendwas tun um ein eventuell geändertes Sendeintervall von meinem WeatherChannel zu übernehmen? Oder das configChanged vom RHSType dort integrieren falls sich das auf die RHSList0 bezieht?
Im RHSType ist auch ein

    TSDevice::configChanged();

mit drin, sollte ich das auch mit reinnehmen als

        DeviceType::configChanged();
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 11 August 2021, 21:47:37
Mach mal nen neuest Thema auf. Das ist hier doch sehr speziell.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Flole am 11 August 2021, 22:23:51
Hab ich, eine gute Idee. Falls irgendwer mal darüber stolpert und den anderen Thread sucht: https://forum.fhem.de/index.php/topic,122450.0.html
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: KurtK am 12 August 2021, 10:47:18
Hat jemand ne STL-Datei für den Magnethalter und 1,6mm Platinendicke?

In der FreeCad Datei für den Small ist leider kein Magnethalter drin und der in der großen Version skaliert sich nicht automatisch mit, sobald man die Platinendicke auf 1,6mm ändert. (Wurde ein paar Seiten vorher auch schonmal angemerkt)

Hab zum Testen den aus dem Repository genommen, der ist aber auch nur für 1mm Dicke und hat keinen Spacer nach oben. Daher hab ich mir schon die erste Leiterbahn beim testen zerkratzt.

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Maxel am 12 August 2021, 18:24:47
Ich habe den Magnethalter oberhalb der Platine plaziert. Darunter war für mich zu wenig Platz. Die Bodenplatte habe seitlich höher geführt. Damit passt die 1,6mm starke Platine gut rein. Die Magnetplatte steckt dann zwischen Platine und Griff.

Gruß Maxel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: KurtK am 13 August 2021, 14:09:34
Habe den Magnethalter jetzt so gelassen und eine 1mm dicke Abdeckung gedruckt, die zwischen Platine und Griff liegt. Funktioniert bis jetzt problemlos.

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Steffih276 am 15 August 2021, 23:05:17
Hallo zusammen,

ich möchte mich nun auch endlich mal an dieses Projekt ranwagen, nachdem ich das im letzten Jahr noch etwas auf die lange Bank schieben musste...

Es hat in der Zwischenzeit ja sehr viele Infos gegeben, daher versuche ich einfach mal zusammenzufassen, ob ich richtig starten würde.

Gerber Files nehme ich von hier: https://github.com/pa-pa/HB-Sec-RHS-3/tree/master/gerber_small
Und lasse bei JLCPCB fertig und die Unterseite direkt bestücken.

Anschließend brauche ich noch die Teile aus diesem Posting: https://forum.fhem.de/index.php/topic,109786.msg1169512.html#msg1169512

Sind die SMD Bauteile auch für mich als komplett ungeübte SMD-Löterin machbar? Ich kann bisher nur nicht-SMD Bauteile löten.

Im Erdgeschoss würde ich auch gerne einen Glasbruchmelder mit anschließen. Gibt es dafür Empfehlungen, welchen ich kaufe sollte?

Passt das so, oder habe ich noch etwas wesentliches vergessen / übersehen?

Schöne Grüße
Steffi
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: KurtK am 16 August 2021, 08:55:17
Hallo Steffi,
das klingt alles erstmal gut. Die 2*1mm Magneten sind noch nicht in der Liste.

An das SMD löten habe ich mich auch im Rahmen dieses Projektes das erste mal rangewagt. Mit einer passend dünnen Lötspitze und einer guten Pinzette ist das aber machbar.

Zum Aufspielen des Bootloaders brauchst du noch einen ISP Programmer (USBasp oder Diamex).
Hier würde ich den Diamex vorziehen, da er echte 3,3V liefert (VCC und SPI) und so das Funkmodul auch schon eingelötet werden kann.
Ist hier auch nochmal beschrieben https://asksinpp.de/Grundlagen/04-isp.html#anschluss-des-isp (https://asksinpp.de/Grundlagen/04-isp.html#anschluss-des-isp)
Jenachdem ob du den Standard Bootloader flasht ist dann auch noch ein FTDI-Programmer notwendig. Dies kann man aber umgehen indem der OTA Bootloader verwendet wird.

Viele Grüße
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 16 August 2021, 10:43:00
Zitat von: Steffih276 am 15 August 2021, 23:05:17
Im Erdgeschoss würde ich auch gerne einen Glasbruchmelder mit anschließen. Gibt es dafür Empfehlungen, welchen ich kaufe sollte?
Der Glasbruchsensor ist nur als Anschluss vorhanden. Die Software unterstützt das bisher nicht.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: eki am 16 August 2021, 10:58:53
Ich habe nun ein geflashtes Modul (schmale Version, nur 2 TLEs) und das Ganze scheint auch erst mal zu starten (rote LED blinkt 7 mal, danach rot und grün danach grün).

Mit dem Seriellen Monitor bekomme ich folgendes:


Start App
AskSin++ v5.0.0 (Aug 13 2021 17:01:32)
Address Space: 32 - 102
CC init1
CC Version: 14
- ready
Pins: 110
Activate Cycle Msg
<- 0E 01 86 10 808E18 000000 06 01 C8 00 00  - 3151
debounce
pressed
released
<- 1A 02 84 00 808E18 000000 22 00 C3 47 49 49 37 32 35 36 34 31 39 80 01 01 00  - 6928


Danach kommt im Monitor nichts mehr. Wenn ich den config button drücke, blinken rot und grün eine Zeitlang, an der CCU kommt aber nichts an. Im Monitor ist dabei auch nichts zu sehen.
Wenn ich den Magneten in die Nähe der TLEs bringe bzw. wieder wegnehme, dann leuchtet die grüne LED auch.

Irgendwelche Tips woran es liegen könnte?

Edit: Beim Drücken des Configbuttons ist doch noch etwas zu sehen, habe die Ausgabe noch mal angepasst.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 16 August 2021, 21:08:28
Ich tippe mal auf ein mangelhaftes Funkmodul.
Hilfe gibt es hier https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html#ermittlung-der-cc1101-frequenz
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: eki am 17 August 2021, 09:01:25
Danke für den Tip, genau das war's. Nach Frequenzkorrektur läuft jetzt alles. Super Sache.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: eki am 17 August 2021, 10:48:35
Noch 'ne blöde Frage, bei mir wurde da ein CUL_HM Device mit model HM-SEC-RHS-2 per autocreate direkt angelegt, obwohl ich das AskSin FHEM Addon gar nicht installiert hatte. Wozu brauche ich das dann? Nur für die ...RHS-3 Variante?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 17 August 2021, 20:10:04
Zitat von: eki am 17 August 2021, 10:48:35
Noch 'ne blöde Frage, bei mir wurde da ein CUL_HM Device mit model HM-SEC-RHS-2 per autocreate direkt angelegt, obwohl ich das AskSin FHEM Addon gar nicht installiert hatte. Wozu brauche ich das dann? Nur für die ...RHS-3 Variante?

ja
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Maxel am 09 September 2021, 17:41:06
Hallo

ich stelle mal meine STLs für einen ovalen Fenstergriff zur Verfügung.

Gruß

Maxel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: eki am 11 September 2021, 12:23:57
Ich habe ein komisches Verhalten, das ich mir nicht so recht erklären kann.

Ich habe, wie oben schon beschrieben, einen Sensor als HM-SEC-RHS-2 geflashed. Er kann in FHEM gepairt werden und meldet nach dem Einschalten auch brav den Status. Wenn ich allerdings den Magneten verschiebe, dann erfolgt, obwohl die Änderung erkannt wird (grüne LED blinkt und im Monitor wird eine Pin Änderung gemeldet), keine Meldung an FHEM (zumindest tut sich nichts an den Readings, erst wenn ich ein Reset auslöse wird der neue Status berichtet). Irgendeine Idee, was da falsch sein könnte?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 11 September 2021, 15:03:57
Kannst Du mal die Ausgaben der seriellen Konsole hier reinstellen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: eki am 11 September 2021, 18:13:01

18:11:16.688 ->
18:11:16.688 ->
18:11:16.688 -> AskSin OTA Bootloader V0.7.0
18:11:16.688 ->
18:11:17.038 -> Start App
18:11:17.085 -> AskSin++ v5.0.0 (Sep 11 2021 14:10:38)
18:11:17.085 -> Address Space: 32 - 102
18:11:17.085 -> CC init1
18:11:17.085 -> CC Version: 14
18:11:17.132 ->  - ready
18:11:17.132 -> Config Freq: 0x216652
18:11:17.132 -> Pins: 110
18:11:17.132 -> Activate Cycle Msg
18:11:20.130 -> <- 0E 01 A2 10 808E18 EC0042 06 01 C8 00 00  - 3149
18:11:20.168 -> -> 0F 03 86 10 3155C8 000000 0A A9 07 0A 00 00  - 3155
18:11:20.268 -> -> 0A 01 80 02 EC0042 808E18 00  - 3289
18:11:20.315 -> waitAck: 01
18:11:29.945 -> ignore 0F 34 86 10 5EA79E 000000 0A A8 FB 0E 00 00  - 13168
18:11:29.998 -> Pins: 010
18:11:32.603 -> Pins: 110
18:11:36.397 -> Pins: 100
18:11:39.424 -> Pins: 110
18:11:41.731 -> Pins: 100
18:11:41.731 -> Pins: 110
18:11:41.731 -> Pins: 100
18:11:41.731 -> Pins: 110
18:11:41.731 -> Pins: 100
18:11:41.731 -> Pins: 110
18:11:41.778 -> Pins: 100
18:11:41.778 -> Pins: 110
18:11:41.778 -> Pins: 100
18:11:41.778 -> Pins: 110
18:11:43.181 -> Pins: 010
18:11:47.348 -> Pins: 110
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 11 September 2021, 21:29:08
Ich würde mal sagen, dass da ein TLE ständig umschaltet. Check doch mal die Lötstellen der TLEs bze. wechsele diese mal aus.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: eki am 11 September 2021, 22:08:27
Nee, das war ich, ich habe mit dem Magneten ständig rum gewackelt, um zu zeigen, dass die TLEs die Aktivität erkennen. Aber, wie gesagt, die Änderungen kommen nicht bei FHEM an, es sei denn, man macht einen Reset.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: eki am 12 September 2021, 13:38:29
Noch ein Zusatzhinweis: Das einzig spezielle bei dem Teil ist, dass ich da zwischenzeitlich mal ein komplett Reset gemacht hatte (langer Druck auf die config Taste). Danach habe ich dann wieder die Fuses gesetzt, die Frequenz angepasst und den Sketch mit HM-SEC-RHS-2 aufgespielt (der gleiche Sketch läuft mit einer anderen Platine einwandfrei).
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Esjay am 13 September 2021, 16:19:39
Hallo zusammen, kurze Frage zum Gateway. Funktioniert ein Cul im HM Modus, oder muss man sich ne CCU besorgen?

LG
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 13 September 2021, 16:36:33
Zitat von: eki am 12 September 2021, 13:38:29
Noch ein Zusatzhinweis: Das einzig spezielle bei dem Teil ist, dass ich da zwischenzeitlich mal ein komplett Reset gemacht hatte (langer Druck auf die config Taste). Danach habe ich dann wieder die Fuses gesetzt, die Frequenz angepasst und den Sketch mit HM-SEC-RHS-2 aufgespielt (der gleiche Sketch läuft mit einer anderen Platine einwandfrei).

Hm - wie ist der SENS3_PIN konfiguriert ? Wenn nur die beiden TLE am Griff genutzt werden, muss er auf 0 definiert sein. Sonst muss für Closed auch der 3. TLE an der Seite durch einen Magneten geschlossen sein.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 13 September 2021, 16:37:12
Zitat von: Esjay am 13 September 2021, 16:19:39
Hallo zusammen, kurze Frage zum Gateway. Funktioniert ein Cul im HM Modus, oder muss man sich ne CCU besorgen?
CUL geht - ist ein "normales" HM-Gerät.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: eki am 13 September 2021, 19:30:24
Zitat von: papa am 13 September 2021, 16:36:33
Hm - wie ist der SENS3_PIN konfiguriert ? Wenn nur die beiden TLE am Griff genutzt werden, muss er auf 0 definiert sein. Sonst muss für Closed auch der 3. TLE an der Seite durch einen Magneten geschlossen sein.

Der SENS3_PIN ist auf 0. Es funktioniert ja auch mit anderen Platinen mit dem selben Sketch einwandfrei.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 13 September 2021, 20:34:07
Dann check mal was bei der EventDelayTime
https://github.com/pa-pa/AskSinPP/blob/62faa59d718c23e3831a6ddfa93401a89e272200/ContactState.h#L112
rauskommt. Vielleicht ist ja da ein Problem mit dem Flashwerten.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 28 September 2021, 21:37:00
Hallo!
Ich habe eine Verständnis-Frage zum flashen meiner schmalen Variante des HB-Sec-RHS-3.
Da meine Funkmodule etwas zickig waren, hatte ich mal testweise den FreqTest-Sketch aufgespielt und dann erst den HB-SEC-RHS-3-Sketch aufgespielt,
danach konnte ich sie problemlos (an einer Raspberrymatic) anlernen. 

Nun brauche ich nur noch eine Version wo der SENS_3 PIN abgeschaltet ist.
Ich hab also im Arduino IDE im HB-SEC-RHS-3 Sketch folgendes aktiviert/geändert:

#define RHS3
#define USE_OTA_BOOTLOADER (Damit er die FreqTest Daten liest)
#define SENS3_PIN 0


und bekomme 2 Dateien (HB-SEC-RHS-3.ino.with_bootloader.eightanaloginputs.hex und HB-SEC-RHS-3.ino.eightanaloginputs.hex).
Leider kann ich mit keiner der beiden den Sensor anlernen.
Er blinkt brav 7x bei Einlegen der Batterie und bei der 2. Version (ohne Bootloader) geht der Sensor imho auch in den Anlern-Modus, taucht aber nicht in der Raspberrymatic auf.

Ich habe folgendermaßen geflasht:

1. Fuses:
avrdude -p m328p -P COM3 -c stk500v2 -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m

2. Testscript zum Frequenz ins Eprom schreiben
avrdude -p m328p -P COM3 -c stk500v2 -U flash:w:FreqTest.ino.with_bootloader.eightanaloginputs.hex
und laufen lassen bis es nicht mehr blinkt.

3. Hex-File mit Bootloader erstellen über makeota.html

4. Datei Flashen über Diamex ISP Programmer
c:\WinAVR-20100110\bin>avrdude -p m328p -P COM8 -c stk500v2 -U flash:w:ASKS234501.hex


Was mache ich falsch? Ich hatte gedacht, dass ich in Schritt 3+4 die Datei ohne Bootloader nehmen muss, ist das richtig?
Oder fehlt noch was?

Danke für einen Hinweis,

Grüße
Sven
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 28 September 2021, 22:13:44
Zitat von: zentis666 am 28 September 2021, 21:37:00
Was mache ich falsch? Ich hatte gedacht, dass ich in Schritt 3+4 die Datei ohne Bootloader nehmen muss, ist das richtig?
Oder fehlt noch was?
Was wurde den in der makeota.html eingetragen.
Ohne Bootloader ist richtig, da ja der OTA-Bootloader dran soll.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 29 September 2021, 07:24:32
Hi papa,

Zitat von: papa am 28 September 2021, 22:13:44
Was wurde den in der makeota.html eingetragen.
Ohne Bootloader ist richtig, da ja der OTA-Bootloader dran soll.

hier meine Einstellungen:

MCU Type: ATmega328
Device Model F209
HM ID + HM Serial: über "Random" Button erzeugt
CC1101 Frequence Settings: leer
Config String 0
und halt das komplierte Firmware-File ohne Bootloader als OTA Firmware ausgewählt


Grüße
Sven
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 29 September 2021, 07:50:26
Sieht eigentlich gut aus.

Kannst Du bitte mal die Ausgaben auf der seriellen Schnittstelle mitschneiden ?
Das Add-On von Jerome https://github.com/jp112sdl/JP-HB-Devices-addon ist installiert ?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 29 September 2021, 07:59:34
Zitat von: papa am 29 September 2021, 07:50:26
Sieht eigentlich gut aus.

Kannst Du bitte mal die Ausgaben auf der seriellen Schnittstelle mitschneiden ?
Das Add-On von Jerome https://github.com/jp112sdl/JP-HB-Devices-addon ist installiert ?

Mit der seriellen Schnittstelle kämpfe ich noch... bekomme nichts angezeigt im seriellen Monitor der Arduino-IDE Software...
Hab schon alle möglichen Baudraten probiert. Gibt es irgendwo eine Übersicht wie genau ich das einstellen muss?

Das Addon ist drauf, ich hab auch schon einen breiten Fensterdrehgriff-Kontakt problemlos mit Raspberrymatic am laufen,
da hatte ich allerdings die Platine fertig geflasht im Markplatz gekauft...

Grüße
Sven
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: eki am 30 September 2021, 16:23:27
Hast Du TX und RX vertauscht?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 30 September 2021, 18:12:38
Zitat von: eki am 30 September 2021, 16:23:27
Hast Du TX und RX vertauscht?
Guter Hinweis.
Ich hab die Platine am DIAMEX Programmer gelassen, da ist zum Flashen nur MISO, MOSI, Reset, SCK, VCC und GND angeschlossen...
Muss ich die RX und TX wohl noch anschließen.
Werd ich mal probieren...
Grüße
Sven
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 30 September 2021, 18:18:38
DIAMEX ist kein serielles Programmiergerät.

Da brauchst du etwas in dieser Art...

https://www.ebay.de/itm/FTDI-Adapter-USB-zu-Serial-TTL-FT232RL-Chip-3-3V-und-5V-Arduino-/283843902902?mkcid=16&mkevt=1&_trksid=p2349624.m46890.l49286&mkrid=707-127634-2357-0 (https://www.ebay.de/itm/FTDI-Adapter-USB-zu-Serial-TTL-FT232RL-Chip-3-3V-und-5V-Arduino-/283843902902?mkcid=16&mkevt=1&_trksid=p2349624.m46890.l49286&mkrid=707-127634-2357-0)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 30 September 2021, 18:24:50
Zitat von: Feinfinger am 30 September 2021, 18:18:38
DIAMEX ist kein serielles Programmiergerät.

Da brauchst du etwas in dieser Art...

https://www.ebay.de/itm/FTDI-Adapter-USB-zu-Serial-TTL-FT232RL-Chip-3-3V-und-5V-Arduino-/283843902902?mkcid=16&mkevt=1&_trksid=p2349624.m46890.l49286&mkrid=707-127634-2357-0 (https://www.ebay.de/itm/FTDI-Adapter-USB-zu-Serial-TTL-FT232RL-Chip-3-3V-und-5V-Arduino-/283843902902?mkcid=16&mkevt=1&_trksid=p2349624.m46890.l49286&mkrid=707-127634-2357-0)

Danke, so einen Adapter hab ich da, werd ihn mal anschließen. Dass der DIAMEX nur zum Flashen taugt hatte ich übersehen.

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 30 September 2021, 18:29:05
Mit dem DIAMEX kannst du programmieren, den Bootloader schreiben und Fuses setzten.

Mit dem FTDI kannst du direkt aus der Arduino IDE den Sketch auf den ,,Atmega" schreiben und am seriellen Monitor verfolgen, was nach erfolgreichem schreiben passiert.

Dann erklärt sich vieles von selbst.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 01 Oktober 2021, 12:06:38
Hallo,

ich bräuchte mal eure Hilfe. Hab jetzt soweit alles zusammengelötet, funzt auch soweit alles. Am Anfang ein paar Probleme gehabt bezüglich der Frequenz, dann mit der Frequenzkorrektur scheint jetzt alles in Ordnung zu sein. Log nach dem Start sieht so aus:

AskSin OTA Bootloader V0.7.0

Start App
AskSin++ v5.0.0 (Sep 30 2021 20:57:07)
Address Space: 32 - 103
CC init1
CC Version: 04
- ready
Config Freq: 0x2165EA
Pins: 110
Activate Cycle Msg
<- 0F 01 86 10 00A100 000000 06 01 C8 00 00 18  - 2861


Hab bei mir debmatic in der aktuellen Version am Laufen, da ist ja das Plugin "JP HB Devices" schon installiert.

Wenn ich jetzt in der CCU auf "HM Gerät anlernen" gehe läuft ja hier die Zeit von 60 Sek. runter. Drücke ich nun den "Config"-Taster auf der Platine gehen beide LED´s an, die rote blinkt dann einmal während die grüne leuchtet, dann gehen beide wieder aus. Folgendes habe ich im Log:

debounce
pressed
released
<- 1A 05 84 00 00A100 000000 10 F2 09 52 48 53 33 30 30 41 31 30 30 80 01 01 00  - 59869

-> 10 01 A0 01 73AFEC 00A100 00 05 00 00 00 00 00  - 60051
<- 0A 01 80 02 00A100 73AFEC 00  - 60325
-> 10 01 A0 01 73AFEC 00A100 00 05 00 00 00 00 00  - 60598
<- 0A 01 80 02 00A100 73AFEC 00  - 60866


Leider habe ich aber kein Device in der CCU, hab es mehrmals probiert, kein Erfolg.

Hat da von euch jemand noch eine Idee?

Gruß Markus

P.S.: Hab eben nochmal das Log von debmatic umgestellt und angeschaut, hier steht beim Anlernversuch der Eintrag:

Oct  1 21:18:03 debian rfd: Peering with RHS300A101 failed

Also sendet ja der RHS3 korrekt an die CCU.

Hab echt keine Idee mehr.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 03 Oktober 2021, 08:58:24
Von euch keiner eine Idee zu meinem oben genannten Problem?

Eventuell könnt ihr mir aber sagen ob die Daten des Serial-Logs soweit richtig aussehen und vor allem der Bereich indem ich den Sensor an die CCU anlernen möchte:

debounce
pressed
released
<- 1A 05 84 00 00A100 000000 10 F2 09 52 48 53 33 30 30 41 31 30 30 80 01 01 00  - 59869

-> 10 01 A0 01 73AFEC 00A100 00 05 00 00 00 00 00  - 60051
<- 0A 01 80 02 00A100 73AFEC 00  - 60325
-> 10 01 A0 01 73AFEC 00A100 00 05 00 00 00 00 00  - 60598
<- 0A 01 80 02 00A100 73AFEC 00  - 60866


Mercy schonmal.

Gruß Markus
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 03 Oktober 2021, 09:06:50
Sieht eigentlich soweit ganz gut aus - vielleicht AES deaktivieren.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 03 Oktober 2021, 09:59:13
Wo kann ich denn AES deaktivieren, geht das irgendwo global? Da sich der Sensor ja nicht anlegt in der CCU kann ich ja dort den Haken für AES nicht entfernen.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: frank am 03 Oktober 2021, 10:40:23
ist der ccu die antwortzeit (274ms) vom sensor vielleicht zu lang, da sie den cmd wiederholt?
-> 10 01 A0 01 73AFEC 00A100 00 05 00 00 00 00 00  - 60051
<- 0A 01 80 02 00A100 73AFEC 00  - 60325
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 03 Oktober 2021, 11:51:34
Gute Frage, dazu kenne ich mich diesbezüglich nicht gut genug aus.

Als Info mal bei mir läuft das Ganze auf einem QNAP-NAS in einer Debian 11 VM in Version 3.59.6.73, als Funkmodul habe ich ein HM-MOD-RPI-PCB in Kombination mit der HB-RF-ETH Platine.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: frank am 03 Oktober 2021, 12:24:36
die 274ms werden ja eigentlich nur im sensor erzeugt.
vom sensor bis in die ccu vergeht dann nochmal zeit.

die frage wäre zunächst, ob bei anderen ebenfalls ähnliche antwortzeiten im sensor entstehen.
ich habe diese sensoren nicht.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 03 Oktober 2021, 13:22:38
Das müsste papa recht gut beurteilen können. Da ich zur Zeit nur diese Geräte habe ich da leider keine Referenz.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 03 Oktober 2021, 15:52:07
Zitat von: papa am 29 September 2021, 07:50:26
Sieht eigentlich gut aus.

Kannst Du bitte mal die Ausgaben auf der seriellen Schnittstelle mitschneiden ?

Hat etwas gedauert aber nun bekomme ich folgende Ausgabe (egal ob ich die hex-Datei aus dem Github oder meine eigene aus Arduino IDE nehme):

AskSin OTA Bootloader V0.7.0
Start App
AskSin++ v5.0.0 (Oct  3 2021 13:18:10)
Address Space: 32 - 103
CAFEA99E
Init Storage: CAFEA54F
CC init1
Error at 00 expected: 2E read: 0E
Error at 02 expected: 06 read: 02
Error at 03 expected: 0D read: 04
Error at 04 expected: E9 read: 00
Error at 05 expected: CA read: 00
Error at 07 expected: 0C read: 00
Error at 0B expected: 06 read: 00
Error at 0D expected: 21 read: 00
Error at 0E expected: 65 read: 00
Error at 0F expected: 6A read: 00
Error at 10 expected: C8 read: 00
Error at 11 expected: 93 read: 00
Error at 12 expected: 03 read: 00
Error at 15 expected: 34 read: 00
Error at 17 expected: 03 read: 00
Error at 18 expected: 18 read: 00
Error at 19 expected: 16 read: 00
Error at 1B expected: 43 read: 00
Error at 1E expected: 2F read: 00
Error at 1F expected: 65 read: 00
Error at 20 expected: 78 read: 00
Error at 23 expected: E9 read: 00
Error at 24 expected: 2A read: 00
Error at 25 expected: 1F read: 00
Error at 26 expected: 11 read: 00
Error at 3E expected: 03 read: 00
CC Version: 00
Error at 3E expected: C0 read: 00
- ready
Pins: 110
Activate Cycle Msg
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tom Major am 03 Oktober 2021, 23:24:25
Zitat von: zentis666 am 03 Oktober 2021, 15:52:07
Hat etwas gedauert aber nun bekomme ich folgende Ausgabe (egal ob ich die hex-Datei aus dem Github oder meine eigene aus Arduino IDE nehme):

AskSin OTA Bootloader V0.7.0
Start App
AskSin++ v5.0.0 (Oct  3 2021 13:18:10)
Address Space: 32 - 103
CAFEA99E
Init Storage: CAFEA54F
CC init1
Error at 00 expected: 2E read: 0E
Error at 02 expected: 06 read: 02


der CC1101 ist vom AVR nicht korrekt erreichbar. Prüf mal alle Verbindungen zwischen AVR und CC sowie auf Kurzschluss gegeneinander.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 04 Oktober 2021, 18:35:02
Zitat von: Tom Major am 03 Oktober 2021, 23:24:25
der CC1101 ist vom AVR nicht korrekt erreichbar. Prüf mal alle Verbindungen zwischen AVR und CC sowie auf Kurzschluss gegeneinander.

Ich hab alle Kontakte nachgelötet und auf Kurzschluss überprüft, scheint als war das ein Problem denn nun bin ich ein bisschen weiter:
wenn ich Config drücke blinken beide LEDs zur Bestätigung, es taucht aber kein neues Gerät in der CCU auf, hier die Ausgabe

AskSin OTA Bootloader V0.7.0

Start App
AskSin++ v5.0.0 (Oct  3 2021 13:18:10)
Address Space: 32 - 103
CC init1

CC Version: 14

- ready

Config Freq: 0x2165F2

Pins: 110

Activate Cycle Msg

<- 0F 01 86 10 40002C 000000 06 01 C8 00 00 21  - 3641

ignore 0F E1 86 10 21DDD3 000000 0A 60 CE 0E 00 00  - 4081

ignore 0C 64 86 70 1E6090 000000 00 CA 3E  - 7921

debounce

pressed

released

<- 1A 02 84 00 40002C 000000 10 F2 09 54 43 47 37 32 31 34 32 34 38 80 01 01 00  - 12013

-> 10 01 A0 01 4F607A 40002C 00 05 00 00 00 00 00  - 12247

<- 0A 01 80 02 40002C 4F607A 00  - 12515

-> 10 01 A0 01 4F607A 40002C 00 05 00 00 00 00 00  - 12849

<- 0A 01 80 02 40002C 4F607A 00  - 13125

ignore 0C 51 86 70 1E679F 000000 00 C7 42  - 23394

ignore 0C 5D 86 5A 6876D2 000000 A8 D4 3A  - 25706


Das JP HB Devices Plugin ist (in Version 5.6) installiert, es läuft wie gesagt schon ein anderer HB-Sec-RHS-3 Sensor,
was kann  es noch sein? AES?

@meier81: haben wir das gleiche Problem?

Grüße
Sven
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: frank am 04 Oktober 2021, 19:27:33
Zitathaben wir das gleiche Problem
die funkmessages sehen zumindest identisch aus.
auch bei dir ergibt sich eine sehr lange antwortzeit von etwa 270ms.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: frank am 04 Oktober 2021, 19:31:30
blöde idee: arbeiten eure prozessoren vielleicht langsamer?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 04 Oktober 2021, 19:53:54
Zitat von: frank am 04 Oktober 2021, 19:31:30
blöde idee: arbeiten eure prozessoren vielleicht langsamer?

Kann man das irgendwie auslesen?
Also auf meinem steht leider nichts drauf, hatte die Platine bestücken lassen...

Ich hab jetzt folgendes probiert, alles ohne Erfolg:

1. AES im Sketch hinzugefügt:
#define USE_AES
#define HM_DEF_KEY 0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x0d,0x0e,0x0f,0x10
#define HM_DEF_KEY_INDEX 0

2. zusätzlich zu 1 noch meinen AES-Key als Hex als Default-Key eingetragen
(dachte ist einen Versuch wert ;-)

3. zusätzlich zu 2 noch
#define USE_OTA_BOOTLOADER_FREQUENCY
mal testweise im Sketch hinzugefügt

Nach Schritt 3 sieht die Ausgabe folgendermaßen aus:
AskSin OTA Bootloader V0.7.0
Start App
AskSin++ v5.0.0 (Oct  4 2021 19:29:22)

Address Space: 32 - 120

CC init1

Boot Loader Freq: 0x216550
CC Version: 14

- ready

Config Freq: 0x2165F2

Pins: 110

Activate Cycle Msg

<- 0F 01 A2 10 90FB7B 4F607A 06 01 C8 00 00 21  - 1564
waitAck: 00

<- 0F 01 A2 10 90FB7B 4F607A 06 01 C8 00 00 21  - 2459

waitAck: 00
<- 0F 01 A2 10 90FB7B 4F607A 06 01 C8 00 00 21  - 3354
waitAck: 00

<- 0F 01 A2 10 90FB7B 4F607A 06 01 C8 00 00 21  - 4251

waitAck: 00

<- 0F 01 A2 10 90FB7B 4F607A 06 01 C8 00 00 21  - 5144

waitAck: 00

<- 0F 01 A2 10 90FB7B 4F607A 06 01 C8 00 00 21  - 6039

waitAck: 00

ignore 0C 6E 84 70 4E7BEA 000000 00 E0 38  - 11794

debounce

pressed

released

<- 1A 02 80 00 90FB7B 4F607A 10 F2 09 44 41 4B 37 30 32 37 31 38 37 80 01 01 00  - 15101
-> 10 01 A0 01 4F607A 90FB7B 00 05 00 00 00 00 00  - 15339
<- 0A 01 80 02 90FB7B 4F607A 00  - 15609

-> 10 01 A0 01 4F607A 90FB7B 00 05 00 00 00 00 00  - 15673

<- 0A 01 80 02 90FB7B 4F607A 00  - 15951

ignore 0F C8 86 10 21DDBA 000000 0A 98 CC 0D 00 00  - 16087

ignore 0F 26 86 10 21DDA7 000000 0A 68 C0 09 00 00  - 22945

ignore 0C 87 86 70 202934 000000 00 D2 3E  - 34529


Gehe ich recht in der Annahme, dass ich mir
#define USE_OTA_BOOTLOADER_FREQUENCY
sparen kann?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 Oktober 2021, 20:41:22
Könnt ihr bitte mal die fertige Firmware aus dem Git flashen. Viellicht hat sich ja ein Problem in die Lib eingeschlichen.
Und bitte nochmal einen RESET (mindistens 6 Sekunden den COnfigTaster drücken) machen. Manchmal ist auch irgendwas im Flash nicht ganz richtig.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 04 Oktober 2021, 21:24:35
Hallo euch allen,

papa, der Tipp war schonmal Gold wert. Das vorgefertigte Image aus GIT geflashed, erstmal ohne Reset probiert anzulernen, hat auf Anhieb funktioniert  ;D

Hier mal das Log dazu:

AskSin OTA Bootloader V0.7.0

Start App
AskSin++ V4.1.3 (May  1 2020 21:49:02)
Address Space: 32 - 120
CC init1
CC Version: 04
- ready
Config Freq: 0x2165EA
Pins: 110
Activate Cycle Msg
<- 0F 01 86 10 43F74F 000000 06 01 C8 00 00 31  - 3969
debounce
pressed
released
<- 1A 02 84 00 43F74F 000000 10 F2 09 4D 52 4A 31 34 38 36 31 35 39 80 01 01 00  - 15095

-> 10 01 A0 01 73AFEC 43F74F 00 05 00 00 00 00 00  - 15280
<- 11 01 A0 02 43F74F 73AFEC 04 99 A0 66 C1 7B 29 00  - 15288
-> 19 01 A0 03 73AFEC 43F74F DF 1C BD DA 64 2D 5A 53 13 B1 74 7E FA 5F 8A BF  - 15564
Signature OK
<- 0E 01 80 02 43F74F 73AFEC 00 6F F9 7F 08  - 15611
-> 13 0A A0 01 73AFEC 43F74F 00 08 02 01 0A 73 0B AF 0C EC  - 15650
<- 11 0A A0 02 43F74F 73AFEC 04 55 7F 44 9B AD 1B 00  - 15659
-> 19 0A A0 03 73AFEC 43F74F DE F9 53 DC 58 C0 6D BB 52 DE 6C F7 7B 5F EC D1  - 15933
Signature OK
<- 0E 0A 80 02 43F74F 73AFEC 00 E9 A4 2D 93  - 15990
-> 0B 13 A0 01 73AFEC 43F74F 00 06  - 16019
Activate Cycle Msg
<- 0A 13 82 02 43F74F 73AFEC 00  - 16146
-> 10 1C A0 01 73AFEC 43F74F 00 04 00 00 00 00 00  - 16183
<- 1A 1C 80 10 43F74F 73AFEC 02 09 01 0A 73 0B AF 0C EC 14 06 10 01 12 16 00 00  - 16324
-> 10 25 A0 01 73AFEC 43F74F 01 04 00 00 00 00 01  - 16357
<- 14 25 80 10 43F74F 73AFEC 02 08 01 20 6C 21 00 22 64 00 00  - 16496
-> 10 2E A0 01 73AFEC 43F74F 01 05 00 00 00 00 01  - 16531
<- 11 2E A0 02 43F74F 73AFEC 04 B2 11 8E F8 5A 95 00  - 16541
-> 19 2E A0 03 73AFEC 43F74F 0F 73 78 50 C2 27 7A B9 32 E8 C9 59 59 D1 35 5B  - 16814
Signature OK
<- 0E 2E 80 02 43F74F 73AFEC 00 97 2B C5 8F  - 16861
-> 0D 37 A0 01 73AFEC 43F74F 01 08 08 00  - 16891
<- 11 37 A0 02 43F74F 73AFEC 04 83 87 43 68 5E 41 00  - 16902
-> 19 37 A0 03 73AFEC 43F74F 24 73 52 51 CF CD 7B BC C5 A6 FA CF 2B 3E D2 CE  - 17174
Signature OK
<- 0E 37 80 02 43F74F 73AFEC 00 8E AA BB F8  - 17223
-> 0B 40 A0 01 73AFEC 43F74F 01 06  - 17254
<- 0A 40 82 02 43F74F 73AFEC 00  - 17375
-> 0B 49 A0 01 73AFEC 43F74F 01 03  - 17405
<- 0E 49 80 10 43F74F 73AFEC 01 00 00 00 00  - 17530
Pins: 100


Jetzt ist halt die Frage wo es klemmt, werde auch nochmal verschiedene Versionen der Asksinn-Bibliothek probieren um zu versuchen den Fehler einzugrenzen. Bräuchte nämlich die Version mit SENS3_PIN 0

Gruß Markus
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 04 Oktober 2021, 22:25:07
Nur noch kurz als Info von mir, ich arbeite mit PlatfomIO, dort sind folgende Libs installiert:

AskSinPP in V5.0.0
EnableInterrupt in V1.1.0
Low-Power in V1.6

Als Sketch habe ich HB-Sec-RHS-3-master auf dem GIT benutzt. Habe eben auch gesehen es ist unter Beispiele in der AskSinPP-master auch der RHS-Sketch dabei, der sieht etwas anders aus, evtl. probiere ich es mit dem nochmal zum testen.

Gibt es die Möglichkeit da die Libs zu aktualisieren, die zieht er sich ja normalerweise aus dem Internet. Da wäre ja die EnableInterrupt aktuell, die Low-Power gibt es mittlerweile ja in V1.8 und die AskSinPP ist zwar auch aktuell V5.0.0, die ist ja aber schon vom 14. Januar.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 05 Oktober 2021, 11:07:17
Also funktioniert die Hardware schon mal.
Kannst Du mal die angehängte Firmware probieren. Ist für OTA übersetzt. Wenn die geht, dann müssen wir mal rauskriegen, warum Deine nicht geht.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 05 Oktober 2021, 20:13:55
Zitat von: papa am 05 Oktober 2021, 11:07:17
Also funktioniert die Hardware schon mal.
Kannst Du mal die angehängte Firmware probieren. Ist für OTA übersetzt. Wenn die geht, dann müssen wir mal rauskriegen, warum Deine nicht geht.

Hallo papa,

die funktioniert auch einwandfrei. Habe jetzt auch ein paar neue Erkenntnisse bezüglich der AskSin Bibliothek. Hatte am Anfang das GitHub Archiv heruntergeladen, entpackt, bei unter Dokumente abgelegt und den Ordner über PlatformIO geöffnet. Beim kompilieren lädt er sich ja dann die 3 benötigen Bibliotheken automatisch herunter und speichert die ja im Sketch-Unterordner \.pio\libdeps\pro8MHzatmega328\
Die Dateien dieser AskSinPP-Bibliothek haben alle das Datum 14.01.2021. Dort wurde die aktuelle V5.0.0 veröffentlicht (siehe Screenshot).

Gehe ich jetzt hin und lösche den Inhalt des AskSinPP-Ordners und kopiere dort die aktuelle GitHub-Library hinein, funktioniert der Sketch auch einwandfrei und ich kann meine Sensoren anlernen.

Irgendwas ist hier anscheinend mit der "alten" Bibliothek nicht ganz in Ordnung.

Könnte man hier nicht hingehen und z.B. den jetzigen Stand als V5.1.0 veröffentlichen, dann kann man ja einfach die Bibliothek in PlatformIO updaten und man hat einen aktuellen, funktionierenden Stand.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 05 Oktober 2021, 20:40:09
Ja - die Aktualisierung steht schon lange auf meiner TODO-Liste. Aber dann kommt immer was dazwischen. Außerdem gab es letztens ein paar größere Änderungen - da wollte ich sicher gehen, dass sich keine Fehler eingeschlichen haben.
Aber schön, dass es nun geht.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 05 Oktober 2021, 21:26:45
Zitat von: meier81 am 05 Oktober 2021, 20:13:55
die funktioniert auch einwandfrei. Habe jetzt auch ein paar neue Erkenntnisse bezüglich der AskSin Bibliothek. Hatte am Anfang das GitHub Archiv heruntergeladen, entpackt, bei unter Dokumente abgelegt und den Ordner über PlatformIO geöffnet. Beim kompilieren lädt er sich ja dann die 3 benötigen Bibliotheken automatisch herunter und speichert die ja im Sketch-Unterordner \.pio\libdeps\pro8MHzatmega328\
Die Dateien dieser AskSinPP-Bibliothek haben alle das Datum 14.01.2021. Dort wurde die aktuelle V5.0.0 veröffentlicht (siehe Screenshot).

Gehe ich jetzt hin und lösche den Inhalt des AskSinPP-Ordners und kopiere dort die aktuelle GitHub-Library hinein, funktioniert der Sketch auch einwandfrei und ich kann meine Sensoren anlernen.

Irgendwas ist hier anscheinend mit der "alten" Bibliothek nicht ganz in Ordnung.

Danke, das war es bei mir auch, ich hatte die AskSIN V5.0.0 über den Manager im Arduino IDE installiert (zip hatte eine Fehlermeldung gebracht) und nachdem ich die Dateien händisch gegen die GitHub Dateien getauscht habe wird mein Sensor auch brav angelernt.

Vielen Dank Euch beiden!

Grüße
Sven
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 05 Oktober 2021, 21:39:48
Freut mich, dann hat sich das bei dir ja auch erledigt  ;)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 05 Oktober 2021, 21:43:36
Mal ne Frage, was nutzt ihr denn als Antennendraht? Kupferader, starr 1mm² isoliert?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 05 Oktober 2021, 22:07:30
Zitat von: meier81 am 05 Oktober 2021, 21:43:36
Mal ne Frage, was nutzt ihr denn als Antennendraht? Kupferader, starr 1mm² isoliert?

Was gerade da ist, ich hab einfach Kupferlitze genommen, 0,4mm² ist das meistens aber ich hab auch schon dickere genommen... gerne "Reststücke".
Hat bisher immer seinen Zweck erfüllt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 06 Oktober 2021, 08:24:51
Ich hab noch eine Frage zum Thema Frequenzen:

Wenn ich den Sketch zusätzlich mit
#define USE_OTA_BOOTLOADER_FREQUENCY
kompiliere, bekomme ich bei meinem ersten Sensor in der Ausgabe:

Config Freq: 0x2165F2
und
Boot Loader Freq: 0x216550


Ohne "USE_OTA_BOOTLOADER_FREQUENCY" das steht nur
Config Freq: 0x2165F2

Wie muss ich das denn machen damit er die Daten, welche der FreqTest Sketch schreibt auch nutzt?
Muss USE_OTA_BOOTLOADER_FREQUENCY mit angegeben werden oder nicht?
Ich hab das jetzt drin und der Sensor läuft mit meiner Raspberrymatic, bevor ich jetzt 20 weitere Sensoren fertigstelle will ich das nur nochmal verifizieren...

Grüße
Sven
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 06 Oktober 2021, 08:56:03
Also es kommt drauf an, welches Frequenzsetting Du nutzen willst.
Der FreqTest-Sketch schreibt den Wert in den EEProm und dieser wird dann bei der Initializierung verwendet.
Wenn Du aber den OTA-Bootloader verwendest und die Frequenz nicht stimmt, kannst Du natürlich auch kein OTA-Update machen. Deshalb kann man in der makeota.html auch die korregierte Frequenz angeben. Diese wird dann auch schon vom OTA-Bootloader richtig eingestellt. Der Sketch könnte dann natürlich diese auch gleich benutzen. Dafür ist dann das USE_OTA_BOOTLOADER_FREQUENCY Flag.
Im Prinzip musst Du, wenn die Funkmodule nicht ordentlich gehen, die Frequenz auch im OTA-Bootloader setzen. Sonst macht dieser keinen Sinn. Dann einfach USE_OTA_BOOTLOADER_FREQUENCY und gut :-)
Wenn Du im Bootloader keine Frequenz gestezt hast, sollte USE_OTA_BOOTLOADER_FREQUENCY nicht gesetzt sein.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 06 Oktober 2021, 17:10:11
Wo habt ihr denn den define USE_OTA_BOOTLOADER_FREQUENCY her, der steht doch gar nicht Standard im Sketch?

Gibt es irgendwo einen Sketch bzw. eine Übersicht aller Parameter mit ihrer Bedeutung?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 06 Oktober 2021, 18:38:15
Zitat von: meier81 am 06 Oktober 2021, 17:10:11
Wo habt ihr denn den define USE_OTA_BOOTLOADER_FREQUENCY her, der steht doch gar nicht Standard im Sketch?

Gibt es irgendwo einen Sketch bzw. eine Übersicht aller Parameter mit ihrer Bedeutung?

Hatte ich bei der Suche nach den AES Parametern gefunden:
https://github.com/pa-pa/AskSinPP#extra-defines-for-configuration (https://github.com/pa-pa/AskSinPP#extra-defines-for-configuration)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 06 Oktober 2021, 18:55:19
Zitat von: papa am 06 Oktober 2021, 08:56:03
Also es kommt drauf an, welches Frequenzsetting Du nutzen willst.
Der FreqTest-Sketch schreibt den Wert in den EEProm und dieser wird dann bei der Initializierung verwendet.
Wenn Du aber den OTA-Bootloader verwendest und die Frequenz nicht stimmt, kannst Du natürlich auch kein OTA-Update machen. Deshalb kann man in der makeota.html auch die korregierte Frequenz angeben. Diese wird dann auch schon vom OTA-Bootloader richtig eingestellt. Der Sketch könnte dann natürlich diese auch gleich benutzen. Dafür ist dann das USE_OTA_BOOTLOADER_FREQUENCY Flag.
Im Prinzip musst Du, wenn die Funkmodule nicht ordentlich gehen, die Frequenz auch im OTA-Bootloader setzen. Sonst macht dieser keinen Sinn. Dann einfach USE_OTA_BOOTLOADER_FREQUENCY und gut :-)
Wenn Du im Bootloader keine Frequenz gestezt hast, sollte USE_OTA_BOOTLOADER_FREQUENCY nicht gesetzt sein.

Ok danke, dann müsste ich also wenn ich Funkprobleme hätte mit dem Frequenz-Test Sketch die beste Frequenz rausfinden und mitloggen,
diese dann nochmal in den Bootloader schreiben und dann wäre der OTA-Bootloader perfekt vorbereitet.

Nachdem der HB-Sec-RHS-3 Sketch nun mit meinen Funkmodulen auch mit Standard-Frequenzeinstellungen läuft
(hatte es reinkompiliert aber keinen Parameter gesetzt, da hat er ja die default Werte genommen und der Empfang war gut),
brauche ich die Frequenzanpassung anscheinend doch nicht, die ersten 5 Sensoren laufen auch so.

Spart etwas an Aufwand, falls doch noch Probleme auftauchen werd ich das dann probieren.

Grüße
Sven
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 06 Oktober 2021, 22:57:49
Zitat von: zentis666 am 06 Oktober 2021, 18:38:15
Hatte ich bei der Suche nach den AES Parametern gefunden:
https://github.com/pa-pa/AskSinPP#extra-defines-for-configuration (https://github.com/pa-pa/AskSinPP#extra-defines-for-configuration)

Schande über mein Haupt, ich habe auf der readme-Seite echt nicht weiter nach unten gescrollt, war immer nur oben bei den Dateien  :o

Aber mercy für die Info.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 10 Oktober 2021, 17:46:08
Hallo euch allen,

hat von euch schon jemand Probleme gehabt bezüglich den Magneten, hab meine erste Fuhre aus Fern-Ost bestellt, habe nun bei 2 von 5 Platinen das Problem das die oberen TLE´s nicht schalten, funktionieren tun sie wenn ich den Magnet neben dran halte, im eingebauten Zustand wollen wie gesagt zwei aber nicht.

Hab jetzt mal folgende bestellt

Zitat von: papa am 03 Mai 2020, 16:04:27
Ich habe diese hier: https://www.amazon.de/First4magnets-F321-50-Neodym-Magneten-Packung-Durchmesser/dp/B007JTKHR6/ref=sr_1_5

bin mal gespannt ob die besser bzw. anders sind.

Ansonsten mal ein dickes Lob an papa, echt super das Projekt, funktioniert echt alles tadellos und die Gehäuse ließen sich auch auf Anhieb drucken (hab die lange Version).

Gruß Markus
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 10 Oktober 2021, 18:17:25
Zitat von: meier81 am 10 Oktober 2021, 17:46:08
hat von euch schon jemand Probleme gehabt bezüglich den Magneten, hab meine erste Fuhre aus Fern-Ost bestellt, habe nun bei 2 von 5 Platinen das Problem das die oberen TLE´s nicht schalten, funktionieren tun sie wenn ich den Magnet neben dran halte, im eingebauten Zustand wollen wie gesagt zwei aber nicht.
Hallo!
Ich habe festgestellt, dass der Magnethalter bei mir etwas Spiel auf dem Vierkant des Fenstergriffs hat. Dadurch ist der Magnet in der oberen Schaltposition leicht "verdreht" und somit nicht ganz korrekt positioniert und schaltet nicht. In der unteren Schaltposition funktioniert es aber komischerweise.

Ich habe zur Abhilfe eine sehr dünne Schicht Heisskleber innen am Vierkant-Loch auf den Magnethalter aufgebracht und solange der Kleber noch etwas flexibel (also noch warm) ist,
den Magnethalter auf den Vierkant des Fenstergriffs aufgesteckt.
Dadurch ist das Spiel weg und der Sensor schaltet auch in der oberen Position.
Das ist mir bei den ersten zwei Sensoren aufgefallen, ich montiere jetzt immer mit Heisskleber und hab keine Probleme diesbezüglich mehr.

Die von Dir verlinkten Magnete hab ich auch.

Grüße
Sven
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 10 Oktober 2021, 18:25:47
Zitat von: zentis666 am 10 Oktober 2021, 18:17:25
Hallo!
Ich habe festgestellt, dass der Magnethalter bei mir etwas Spiel auf dem Vierkant des Fenstergriffs hat. Dadurch ist der Magnet in der oberen Schaltposition leicht "verdreht" und somit nicht ganz korrekt positioniert und schaltet nicht. In der unteren Schaltposition funktioniert es aber komischerweise.

Okay, gut zu wissen, soweit habe ich es noch gar nicht getestet, hatte jetzt hier vor mir alles zusammengebaut und dann mit einem Vierkant das Ganze zum testen immer bewegt. Da habe ich natürlich das Ganze immer "korrekt" gestellt, also immer schön oben mittig oder unten mittig. Wie gesagt habe hier etwas Probleme mit den oberen TLE´s, mal schauen wie es mit den Magneten aus dem Link am Dienstag funzt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 11 Oktober 2021, 20:37:42
Nabend,

kurze Zwischeninfo: Die vorgenannten Magnete von A****n sind tatsächlich um einiges besser, gehen alle vier Sender jetzt einwandfrei. Hat man auch gleich beim auseinandermachen gemerkt den Unterschied zwischen denen und meinen aus China bestellten.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 27 Oktober 2021, 20:10:25
Servus, ich mal wieder.

Hab jetzt hier 5 Sensoren am laufen, alles top soweit. Die nächsten 15 sind schon geordert  ;)

Hab jetzt allerdings ein kleines Problem mit dem OTA updaten. Hab OTA im Sketch definiert, den dann über die html-Datei mit der Seriennummer usw. versehen und die Datei dann geflasht. Das ging ja auch alles, Sensoren ließen sich anlernen.

Jetzt habe ich den Sketch mit einer neuen Versionsnummer versehen und laut Anleitung eine eq3 Datei erstellt, dann das Archiv erstellt und in debmatic hochgeladen, auch alles in Ordnung.

Hab dann mal für einen Sensor auf "Update" geklickt um das zu testen, kam wie beschrieben die Fehlermeldung und er stellt es in die Warteschlange. Hab dann am Sensor auf config gedrückt, dann leuchtet die grüne LED kurz und die rote LED blinkt 4 mal. Dann ist etwas Pause und das Ganze wiederholt sich mehrfach. Der Duty Cycle steigt auf 40-50 an, dann ist erstmal Pause. Wenn ich jetzt z.B. das Fenster öffne beginnt das Ganze von vorne.

Auf jeden Fall läuft das jetzt schon seit gestern Abend so und er ist immer noch nicht fertig mit dem Update, ist das normal oder hab ich hier noch ein Problem irgendwo?

Vielleicht weiß von euch ja da jemand mehr.

Gruß Markus
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 30 Oktober 2021, 11:59:18
So, mal ne kurze Info bezüglich dem OTA-Update: Ich habe dann nach 2 Tagen das Update mal abgebrochen, hat weiterhin nicht funktioniert.

Da jemand ne Idee wo bzw. was ich da noch prüfen könnte?

Gruß Markus
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 30 Oktober 2021, 14:03:56
Bei debmatic bin ich raus - mal im anderen Forum probiert ?

https://homematic-forum.de/forum/viewforum.php?f=76
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 11 November 2021, 11:38:14
Hallo zusammen,

Hat zufällig noch jemand welche von den großen Platinen übrig?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Esjay am 11 November 2021, 13:15:17
Meinst du die lange Version, oder die kurze Breite?

Gruß
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 11 November 2021, 15:15:44
Die kurze breite
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Esjay am 13 November 2021, 11:47:02
Ich hätte nur noch 9 Stück der langen Version über.
Als falls jemand an denen Interesse hat gerne PN.
Atmegaseitig bestückt, alle anderen Bauteile vorhanden.

Grüße
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tobias am 14 November 2021, 11:49:47
Hi,
etwas OT, passt aber hier
Ich habe mir vor ein paar Jahren einen UP 8Fach Fensterkontaktsensor auf Panstamp NRG Basis gebaut, Kann man bis zu 4 Fenster anschließen. Funktioniert so gut das ich jetzt weitere brauche. Dummerweise gibts keine Panstamps mehr und die verwendete SWAP Library funktioniert auschließlich mit Panstamps (da habe ich schon ein paar Tage probiert die Lib auf Arduino zu portieren)

Eine neue Idee geht dahin, jetzt mit der Asksin++ Lib zu arbeiten. Der ThreeStateSensor Sketch passt eigentlich perfekt. Leider aber nur für 3 Sensoren, ich brauche mindestens 4, besser 8. (Pro Fenster braucht man 2 Reed-Kontakte: 1x oben, 1x unten)
Kann man (ich) den Sketch dahingehend erweitern und kann man irgendwo nachlesen wie die Lib funktioniert? Im Netz finde ich nur fertige sketche und Anleitungen wie man diese auf die Arduinos flasht. Leider keine "Einführung" in die Asksin Entwicklung ;)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 14 November 2021, 18:57:49
Hallo Tobias,

da geht sicherlich was.
So wie ich Dich jetzt verstanden habe, willst Du nen Sensor mit 4 ThreeStateChannels machen. Pro Channel hast Du 2 Reedkontake. Der Sketch sollte kein Problem sein. Da dass dann allerdings ein neues Gerät ist, muss auch der FHEM-Addin noch dafür gemacht werden.
Mach doch mal nen neuen Thread dafür auf.

BTW: Ein Einführung in AskSin++ gibt es leider nicht.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Dared am 19 Januar 2022, 10:33:43
Hallo zusammen,

ich habe mich mit dem Thema nun auch etwas auseinander gesetzt und mir mal JLCPCB angeschaut zwecks Bestellung von Platinen (die breite) und gleichzeitiger Bestückung der Rückseite.

Aber entweder ich habe in dem Prozess etwas falsch gemacht, oder die Preise für die ATMEGA sind wirklich in die Höhe geschossen. Der Unit-Preis steht dort aktuell bei 10-29 auf $16.6, was bei 15 Stück dann schon $249 sind.

Mache ich da irgendetwas falsch, oder ist das aktuell wirklich so unbezahlbar?

Gruß
Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 19 Januar 2022, 10:43:04
Willkommen in der Chipkrise. Das sieht derzeit wirklich so schlecht aus.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Dared am 19 Januar 2022, 10:46:18
Danke für die schnelle Antwort, ich habe mir das schon fast gedacht.

Na dann muss es noch eine Zeit lang warten.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 19 Januar 2022, 12:11:45
Da hatte ich ja noch Mitte Oktober Glück, waren zwar auch schon etwas teurer, aber echt noch human im Gegensatz zu heute.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 19 Januar 2022, 12:27:43
Kosten aktuell beim Ali 3,54 € pro Stück.

Hat man ja auch fix selber drauf gelötet.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 19 Januar 2022, 15:07:47
Zitat von: Feinfinger am 19 Januar 2022, 12:27:43
Kosten aktuell beim Ali 3,54 € pro Stück.

Hat man ja auch fix selber drauf gelötet.

Ist aber zusätzlicher Aufwand wenn man die Platine sonst bei JLCPCB fertig bestücken lässt.
Nicht jeder schafft auch die kleinen Teile sauber zu löten.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: gloob am 19 Januar 2022, 15:09:00
Zitat von: papa am 19 Januar 2022, 10:43:04
Willkommen in der Chipkrise. Das sieht derzeit wirklich so schlecht aus.

Gibt es aktuell keine günstige und modernere Alternative zum ATMega?
So nen ESP kostet ja fast weniger und hat mehr Leistung, frisst natürlich auch deutlich mehr Strom als so nen ATMega
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 31 Januar 2022, 17:54:13
Moin, hat zufällig noch funktionierende TLE Sensoren übrig, die er abgeben will? Mein noch vorhandenen Bestand scheint China Ausschuss-Schrott zu sein  ::)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: PeMue am 31 Januar 2022, 17:59:11
Zitat von: Kai-Alfonso am 31 Januar 2022, 17:54:13
Mein noch vorhandenen Bestand scheint China Ausschuss-Schrott zu sein  ::)
Wie hast Du festgestellt, dass die Dinger Schrott sind?

Gruß Peter
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 31 Januar 2022, 18:18:52
Zitat von: PeMue am 31 Januar 2022, 17:59:11
Wie hast Du festgestellt, dass die Dinger Schrott sind?

Gruß Peter

Kommando zurück - grad festgestellt, das es nicht an den TLEs lag, sondern eine Leiterbahn ist defekt - die Reibung hat ihr wohl zugesetzt. Löte ich ein Kabel zwischen R4 und R5, dann geht TLE U1 wieder. Kann man die Leiterbahn dazwischen reparieren.


Wie ich auf TLE=Schrott kam? Ich hab die mal von einem Boardie hier gekauft und er hat danach festgestellt, das die wohl 1:2 Ausschuss sind. Nachdem meine von RS auch aus waren, habe ich die benutzt und tatsächlich ging ungefähr jeder zweite Sensor nur.  Jetzt funktionierte ein Fenster nicht mehr in einer Position - Sensor getauscht und selbst der dritte wollte nicht gehen. War zu sehr auf kaputten Sensor statt kaputte Platine versteift - dabei war es vor meiner Nase und hab es echt nicht gesehen.

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 31 Januar 2022, 20:33:57
Das sieht bei dir aber ganz stark nach Schleifspuren durch das bewegen aus, da hatte sich doch mal was geändert am Gehäuse, bei mir ist echt alles bestens, keinerlei Schleifspuren oder sonstiges. Hab auch nicht weiter modifiziert.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 09 Februar 2022, 21:04:27
Hallo papa,

Zitat von: papa am 16 August 2021, 10:43:00
Der Glasbruchsensor ist nur als Anschluss vorhanden. Die Software unterstützt das bisher nicht.

gibt es schon was neues zum Glasbruchsensor? Ich hab mit einem Freund einen Satz Fenstersensoren für unsere Häuser gebaut und nun haben sie ihm die Balkontür aufgebrochen und wir würden den Sensor gerne nachrüsten.
Die Position direkt am Fenstersensor ist übrigens perfekt, genau da haben sie die Scheibe eingeschlagen und die Tür aufgehebelt >:(

Grüße
Sven
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 09 Februar 2022, 22:09:24
Nein - da ist nichts passiert.
Was relativ einfach gehen sollte, ist den Glasburchsensor-Kontakt als Sabotage-Pin im Sketch zu definieren. Dann sollte sich bei Änderung der Status des Sabotage-Readings ändern.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: zentis666 am 10 Februar 2022, 06:23:36
Zitat von: papa am 09 Februar 2022, 22:09:24
Nein - da ist nichts passiert.
Was relativ einfach gehen sollte, ist den Glasburchsensor-Kontakt als Sabotage-Pin im Sketch zu definieren. Dann sollte sich bei Änderung der Status des Sabotage-Readings ändern.

Ja daran hab ich auch schon gedacht, danke Dir für die Rückmeldung!

Grüße
Sven
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 16 November 2022, 14:56:32
Hey Leute,

hat jemand noch ein paar (teil-)bestückte Platinen der schmalen Version zufällig?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Esjay am 17 November 2022, 10:59:11
Grüß dich,

habe noch diverse Platinen da. Zudem auch alle Teile die noch benötigt werden.

Gerne PN
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tobias am 13 Dezember 2022, 10:10:32
Hi,
ich habe gerade gesehen das der ATMEGA328P-AU bei JLCPCB "nur" noch 3-4€ kostet.
Wenn also eine Sammelbestellung bzgl bestückter Platinen startet, wäre ich dabei :)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 13 Dezember 2022, 13:20:13
Hi Tobias,

bezüglich deiner "Teilnahme" an einer Bestellung, welchen Typ bräuchtest du denn (die längliche?) und wieviel würdest du denn nehmen? Würde nämlich auch noch ein paar benötigen und kann auch gerne das Bestellen übernehmen.

Gruß Markus
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 13 Dezember 2022, 19:46:51
Hi,

ich hab jetzt seit ein paar Tagen an 2 Fenstersensoren das selbe Problem: Ich bekomme immer im State ein RESPONSE TIMEOUT:RegisterRead

Der Sensor selber lief schon recht lange ohne Probleme, Batterien habe ich auch getauscht. Empfangsstärke ist auch ok.  Hab dann den Sensor unpaired, und neu angelernt + getConfig. War alles kein Problem, ich bekomme nur keinen richtigen State mehr. Jemand eine Ahnung, was ich noch tun kann und was der Grund ist?

Anbei das List des Device


define HM_A9B8C7 CUL_HM A9B8C7
attr HM_A9B8C7 .mId F209
attr HM_A9B8C7 IOgrp VCCU:HMUART_OG
attr HM_A9B8C7 autoReadReg 4_reqStatus
attr HM_A9B8C7 expert defReg,allReg,rawReg
attr HM_A9B8C7 firmware 1.0
attr HM_A9B8C7 model unknown
attr HM_A9B8C7 room CUL_HM
attr HM_A9B8C7 serialNr papaa9b8c7
attr HM_A9B8C7 subType no
#   DEF        A9B8C7
#   FUUID      6398c2f5-f33f-ce3b-e95c-724f19d13a148cd6
#   HMUART_EG_MSGCNT 17
#   HMUART_EG_RAWMSG 0500004C0AA241A9B8C70B98D001050019
#   HMUART_EG_RSSI -76
#   HMUART_EG_TIME 2022-12-13 19:45:16
#   HMUART_OG_MSGCNT 30
#   HMUART_OG_RAWMSG 050100260AA241A9B8C70B98D001050019
#   HMUART_OG_RSSI -38
#   HMUART_OG_TIME 2022-12-13 19:45:16
#   IODev      HMUART_OG
#   LASTInputDev HMUART_OG
#   MSGCNT     47
#   NAME       HM_A9B8C7
#   NR         23725
#   NTFY_ORDER 48-HM_A9B8C7
#   STATE      RESPONSE TIMEOUT:RegisterRead
#   TYPE       CUL_HM
#   chanNo     01
#   disableNotifyFn 1
#   eventCount 40
#   lastMsg    No:0A - t:41 s:A9B8C7 d:0B98D0 01050019
#   protCmdDel 1
#   protLastRcv 2022-12-13 19:45:16
#   protRcv    31 last_at:2022-12-13 19:45:16
#   protResnd  4 last_at:2022-12-13 19:31:48
#   protResndFail 1 last_at:2022-12-13 19:31:52
#   protSnd    10 last_at:2022-12-13 19:45:16
#   protState  CMDs_done
#   rssi_at_HMUART_EG cnt:18 min:-77 max:-69 avg:-74.11 lst:-76
#   rssi_at_HMUART_OG cnt:30 min:-51 max:-29 avg:-37.56 lst:-38
#   READINGS:
#     2022-12-13 19:30:05   CommandAccepted yes
#     2022-12-13 19:44:43   D-firmware      1.0
#     2022-12-13 19:44:43   D-serialNr      papaa9b8c7
#     2022-12-13 19:45:16   IODev           HMUART_OG
#     2022-12-13 19:44:48   PairedTo        0x0B98D0
#     2022-12-13 19:30:05   R-pairCentral   0x0B98D0
#     2022-12-13 19:44:48   RegL_00.         00:00 09:01 0A:0B 0B:98 0C:D0 10:01 12:16 14:06
#     2022-12-13 19:44:47   cfgState        updating
#     2022-12-13 19:45:16   commState       CMDs_done
#     2022-12-13 19:29:05   powerOn         2022-12-13 19:29:05
#     2022-12-13 19:29:05   recentStateType info
#     2022-12-13 19:31:53   state           RESPONSE TIMEOUT:RegisterRead
#     2022-12-13 19:29:42   trigDst_broadcast noConfig
#     2022-12-13 19:45:16   trigger_cnt     5
#   helper:
#     HM_CMDNR   10
#     PONtest    0
#     cSnd       010B98D0A9B8C700040000000000,010B98D0A9B8C700040000000000
#     cfgChkResult No regs found for:-ret--ret-HM_A9B8C7 type:no - -ret-list:peer register         :value-ret-   0:      pairCentral      :0x0B98D0-ret-                       -ret-                       -ret-
#     cfgStateUpdt 1
#     lastMsgTm  1670957116.50669
#     mId        no
#     supp_Pair_Rep 0
#     ack:
#     cmds:
#       TmplKey    :no:1670956071.96118
#       TmplTs     1670956071.96118
#       cmdKey     1:1:0::HM_A9B8C7:no:01:
#       cmdLst:
#         clear      (readings|all)
#         getConfig  noArg
#         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
#         peerBulk   -peer1,peer2,...- [({set}|unset)]
#         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
#         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
#         tplDel     -tplDel-
#         tplSet_0   -tplChan-
#         update     noArg
#         virtual    [(1..50;1|{1})]
#       lst:
#         condition  slider,0,1,255
#         peer       
#         peerOpt   
#         tplChan   
#         tplDel     
#         tplPeer   
#       rtrvLst:
#         cmdList    [({short}|long)]
#         deviceInfo [({short}|long)]
#         list       [({normal}|full)]
#         listDevice [({all}|alive|unknown|dead|notAlive)]
#         param      -param-
#         reg        -addr- -list- [-peerChn-]
#         regList    noArg
#         regTable   noArg
#         regVal     -addr- -list- [-peerChn-]
#         saveConfig [-filename-]
#         status     noArg
#         tplInfo    noArg
#     expert:
#       def        1
#       det        1
#       raw        1
#       tpl        0
#     io:
#       flgs       0
#       newChn     +A9B8C7,00,00,00
#       nextSend   1670957116.76281
#       rxt        0
#       vccu       VCCU
#       p:
#         A9B8C7
#         00
#         00
#         00
#       prefIO:
#         HMUART_OG
#     mRssi:
#       mNo        0A
#       io:
#         HMUART_EG:
#           -76
#           -76
#         HMUART_OG:
#           -30
#           -30
#     peerIDsH:
#     prt:
#       bErr       0
#       sProc      0
#       rspWait:
#       tryMsg:
#     q:
#       qReqConf   
#       qReqStat   
#     regCollect:
#     role:
#       chn        1
#       dev        1
#     rpt:
#       IO         HMUART_EG
#       flg        A
#       ts         1670957116.50669
#       ack:
#         HASH(0x8383a10)
#         0A80020B98D0A9B8C700
#     rssi:
#       at_HMUART_EG:
#         avg        -74.1111111111111
#         cnt        18
#         lst        -76
#         max        -69
#         min        -77
#       at_HMUART_OG:
#         avg        -37.5666666666667
#         cnt        30
#         lst        -38
#         max        -29
#         min        -51
#     shadowReg:
#     tmpl:
#   nb:
#     cnt        1
#
setstate HM_A9B8C7 RESPONSE TIMEOUT:RegisterRead
setstate HM_A9B8C7 2022-12-13 19:44:43 .D-devInfo 010100
setstate HM_A9B8C7 2022-12-13 19:44:43 .D-stc 80
setstate HM_A9B8C7 2022-12-13 19:22:50 .associatedWith HM_A9B8C7,HM_A9B8C7
setstate HM_A9B8C7 2022-12-13 19:45:16 .protLastRcv 20221213194516
setstate HM_A9B8C7 2022-12-13 19:30:05 CommandAccepted yes
setstate HM_A9B8C7 2022-12-13 19:44:43 D-firmware 1.0
setstate HM_A9B8C7 2022-12-13 19:44:43 D-serialNr papaa9b8c7
setstate HM_A9B8C7 2022-12-13 19:45:16 IODev HMUART_OG
setstate HM_A9B8C7 2022-12-13 19:44:48 PairedTo 0x0B98D0
setstate HM_A9B8C7 2022-12-13 19:30:05 R-pairCentral 0x0B98D0
setstate HM_A9B8C7 2022-12-13 19:44:48 RegL_00.  00:00 09:01 0A:0B 0B:98 0C:D0 10:01 12:16 14:06
setstate HM_A9B8C7 2022-12-13 19:44:47 cfgState updating
setstate HM_A9B8C7 2022-12-13 19:45:16 commState CMDs_done
setstate HM_A9B8C7 2022-12-13 19:29:05 powerOn 2022-12-13 19:29:05
setstate HM_A9B8C7 2022-12-13 19:29:05 recentStateType info
setstate HM_A9B8C7 2022-12-13 19:31:53 state RESPONSE TIMEOUT:RegisterRead
setstate HM_A9B8C7 2022-12-13 19:29:42 trigDst_broadcast noConfig
setstate HM_A9B8C7 2022-12-13 19:45:16 trigger_cnt 5

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: frank am 13 Dezember 2022, 23:06:12
die attribute model und subtype sind "faul".
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 14 Dezember 2022, 08:20:18
Zitat von: frank am 13 Dezember 2022, 23:06:12
die attribute model und subtype sind "faul".

Das stimmt. Normalerweise werden die ja beim anlegen gesetzt. Das kommt wohl daher, das ich ihn frisch angelegt habe und irgendwie das Attribut nicht gesetzt wurde. Hab jetzt festgestellt, das beim mir kein Fenstersensor mehr geht. Andere HM Komponenten wie Rolladenaktor, Thermostat oder HB Temperatursensor gehen ohne Probleme. Was ist denn da los? Jemand spontan eine Idee bevor ich die Loglevel hochschraube?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 14 Dezember 2022, 09:56:38
Ich hab den Fehler gefunden - irgendwas hat mir bei allen Fenstersensoren das Attribut Model auf ACTIONDETECTOR gesetzt. Kann das durch ein Update gekommen sein? Selber habe ich das nicht gesetzt.

Setze ich Modelforce auf HM-SEC-RHS-2. dann geht es wieder.... :o :o :o

Was war denn da los? Kann sich das jemand erklären?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: frank am 14 Dezember 2022, 10:26:34
ZitatSetze ich Modelforce auf HM-SEC-RHS-2. dann geht es wieder....
das passt aber nicht zu deiner modelID.
Zitatattr HM_A9B8C7 .mId F209

hast du die passende add-on datei installiert?
oder die fw nicht angepasst?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 14 Dezember 2022, 10:57:19
Zitat von: frank am 14 Dezember 2022, 10:26:34
das passt aber nicht zu deiner modelID.
hast du die passende add-on datei installiert?
oder die fw nicht angepasst?


Normalerweise müsste ich das model HM-SEC-RHS-3 nehmen, ist aber im Dropdown von modelForce nicht verfügbar. Deswegen habe ich das ähnliche HM-SEC-RHS-2 genommen, was ja auch geht.

Die Sensoren liefen jetzt über Monate/Jahre quasi durch ohne Probleme - an der FW und kann es meiner Meinung nach nicht liegen. Ich musste auch noch bei keinem Sensor per Hand das model per modelforce festlegen, weil er sich das immer über die FW gezogen hatte.

Die  HMConfig_AskSinPPCustom.pm ist auch die aktuellste (habe ich Ende November installiert, nach der installation hat es aber weiterhin funktioniert, der Fehler kam später)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: frank am 14 Dezember 2022, 14:23:30
ZitatNormalerweise müsste ich das model HM-SEC-RHS-3 nehmen, ist aber im Dropdown von modelForce nicht verfügbar.
ok, das ist wohl leider ein bug in cul_hm. meine homebrew models finde ich dort auch nicht.

aber mit einer passenden/funktionierenden HMConfig_AskSinPPCustom.pm sollte das model trotzdem automatisch erkannt werden. was sagt:
get hminfo models -f F209
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 14 Dezember 2022, 14:31:34
Ich habe übrigens seit Ewigkeiten das "Problem", dass ich immer 2x pairen muss, damit alles richtig gesetzt wird. Vielleicht hilft das ja auch hier.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 14 Dezember 2022, 15:43:07
Zitat von: papa am 14 Dezember 2022, 14:31:34
Ich habe übrigens seit Ewigkeiten das "Problem", dass ich immer 2x pairen muss, damit alles richtig gesetzt wird. Vielleicht hilft das ja auch hier.

Leider nein - die Geräte waren auch schon ewig richtig mit der Zentrale gepairt
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 14 Dezember 2022, 15:44:12
Zitat von: frank am 14 Dezember 2022, 14:23:30
ok, das ist wohl leider ein bug in cul_hm. meine homebrew models finde ich dort auch nicht.

aber mit einer passenden/funktionierenden HMConfig_AskSinPPCustom.pm sollte das model trotzdem automatisch erkannt werden. was sagt:
get hminfo models -f F209

models filtered:F209
  subType          name                       ID supportedMode            Info  List  channels
  no                                        F209 normal                               

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: frank am 14 Dezember 2022, 16:10:57
Zitat von: Kai-Alfonso am 14 Dezember 2022, 15:44:12
models filtered:F209
  subType          name                       ID supportedMode            Info  List  channels
  no                                        F209 normal                             
dann ist wohl im file was faul.

gab es in fhem.log beim letzten restart einträge mit diesem inhalt?
additional HM config file loaded:
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 14 Dezember 2022, 16:45:24
Zitat von: frank am 14 Dezember 2022, 16:10:57
dann ist wohl im file was faul.

gab es in fhem.log beim letzten restart einträge mit diesem inhalt?
additional HM config file loaded:

Nein, aber sowas

Error loading file: ./FHEM/HMConfig_AskSinPPCustom.pm:
Global symbol "$batflags" requires explicit package name (did you forget to declare "my $batflags"?) at ./FHEM/HMConfig_AskSinPPCustom.pm line 376
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 14 Dezember 2022, 16:58:48
Das ist auf jeden Fall ein (Copy&Paste) Fehler.
Mach mal ein Update. Habe ich angepasst.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 14 Dezember 2022, 17:21:38
Zitat von: papa am 14 Dezember 2022, 16:58:48
Das ist auf jeden Fall ein (Copy&Paste) Fehler.
Mach mal ein Update. Habe ich angepasst.

jetzt bekomme ich ein

'2022.12.14 17:20:13.148 1: Error loading file: ./FHEM/HMConfig_AskSinPPCustom.pm:
Can't locate object method "culHmModel" via package "HMConfig" at ./FHEM/HMConfig_AskSinPPCustom.pm line 359.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 14 Dezember 2022, 17:27:22
Sorry - mach das gerade alles blind.
Mach mal bitte nochmal ein Update.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 14 Dezember 2022, 17:44:39
Zitat von: papa am 14 Dezember 2022, 17:27:22
Sorry - mach das gerade alles blind.
Mach mal bitte nochmal ein Update.

Kein Problem - bin ja froh für deine Arbeit und Support hier 👍👍👍

Jetzt lädt er das Modul ohne Fehlermeldung
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Kai-Alfonso am 14 Dezember 2022, 18:21:44
jetzt erkennt er auch ohne modelForce wieder das richtige HM Model. Hab modelForce gelöscht und set getConfig gemacht, dann kam auch direct wieder das richtige Model. War also irgendwas in einer Zwischenversion der  HMConfig_AskSinPPCustom.pm "faul"

Nur falls jemand auf das selbe Problem stößt - hab es erst nicht gemerkt, da im Winter die Fenster nur kurz auf sind
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: caldir65 am 14 Dezember 2022, 21:36:13
Zitat von: meier81 am 13 Dezember 2022, 13:20:13
Hi Tobias,

bezüglich deiner "Teilnahme" an einer Bestellung, welchen Typ bräuchtest du denn (die längliche?) und wieviel würdest du denn nehmen? Würde nämlich auch noch ein paar benötigen und kann auch gerne das Bestellen übernehmen.

Gruß Markus

Moin,

ist das noch aktuell? Ich wäre möglicherweise auch an ein paar Schmalen interessiert - da wären noch ein paar Fenster bestücken  :).
Was kosten die Dinger denn aktuell?

Gruß, Christoph
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Tobias am 15 Dezember 2022, 08:54:54
Zitat von: meier81 am 13 Dezember 2022, 13:20:13
Hi Tobias,

bezüglich deiner "Teilnahme" an einer Bestellung, welchen Typ bräuchtest du denn (die längliche?) und wieviel würdest du denn nehmen? Würde nämlich auch noch ein paar benötigen und kann auch gerne das Bestellen übernehmen.

Gruß Markus

Hi Markus,
sorry das ich mich so spät zurückmelde, ich habe noch ein paar Panstamp NRG2 in meinem Keller gefunden und würde dann lieber auf die unsichtbare Lösung umschwenken. Wenn die Panstamps aufgebraucht sind mache ich mit der WindowStatusSensor Arduino Version weiter (-> HM-SEC_RHS-4x). Davon habe ich hier auch schon 2 Stück im Testeinsatz.
Auf jeden Fall sind beide Versionen nicht Batterie sondern Stromversorgt und hängen in der Fensterleibung in einer Unterputzdose schön versteckt.

https://github.com/tobiasfaust/WindowStatusSensor
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Esjay am 15 Dezember 2022, 11:20:23
Zitat von: caldir65 am 14 Dezember 2022, 21:36:13
Moin,

ist das noch aktuell? Ich wäre möglicherweise auch an ein paar Schmalen interessiert - da wären noch ein paar Fenster bestücken  :).
Was kosten die Dinger denn aktuell?

Gruß, Christoph

Hätte noch folgendes abzugeben, falls Interesse besteht.

7 x Platinen der schmalen Version, Teilbestückt mit 328P, diversen Kondensatoren und Widerständen
9 x Funkmodule CC11010 Originalverpackt.
20 x LED Kit / grün gelb rot
50 x Microschalter
100 x 10nF / 10pf / 9pF
100 x TLE
40 Batteriehalter
100 x SMD Widerstände

Grüße
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: caldir65 am 27 Dezember 2022, 11:19:50
Moin,

ich muß die Fenstersensoren erst einmal gaanz hinten an stellen ...
Trotzdem Danke

Gruß, Christoph
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Quick am 13 Januar 2023, 21:02:21
Suche eine aktuelle Einkaufsliste. Irgendwie sind fast alle Links hier tot.
Bei JLPSB wollen die mittlerweile knapp 68€ für 5 Platinen.
Ich bräuchte 15-20 Platinen.
Es soll die schmale-Version sein.
Vielleicht hat noch jemand was liegen, oder hat eine aktuelle Teile Einkaufsliste?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Feinfinger am 13 Januar 2023, 21:22:08
Also ich hab am 14.12. für 5 fertig bestückte Platinen in der schmalen Version incl. Versand 32 Euro bezahlt.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Quick am 13 Januar 2023, 22:23:00
Zitat von: Feinfinger am 13 Januar 2023, 21:22:08
Also ich hab am 14.12. für 5 fertig bestückte Platinen in der schmalen Version incl. Versand 32 Euro bezahlt.

Vielleicht habe ich auch etwas falsch gemacht.
Wäre das erste mal, dass ich bei jlpcb bestelle  :'(

Wie sieht es eigentlich mit dem Zoll aus? Gebühren?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 14 Januar 2023, 20:50:23
Zitat von: Quick am 13 Januar 2023, 22:23:00
Wie sieht es eigentlich mit dem Zoll aus? Gebühren?

Also ich hatte 20 Stück bestellt und hab keine Gebühren bezahlt  ;)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Quick am 14 Januar 2023, 21:27:46
Zitat von: meier81 am 14 Januar 2023, 20:50:23
Also ich hatte 20 Stück bestellt und hab keine Gebühren bezahlt  ;)

Bräuchte auch 20 Stück. Aber scheint mittlerweile teuer zu sein. Bestück kostet das knapp 200€. Wobei dann nicht alles bestück ist ( paar Teile fehlen ).

Darf man fragen was du bezahlt hast?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 15 Januar 2023, 13:55:08
Hab gerade mal nachgeschaut, hatte die bei JLCPCB bestellt, beim ersten Mal 5 Stück für 31,79€ incl. Porto, beim zweiten Mal 15 Stück für 66,14€ incl. Porto. Beide Mal als Teilbestückt, heißt die Seite mit dem IC bestücken lassen.

Hab auch eben mal geschaut, ich komme auf einen Preis von aktuell 80,53€ für 20 Stück.

Gruß Markus
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Quick am 15 Januar 2023, 13:59:59
Ok, dann lötest du den Rest praktisch selber. Wäre auch eine Möglichkeit.
Lässt du irgendwas speziell noch machen von JLCPCB? Oder einfach Standardeinstellung lassen?
Hast du die Platinen in weiß oder grün?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: meier81 am 15 Januar 2023, 15:14:31
Ich habe meine Platinen in Standard "grün" genommen, denke das ist Geschmackssache.

Also extra machen lasse ich nichts, eigentlich alles auf "Standard"-Einstellungen.

Und beidseitig bestücken machen die ja meine ich eh nicht, dementsprechend habe ich mir die Seite mit dem IC ausgesucht zum bestücken, das war mir dann zu viel des guten  ;)
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Quick am 15 Januar 2023, 17:37:02
Ich muss da praktisch nur die "gerber_small" hochladen? Da dann im Warenkorb zwei Items liegen
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Quick am 21 Februar 2023, 10:19:27
Habe vergessen die Batteriehalter zu bestellen, hat vielleicht jemand welche die er nicht mehr braucht? Bräuchte 20 Stück.
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Quick am 12 März 2023, 20:50:37
Wollte heute den ersten Sensor machen, aber ich bekomme keine Verbindung zum Atmel. Habe das Projekt in VSCode geöffnet und die fehlenden Libaries installiert. Kompien geht, jedoch steht hier immer
avrdude error: programmer is not responding
avrdude warning: attempt 1 of 10: not in sync: resp=0x00


Ich komm einfach nicht dahinter, was das Problem ist. Kann vielleicht jemand Hilfestellung geben?

Habe folgendes Leitungen vom FTDI zum Board (lange Version) gesetzt:
FTDI:            Board:
VCC 3,3V --> VCC
GND        --> GND
RX          --> TX
TX          --> RX
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 12 März 2023, 21:09:32
Ist da ein schon Bootloader drauf? Muss man ein jungfräulichen Atmel nicht erst mal über ISP flashen?

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Quick am 12 März 2023, 21:11:02
An das denke ich auch schon die ganze Zeit, aber ich hab keinen ISP - Programmer. Nur so eine FTDI/USB/TTL
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 12 März 2023, 21:16:35
Nagut den brauchste aber. Eventuell ist der Hauseigene Bootloader drauf von AVR aber im Prinzip ist ein ISP Programer schon sinnvoll zu besitzen. Du kannst aber auch ein Arduino dafür verwenden.

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Quick am 12 März 2023, 21:18:28
Dann werde ich mir mal so einen ISP besorgen.

Mit welchem Programm kann man dann den Bootloader schreiben? Mit VSCode?
Wenn ja wie?
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: ext23 am 12 März 2023, 21:48:05
Google hilft weiter wa ;-) Aber gabs für den Sensor hier nicht fertige hex files?

/Daniel
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 13 März 2023, 07:54:31
https://github.com/pa-pa/HB-Sec-RHS-3/tree/master/firmware
Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Quick am 16 März 2023, 02:04:26
Also irgendwie bin ich zu doof für das. habe mich an die Anleitung gehalten. Einmal konnte ich per ISP flashen, aber es kam keine Verbindung mit der Raspberrymatic zu stande. Das Addon habe ich bereits installiert.
Wenn ich nun erneut flashen möchte, kommt folgende Meldung mit AVRDUDE (siehe Bildanhang)
Zudem kann ich per FTDI nichts machen, da keine Verbindung zustande kommt (mit VSCode). FTDI RX --> TX und FTDI TX --> RX
ISP und FTDI waren beide auf 3,3V gesteckt und das CC1101 war noch nicht verbaut.

Titel: Antw:Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Quick am 18 März 2023, 20:39:19
Der erste läuft jetzt. Leider funktioniert kein einziges geliefertes CC1101 Modul. Gott sei Dank hatte ich noch 2 aus anderen Projekten, die laufen.

Einzig, was ich nicht verstehe, was mir vielleicht jemand erklären könnte:
Der Magnet kommt zu ,,U2" es wird gekippt angezeigt, kommt man wieder zu ,,U2" wird offen gemeldet. Kommt man zu ,,U1" wir nicht gemeldet.

Und ist ,,U3" dann der Sabotagekontakt? Den habe ich nämlich noch nicht aufgelötet.
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Quick am 22 März 2023, 11:13:14
Irgendwie klappt das alles nicht.

Ich habe nun folgenden Bootlouder mittels USBasp auf den Atmel geschrieben
ATmegaBOOT_168_atmega328_pro_8MHz.hex
Danach wollte ich mittels des FTDI-Adapters und VSCode die .Ino schreiben.
Aber hier kommt immer folgende Meldung:

Uploading .pio\build\pro8MHzatmega328\firmware.hex
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x33

Das zählt dann bis 10 durch und wird dann abgebrochen.

RX und TX auch schon mehrmals getauscht. Ich komme bei keinem Atmel von meinen Platinen per RX und TX auf den Chip.

Woran kann das liegen?

Ich möchte doch nur den RHS 3 mit U1 und U2 und Batteriespannungsanzeige
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 03 April 2023, 23:06:57
Guten Abend ihr,
Ich nutze schon einige Zeit / Jahre diese Fenstergriffsensoren bei uns im Haus. Aktuell sind diese mittels einem NeumannCul in FHEM eingebunden.
Bei uns läuft aber auf einem pi noch RaspbertyMatic für Heizkörperthermostate (IP) und eine alte Keymatic.
Kann ich denn diese Sensoren von hier ,,einfach" ebenfalls an die RaspberryMatic anlernen?
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 April 2023, 07:48:46
Fast - Du nusst due Addins von hier installieren: https://github.com/jp112sdl/JP-HB-Devices-addon
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 04 April 2023, 09:22:37
Ah okey, die habe ich bei mir bereits installiert auf der RaspberryMatic  ;D

Wie war das denn nochmal mit dem anlernen, bzw auch das zurücksetzten, die müssen doch erst einmal zurück gesetzt werden wenn die bereits wo angelernt sind oder?
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 April 2023, 09:47:26
Mindestens 6 Sekunden den Config-Taster drücken
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 04 April 2023, 13:29:24
Hm, ich bekomme sie an die RM nicht angelernt, ich gehe wie folgt vor:
-Anlernmodus starten im RaspberryMatic
- Dann am Sensor den config Button 6 Sekunden drücken (nach ca. 3 Sekunden fangen Grün und rot an zu blinken, 6 mal, danach gehen beide nochmal an für ca. eine Sekunde und danach nur noch einmal die grüne LED)

Jedoch taucht kein neues Gerät auf  :(
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 04 April 2023, 14:36:21
6 Sekunden ist der Reset - zum Anlernen nur kurz drücken
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: networker am 12 April 2023, 11:24:31
Ich habe versehentlich zwei mal die gleiche HEX auf verschiedene Platinen mit avrdude aufgespielt.
Ich habe danach versucht auf einem der beiden Platinen die richtige HEX aufzuspielen mit

C:\Downloads\avrdude-v7.1-windows-windows-x64>avrdude -p m328p -P COM9 -c stk500v2 -V -U flash:w:A993A4.hex
avrdude: AVR device initialized and ready to accept instructions
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: reading input file A993A4.hex for flash
         with 32531 bytes in 3 sections within [0, 0x7ffe]
         using 255 pages and 109 pad bytes
avrdude: writing 32531 bytes flash ...

Writing | ################################################## | 100% 13.19 s

avrdude: 32531 bytes of flash written

avrdude done.  Thank you.

Der Fenserkontakt meldet sich aber immer noch mit der falschen HM-ID

Welche Möglichkeit gibt es das zu fixen?

Die HEX die ich mit /bootloader/avr/makeota.html erzeugt habe sollte die HM-ID A993A4 haben, die Platine meldet sich aber mit A9B8C7
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 12 April 2023, 14:01:34
Hast Du selber compiliert oder das HEX aus dem Git genommen ?
Wenn selbst compiliert - dann auch USE_OTA_BOOTLOADER gesetzt ?
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: networker am 12 April 2023, 15:09:05
Habe die HEX aus dem Git und als Input für die makeota.htm angegeben.
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 12 April 2023, 15:40:30
Dann sollte es eigentlich ohne Probleme gehen. Mach mal nen RESET - mindestens 6 Sekunden den Config-Taster drücken.
Dann wird auch der EEPROM neu initialisiert.
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: networker am 13 April 2023, 10:53:15
ok, bin einen Schritt weiter, ich hatte 2 namentlich gleich HEX-Datein in verschiedenen Verzeichnissen.
Einmal die HEX aus dem GIT und eimal die HEX Datei aus deinem Post #507
Zitat von: papa am 05 Oktober 2021, 11:07:17Also funktioniert die Hardware schon mal.
Kannst Du mal die angehängte Firmware probieren. Ist für OTA übersetzt. Wenn die geht, dann müssen wir mal rauskriegen, warum Deine nicht geht.
Wenn ich diese als Input für makeota.htm verwende bekomme ich immer die HM-ID A9B8C7 mit der Serial papaa9b8c7 --> diese funktioniert aber mit 2 Sensoren
Die aus dem GIT übernimmt meine HM-ID und Serial, funktioniert aber anscheinend nicht mit 2 sondern nur mit 3 Sensoren?
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 13 April 2023, 12:28:26
Dann ist die verlinkte Firmeware nicht richtig für OTA übersetzt.
Es wird nicht die ID aus dem Bootloader verwendet :-(
Am besten wäre, wenn Du das überseten selbst hinkriegst. Ich habe hier gerade nichts zum Testen.
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: networker am 13 April 2023, 17:12:55
@papa  danke, habs compiliert bekommen und dann die HEX ohne Bootloader als input für die makeota.html verwendet.
Danach die HEX vom Output auf die Platine geflasht, angelernt --> funktioniert  ;D
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 07 Mai 2023, 10:42:14
Zitat von: papa am 04 April 2023, 14:36:216 Sekunden ist der Reset - zum Anlernen nur kurz drücken
Ich bin heute mal dazu gekommen, 1-2 in HomeMatic einzubinden. Das funktionierte soweit auch, mir werden diese Angezeigt, jedoch wird der Status nicht aktualisiert, heißt er steht immer auf "geschlossen", egal ob das Fenster offen oder gekippt ist..  :-\
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: DerD! am 23 Mai 2023, 12:39:54
Zitat von: gloob am 25 Mai 2020, 14:26:06Kann 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

Hallo zusammen

Ich habe gestern meine erste Platine der Small-Version zusammen gelötet und erfolgreich auf die CCU anlernen können.
Die PCBs habe ich auf der MCU Seite von JLPCB vorbestücken lassen (also inklusive der beiden TLE U1 & U2.
Seltsamerweise reagiert der RHS nicht, wenn der Magnet oben steht, kann es sein, dass hier ebenfalls ein Fehler in der Platine vorliegt.
Ich kann mir (oder will es mir) nicht vorstellen, das JLPCB hier ebenfalls minderwertige Bauteile eingesetzt hat.

Danke für eure Rückmeldungen

Denni
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 23 Mai 2023, 14:17:37
Was hast Du  denn für ne Firmware geflasht ?
Selbst übersetzt ?
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: DerD! am 23 Mai 2023, 18:07:03
Hallo

Ich habe den Sketch aus: GitHub (https://github.com/pa-pa/HB-Sec-RHS-3/tree/master/Sketch/HB-SEC-RHS-3) //- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2020-03-29 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// ci-test=yes board=328p aes=yes
//- -----------------------------------------------------------------------------------------------------------------------

// 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
#define CC1101_PWRPIN 0xff

#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 16   // 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,CC1101_PWRPIN> 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<>();
  }
}
genommen und mit Arduino IDE kompiliert.

Anschliessend das hex-File nach dieser Anleitung aus Git (https://github.com/pa-pa/HB-Sec-RHS-3/tree/master/firmware) ein bootloader File (PAPARHS301.hex) ersetllt welches ich dann mit AVRDUDESS auf den MCU geflashed habe.
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: DerD! am 24 Mai 2023, 22:33:33
Zitat von: DerD! am 23 Mai 2023, 18:07:03Hallo

Ich habe den Sketch aus: GitHub (https://github.com/pa-pa/HB-Sec-RHS-3/tree/master/Sketch/HB-SEC-RHS-3) //- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2020-03-29 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// ci-test=yes board=328p aes=yes
//- -----------------------------------------------------------------------------------------------------------------------

// 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
#define CC1101_PWRPIN 0xff

#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 16   // 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,CC1101_PWRPIN> 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<>();
  }
}
genommen und mit Arduino IDE kompiliert.

Anschliessend das hex-File nach dieser Anleitung aus Git (https://github.com/pa-pa/HB-Sec-RHS-3/tree/master/firmware) ein bootloader File (PAPARHS301.hex) ersetllt welches ich dann mit AVRDUDESS auf den MCU geflashed habe.

Ich habe jetzt mal ein wenig mit den Pins gespielt.

Mit folgender Einstellung wird der obere und untere TLE erkannt und ich kann die Drehgriffstellungen sauber erfassen:

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

Was jetzt noch stört, ist dass ich permanent eine Sabotagemeldung erhalte, da ich den U3 nicht bestückt habe.

Ich könnte ihn nötigenfalls mit einem Lötklecks brücken, es wäre aber nice, wenn ich das über den Sketch bewerkstelligen könnte.

Ein Auskommentiren des Sabotage Pins nimmt er leider nicht an, da bekomme ich eine Fehlermeldung beim Kopilitieren.
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 24 Mai 2023, 22:40:37
SABOTAGE_PIN auch einfach auf 0 sollte helfen
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 21 Juni 2023, 13:00:01
Zitat von: Fillip am 07 Mai 2023, 10:42:14
Zitat von: papa am 04 April 2023, 14:36:216 Sekunden ist der Reset - zum Anlernen nur kurz drücken
Ich bin heute mal dazu gekommen, 1-2 in HomeMatic einzubinden. Das funktionierte soweit auch, mir werden diese Angezeigt, jedoch wird der Status nicht aktualisiert, heißt er steht immer auf "geschlossen", egal ob das Fenster offen oder gekippt ist..  :-\
Jemand eine Idee, warum ich keine aktualisierungen bekomme? In FHEM direkt eingebunden über einen NeunammCUL bekomme ich die werte aktualisiert, sobald ich das ganze jedoch an RaspberryMatic anlerne steht das Device die ganze zeit auf "geschlossen"
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 21 Juni 2023, 13:41:31
Gesicherte Verbindung abschalten oder den Sketch mit "AES enabled" übersetzen

https://asksinpp.de/Grundlagen/FAQ/Standard_vs_gesicherte_Uebertragung.html
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 21 Juni 2023, 13:55:06
Danke das war es! Nun läuft es. Denke mal aber die "sauberste" Methode wäre die Module neu zu flashen und AES enabled zu setzen oder?
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 21 Juni 2023, 16:04:32
Ja
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: Fillip am 22 Juni 2023, 07:00:36
Muss ich dazu denn die Geräte alle neu flashen (Bootloader) oder geht das auch über OTA?
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: papa am 22 Juni 2023, 08:32:16
Den Sketch zusätzlich mit USE_AES (siehe https://github.com/pa-pa/AskSinPP/tree/master#enable-aes-support) übersetzen.
Dann einfach per OTA flashen
Titel: Aw: Fensterdrehgeriffkontakt - Die nächste Runde
Beitrag von: HomeMike am 27 Juli 2023, 13:26:42
Liebe Alle,

wollte nur kurz allen für die hervorragende Arbeit danken! Vermutlich könnte man hier viele Namen nennen, papa danke ich besonders.

Bin offensichtlich einige Jahre zu spät eingestiegen und beim Lesen dieses Threads erst auf Seite 24.

Insgesamt aber ist Eure Arbeit wirklich extrem gut! Ich werde noch viel lesen damit ich nicht 100mal gestellte Fragen wiederhole.

Das war's schon. Schöne Grüße!