Fensterdrehgriffkontakt selber bauen

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

Vorheriges Thema - Nächstes Thema

Fixel2012

Zitat von: Wzut am 23 Oktober 2017, 10:07:33
@ 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)

Doch, bei mir funktioniert es.
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

Richtig - mittlerweile funktioniert es auch  :)
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Per

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
Der ATMega schon, der Pullup nicht. Oder bekommt der seine Spannung von einem Ausgang, der explizit für das Lesen kurz angeschaltet wird?
Einen Schaltplan konnte ich nicht finden (falscher Suchbegriff?) und Post 1 ist leider nicht der Sammelpost.

papa

Die Pins werden immer nur kurz zur Prüfung aktiviert - also INPUT_PULLUP. Sonst stehen sie die gesamte Zeit auf OUTPUT / LOW.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Per

Dann hast du dennoch bei geschlossenem Reed über den Pullup einen Stromfluss.
Wenn die Spannungsversorgung des Pullups hingegen nicht von Plus, sondern von einem geschalteten Ausgang geliefert wird, hätte man in der Ruhepause dort keinen Stromfluss.

papa

In der Ruhepause steht der Pin doch aber auf OUTPUT / LOW. Damit sind dann beide Seiten auf GND. Da fließt nichts.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Per

Wahrscheinlich reden wir aneinander vorbei. Hast du mal ein Link vom Schaltplan?

joschi2009

Zitat von: Per am 23 Oktober 2017, 16:55:51
Wahrscheinlich reden wir aneinander vorbei. Hast du mal ein Link vom Schaltplan?

Ich denke du meinst einen externen Pullup, Papa redet vom internen

papa

Zitat von: Per am 23 Oktober 2017, 16:55:51
Wahrscheinlich reden wir aneinander vorbei. Hast du mal ein Link vom Schaltplan?

https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/files/HMSensor-CR2032.pdf

A0 & A1 werden per Reed gegen Masse geschalten.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Per

Zitat von: joschi2009 am 23 Oktober 2017, 17:23:43
Ich denke du meinst einen externen Pullup, Papa redet vom internen
Danke, das wars! Klar, warum einen externen einsetzen, wenn es einen internen gibt.

Wzut

Zitat von: papa am 23 Oktober 2017, 11:18:08
Richtig - mittlerweile funktioniert es auch  :)
das glaube ich dir blind :) Bei meinen noch etwas älteren Versionen der FW steht nach dem Versuch es auf einen Wert > 0 zu setzen in der reg Table der Wert auf set_2_s - lege ich jetzt als "hätte gewollt aber nicht gekonnt" aus :) 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

tndx

Ich habe hier noch eine FDGK, der noch mit einer alten Firmware arbeitet, die ich gerne aktualisieren würde. Behält der FDGK seine Einstellungen (Registerwerte und AES-Schlüssel) oder ist er danach zurückgesetzt?

Und wo ich beim Thema AES und Homebrew bin: wie sieht es hier mit der Auslesbarkeit der AES-Schlüssel aus? Bei den Original-HM-Devices soll das ja nur durch den Hersteller selber möglich sein und das bietet mir Sicherheit, falls ich meine Keymatic-Fernbedienung verlieren sollte. Wie sieht es aus, wenn ich meine Homebrew-Fernbedienung verliere?

papa

Zitat von: tndx am 24 Oktober 2017, 14:50:05
Ich habe hier noch eine FDGK, der noch mit einer alten Firmware arbeitet, die ich gerne aktualisieren würde. Behält der FDGK seine Einstellungen (Registerwerte und AES-Schlüssel) oder ist er danach zurückgesetzt?

Eigentlich sollte das alles erhalten bleiben, wenn sich die Regsiter und Anzahl der Peers nicht geändert hat. Ich glaube ganz am Anfang, war das mal nötigt. Könnte also auch sein, dass alles zurück gesetzt wird, wenn es eine der ersten Firmwareversionen ist.

Zitat von: tndx am 24 Oktober 2017, 14:50:05
Und wo ich beim Thema AES und Homebrew bin: wie sieht es hier mit der Auslesbarkeit der AES-Schlüssel aus? Bei den Original-HM-Devices soll das ja nur durch den Hersteller selber möglich sein und das bietet mir Sicherheit, falls ich meine Keymatic-Fernbedienung verlieren sollte. Wie sieht es aus, wenn ich meine Homebrew-Fernbedienung verliere?

Puh - gute Frage. Je nachdem wie die Lock-Bits im ATMega328 gesetzt sind, kann man den EEProm von außen auslesen oder auch nicht. Da der Key im steht im EEProm. Wenn dieser entsprechend gelockt ist, sollte alles sicher sein. Mit den Lock-Bits habe ich mich aber auch noch nicht weiter beschäftigt.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

tndx

Zitat von: papa am 24 Oktober 2017, 22:08:37
Puh - gute Frage. Je nachdem wie die Lock-Bits im ATMega328 gesetzt sind, kann man den EEProm von außen auslesen oder auch nicht. Da der Key im steht im EEProm. Wenn dieser entsprechend gelockt ist, sollte alles sicher sein. Mit den Lock-Bits habe ich mich aber auch noch nicht weiter beschäftigt.

D.h. der Schlüssel kann dann mit entsprechend gesetzten Lockbits von außen nicht ausgelesen werden, wohl aber von der Firmware, weil sonst könnte sie ja nicht vernunftig funktionieren. D.h. man könnte die Firmware so modifizieren, dass sie den Schlüssel im Klartext ausgibt? Und das gilt theoretisch auch für Original-HM-Devices, oder kochen sie nicht mit Wasser?

papa

Zitat von: tndx am 25 Oktober 2017, 08:10:08
D.h. der Schlüssel kann dann mit entsprechend gesetzten Lockbits von außen nicht ausgelesen werden, wohl aber von der Firmware, weil sonst könnte sie ja nicht vernunftig funktionieren. D.h. man könnte die Firmware so modifizieren, dass sie den Schlüssel im Klartext ausgibt? Und das gilt theoretisch auch für Original-HM-Devices, oder kochen sie nicht mit Wasser?

Ja und wahrscheinlich auch ja. Wenn die Firmware mittels OTA übertragen werden kann und diese Software den EEProm auslesen kann, kann auch der Key ausgelesen werden. Das kann nur durch das Signieren der Firmware und entsprechende Prüfung beim OTA-Flashen unterbunden werden. Allerdings wird das kaum in den Bootloader passen.
Wenn man auf OTA verzichtet und die Lockbits setzt, sollte das nicht mehr möglich sein, da dann das Flashen nur noch nach einem Chip-Erase geht und das löscht komplett alles - auch das EEProm. Soweit ich das verstanden habe.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire