Unbekanntes device, oder?

[Puschel74]

Hallo,

A0DC4A61016656813D15506012700
................166568

A0C09867012BA8000000000E63A
................12BA80

A0C00867011439300000000DC41
................114393

Wobei ich mich jetzt frage wozu man dafür den Quellcode lesen muss 

Grüße

[Andre]

Hi,

konkret bei deiner Message:

A0EFF8202113EE01143930101000043

wird zerlegt in

Code Auswählen Erweitern


A 0E FF 82 02 113EE0 114393 0101000043

A : HM Message indicator
0E: Message length (0E -> 14 Byte)
FF: Message counter
82: Communication bit field
02: Message type
113EE0: Source ID (Absender)
114393: Target ID (Empfänger)
0101000043: Payload (Nachrichteninhalt)


Gruß
André

[martinp876]

wer den code verstehen will muss ihn lesen.

wer unbekannte IDs identifizieren will sollte eine vccu definieren und die IOs zuweisen. Dann werden in den Readings die IDs angezeigt:
   unknown_172A85  received
quellcode braucht es hier nicht.

[betateilchen]

Hallo Martin,

hast Du einen Tipp für mich, wie ich dieser Meldung auf die Spur komme?

Code Auswählen Erweitern

2014.06.20 09:54:53 2: CUL_HM az_Drucker attack:01127000258DF40103:01127000258DF400040000000000

127000 ist die ID meiner HMUSB, CCU2 und vccu
258DF4 ist die ID des Schaltaktors az_Drucker

EDIT:

Und diese Meldung im Log bekomme ich auch nicht weg:

Code Auswählen Erweitern


Use of uninitialized value $updt in concatenation (.) or string at ./FHEM/00_HMLAN.pm line 750.
Use of uninitialized value $updt in concatenation (.) or string at ./FHEM/00_HMLAN.pm line 752.


[Andre]

Hallo Martin,

das mit dem unknown_ID klappt super. Da ich umgeben von Homematic Nachbarn bin, wäre es für mich hilfreich den jeweiligen Empfänger zu sehen. Hast Du etwas dagegen, das in etwa so abzuändern:

Code Auswählen Erweitern


if ($defs{$ccu}){#
  push @evtEt,[$defs{$ccu},0,"unknown_$src:received_$dst"];# do not trigger
  return CUL_HM_pushEvnts();
}


?

Gruß
André

[betateilchen]

Hallo Martin,

was spricht eigentlich dagegen, die ganzen "help me!" Meldungen im Loglevel 4 auszugeben, damit im Standard-Loglevel 3 einfach keine Ausgabe erfolgt?

[krannich]

Hallo Martin,

was spricht eigentlich dagegen, die ganzen "help me!" Meldungen im Loglevel 4 auszugeben, damit im Standard-Loglevel 3 einfach keine Ausgabe erfolgt?

Ich würde mich diesem Vorschlag anschließen wollen! Oder ein Flag mit dem ich das an/ausschalten kann.

In meiner Nachbarschaft sind gut 30 Geräte registriert und die senden laufend.

[betateilchen]

Oder ein Flag mit dem ich das an/ausschalten kann.

Das globale Attribut "verbose" in Verbindung mit einem geeigneten Loglevel ist das (somit bereits existierende) Flag.

[krannich]

Das globale Attribut "verbose" in Verbindung mit einem geeigneten Loglevel ist das (somit bereits existierende) Flag.

Ich dachte eher daran über ein Flag zu bestimmen, ob die Daten überhaupt in dem Loglevel auftauchen.
Aber vielleicht ist das auch zu kompliziert gedacht.

[betateilchen]

Aber vielleicht ist das auch zu kompliziert gedacht.

Nochmal - auch für die BILD Leser: Der Loglevel in Kombination mit verbose IST das Flag. 0 = nix loggen, 1-5 legt fest, wieviel/wie genau geloggt wird.

[martinp876]

was spricht eigentlich dagegen, die ganzen "help me!" Meldungen im Loglevel 4 auszugeben, damit im Standard-Loglevel 3 einfach keine Ausgabe erfolgt?

