Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Ralla66]

Hallo liebe Gemeinde.
Möchte mich in diesem Thread mal den Funk Rauchwarnmelder 433,92 Mhz mit Batteriebetrieb widmen.
Da es noch wenige Infos gibt wie diese in IO einzubinden sind beginne ich jetzt mal mit dem selbst Versuch.
Um mich dem Thema erst einmal zu nähern habe ich die Flamingo FA22RF bestellt.
Bedienungsanleitung hier :

https://gzhls.at/blob/ldb/5/2/d/e/e638b3c3ab195890c7bcca9b1aad507769a2.pdf

Leider halten die Batterien scheinbar nur 1 Jahr und eine Abschaltung des Alarms nach auslösen scheint nicht gegeben zu sein.
Die Bedienungsanleitung sagt aus das Gruppen gebildet werden können mit Max 15 Teilnehmern.
Vernetzbar scheint dieser ja zu sein.
Das Ziel muß ja die Einbindung in IO sein mit eventueller Adapter Entwicklung der verschiedene
Rauchmelder erkennt.
Also ist erst einmal Tiefenforschung angesagt, von Bauteile bestimmen bis Protokollzerlegung.

Projektbeginn :

Die FHEM Forumsmitglieder haben hier schon gute Hinweise geliefert bezüglich des Timings.
Das werden wir anders machen und eine Statemachine proggen und selbst auswerten.
Das macht der Kollege und proggt das in C für den Wemos.
@Hardwearhansi , CL`Design :nerd_face:
Die Auswertung der Data ist wieder mein Part, eben Bit genau.
Also erst einmal Analyse machen.

Die Funk Rauchmelder sind bestellt und schon da.
Im weiterem Text verwende ich die Abkürzung FRM.

Die Zerlegung oder was haben wir denn DA :

Bilder werden noch besser, für den ersten Eindruck sollte das reichen.

[Ralla66]

Direkt ab in die Therorie,
15 Teilnehmer pro Gruppe da bietet sich ja das Nibbel an.
Gruppe max 15 und Teilnehmer max 15 wären ja ein Byte.

Das wäre im Protokoll zu suchen.

Sync nach FHEM wäre,

Pause 13000 us
Signal 16000 us
Pause 400 us

So wie ich das erlesen habe bekommen die Slaves die gleiche ID wie der Master.
Also auch irgendwo versteckt, eventuell in der Gruppen ID.

Bin mal gespannt auf das Raw Data Timing.

Soweit der Ralla.

[zahnheinrich]

@Ralla66
Lese gespannt mit 😎

[Ralla66]

@zahnheinrich

Schaue mir erst einmal die Platine an und versuche den Ton 85 db mit ner Led zu ersetzen.
Bekommst ja sonst beim testen ein Gehörschaden. :-)

[zahnheinrich]

@Ralla66
Gute Idee 🤣

[Hardwearhansi]

@Ralla66 Interessant, bei mir stehen Rauchmelder auch noch auf der ToDo Liste

[Ralla66]

@Hardwearhansi
@zahnheinrich

So heute ging es weiter.
Ton konnte abgestellt werden nach trennen des Steckers.
Wenn Alarm ist meldet das jeder Slave mit einer grünen Led.
Also brauchte ich keine einlöten.

Erste Test mit Tasmota 8.3.1 Sensor .bin RFreceiv keine Data.
Sonoff Bridge Test Raw auch keine Erfolge.

Bezüglich FHEM Data konnte ich festellen das 4 mal was gesendet wird.
Auswertung im Bild.

Mit meinem Logicanalyser konnte ich ein Mitschnitt machen siehe Bild bei Alarm.

Jetzt erst einmal die Geschichte auswerten und ne Statemachine bauen.
So eine Handauswertung ist eben viel Arbeit.
Bedeutet ja im Endeffekt das wir nur ein Weg finden müssen die Daten in den IO zu bringen.

Der Ralla :-)

[zahnheinrich]

@Ralla66
Folge dir sehr aufmerksam, auch wenn ich nur "Bahnhof" verstehe 🤓

[Ralla66]

@zahnheinrich

Hier mal ohne Fachgesimpel,

Letzte Test und Fazit dazu aus meiner Sicht.
Alarmgruppen haben sich bilden lassen.
Die Vernetzung als Gruppen ist sehr positiv.
Für den Hausgebrauch ok. Schlecht das man den Alarm nicht abschalten kann.
Batterien sind nur bis 1 Jahr Haltbar. Das lästige Bohren gefällt mir auch nicht
gibt ja heute Magnete oder 3M Klebemöglichkeit.
Und Ja wußte ich vorher war ja auch nur ein Test.
Einer muß ja testen :-)
Was die Einbindung in IO angeht eher schwierig.
Die Sonoff Brigde mit Portisch sowie Tasmota 8.3.1 Sensor .bin erkennt den Code nicht.
Mit dem Broadlink Pro konnte ich ein Code anlernen und den Alarm auslösen.
Damit schließe ich den Test, hätte mir gewünscht das wenigstens der 3 Byte Code
per Sonoff Brigde mit Portisch oder Tasmota Sensor .bin erkannt wird.
Hier dann bei Alarm per Telegramm eine Nachricht senden.
Das geht nur sehr umständlich und für die meisten nicht umsetzbar.
Fazit:
Nicht der richtige Rauchmelder zum mal eben mal einbinden.
Ob dies mit EspEasy oder RFlink geht müßte mal jemand gegenprüfen.
Mit meinen Möglichkeiten nicht einfach umsetzbar.

Soweit der Ralla :-)

[zahnheinrich]

@Ralla66
Danke für den Test! 👍
Scheint ja nicht das zu sein, was wir brauchen.
Teste bitte weitere Modelle mit besseren Aussichten.

[Ralla66]

@zahnheinrich

Teste gerne wenn du welche Käuflich erwirbst und mir zusendest.
Natürlich alles Kostenneutral für mich.
:-)

[zahnheinrich]

@Ralla66
Akut brauche ich keine neuen. Hab alles mit HM Meldern versorgt. Habe mich immer über die Preisgestaltung von ELV gewundert und warte gespannt auf eine brauchbare Alternative.
Komme ggf. gerne auf dein Angebot zurück.
Schönes Wochenende!

[KLVN]

@Ralla66 sagte in Erkundung Funk Rauchwarnmelder 433 Mhz mit Batteriebetrieb.:

So eine Handauswertung ist eben viel Arbeit.

Schau dir mal den "Universal Radio Hacker" (https://github.com/jopohl/urh) an ;) Mit dem Programm war ich in der Lage ganz easy die Signale einer Brennenstuhl-Fernbedienung aufzuzeichnen, auszuwerten und dann mit einem ESP32 und Raspberry Pi zu replizieren (der RPi hat Schwierigkeiten mit zu langen Signalen, weil er das Timing nicht einhalten kann. Ein ESP ist besser geeignet).

Senden die Rauchmelder bei einem Alarm immer dasselbe Signal? Dann bräuchtest du nur einmal alle aufzeichnen (oder eben nur das Signal vom Master) und einen ESP32 24/7 'sniffen' lassen, bis er das Signal empfängt. In ioBroker einen neuen Datenpunkt erstellen und mit dem "Simple RESTful API"-Adapter lässt du den ESP diesen neuen Datenpunkt ändern, sobald ein Alarm erkannt wurde. In Blockly reicht dann ein einfaches Skript, das auf eine Änderung vom Datenpunkt wartet und dann eine gewünschte Aktion ausführt.
So ähnlich habe ich meine Türklingel realisiert: Klingeltaster hängt an einem anderen Pi; sobald geklingelt wurde, ändert dieser Pi den Zustand eines Datenpunktes im ioBroker (zweiter Pi); ioBroker achtet auf diese Änderung und lässt dann meine Lampen blinken; danach wird der Zustand vom ioBroker wieder auf einen Standardwert zurückgesetzt.

[Ralla66]

@KLVN

Mal auf den Punkt gebracht.
Bekomme den Code nicht nach IO geschaufelt.
Läuft auf nem Wemos D1.
Tasmota RfRec sowie Sonoff Bridge bekommen den Code nicht in den Datenpunkt.
Hier auch soweit verständlich da die Libraries das nicht können.

Bin gerade am Uno die RcSwitch am testen.
Bekomme diese aber nicht aktiviert in der Tasmota.
Sollte ja unter Generic ein RCswitch anwählbar sein.

Nachtrag,

Selbst die RcSwitch kann den Code nicht empfangen.
Was bei meinen Intertechno Funksteckdosen auch nur Teilweise geht.

Könntest du das mit der Simple RESTful API genauer beschreiben bitte.
Ist alles neu für mich.

[OpenSourceNomad]

@Ralla66

Ich würde einfach den raw code mit esphome, genauer mittels remote_receiver component aufzeichnen und direkt einen switch oder binary_sensor daraus machen. Fertig ist die Laube.

[KLVN]

@Ralla66 sagte in Erkundung Funk Rauchwarnmelder 433 Mhz mit Batteriebetrieb.:

Nachtrag,

Selbst die RcSwitch kann den Code nicht empfangen.
Was bei meinen Intertechno Funksteckdosen auch nur Teilweise geht.

Könntest du das mit der Simple RESTful API genauer beschreiben bitte.
Ist alles neu für mich.

Bei mir ist es ein Python-Programm, das sich aber auch in C umschreiben lässt. Wenn jemand klingelt, wird ring() aufgerufen und dann der Datenpunkt im ioBroker, über den Simple RESTful API Adapter, geändert:

def ring(delay):
  requests.get("http://192.xxx.xxx.xxx:8087/set/0_userdata.0.Klingel?value=true").text
  ...

Im ioBroker wartet dann ein Skript auf diese Änderung und führt dann eine entsprechende Funktion aus:

Dieser Schritt kommt aber erst dann, wenn du deine Signale überhaupt empfangen kannst. Ohne empfangenes Signal bringt dir das hier nichts.

Und Info: Dieser Mechanismus hat keine Sicherheitsabfragen! Jeder, der im Netzwerk ist und IP und Name des Datenpunktes von ioBroker kennt, kann diese Variable setzen und einen Alarm auslösen. Statt einem einfachen true könntest du einen langen String nehmen, der dann im Skript hinterlegt ist und abgefragt wird. Also Wenn Variable == "123abc456def", dann löse Alarm aus. Sonst mache nichts. Ist immer noch nicht auf NSA-Niveau, aber macht die Sache etwas sicherer.

[OpenSourceNomad]

@KLVN said in Erkundung Funk Rauchwarnmelder 433 Mhz mit Batteriebetrieb.:

Statt einem einfachen true könntest du einen langen String nehmen, der dann im Skript hinterlegt ist und abgefragt wird. Also Wenn Variable == "123abc456def", dann löse Alarm aus. Sonst mache nichts. Ist immer noch nicht auf NSA-Niveau, aber macht die Sache etwas sicherer.

Klartext bleibt Klartext und http bleibt http :cold_sweat:

[KLVN]

@OpenSourceNomad sagte in Erkundung Funk Rauchwarnmelder 433 Mhz mit Batteriebetrieb.:

@KLVN said in Erkundung Funk Rauchwarnmelder 433 Mhz mit Batteriebetrieb.:

Statt einem einfachen true könntest du einen langen String nehmen, der dann im Skript hinterlegt ist und abgefragt wird. Also Wenn Variable == "123abc456def", dann löse Alarm aus. Sonst mache nichts. Ist immer noch nicht auf NSA-Niveau, aber macht die Sache etwas sicherer.

Klartext bleibt Klartext und http bleibt http :cold_sweat:

Richtig, aus diesem Grund habe ich auch nie von einer vernünftigen Sicherheit gesprochen. Ist vergleichbar mit einem Zahlenschloss am Fahrrad: Es macht die Sache sicherer, ist aber keine Garantie für Sicherheit (sofern man überhaupt eine Garantie darauf geben kann). Letztendlich muss jeder für sich selbst entscheiden, welches Niveau an Sicherheit man anstrebt und umsetzen kann.

[Ralla66]

@KLVN
@OpenSourceNomad

Ja ok wer ne Stehlampe per 433 MHZ anschalten / ausschalten will kommt bei mir rein.
Feuermelder müßte man gezielt machen.
Wichtige Dinge sind Autark bei mir ohne Internet.
Selbst wenn Internet dann per selbstgebauter Bridge.

Stellt sich einfach die Frage was an Stehlampen hacken so toll ist.
Interessiert kein Mensch.

Und ja Rollcode geht auch hatte die Uni Bochum getestet.

Aber bitte wer macht das für ne Stehlampe.

:-)

[OpenSourceNomad]

@OpenSourceNomad said in Sicherheit Smarthome:

Sicherheit und Smarthome ? Da können oder wollen wohl nicht viele was zu sagen 😬

@Ralla66 said in Erkundung Funk Rauchwarnmelder 433 Mhz mit Batteriebetrieb.:

Interessiert kein Mensch.

quod erat demonstrandum

Im allgemeinen kann man wohl sagen das du den Angriffsvektor mit jedem Stück "Smart Home" Hardware, welches Software/Firmware enthält und vernetzt ist grundsätzlich nur erhöhst. [,,,]

:arrow_right: Sicherheit Smarthome