Rauchmelder von Techem

[JanWittke]

Du hast eine PN

[herrmannj]

Jute Nachricht: ich sehe ihn, die ID wird übertragen. Techem Rauchmelder haben die Kennung "F0". Der Datensatz hat fast die Länge der WZ oder HKV Nachrichten. Alles nach der fetten "A0" sind Nutzdaten, die beiden 4er Blöcke sind CRC.

b29 44 6850 60884854 76F0 8181 A0 00 8B 1F 8C 1F 00 E4 8C 1F 00 80 07 00 00 09 F16F 00 6B A1 00 7C B2 00 8D C3 00 9E D4 00 0F E5 00 96BA 80

Ich frag mich was so ein SD überhaupt zu erzählen hat. Im Sinne von: bei einer Wasseruhr ist es der Zählerstand. Bei einem SD ist es

Müssen wir mal über einige Tage beobachten. Bin mal gespannt was sich verändert. Vielleicht bekommt man ein Gefühl was überhaupt übertragen wird. Denkst Du das da mal ein Fehlalarm im log landen könnte ? Das wäre ja auch interessant

vg
joerg

[herrmannj]

In dem SD scheinen verbaut: 3x Ultraschall Abstand / Helligkeit / Temperatur und eben die Rauchkammer.

In der Theorie "könnten" die Sensoren also Übertragen werden. Bin mal gespannt

vg
joerg

*www.opengeiger.de/BoesesErwachenRauchmelder.pdf

[JanWittke]

Gib mal bei Google ein Boeseserwachenrauchmelder.PDF
Steht einiges drin. 

Gruß
Jan

[herrmannj]

Hi,

nach dem ersten Zwischen-log sehe ich leichte Änderungen in den Daten die übertragen werden. Allerdings ändert sich wirklich nur wenig, von daher ist erst einmal unklar welche physikalische Größe sich (dazugehörig) geändert hat.

Werden wir weiter beobachten müssen. Bisher habe ich nur vage Theorien was die einzelnen Teile bedeuten könnten und man muss die Änderungen über die Zeit beobachten.

Richtig interessant wäre auch ein (Fehl-) Alarm 

Sollte jemand eine Quelle kennen wo man die SD günstigst gebraucht bekommt oder so ein Ding als Leihgabe haben wäre ich interessiert.

vg
joerg

[JanWittke]

Hallo Jörg,

Fehlalarm hatte ich am Freitag zwischen 18 und 19 Uhr.   Die Frau hat was leckeres gebraten und die Küchentür stand offen 

Vielleicht findest du doch was die aufgeklebte Nummer vom ausgelösten Rauchmelder ist 5448 8856 HV.


lg Jan

[herrmannj]

Hey, ziemlich cool

Ich sehe tatsächlich.

18:52 normale Meldung
18:56 an der Stelle wo ich es anhand der Erfahrung der HKV suchen würde ist ein bit gesetzt -> ALARM  
19:00 der Alarm ist weg, ein Zähler ist auf 1 gesprungen
19:04 ein unbekanntes bit
19:09 unbekanntes bit wieder weg - Zähler bleibt auf 1

Ich denke damit kommt man deutlich näher. Wenn sich das so bestätigt könnte man die Kernfunktion (gib Meldung an fhem wenn Rauch) so implementieren. Das ist ja am Ende der Part der wesentlich ist.

Was mich wundert: die Meldung mit dem Alarm kommt genau in dem normalen Sendefenster. Scheint so als ob der Rauchmelder im Falle eines Alarms keine Funkmeldung schickt. Stattdessen sieht man das erst im nächsten regulären Telegramm. Die Sendefenster sind 4Minuten + x Sekunden. Im Fall der Fälle würde es also bis zu 4 Minuten dauern bis FHEM den Alarm gemeldet bekommt (wobei das ja für push msg noch ok wäre.)

Für das bit welches noch als Nachzügler kommt fehlt mir noch eine Idee. Vielleicht hat das was mit dem ausschalten zu tun. Wie macht man das eigentlich ? Auf einen Knopf drücken ?

Meinst Du Deine Frau kocht nochmal sowas leckeres - und Du nimmst die genauen Zeiten ? 

Mit dem smoke event kommen wir jetzt schon einen riesigen Schritt voran ! Danke an Frau

vg
joerg

[JanWittke]

Ich denke wir kriegen das Gerät schon noch gesprächig.
Es soll auch Warntöne abgeben, wenn der Abstand zu Gegenstände nicht der eingestellten Norm entspricht. Auch das werde ich an diesem Rauchmelder testen. 
Ich mache mir mehr Gedanken darüber wie Techem diese Geräte jährlich Warten will ohne in die Wohnung zu gelangen?

Gruß Jan

[peterk_de]

