868Mhz-Funksignal ansehen mit DVB-T Stick

[Wortmann30]

Hm ok und wie kann ich dem Programm oder dem Schreikind auf die Schliche kommen?

Um jede Nacht Tipp bin ich froh.

Den Vorschub und die Sendelänge kannman dem Zeitstempel im Bild doch ablesen. So ca. Ne halbe Sekunde Sendezeit nehmen die Pulse ein.

[Familienvater]

Hi,

laut Samy's Erinnerungen ist ein Burst Signal 400 ms lang, evtl. wird da etwas dauernd geweckt.
Wie immer: rfd auf "alles loggen" stellen, und die grafische Darstellung mit den Events vom rfd anhand von den Zeitstempeln versuchen in Deckung zu bringen, wobei die Zeitstempel der CCU um einige Sekunden von dem PC abweichen können (die CCU-Uhr geht ein bischen nach dem Mond, je nachdem, wie lange der letzte NTP-Sync her ist...).

Der Familienvater

[Wortmann30]

Hi

Danke für die Antwort.

Das bringt mich zum Thema wo das ganze etwas kompliziert wird, da ich im Moment laut Pocket Control Synchronisierung 180 Geräte betreibe. Davon ca. 40 als Wired über den RS485 und CUXD Geräte also bleiben immer noch 140 Geräte.

Also würde ich das Ganze noch etwas mehr eingrenzen und nicht eine Datenflut durch alles RFD loggen produzieren durch die ich mich dann kämpfen muss.

So nun meine Fragen zum Eingrenzen:
- Wer sendet diesen Burst? Die Zentrale also der Raspberry oder die einzelnen Geräte? (ich denke auch Geräte können den Burst senden Oder?)
- Wenn Geräte einen Burst senden welche sind das?
- Welche Geräte wachen durch den Burst auf?
- Die Zentrale sendet doch ein AM (Amplituden Moduliertes) Signal aus? Wenn das Signal ausgesandt wird sollte es doch theoretisch so sein das je näher ich dem Gerät komme das sendet je mehr sollte der Ausschlag im oberen Teil der SDR Software sichtbar sein?
- Wenn ich weiss welche Geräte ein Brust Signal senden, sollte ich doch diese nur auf Protokolieren in den Geräte Einstellungen stellen?

Ich weiss das die Heizungs Thermostate HM-TC-IT-WM-W-EU und die Batterie Aktoren 4 Fach HM-LC-Sw4-Ba-PCB sowie der einfach HM-LC-Sw1-Ba-PCB ein Burst Signal verwenden. Gibt es da noch mehr?

Von all diesen Geräten habe ich 12 Thermostate, 2 4-Fach und 2 1-Fach Aktoren.

Ich weiss auch das die Fenster Drehgriff Sensoren HM-Sec-RHS Bursts irgendwie nutzen aber nicht aufwachen. Davon habe ich 17 Stück.

Machen die Normalen Fenster Kontakte HM-Sec-SC-2 von denen habe ich 18 Stück, das auch?

Von den Optischen Fenster Kontakte HM-Sec-SCo habe ich 1 Stück in Betrieb, was ist mit dem?

Ich denke die Fenster Kontakte kann ich als Fehler Quelle ausschliessen?

Was ich in der Vergangenheit Probleme hatte waren die Heizungs Thermostate, da waren alle 2-3 Monate die Batterien leer bis ich diese schlussendlich aus Verzweiflung alle auf Netzbetrieb umgebaut habe.

Ich möchte meine Fehlersuche einfach so weit wie möglich eingrenzen.

Danke

[Familienvater]

Hi,

grundsätzlich kann jedes Gerät Burst-Signale aussenden (wenn es in der Direktverknüpfung so konfiguriert ist), um alle Batterie-Empfänger aufzuwecken.
Da ich keine TFKs oder RHS in einer Heizungsgruppe betreibe, kann ich es dafür nicht sagen, aber rein logisch gesehen müsste ein TFK oder auch RHS in einer Heizungsgruppe eigentlich den WT oder auch die HTs per Burst aufwecken, wenn sich der Zustand des TFK/RHS ändert.

Was das Protokollieren (Option) auf der Zentrale angeht:
Keine Ahnung, ich denke, da werden nur Events aufgezeichnet, bei denen die CCU direkt (Zentralenkennung sendet oder es wird gezielt an die Zentralenkennung gesendet) oder indirekt (Empfang eines Rundspruchs an alle) involviert ist, Details dazu ob mit oder ohne Wakeup-Burst etc. tauchen da aber nicht auf, und auf das Syslog hat die Protokollieren-Option keine Auswirkung, da zählt alleine der Loglevel des Daemons.

