Einen schönen Guten Abend Zusammen! Ich versuche gerade das Netzwerkprotokoll eines Smarthome-Systems zu analysieren. Das System kommt von der Firma TFA-Dorstmann und wird unter dem Label WEATHERHUB vertrieben. Es bindet Funksensoren (Temperatur, Hygrometer, ...) mit 433 MHz Funksendern an ein Ethernetfähiges Gateway an, welches die gemessenen Werte dann an den Dienst MobileAlerts sendet. Nun ist die einzige Möglichkeit die Daten dort abzurufen eine furchtbare Smartphone App, die weder Graphen zeichnen kann noch die Daten exportieren lässt. Es gibt also keine Möglichkeit die Daten lokal zu speichern und das System ohne die Cloud zu benutzen. Ich habe jetzt die Adresse, des Servers, an den das Gateway die Daten sendet im DNS auf meinen Rechner gesetzt und dort einen Socket offen, der die Daten (zunächst uninterpretiert) entgegennimmt und dem Gateway den Empfang quittiert (sonst wechselt es in einen Fehlermodus und versucht eine erneute Übermittlung). Da es im Netz noch nichts zu diesem Sensorgateway gibt, möchte ich, sobald fertig, meine Rechercheergebnisse und das Skript hier anhängen. Evtl. hilft es ja jemandem. Nun zum Problem. Ich habe einige Readings von einem Temperatursensor aufgezeichnet, kann aber die Kodierung der Temperatur im Paket nicht erkennen. Das Format der Readings sieht so aus: ce 58 24 e5 b5 12 02 16 2c 14 62 8e 01 e7 80 46 00 43 1a | | | | | | | | | | | | | | | | | + evtl. Batterieindikator [len:1] | | | | | | | + Temperatur des letzten Readings [len:2] | | | | | | + Aktuelle Temperatur (7.0°C) [len:2] | | | | | + Sequenznr. (++ bei jedem Reading) [len:1] | | | | +-- ? | | | +-- Sensor-Seriennummer [len:6] | | +-- Reading type (12=Temperatur) [len:1] | +-- Epoch als 32bit Ganzzahl in Big Endian Order [len:4] +-- Nachrichtentyp (ce=Sensordaten) [len:1] Falls die Zeilen umbrechen, hier in groß: http://pastebin.com/0nUygVBS Die Temperatur, hier 7.0°C ist mit 0x8046 kodiert. 46h = 70d/10 = 7,0. Das geht aber nur, wenn die Temperatur unter 25,5°C liegt (dann ist das rechte Byte voll) und die Temperatur positiv ist. Hier nun einige Readings mit Testwerten (Temperaturbytes in Klammern): ce 58 24 e5 b5 12 02 16 2c 14 62 8e 01 e7 [ 80 46 ] 00 43 1a = 7,0 °C ce 58 24 ec 4b 12 02 16 2c 14 62 8e 01 eb [ 00 4d ] 00 4c 1a = 7,7 °C ce 58 24 ed f0 12 02 16 2c 14 62 8e 01 ec [ 80 a6 ] 00 4d 1a = 16,6 °C ce 58 2b 1f cc 12 02 16 2c 14 62 8e 00 ab [ 47 6c ] 47 74 1a = -19,5 °C ce 58 2b 2c fd 12 02 16 2c 14 62 8e 00 b3 [ 07 5b ] 87 5d 1a = -16,5 °C ce 58 2b 54 8f 12 02 16 2c 14 62 8e 00 cb [ 47 38 ] 47 3e 1a = -20,0 °C ce 58 2b 5b 25 12 02 16 2c 14 62 8e 00 cf [ 40 16 ] 87 52 1a = 2,2 °C Es fällt auf: a) Das erste Nibble des ersten Bytes ist immer 0h, 4h oder 8h. b) Das zweite Nibble des ersten Bytes ist bei positiven Werten immer 0, bei negativen immer 7. Ich finde aber die Kodierung nicht, die verwendet wurde um z. B. -20°C in 0x4738 zu packen) - oder ich bin schon Betriebsblind. Jedenfalls bin ich um einen kurzen Tipp dankbar! Grüße aus dem Süden! Jonathan
Jonathan H. schrieb: > Jedenfalls bin ich um einen kurzen Tipp dankbar! Jonathan H. schrieb: > Das System kommt von der Firma TFA-Dorstmann Dann würde ich erst einmal dort fragen: http://www.tfa-dostmann.de
Leider keine Unterstützung von dort. Das System wurde auch von einer anderen Firma im Auftrag entwickelt, dort werden die Informationan aber freilich nicht ohne Zustimmung von TFA erteilt. Viele Grüße J.
Also für die positiven Werte sieht es doch nach 12 bit hex in 0.1 Grad Schritten aus: 046 hex = 70 = 7,0C 04d hex = 77 = 7,7C 0a6 hex = 166 = 16,6C Stimmt Dein Aufschrieb mit den negativen Werten? ich würde im Zweierkomplement 12 bit so etwas erwarten: 000 hex = 0 = 0C 7ff hex = -1 = -0,1C ???? Bei diesen Werten stimmt es: 7 5b hex = -165 = -16,5C 7 38 hex = -200 = -20,0C nur die Zeile mit 19,5 stimmt nicht: 7 6c hex = -148 = -14.8C oder 7 3d hex = -195 = -19,5C
Im FHEM Forum findet man da einiges zu. Es gab sogar schon mal eine deutlich besser App dafür. Aber da hatte der Hersteller was dagegen, bei jeden neuen Update der APP basteln die da wieder an der Übertragung rum um es den "Daten Fremdzugreifern" schwerer zu machen. Deutlich besser währe es da wohl bei der Funkschnittstelle anzusetzen und das Gateway durch was eigenes zu ersetzen. Ich meine aber das es das 866MHz Band ist.
Die meisten Infos findet man darüber aber mit dem Suchbegriff: MobileAlerts
@Poster: da findet man aber keine Infos zum Protokoll. über irgend eine Cloud Verbindung möchte es der TO ja eben nicht die Daten bekommen......
Ist schon einige Zeit her wo ich mir das mal angeschaut hatte, aber irgendwie kommt mir da das Problem des TS bekannt vor. Vielleicht sind ja die Daten die von der Cloud zurückkommen ähnlich kodiert, und darüber sollte sich da ja was finden lassen.
Guten Abend!
Erstmal danke für die hilfreichen Tipps!
Es ergab sich folgendes:
>ich würde im Zweierkomplement 12 bit so etwas erwarten
Jein, es ist schon sowas ähnliches. 12 Bit ZWK funktioniert (hatte
selbst nur 16 Bit getestet), es fehlt aber durchgängig das Vorzeichen.
Das 12 Bit von rechts ist immer low.
Es ist vermutlich ein 11 Bit-ZWK, denn das 11 Bit ist bei den negativen
Werten immer 1. Bei Werten <1023d ist der Temperaturrange des Sensors ja
auch noch gut abgedeckt. Wer auch immer auf die Idee kam das so zu
machen. Nix mit Ockham's Knife.
1 | 80 46 = 7,0 °C = 1000 0000 0100 0110 |
2 | 00 4d = 7,7 °C = 0000 0000 0100 1101 |
3 | 80 a6 = 16,6 °C = 1000 0000 1010 0110 |
4 | 40 16 = 2,2 °C = 0100 0000 0001 0110 |
5 | 00 48 = 7,2 °C = 0000 0000 0100 1000 |
6 | 80 4b = 7,5 °C = 1000 0000 0100 1011 |
7 | 80 f8 = 24,8 °C = 1000 0000 1111 1000 |
8 | 00 4c = 7,6 °C = 0000 0000 0100 1100 |
9 | 47 6c = -14,8 °C = 0100 0111 0110 1100 |
10 | 07 5b = -16,5 °C = 0000 0111 0101 1011 |
11 | 47 38 = -20,0 °C = 0100 0111 0011 1000 |
Nun gibt es noch das vordere Nibble. Das ist sicherlich ein Flag. Da ist wechselnd das erste Bit, das zweite oder keines gesetzt. Einen Verwendungszeck kann ich aber keinen erkennen. Fällt euch da aus der Erfahrung mit anderen Systemen was ein? >Im FHEM Forum findet man da einiges zu. Die Hardware kommt wohl vom Hersteller LaCrosse (OUI von der MAC ist auch LaCrosse), da findet sich viel zum Funkprotokoll, leider aber nichts für das Ethernetbasierte. Aus ersterem lässt es sich leider auch nicht ableiten, schon versucht. >Vielleicht sind ja die Daten die von der Cloud zurückkommen ähnlich kodiert Schwer zu sagen, es gibt nur die App für den Zugriff auf die Cloud. Da habe ich als erstes angesetzt. Dort wird Certificate Pinning anhand der Serial benutzt, soll heißen, der App ein falsches Zertifikat unterzuschieben, selbst wenn ihm vertraut wird, funktionierte nicht. Also keine Trafficanalyse. Ich hatte anfangs auch den Plan, die Daten aus der Cloud zu holen und zu verarbeiten, aber dann stellt der Hersteller mal den Dienst ein und es ist Schluss. EDIT: Um das Chaos mit den Namen noch zu beseitigen: Hardware-Hersteller ist La Crosse Technology LTD. Software-Hersteller ist die DATA INFORMATION SERVICES GmbH, die auch MobileAlerts betreibt (nicht nur für das eine Produkt). Vertrieb kommt von TFA Dorstmann, Geräte sind aber auch mit TFA-Logo versehen. Viele Grüße! Jo.
:
Bearbeitet durch User
Ist zwar schon uralt, aber falls jemand ein ähnliches Problem hat: Das Gerät von RfxTrx kann 433MHz Sensoren lesen. Und es kann auch das "La Crosse" Protokoll.
Martin schrieb: > Ist zwar schon uralt, aber falls jemand ein ähnliches Problem hat: > Das Gerät von RfxTrx kann 433MHz Sensoren lesen. Und es kann auch das > "La Crosse" Protokoll. Das geht auch mit einem simplen jeelink auf Arduino und https://github.com/deveth0/lacrosse-mqtt-gateway Ich hatte Adapter und Sensoren schon fast in der Tonne, hiermit sind sie wieder brauchbar (für mich).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.