Moinsen,
habe locutus´ Board für den AskSynAnalyzer (https://forum.fhem.de/index.php/topic,102701.0.html) neu in Betrieb genommen und bin restlos begeistert sowohl von Hard- als auch der verwendeten Software.
Das Teil schreibt ja Telgramme inklusive der eigentlichen Daten auf die CSV (die im AskSinAnalyzer allerdings nur klassifiziert, aber nicht dekodiert werden).
Solche Kolonnen liefert ja auch das HM-Sniffen in FHEM.
Auf der Suche nach Infos zur Interprettion (Format, Bedeutung) komme ich jedoch nicht weiter. Klar, die Adressen findet man schon problemlos, aber Flags und "Nutzlast" könnte ich mir jetzt mühsam aus CUL_HM erarbeiten oder dem Quelltext zum AskSinAnalyzer ...
Hat/kennt jemand eine Quelle, und sei es ein 200-seitiges PDF? Findet sich in den Quelllen zur OCCU so etwas?
Irgendeine Idee?
martin786 und frank lesen das natürlich schon im Schlaf, ich möchte das auch gern lernen oder mir ein Tool dafür basteln...
so ein homematic duden wäre ne feine sache. :)
ich kenne nichts.
früher hatte homegear ein paar beispiele, da sind meine alten links aber nun tot.
ansonnsten hast du die verdächtigen ja bereits aufgezählt.
am besten gehts eigentlich "live" im eventmonitor mit sniffen. man braucht es ja höchstens, wenn etwas nicht funktioniert.
dabei ist aber eigentlich nur der timestamp wichtig, wegen timing. weil wenn eine antwort zu spät kommt, dann schläft der partner eventuell schon. fehler in der nutzlast kommen ja eigentlich nicht vor.
jedes device macht auch irgendwas etwas anders.
welches byte nun temp oder humidity anzeigt ist in der regel unwichtig. wenn doch mal, findet man es auch in culhm oder die bytes "bewegen" sich entsprechend, dann hast du die position.
fang klein an, zb mit statusrequest, bei verschiedenen devices und channels.
oder anlernmessages mit und ohne pairing.
viel spass jedenfalls. 8)
ja, try & error hatte ich auch schon in Erwägung gezogen. Würde auch genau so vorgehen: Fenster im Büro auf und zu - damit dürfte das wesentliche klar sein. Und so weiter. Da lernt man schön analysieren. Irgendwann hatte ich auch mal das Binärspeicherformat eines ISDN-Telefon-Adressbuchs analysiert und damit eine Soft geschrieben, die weit über die Herstellersoftware hinaus Funktionen hatte.
Viel Inhalt ist da ja selten. Die Meldung eines Fensterkontaktes dürfte sich von einem Schalterinterface in nichts unterscheiden bspw - bis auf die hmID eben und damit ist das Gerät an sich dann identifiziert...
Nutzlastfehler hatte ich in der Tat erst ein einziges Mal: Ein Wandthermostat sendete solide eine falsche hmID - reagierte nicht auf Steuerbefehle, tauchte dafür im Autocreate neu auf und lieferte verlässliche Daten (Weather). Nach einem Batteriereset war alles wieder ok.
Die Ergebnisse wäre eigentlich auch was fürs Wiki.
edit: es sieht doch gar nicht so schwer aus, soviel habe ich gerade allein herausgefunden:
0. Byte: Anzahl der folgenden Bytes. Der AskSinAnalyzer nimmt dies als Nachrichtenlänge.
1. Byte: "Count": fortlaufender Zähler der ausgesendeten Nachricht des Gerätes, die vom Antworter in der Antwort wiederholt wird (quasi eine temporäre Funktelegramm-ID, 0-255)
2.+3. Bytes: Bezeichnung der Nachricht, Nachrichtenflags
4.-6. Byte: hmId des Senders
7.-9.Byte: hmId des Empfängers
Ab da wird es spezifisch: ein Kontakt etwa sendet nun ein 01 (ist nicht sicher, irgendwo müsste auch eine Kanalnummer versteckt sein), anschließend die fortlaufende interne Zählung des Ereignisses, dann den Wert (C8=200 für offen, 00=0 für geschlossen). Wird ein Ereignis an mehrere Geräte/Peers gemeldet, so bekommt jedes Gerät dasselbe Ereignis gemeldet. Eine wiederholte Statusmeldung eines geschlossenen SCo (stündlich) ist ein Byte länger und endet immer mit 06 01 00 00 (eins davon ist der Zustand 00 - ich lasse jetzt deswegen nicht ein Fenster eine Stunde offen stehen).
Interessant sind in diesen Fällen die Antworten der Zentrale: Eine zyklische Statusmeldung wird nur quittiert, nach dem Empfänger folgt 00. Wenn eine Änderung erkannt wurde, folgt eine zusätzliche Quittierung, in der das Sensorereignis (01 + Ereignisnummer) wiederholt wird...
Hin und wieder sendet die Zentrale zwei Antworten oder drei Antworten hintereinander. Das finde ich besonders spannend, ist mir aber auch erst heute nach dem Update untergekommen. Gab es da eine Änderung?
edit2: was nach dem Empfänger (Target) an Bytes kommt, hängt wesentlich von der Art der Message ab (Byte 3).
Diesen Post bitte nicht als Referenz benutzen, meine Orakel werden sich als noch als teilweise fehlerhaft herausstellen...
Schaut mal hier https://github.com/trilu2000/NewAskSin/blob/master/docs/AskSin%20library.docx
Da stehen viele Grundlagen drin.
So, DAS habe ich gesucht. Jetzt kann ich selber gucken ob ich richtig liege ...DANKE!
Edith meint, das da noch einiges fehlt. Irgendwo müsste es eine aktuellere und vollständigere Version geben ...