Empfängerwanderung

[Rockojfonzo]

Jetzt hätte ich da gerne mal ein Phänomen:

Ich benutze normalerweise zwei Sender/Empfänger, einen CUL oben unterm Dach an Linux-Kiste, einen HMLAN im Keller.

Nun musste ich meinen CUL für ein paar Tage ausleihen. Also FHEM gestoppt, CUL abgezogen, neu gestartet, alle mit dem HMLAN gepaarten Geräte laufen einwandfrei.

Nun ist mir aufgefallen, dass plötzlich automatisch vom mit dem CUL gepaarten und mit

Code Auswählen Erweitern

attr DG.Schlaf.Heiz IODev CUL
versehenen Device(!) HM-CC-RT-DN die Messdaten vom HMLAN empfangen werden.
Also exakt gesprochen geht es (natürlich) um den Kanal 04. Aber beim Kanal kann ich doch gar kein IODev angeben?

Soll das so? Ich dachte, über die eindeutige hmId würde ein Device immer nur mit dem Empfänger reden, mit dem er ursprünglich gepaart wurde.
In diesem Fall ist das natürlich eigentlich sogar ganz praktisch, aber welche Möglichkeiten hat der böse Nachbar?
Jaja, ich weiß, solange sich bei mir nichts im Paarungsmodus (also bei den Geräten...  ) befindet, sollte da nichts passieren können. Trotzdem fand ich das irritierend.

[Puschel74]

Hallo,

Jetzt hätte ich da gerne mal ein Phänomen:

Hättest du gerne eines oder hast du eines? 

über die eindeutige hmId würde ein Device immer nur mit dem Empfänger reden, mit dem er ursprünglich gepaart wurde.

Ich dachte das über die hmid und dem IODev das Device immer nur über den zugewiesenen CUL angesprochen wird.
Umgekehrt (Devcie sendet - CUL oder HMLAN empfängt) ist es doch egal welcher CUL oder HMLAN sich angeprochen fühlt.

aber welche Möglichkeiten hat der böse Nachbar?

Wie du schon geschrieben hast:

Jaja, ich weiß, solange sich bei mir nichts im Paarungsmodus (also bei den Geräten...  ) befindet, sollte da nichts passieren können.

Kann auch nicht da das Device mit dem IODev gepairt ist.

So zumindest mein Verständnis von IODev, Sender und Empfänger.

Grüße

[Rockojfonzo]

Ich dachte das über die hmid und dem IODev das Device immer nur über den zugewiesenen CUL angesprochen wird.
Umgekehrt (Devcie sendet - CUL oder HMLAN empfängt) ist es doch egal welcher CUL oder HMLAN sich angeprochen fühlt.

Genauso ist es auch: Senden an das Device geht nicht über den falschen ,,Sender", also hier den HMLAN. Er empfängt nur.

Also alles gut.

[chris1284]

kurze frage: wenn er mit HMLAN die daten empfangen kann aber nur nicht senden weil die hmid eine ander ist, kann er aus den empfangenen daten die hmid extrahieren? wäre es dann möglich mit dem hmlan auch  zu senden?

sprich ich höre die geräte, höre die hmid, setze die bei mir ein  und sende somit zu devices die ich eigentlich nicht paired habe?

das würde auch mit dem wiki-artikel zum hmlan einhergehen. dort wird beschrieben wie man von cul zu hmlan wechslet ohne neu paaren zu müssen.

das wäre dann ja eine arge lücke oder nicht (falls das abgehörte devices die hmid irgendwie preis gibt)?

[Puschel74]

Hallo,

senden kannst du immer - auch mit der falschen hmid. Nur reagiert dann nichts drauf 

Aber zu deinen Fragen:
Wenn du aus den gesendeten Daten die hmid extrahieren kannst kannst du deinem Device natürlich die hmid zuweisen und über dieses dann senden.
Ob die HM-Geräte die hmid aber immer mitsenden weiß ich nicht -->martin

das wäre dann ja eine arge lücke oder nicht

Naja. Bei FS20 brauchst du nur den Haus- und Gerätecode und kannst alles schalten und dimmen wie du möchtest.
Aber von "arger Lücke" würde ich hier nicht gerade sprechen - es sei den die Geräte senden die hmid immer mit.
Du musst ja noch den Aufwand (wie hoch der ist weiß ich nicht) betreiben um die hmid zu extrahieren.