der Ablauf in FHEM ist:
wenn ich der Endpunkt einer Message bin, sie also zuordnen kann mache ich das. Ansonsten muss ich anzeigen, dass ich nicht der Empfänger bin - der Kernal sucht dann weiter. Es könnte parser geben, die die Nachricht kennen. Ok - unwahrscheinlich in diesem Fall... aber wer weiss, das ist das Prinzip.
Der Log kommt aus dem Kernal - also mit Rudi verhandeln.

@Andre
hm - das ist immer nur die letzte $dst. Die Info ist in jeden Fall unvollständig.
Da die $dst antworten sollte solltest du diese auch sehen. Falls die $dst dir gehört sollte es ein 'attack' geben- zumindest bei einstellmessages.
Bringt es als etwas?
Aktuell wäre es möglich... da dieses Reading keinen trigger auslöst. Ansonsten hättest du eine triggerschwemme - würde dein System behindern.

@betateilchen
CUL_HM hat sich das letzte Kommado von HMUSB/ vccu an az_Drucker gemerkt.
Jetzt sendet jemand ein anderes kommando an az_Drucker - FHEM kennt es nicht. i.a. ist dies ein hackangriff - jemand hat die ID der Zentrale audgespäht und sendet an deine Devices.
In deinem Fall ist es wohl die CCU2 -die ist für FHEM auch extern - also eine Attack an die Sys-Integrity.

Errors sind beseitigt.

[Andre]

Hallo Martin,

ja das ist natürlich richtig, das wäre nur unvollständig. War bzw. ist für mich aber sehr hilfreich (Hatte ich zum Test mal eingebaut). Die antwortende Zentrale sehe ich auch, aber wer mit wem spricht nicht. Vielleicht kann man es sinnvoller benennen (last_dest_$dst)? Oder vielleicht kann der "verworfene" Funkverkehr in HMInfo abgebildet werden?

Gruß,
André

[martinp876]

Hallo Andre,

wir haben in keinem Fall ein "wer-mit-wem-redet" log in CUL_HM. Warum braucht es dies für Devices, die garnicht angemeldet sind?
Was ich nicht will ist ein debug-log in den Readings. Das gehört m.E. nicht hier rein - zum debuggen gibt es andere Methoden.
Wenn du wissen willst, mit wem ein unbekanntes Device sich unterhält, dass auch worüber? Also alles dekodieren?
Ich bin nicht überzeugt, dass dies einen Eintrag für den User rechtfertigt.

Der User hat die Optionen
- das Device einrichten
Der interessierte User hat die Optionen
- die helpme-logs auswerten

der entwickler kann
- rohmessages loggen(bei HMLAN zumindest)

braucht es wirklich mehr? HMInfo ist nicht zum loggen aufgestellt.
Gruss Martin

[Andre]

Hi,

ich bin eher vom Gegenteil überzeugt, ich denke es ist auch für den User interessant. Zumindest für mich, wobei mit der Inhalt der Message egal ist. Die "Help me"-Messages stehen nicht mehr im Logfile (wenn ich das richtig sehe), oder?. War aber auch nur eine Idee, Du entscheidest am Ende natürlich was Du umsetzen möchtest.

Gruß,
André

[martinp876]

Hallo Andre,

ich lasse mich gerne überzeugen - will aber, wie gesagt, die Readings nicht überfrachten.
Wozu es bei dir gut sein soll kann ich nicht erkennen. Es ist ein unbekanntes device. Sollte es an ein anderes unbekanntes device schicken ist es sicher irrelevant. Falls du etwas spezielles entwickelst ist dies m.E. kein Fall für die Readings - du kannst dann mit HMLAN die ID loggen.
Sollte das Unbekannte device an ein bekanntes senden könnte es interessant sein - wer triggert die "unsere" Devices? Das sollte aber abgefangen werden - zum einen durch peers und  zum 2. durch attack detection.

Help-me kommen nicht mehr, wenn die vccu die messages "anzeigt".

Was macht ein User mit der dst-ID? Ist der Fall allgemein von interesse? Wie gesagt, ich erkenne dies nicht

Gruss Martin