Fensterdrehgriffkontakt selber bauen

[Kai-Alfonso]

Ich habe mal einen Frage zum Batterieverbrauch - mir ist jetzt nach 2 Tagen der Sensor "gestorben" - die Batterie hatte nur noch 1.8V (Varta) geliefert, am Anfang waren es 3V  - hab jetzt mal eine frische Varta reingetan, dann ging es wieder.

Jetzt hab ich mein Fenster so, das geschlossen A1 schließt, gekippt A0 schließt und offen A0 und A1 offen sind. Bedeutet das mehr Stromverbrauch, wenn die Tür geschlossen ist? Normalerweise hab ich hier gelesen, dass das System eigentlich so ist, das A0 und A1 offen sind, wenn Tür = zu. Geht aber doch irgendwie nicht mit der Anordnung von den Reed Kontakten und ein Magnet, oder?

[Wzut]

Noch zur Info: Kurz vorher habe ich versucht nach der Anleitung den FDGK mit meinem Thermostat zu peeren. Seit dem geht nichts mehr.

Würde mich über Vermutungen und Ideen zur Problembehebung freuen 

ach das ist aber lustig .. ( ok nicht für dich ) Ich habe seit Wochen einige der Dinger ohne jegliche Probleme laufen. Vor ein paar Wochen bin ich durch die Telekom Aktion in den Besitz von zwei  HM-CC-RT-DN gekommen. Nr 1 hatte ich gleich verbaut und mit dem dortigen Griffkontakt direkt gepeert - läuft alles einwandfrei.
Letzte Woche wollte ich den zweiten HM-CC-RT-DN in Betrieb nehmen mit einem Griffkontakt der zuvor schon eine Woche zuverlässig lief.
Und ab da begann das Trauerspiel , Peering war fast unmöglich und wenn dann nur mit ganz viel config drücken , Batterie raus , Reset drücken.
Irgendwann kommt er in einen Zustand in dem er fröhlich blinkt aber keine Telegramme mehr empfangen werden. Ich habe das mit dem Ding jetzt zweimal erfolglos versucht und war eigentlich der Meinung das er halt irgendeinen Defekt hat. Wäre nicht so tragisch da ich noch drei unverbaute Platinen habe.
Nach Fixel2012 Beschreibung glaube ich nun aber nicht mehr an einen Hardwarefehler. Blöd ist halt das ich auch keine Ahnung habe welche FW Version von papa auf welchem Sensor ist. Mal schauen ich werde dann wohl mal mit der neusten Version aus dem V2 Branch anfangen.

[Fixel2012]

ach das ist aber lustig .. ( ok nicht für dich ) Ich habe seit Wochen einige der Dinger ohne jegliche Probleme laufen. Vor ein paar Wochen bin ich durch die Telekom Aktion in den Besitz von zwei  HM-CC-RT-DN gekommen. Nr 1 hatte ich gleich verbaut und mit dem dortigen Griffkontakt direkt gepeert - läuft alles einwandfrei.
Letzte Woche wollte ich den zweiten HM-CC-RT-DN in Betrieb nehmen mit einem Griffkontakt der zuvor schon eine Woche zuverlässig lief.
Und ab da begann das Trauerspiel , Peering war fast unmöglich und wenn dann nur mit ganz viel config drücken , Batterie raus , Reset drücken.
Irgendwann kommt er in einen Zustand in dem er fröhlich blinkt aber keine Telegramme mehr empfangen werden. Ich habe das mit dem Ding jetzt zweimal erfolglos versucht und war eigentlich der Meinung das er halt irgendeinen Defekt hat. Wäre nicht so tragisch da ich noch drei unverbaute Platinen habe.
Nach Fixel2012 Beschreibung glaube ich nun aber nicht mehr an einen Hardwarefehler. Blöd ist halt das ich auch keine Ahnung habe welche FW Version von papa auf welchem Sensor ist. Mal schauen ich werde dann wohl mal mit der neusten Version aus dem V2 Branch anfangen.

Also ich habe die neuste FW bei mir drauf. Dann werde ich den FDGK wohl resetten und das peeren erstmal sein lassen.

Gesendet von meinem ONEPLUS A3003 mit Tapatalk

[UweH]

Geht aber doch irgendwie nicht mit der Anordnung von den Reed Kontakten und ein Magnet, oder?

Doch, ein paar Seiten vorher und noch ein paar Seiten vorher und auch davor nochmal wird auf dieses Thema eingegangen.
Wenn Du das so haben willst, musst Du die Register ändern:

Code: [Auswählen]

set <name> getConfig
config -Button drücken
set <name> regSet msgRhsPosB closed
set <name> regSet msgRhsPosA open
config - Button drückenDamit erreichst Du die Konstellation "beide Kontakte offen" -> Status geschlossen.

Gruß
Uwe

[Kai-Alfonso]

Doch, ein paar Seiten vorher und noch ein paar Seiten vorher und auch davor nochmal wird auf dieses Thema eingegangen.
Wenn Du das so haben willst, musst Du die Register ändern:

Code: [Auswählen]

set <name> getConfig
config -Button drücken
set <name> regSet msgRhsPosB closed
set <name> regSet msgRhsPosA open
config - Button drückenDamit erreichst Du die Konstellation "beide Kontakte offen" -> Status geschlossen.

Gruß
Uwe

