Böse: Störsender auf 433 / 868 MHz, erkennen wir das ?!

Begonnen von JoWiemann, 10 Mai 2016, 20:21:11

Vorheriges Thema - Nächstes Thema

KölnSolar

Hi Jörg,
super Fragestellung. Habe mich auch schon ansatzweise mit dieser Frage beschäftigt.
ZitatDie meisten Sensoren senden eher im 5 Minuten, wenn nicht noch länger, Bereich
Dagegen hätte ich die NC-5462 anzubieten. Die funken eigentlich zuviel, aber für den Einsatzzweck....
Mit CUL und RFXTRX empfangbar. Leider oftmals geringe Reichweite.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Koelschejeck

#16
Zitat von: betateilchen am 10 Mai 2016, 21:13:10
Du meinst so, wie die immer wieder auftretende Frage, was mit den letzten drei Buchungssätzen in einem EDV System passiert, wenn ein Flugzeug auf das Bürogebäude stürzt, in dem der Computer steht?

Achso... na dann.
Wenn es eine vernünftige Datenbank ist - Nichts :)

Zum Thema:
Funktechnik ist immer anfällig, aber man kann ja so weit es geht/der Aufwand vertretbar ist versuchen sie zu schützen.


Gesendet von meinem HTC One_M8 mit Tapatalk

mbruehl

Also wenn ich mir  im Event-Monitor ansehe, was da so alles mit CUL_HM beginnend durchläuft (Grade Bewegungsmelder mit Helligkeit, und vor allem der Stromzählermonitor) , dürfte ein Watchdog auf  30Sek. ohne CUL_HM.* Meldung ausreichend sein. Wenn dieser auslöst kann man dann ja evtl. genauere aber aufwändigere Tests starten (z.B. Anschalten einer Lampe und testen ob diese anständig quittiert)
FHEM 5.6 auf Banapi mit SSD
HM-Lan mit vielen HM-Devices für Licht/Rolladen/Heizung
VDR und XBMC mit FHEM Anbindung, Denon AVR und Logitec Harmony Hub im Dachboden

Bapt. Reverend Magersuppe

#18
Man kann mit einem DVB-T-Dongle das 433/868er Frequenzband überwachen (http://sdr.osmocom.org/trac/wiki/rtl-sdr). Wenn da ein (starkes) Signal länger als x Sekunden sendet, stimmt was nicht. Ob nun die eigene Installation oder eine in der Nachbarschaft gejammt wird oder bei irgendwem ein Krümmel im Funkschlüssel vom Auto in der Hosentasche klemmt, weiss man so natürlich nicht.

Wenn man das dann am Laufen hat, wird das vermutlich 5 Jahre oder noch länger vor sich hin horchen und es wird NICHTS passieren ausser etlichen Fehlalarmen.
--
If I was born in 1453, Leonardo da Vinci would be jealous of me.
Reverend Paul Egon Magersuppe
Aus versicherungstechnischen Gründen sind sämtliche Beiträge von mir rein spekulativer und theoretischer Natur und sollten nicht in die Tat umgesetzt werden!
Bin hier selten DRIN. AUS GRÜNDEN!

Wernieman

Wenn ich es mir richtig durchlese, gier es hier 2 "Ergebnisse"

a) Für Alarmanlagen ist die Zuverlässigkeit von Funk etwas .... einschränkend. Würde mich in diesem Bereich auch nicht darauf verlassen (wie die "echten" Profis).
Meine Meinung über FHEM als Alarmanlage dürfte bekannt sein ;o)

b) Aber für den normalen Betrieb wäre eine "Überlastungserkennung" doch mehr als Sinnvoll und ?eventuell möglich?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Markus M.

Besonders wenn man 433MHz nutzt gehört ein SDR zur Grundausstattung.
Ein regelmässiger Check des letzten Timestamps macht auch Sinn.
Es kommt häufiger vor als man denken würde, dass sich ein Sensor dank Feuchtigkeit oder schwacher Batterien in einen Störsender verwandelt.
Aktuell weder Smarthome noch FHEM vorhanden

KölnSolar

ZitatEin regelmässiger Check des letzten Timestamps macht auch Sinn.
Meinst Du mit einem  at +*00:00:ss und Prüfung auf den timestamp des CULs oder sonstigen Transceivers ?
watchdog geht ja nicht, weil keine "eigenen" Events erzeugt werden.
Signalisieren müsste man dann kabelgebunden, z.B. Telefonklingeln über Fritzbox, InfrarotSender/-Empfänger, Fernseher ausschalten.....  ;)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

JanHH

Zitat von: betateilchen am 10 Mai 2016, 22:38:43
Und wenn ich eine Alarmanlage haben wollte, die störsicher ist, dann wäre das bestimmt keine auf Funksignale basierende Lösung.
Wie bei jeder drahtgebundenen Anlage auch würde man eine (zeitnahe) Sabotageerkennung benötigen.
Das geht auch mit Funk, ist aber nicht trivial.
Für eine ganz andere Anwendung habe ich es mal mit einem kryptographisch gesicherten Challenge-Response-Verfahren gelöst - Zentrale = Messgerät sendet einen signierten Text sowie einen Zufallswert sowie einen Zeitstempel. Die Gegenstelle (hier. Sensor) validiert die Challenge und sendet dann eine signierte Antwort (d.h. signiert den von der Zentrale gesendeten Zufallswert sowie natürlich Messwerte/Status).
Damit authentifizieren sich die Stellen gegenseitig. Der Zeitstempel verhindert Replay-Attacken.
Schwierig ist dabei eine sinnvolle Festlegung, ab wann man Alarm gibt. Auch ohne Angreifer kann ja mal ein Paket im Äther verschwinden.

