Fensterdrehgriffkontakt selber bauen

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

Vorheriges Thema - Nächstes Thema

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?
Raspi2|nanoCul433|nanoCul868|CCU2
Energie-USBZähler|homebrew HM Devices
DBLog|DBRep|Homematic|Baumarktsteckdosen
Hue|Webcams mit DS-Station (Synology)|Bewegungsmelder|Rollladen|Schalter (IT|HM)

Wzut

Zitat von: Fixel2012 am 22 Oktober 2017, 15:38:52

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  :-X
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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Fixel2012

Zitat von: Wzut am 22 Oktober 2017, 17:14:25
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

Fhem 5.8 auf Raspi 3, HMLAN und 868MHz CUL mit einigen Komponenten, Z-Wave Rollladenaktoren, Tablet UI, 433 MHz CUL mit Baumarktsteckdosen und Temp Sensoren, Amazon Echo, Echo Dot, 2x SONOS  play1, 1x SONOS Connect AMP,  presence, HUE, Lightify

UweH

Zitat von: Kai-Alfonso am 22 Oktober 2017, 16:54:01
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:

set <name> getConfig
config -Button drücken
set <name> regSet msgRhsPosB closed
set <name> regSet msgRhsPosA open
config - Button drücken

Damit erreichst Du die Konstellation "beide Kontakte offen" -> Status geschlossen.

Gruß
Uwe

Kai-Alfonso

Zitat von: UweH am 22 Oktober 2017, 17:56:42
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:

set <name> getConfig
config -Button drücken
set <name> regSet msgRhsPosB closed
set <name> regSet msgRhsPosA open
config - Button drücken

Damit 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
Raspi2|nanoCul433|nanoCul868|CCU2
Energie-USBZähler|homebrew HM Devices
DBLog|DBRep|Homematic|Baumarktsteckdosen
Hue|Webcams mit DS-Station (Synology)|Bewegungsmelder|Rollladen|Schalter (IT|HM)

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

Zitat von: Wzut am 22 Oktober 2017, 17:14:25
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.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Wzut

Zitat von: papa am 22 Oktober 2017, 18:12:48
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.   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Kai-Alfonso

Zitat von: UweH am 22 Oktober 2017, 18:03:08
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..
Raspi2|nanoCul433|nanoCul868|CCU2
Energie-USBZähler|homebrew HM Devices
DBLog|DBRep|Homematic|Baumarktsteckdosen
Hue|Webcams mit DS-Station (Synology)|Bewegungsmelder|Rollladen|Schalter (IT|HM)

Wzut

Zitat von: Kai-Alfonso am 22 Oktober 2017, 18:23:59
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
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Fixel2012

Zitat von: Wzut am 22 Oktober 2017, 18:22:13
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 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.
Fhem 5.8 auf Raspi 3, HMLAN und 868MHz CUL mit einigen Komponenten, Z-Wave Rollladenaktoren, Tablet UI, 433 MHz CUL mit Baumarktsteckdosen und Temp Sensoren, Amazon Echo, Echo Dot, 2x SONOS  play1, 1x SONOS Connect AMP,  presence, HUE, Lightify

papa

Zitat von: Fixel2012 am 22 Oktober 2017, 18:59:33
Frage mich nur ob in dem Register auch weniger als eine Sekunde geht, das finde ich ein wenig viel.

Nein - kleiner geht nicht.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

papa

Zitat von: Wzut am 22 Oktober 2017, 18:29:16
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.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

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.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

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)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher