Was schwätzen die nur??? -> Funkverkehr verstehen

[corneliusweiss]

Moin,

mit steigender Anzahl von Geräten bin ich jetzt schon einige male in den msg overload gerannt. Daher versuche ich meinen Funkverkehr zu verstehen und zu optimieren. Ich sniffe also den Funkverkehr uns ersetzte die Geräte ID's durch ihre Namen.

Dabei ist mir aufgefallen, dass die Zentrale mit einigen Geräten redet wo ich es gar nicht verstehe.
z.B. bei einigen meiner Fensterkontakte (HM-SEC-SC) sendet die Zentrale bei jeder Status-Änderung(öffnen/schließen):
HMLAN_Send:  HMLAN1 S:SBAEAAD58 stat:  00 t:00000000 d:01 r:BAEAAD58 m:1C 8002 000001 EG.Kueche.Tuer.Terasse 0101C800

Es ist jedes mal exakt die gleiche payload "0101C800"
Was machen die da???
Wie kann ich die payload verstehen? kann mir da jemand einen Tipp geben?


Ähnlich ist es bei einem Bewegungsmelder (HM-Sen-MDIR-O)
HMLAN1 S:SBB01AD28 stat:  00 t:00000000 d:01 r:BB01AD28 m:41 8002 000001 Innenhof.Bewegungsmelder 01017300

Bei jeder gesendeten Bewegung sendet die Zentrale was zurück. Allerdings ändert sich die payload da auch jedesmal. Ich würde trotzdem gerne verstehen was die Zentrale da mitzuteilen hat.

Kann mir jemand weiterhelfen oder einen Link zu den Specs des Protokolls geben?

LG
Cornelius

[martinp876]

Kann mir jemand weiterhelfen oder einen Link zu den Specs des Protokolls geben?

ich kenne keine Spec. Ich werden auch keine Schreiben - wenn sich einer die Zeit nimmt, ok.
Du kannst aber im Code nachsehen.
Es wird nicht 0101C800 gesendet sondern
8002000001xxxxxx0101C800
das ist ein ack. Sollt schon kommen, wenn eine msg an die Zentrale gesendet wird (000001 in deinem Fall)

Viel Spass beim dekodieren. Solltest du Potentioal zum Optimieren finden lass uns teilhaben.

[MadMax-FHEM]

Hi,

es gibt nicht wirklich eine Doku...

Das hier ist wohl neben dem Code in fhem die einzige "Doku":

http://matthiasm.com/homematic_protokolle.html

Wieviele Geräte hast du denn, dass du in Overload kommst?

Evtl. noch ein IODev und dann explizit die Geräte aufteilen auf die IODevs geht per vccu:

http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU#Dynamisches_IO

Gruß, Joachim

[corneliusweiss]

Hi, es sind derzeit 85 Geräte.
An einen zweiten IODev habe ich auch schon gedacht, ich wollte aber vorher noch optimieren. Da ist auch noch potential in meinen Schaltungen...

@martin: ich dachte auch nicht an eine spec von FHEM, sondern dass es da ggf. elv/eq3 Seitig etwas gibt. Irgendwo habe ich mal gelesen, dass es da XML's in der deren Firmware gibt. Aber ich habe das Projekt auf GitHub nicht mehr gefunden.

Ich hatte vermutet,  der ACK währe im log immer als
HMLAN_Send:  HMLAN1 I:K
dargestellt. Ist wohl was anderes?

und dann gibt es noch solche Nachrichten
HMLAN_Send:  HMLAN1 I:+4DA81C,02,01,00
hat das was mit signierten Nachrichten zu tun?

LG und Danke für die schnelle Antwort!
Cornelius

[Benni]

HMLAN_Send:  HMLAN1 I:K
dargestellt. Ist wohl was anderes?

Das müsste der KeepAlive für den HMLAN sein.

[martinp876]

eq3 hat das nicht offengelegt. macht uns das Leben schwer .

Wenn du im IO hmProtocolEvents einschaltest bekommst du schon einiges. Alles wesentliche sollte erklärt sein. Aber Vorsicht - das kann zu Timingproblemen führen. Also testen ja, dann wieder ausmachen. Wenn etwas nicht klappt, nicht beschweren.

Es sind nicht alle messages nachgeführt - insbesonderen die neueren. Aber wenn du hier durch bist ist der Rest geschenkt.

K ist keepalive. Kommt ja auch nicht als Antwort sondern einfach so - zusammenhanglos und regelmäßig.

eq3 unterstützt nur SW on top einer CCU, nicht als deren Ersatz - also keine Protokol-details.

Wenn du wissen willst wie der load-status der IOs ist sind einige Statistiken abrufbar. Schaue einmal in HMInfo nach statistiken
Solltest du unnötige message entdecken werde ich mich darum kümmern.
wie ist eigentlich die msg belastung in deinem System?