Ich nenne das mittlerweile "FHEM-Effekt": Vorhin kam mir die Idee, meine neuen, furchtbar hässlichen Zwangsrauchmelder von Techem in FHEM anzubinden - und voila, es sitzt tatsächlich schon wieder jemand dran, das Protokoll zu dekodieren, und ausgerechnet auch noch der, dem ich meine abendliche LED-Beleuchtung zu verdanken habe Danke, Jörg! CUL868 ist - extra dafür - bestellt, Rauchmelder-Testspray schon vorhanden. Dass ich damit dann gleich noch meine HKVs und Wasserzähler auslesen kann ist fantastisch - schonmal großes Lob vorab - du machst glaub ich viele Nerds wie mich sehr glücklich

Dass die Teile womöglich zeitnah eine Alarmmeldung übertragen finde ich andererseits aber auch ne absolute Frechheit. Mir wurde gesagt, dass NUR übertragen wird, wenn man ihn abbaut oder zustellt (dafür der Ultraschall) - mit der Begründung, ihn nicht per Augenschein warten zu müssen. Dass das Ding meine Kocheskapaden an den Vermieter und alle Nachbarn funkt, wurde nicht erwähnt ... naja.

@Jan die gucken einfach nach, ob ein Flag "zugebaut/verstopft" oder "abgebaut" oder "Fehlfunktion" auf 1 gesprungen ist, und kommen in dem Fall dann halt bei denen trotzdem händisch nachgucken. Bei der Masse der Melder spart denen das immens Zeit ... ich hab immerhin 6 Stück davon bekommen.

[herrmannj]

Peter. Du schon wiedwer

Jan hat mir schon einige logs geschickt. Wir könnten mal das nächste, mittlerweile müsste ja schon einiges zusammen sein.

Alarm wird übertragen, scheinbar mit leichter Verzögerung (<4min). Schneller würde ich schön finden. Die Sabotage Flags müsste man per try suchen.

Vielleicht kann ich an den dann neuen Daten schon mehr sehen,

vg
joerg

[JanWittke]

Asche auf mein Haupt.

Hatte viel zu tun, aber ich werde diese Woche noch liefern 

Gruß Jan

[herrmannj]

Kein stress. Ich komme diese und kommende Woche eh nicht zu. Dont panic

Vg
Joerg

[Future001]

Hallo Allerseits!

Ich bin hellauf begeistert, das sich jemand dieser 'Dinger' annimmt.
Ich hatte bisher selbst welche angebaut und in FHEM eingebunden (KD101LA) - doch heute war Techem im Auftrag des Vermieters da und ... bin jetzt hier gelandet .
Ich bin auch SEHR an einer Fhem-Integration (wie bisher - z.B. Batteriestand) interessiert. Also: falls ich irgendwie helfen kann - hab für diese Frequenz einen CUL868.


VG

[herrmannj]

Hi,

ja, kannst gerne die raw msg mitschneiden.

- beim CUL das attribut addvaltrigger RAWMSG setzen.
- den CUL dazu auf rfmode WMBUS_T schalten.
- dann die MSG aus dem eventmonitor kopieren oder (besser!!!) in ein log schreiben.

Das Protokoll muss noch dekodiert werden, ich habe aber schon Gemeinsamkeiten zu den HKV und co gesehen. Was wir halt noch empirisch testen müssen sind die Einflüsse von außen.

Die sollen ja melden wenn sie abmontiert werden, wenn sie zugebaut werden und so weiter. Freiwillige vor.

Da bräuchten wir msg die ein / zwei Tage davor und danach covern und den genauen Zeitpunkt wann sie abgebaut (zugestellt etc) wurden.

Einen Alarm habe ich schon mal gesehen, sollten wir aber gegen checken.

Ich habe noch andere Sachen vorher (sorry), wird vmtl Q2

Daten jetzt schon sammeln ist perfekt

vg
joerg

[peterk_de]

Jörg, CUL installiert - alles läuft perfekt (nachdem ich noch alle Voraussetzungen für das WMBUS-Modul geschaffen habe - vorher ist mein FHEM-Log explodiert.)

Ich bekomme genau 20 Wasseruhren und offensichtlich genau 46 Rauchmelder empfangen - das müssten ja die sein, die an WMBUS durchgereicht werden. Meine HKV senden auch alle fleißig. Bei insgesamt 10 Mietparteien sieht das also vom Empfang her sehr vollständig aus .... Die Rauchmelder hab ich so erstmal per WMBUS/autocreate anlegen lassen, und dann verbose auf 1 gestellt, um die Logs etwas zu entlasten, mein FHEM wurde schon lahm und das FHEM-FehlerLog war vollgelaufen

Die Frage ist, siehst du aktuell irgendeine Möglichkeit, das logging auf eigene Rauchmelder einzuschränken:

a) Reicht dir der Payload, den das WMBUS-Modul als Unbekannt meldet? (schneidet offenbar den Anfang vor a0 ab)?

Edit: hat sich erledigt.

b) Du schriebst, an einer Stelle kippt bei Alarm ein Bit um. Kannst du genauer sagen, welches, damit ich von den 46 mal einen Rauchmelder zum Testen identifizieren kann? Über die RSSi wird das schwer, da liegen 10 ziemlich nah beieinander ...