Grüße

[Rockojfonzo]

Hab's gerade mal probiert und dem HMLAN die hmId vom CUL gegeben. Dann Änderung von set_desired-temp.

Device hat STATE IOErr und desired-temp ist unverändert. Also ich glaube nicht, dass es so (einfach) geht. Daumen hoch.

[Rockojfonzo]

Urrrgh! Zu früh "gefreut". Änderung wurde akzeptiert.

Also, mit bekannter hmId klappt's wohl auch bei entsprechender Fertigkeit mit dem Nachbarn.

[Mr. P]

Hej,

ich wollte auch gerade schreiben... es ist in der Tat so einfach.
Aber eben deshalb gibt es ja noch die AES-Verschlüsselung. Wenn der Schlüssel verwendet wird (und bitte nicht den Default-Key dafür verwenden), ist es schon ein gutes Stück schwieriger, sich Zugang zu verschaffen.
Aber weil das ganze Thema gerade ohnehin aktuell ist, könnt ihr hier weiter lesen.

[Puschel74]

Hallo,

Aber eben deshalb gibt es ja noch die AES-Verschlüsselung.

Die aber nur in Verbindung mit einer Keymatic klappt und nicht mit einem Schalter/Dimmer/Thermostat etc. (so wie ich das verstanden habe).

Aber stimmt.
Martin ist schon dran so wie ich das gelesen habe.

Grüße

[LuckyDay]

Die aber nur in Verbindung mit einer Keymatic klappt und nicht mit einem Schalter/Dimmer/Thermostat etc. (so wie ich das verstanden habe).

Man schaue ins Register vom device nach R-sign off/on

[martinp876]

Ich fasse noch mal zusammen:

- Funk kann (natürlich) jeder Empfangen - das ist unabhägugn von einer ID (gleiche Frequenz, modulation, protokoll...)
- so lange du in reichweite bist wirst du die Messages deines Nachbarn empfangen - und er deine
- er werden immer Sende und Empfangsadresse übertragen
- Ohne AES ist es ein leichts (wenn in Reichweite) alle deine Geräte zu steuern - da muss man nicht viel können
- Über ein IO device kann man alle Addressen senden, es ist einfach die addressen zu faken - macht FHEM auch bei virtuellen Devices.

Somit werden auch immer RSSI werte für ggf mehrere IOs angezeigt
- FHEM empfängt nicht "strikt" - es werden alle empfangenen Messages ausgewertet, egal von welchem IO. Es kann passieren, dass ein IO konzeptionell schneller ist (mein CUL über USB ist schneller als HMLAN über Etnernet) - FHEM antwortet trotzdem(hoffentlich) korrekt. (wurde erst die Letzten Wochen verbessert)
- FHEM sendet strikt - also nur über das Assignte IO-Device. Hat man keines festgelegt sucht FHEM eines aus. Das ist dann 'fix' bis zum Reset.

- das IO device sollte die HMId haben, mit dem das Device gepairt ist.
- attr IODev an Kanälen hat mit Sicherheit keinerlei Wirkung
- man kann mehreren IO devices die gleiche HMId geben. Bei HMLAN könnte dies zu doppelten ACKs führen, was aber erträglich sein sollte. Etwas sauberer aber umständlicher ist es, verschiedene  HMIds zu nutzen.

- wenn man einen Nachbarn mit HM im Funkfeld hat sollte man dessen erkannte Devices auch definieren und das Attribut 'igonre' vergeben
- Sofern der Nachbar nicht böswillig ist sollte es kein Problem sein, sich das funkfeld zu teilen. Lichter und Heizung wird er schon nicht steuern.
- sobald man sicherheitsrelevante Dinge nutzt (key, Alarmanlage,...) ist AES unerläaslich. Das system kann immer noch gemonitort werden, aber der AES schlüssel sollte sicher sein... darauf basiert die gesamte sicherheit!
- FHEM zeigt mittlerweile an, wenn jemand versucht kommandos auf eigenen devices ausführen will. Readings zum Triggern kommen noch

Gruss Martin