Das ist mir schon klar - das meinte ich auch nicht. Ich meinte, das ich aus stromspargründen beide Kontakte offen = Status geschlossen zwar einstellen kann. Dann wäre aber, wenn ich das Fenster kippe, die Kontakte wieder offen = Status geschlossen

[UweH]

POPCORN!!!!!!!!!!!!!!!!!!!!!!

Ich bin raus. Das ist hier alles schon gefühlt 100x beschrieben worden. Auch wenn der Thread lang ist, lies es Dir bitte durch.

[papa]

ach das ist aber lustig .. ( ok nicht für dich ) Ich habe seit Wochen einige der Dinger ohne jegliche Probleme laufen. Vor ein paar Wochen bin ich durch die Telekom Aktion in den Besitz von zwei  HM-CC-RT-DN gekommen. Nr 1 hatte ich gleich verbaut und mit dem dortigen Griffkontakt direkt gepeert - läuft alles einwandfrei.
Letzte Woche wollte ich den zweiten HM-CC-RT-DN in Betrieb nehmen mit einem Griffkontakt der zuvor schon eine Woche zuverlässig lief.
Und ab da begann das Trauerspiel , Peering war fast unmöglich und wenn dann nur mit ganz viel config drücken , Batterie raus , Reset drücken.
Irgendwann kommt er in einen Zustand in dem er fröhlich blinkt aber keine Telegramme mehr empfangen werden. Ich habe das mit dem Ding jetzt zweimal erfolglos versucht und war eigentlich der Meinung das er halt irgendeinen Defekt hat. Wäre nicht so tragisch da ich noch drei unverbaute Platinen habe.
Nach Fixel2012 Beschreibung glaube ich nun aber nicht mehr an einen Hardwarefehler. Blöd ist halt das ich auch keine Ahnung habe welche FW Version von papa auf welchem Sensor ist. Mal schauen ich werde dann wohl mal mit der neusten Version aus dem V2 Branch anfangen.

Hm - nen HM-CC-RT-DN hab ich auch da. Schau ich mir mal an.

[Wzut]

Hm - nen HM-CC-RT-DN hab ich auch da. Schau ich mir mal an.

Das wäre fein. Meine Platinen waren von Wolfgang und mit einer rechten frühen Version von dir hier aus dem Thread. Ich hatte manche via OTA auf einen neueren Stand (auch von hier ) gebracht. Ich habe auch etwas den Überblick verloren was nun der Vorteil welcher Version war  (IMHO war die erste ohne AES)
und wie ist eigentlich der letzte Stand zum Thema Senden verzögern wenn 2x schnell der Status gewechselt wird z.b. beim direkten Drehen von gekippt über offen nach zu ? Ich werde dann mit dem flashen warten bis es da von dir gesicherte Erkentnisse gibt.   

[Kai-Alfonso]

POPCORN!!!!!!!!!!!!!!!!!!!!!!

Ich bin raus. Das ist hier alles schon gefühlt 100x beschrieben worden. Auch wenn der Thread lang ist, lies es Dir bitte durch.

Sorry, ich benutze eigentlich immer die Boardsuche - die Register habe ich natürlich richtig gesetzt und die Stati werden auch richtig angezeigt bzw. gesetzt. Mein Problem war auch eher die Batterielebensdauer. Vielleicht habe ich auch nicht richtig gesucht bzw die falschen Suchbegriffe genutzt. Werd mal schauen - vielleicht hab ich auch nen Kurzschluß

Nix für ungut Uwe..

[Wzut]

Mein Problem war auch eher die Batterielebensdauer.

IMHO hat papa irgendwann und irgendwo geschrieben das der ATMega eh die meiste Zeit schläft, egal ob nun ein Reed offen oder zu ist

[Fixel2012]

und wie ist eigentlich der letzte Stand zum Thema Senden verzögern wenn 2x schnell der Status gewechselt wird z.b. beim direkten Drehen von gekippt über offen nach zu ? Ich werde dann mit dem flashen warten bis es da von dir gesicherte Erkentnisse gibt.

Ist eingebaut, das register heißt

Code: [Auswählen]

1: eventDlyTime     |   0 to 7620s       |          | filters short events, causes reporting delay Die eingestellte Zeit wird abgewartet, wenn in der Zeit sich der Status noch ändert, kriegt Fhem dies nicht mit.

Frage mich nur ob in dem Register auch weniger als eine Sekunde geht, das finde ich ein wenig viel.

[papa]

Frage mich nur ob in dem Register auch weniger als eine Sekunde geht, das finde ich ein wenig viel.

Nein - kleiner geht nicht.

[papa]

IMHO hat papa irgendwann und irgendwo geschrieben das der ATMega eh die meiste Zeit schläft, egal ob nun ein Reed offen oder zu ist

Ja - die Pins werden 1x pro Sekunde abgefragt. Den Rest der Zeit sind sie deaktiviert und die CPU schläft.

[papa]

Bei der Umstellung der Sende-Routine scheint der Burst-Sende-Modus kaputt gegangen zu sein. Mit einer alten Version der Sende-Routine funktioniert es super. Müssen mal sehen, woran das liegt.

[Wzut]

Danke für die schnelle Rückmeldung, dann kann ich mir vorerst das aus und einlöten sparen und warte auf eine neue Version.

@ Fixel2012, ja das Register  eventDlyTime gibt es auch schon bei recht frühen Versionen. Aber ich konnte da bisher noch keine Verzögerung feststellen ( gesetzt bei mir auf 2)