Auf rfd-Seite kann man nicht "vorfiltern", da gibt es nur friß oder stirb, aber weil es der rfd ist, werden dort keine wired- oder cuxd-Geräte geloggt, das sind andere Daemons, die man auch vom Loglevel höher drehen können.
Und der rfd (multimac) würde auch erkannte Burstsignale loggen, wenn diese nicht von der CCU aus gesendet, aber empfangen werden (weil z.B. ein TFK das WT aufweckt), der Sender des Burst kann nicht identifizert werden, aber anhand der folgenden Funkpakete kann man da im Zweifelsfall Rückschlüsse drauf ziehen (wenn das alles von der CCU selber gescheit mitgehört wird).

Du kannst Dir auch jede angelegte Direktverknüpfung in der CCU anschauen, ggf. als Experte, da müsste man auch sehen, ob eine Verknüpfung zwischen TFK/RHS und WT ein Burst sendet (wovon ich ausgehe).

Mit dem DVB-T-Stick SDR zeigt Dir nur das evtl. Problem grafisch an, die Pakete dekodieren tut es definitv nicht, da hilft definitiv nur der multimac bei (oder eine externe Sniffing-Lösung, die Bidcos-Pakete dekodieren kann).

Der Familienvater

[Wortmann30]

Hi

Also schließe ich daraus das ich am besten mal dann wenn ich das versuche herraus zu finden wer da funkt das rfd log einschalte und nach Parallelen Ausschau halte?

Da habe ich gerade nich eine Frage zu diesen Logs die sind derzeit alle 3 auf nur Fehler gestellt. Wohin speichern die denn und in welchem Zyklus wird gespeichert? Fortlaufend oder nach Zeit Intervall oder log Menge (wenn bestimmte Zahl von Einträgen erreicht wird).
Und ist es nich klüger das bei einer Raspberrymatic die auf es Karte speichert ab zu schalten um die sd Karte zu schonen?

[Familienvater]

Hi,

das syslog geht nach /var/log/messages (und wird 2x? nach .0, .1 rotiert). Da sind je nach Menge der Funkerei ca. 5-10 min drin, am besten ist ein externer Syslog-Server, der könnte theoretisch dann auch noch Zeugs rausfiltern, was man nicht braucht.

Von Raspi, Yahm und Co habe ich keine Ahnung... Auf der ccu ist /var/log so etwas wie eine Ramdisk, weswegen man nach einem Absturz mit Reboot dort keinerlei Informationen zur Ursache mehr findet.

Der Familienvater

[Wortmann30]

Ok

Eine Frage habe ich noch für den Moment
http://homematic-forum.de/forum/viewtop ... 30#p323190
Was denkt ihr Handel es sich da um ein Schreikind da die Pulse direkt hintereinander kommen und dann wieder länger so ein bis zwei Minuten Ruhe ist oder sind das Einzelgeräte? Eventuell ne Kettenreaktion nachdem einer anfängt? Auf was soll ich da achten bei der Suche ich denke so ein Input ins nützlich zur Analyse.

Danke

[Familienvater]

Hi,

die Frage könnte dir nur das historische Syslog des rfd beantworten. Das kann Deine Homematic sein, das kann auch die Homematic der Nachbarn sein, vielleicht auch Max von jemand in der Nähe, oder eine Discounter-Wetterstation, die auf 868 Mhz ihre Daten überträgt, oder eine Garagentor-FB...
Wenn es Bidcos ist, und die CCU hört das auch, dann schreibt der rfd dazu was ins syslog.

Alles andere ist Kaffeesatzlesen, und auf meiner Glaskugel ist aktuell rauhreif.

Der Familienvater

[Wortmann30]

So habe jetzt mal ein wenig beobachtet

die Pulse kommen und ich identifiziere die MEQ0836257 dort steht auch im Log um die zeit mit Versatz von ca 2 sec gegenüber meiner SDR Anzeige das der Burst=1 sendet ist es das?

Wenn ich unter den Geräten suche finde ich diese Seriennummer nicht, daher gehe ich davon aus dass das der Rasberrymatic Transmitter ist.

Kann das zusammen passen? Oder nach was genau muss ich ausschau halten?

Hier mal den SDR Ausschlag:

Und das Log dazu:

Dec 3 13.docx

(14.58 KiB) 142-mal heruntergeladen

[Familienvater]

Hi,

schau mal hier http://homematic-forum.de/forum/viewtop ... 10#p318396

da habe ich beschrieben, wie man an die "Funkadressen" der Geräte kommt. Das nächste mal Syslog bitte einfach als text-Datei anhängen oder in Code-Tags posten, docx mag nicht jeder.

MEQ0836257 ist das genutzte Funkinterface, entweder die "CCU" selbst, oder ein LAN-Gateways, die Funkadresse der Zentrale müsste die 0x3D12CF sein.

Was mich ein wenig wundert, ist das der Raspi das gesendete Event nicht aufdrösselt, aber das ist eben evtl. Raspi, ich bin CCU2 mit multimac gewohnt, da ist das dann sogar bis auf byte-Ebene runtergebrochen, was so rein- und rausgeht.

Der Familienvater