KölnSolar

nachdem nun auch der RFXTRX seinen state-timestamp regelmäßig aktualisiert, habe ich es mit einem at umgesetzt:

Zitatdefine check_jammer at +*00:00:05 {if (ReadingsAge('TRXUSB','state',0) > 30) {fhem('set Fritzbox ring 611 60')}}

Hat den zusätzlichen Charme, dass ich auch merke, wenn der RFXTRX mal keine Lust hast.

Mal sehen, wie viel Fehlalarme(Telefonklingeln) ich nun bekomme.
Grüße, Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

betateilchen

Zitat von: rudolfkoenig am 10 Mai 2016, 23:11:08
Raus damit, das ist hier eine Lehrveranstaltung :)

Nein. Als Funkamateur darf ich dazu keine Lehrveranstaltung abhalten.

Zitat von: Bapt. Reverend Magersuppe am 12 Mai 2016, 15:32:25
Wenn da ein (starkes) Signal länger als x Sekunden sendet,

Genau das tun professionelle Störsender nicht. Allenfalls die 10-Euro-Chinaware arbeitet mit einem Dauerständerträger, was aber in vielen Fällen einfach wirkungslos ist.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

schka17

Zitat von: KölnSolar am 17 Mai 2016, 15:43:31
nachdem nun auch der RFXTRX seinen state-timestamp regelmäßig aktualisiert, habe ich es mit einem at umgesetzt:

Hat den zusätzlichen Charme, dass ich auch merke, wenn der RFXTRX mal keine Lust hast.

Mal sehen, wie viel Fehlalarme(Telefonklingeln) ich nun bekomme.
Grüße, Markus
Hallo Frank,

Ich habe das auch gleich mal eingefügt, ich habe nämlich seit einiger Zeit das Problem, dass alle meine Torfernbedienungen (Came, 433 MHz) aus nicht nachvollziehbaren Gründen manchmal nicht funktionieren, manuelle Bedienung der Tore aber sehr wohl. Da ich sonst keine Aktoren, Sensoren, in diesem Frequenzbereich verwende, ist mir bisher nicht aufgefallen dass es hier tatsächlich scheinbar ziemliche "Aussetzer" gibt.
Jetzt habe ich habe ich diese "Ausfälle" mal gelogged und die entsprechenden Zeitfenster, nur wie soll ich jetzt weiter vorgehen um den Verursacher zu finden.
Hat da jemand eine Idee?

Gruß

Karl

M: Thinclient x64 Debian | CUL FS20, HMS100WD, HMS100TF, HMS100T, HMS100CO, S300, S555TH | OWServer DS1420, DS18B20, DS2408 | RFXCOM UVN128, THWR800, THGR228N,RTGR328, PCR800 |Jeelink PCA301 EC3000|CUNO+IR|HMLAN|HMUSB|CUL433 Somfy|mySensors|espEasy
S1:Raspberry mit BPM810, Jeelink EC3000

KölnSolar

Frank ?!?!?!
Ist schon etwas off-Topic Dein Thema. Mach doch lieber ein neues Thema unter Anfängerfragen auf und beschreib Dein Problem und Deine Umgebung(z.B. Art des Transceivers,Nur-Senders; FHEM_Modul,433-Protokoll.....) noch etwas genauer. Ich könnt mir vorstellen, dass es am sendenden Gerät liegt, also weniger eine Störung, sondern qualitativ zu schlechtes Signal. Aber das ist mehr das Ergebnis meines Glaskugelblicks  ;)
Grüße, Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

schka17

Zitat von: KölnSolar am 19 Mai 2016, 10:04:53
Frank ?!?!?!
Ist schon etwas off-Topic Dein Thema. Mach doch lieber ein neues Thema unter Anfängerfragen auf und beschreib Dein Problem und Deine Umgebung(z.B. Art des Transceivers,Nur-Senders; FHEM_Modul,433-Protokoll.....) noch etwas genauer. Ich könnt mir vorstellen, dass es am sendenden Gerät liegt, also weniger eine Störung, sondern qualitativ zu schlechtes Signal. Aber das ist mehr das Ergebnis meines Glaskugelblicks  ;)
Grüße, Markus
Sorry, natürlich Markus

Wieso ist das Thema offtopic, gehts nicht um die Erkennung von Störsendern? Hätte ich jetzt so verstanden.

Ich habe kein Problem mit meiner Umgebung, soweit es FHEM betrifft. Ich habe das Problem das dass 433 MHz Band zeitweise nicht nutzbar ist und ich die Ursache herausfinden will.  Insofern ist es also offtopic da mein Thema nichts mit FHEM zu tun hat.

M: Thinclient x64 Debian | CUL FS20, HMS100WD, HMS100TF, HMS100T, HMS100CO, S300, S555TH | OWServer DS1420, DS18B20, DS2408 | RFXCOM UVN128, THWR800, THGR228N,RTGR328, PCR800 |Jeelink PCA301 EC3000|CUNO+IR|HMLAN|HMUSB|CUL433 Somfy|mySensors|espEasy
S1:Raspberry mit BPM810, Jeelink EC3000

rudolfkoenig

Hier ein Video von busware, wo ein scheinbar totes Geraet (MAX! Thermostat) erstaunliche Stoer-Aktivitaeten zeigt:

https://youtu.be/ZR2VQ460duk