Klimalogg Pro TFA 30.3039 via USB am Mac auslesen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Klimalogg Pro TFA 30.3039 via USB am Mac auslesen

    Hallo Leute!

    Ich habe einen Klimalogger Klimalogg Pro TFA 30.3039.
    Die gespeicherten Daten kann man über einen USB-Funkdongle auf einem PC auslesen.
    Ich würde dies aber auch gerne am MAC machen.
    Wie geht man da am besten vor?

    In der USB-Doku habe ich etwas gefunden und die Device VendorID/ProductID: 0x6666/0x5555 angepasst.
    So kann ich feststellen ob und wo der Dongle angesteckt ist.

    Der nächste Schritt wäre rauszufinden, wie der Datenaustausch funktioniert. Ich habe auf einem PC etwas mit einem
    (Software-)Sniffer rumgespielt, finde aber nichts was auf den Datenaustausch schliessen lässt.

    Hat jemand Erfahrung wie man so etwas angeht?

    USB-Infos:

    Full Speed device @ 3 (0x04100000): ............................................. Unknown device: "Weather Direct Light Wireless Device"
    Port Information: 0x101a
    Not Captive
    Attached to Root Hub
    External Device
    Connected
    Enabled
    Number Of Endpoints (includes EP0):
    Total Endpoints for Configuration 1 (unconfigured): 2
    Device Descriptor
    Descriptor Version Number: 0x0200
    Device Class: 3 (Unknown)
    Device Subclass: 0
    Device Protocol

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Fritz ()

  • Ist der Dump aus dem USB Prober? Hmmm, der weigert sich, den Report Descriptor im Klartext auszugeben? Kann man den davon irgendwie überzeugen, das anzuzeigen?

    Vielleicht noch zwei Ergänzungen zu den Materialien des Macoun-Vortrags, die damals nicht im Vortrag erwähnt wurden aber vielleicht hilfreich sein könnten:

    - Im Projekt HID3, HIDDevice.m ist eine Methode -dumpElements, die nicht aufgerufen wird. Wenn man sie einfügt (z.B. im init vor findElements), sollte sie alle bekannten Elemente des Geräts ausgeben. Hilfreich für neue Geräte. Das Beispiel sollte sich ziemlich einfach auf dein Gerät umbiegen lassen.

    - Das Projekt HID5 ist ein Beispiel dafür, die Reports direkt auszulesen statt sich die Elemente zu hängen. Das kann bei Geräten mit kaputten Deskriptoren sinnvoll sein (kommt leider viel zu oft vor)

    Edit: Ich sehe gerade im Dump, dass das Gerät anscheinend unkonfiguriert ist. Das könnte der Grund sein, dass der Report Descriptor nicht kommt. Außerdem ist der Device Descriptor anscheinend nicht ganz richtig - Als USB Device Class kommt 3, eigentlich sollte da für HID-Geräte 0 (Composite) stehen.

    Mit etwas Glück kommt die IOHIDLib damit klar und kümmert sich um die Konfiguration, ansonsten muss man das selbst auf IOUSBLib-Ebene machen.

    Wenn das alles nicht funktioniert ist ein USB Sniffer unter Windows eigentlich eine gute Idee.
    Multigrad - 360°-Produktfotografie für den Mac

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von mattik ()

  • Ja der Dump ist vom USB-Prober.

    Ich hatte gehofft dass ich mit der Anleitung ontrak.net/xcode.htm etwas weiter komme, aber Bahnhof.
    Mit dem Testprogramm im Anhang kann man zwar feststellen ob der Dongle steckt oder nicht, aber dann viel mehr sagt das auch nicht aus.
    Das Problem wird auch sein festzustellen, wie der Datenaustausch erfolgt. Ohne Tracer ist man da wahrscheinlich aufgeschmissen, oder täusch ich mich da?

    lg. fritz

    BTW wenn ich HID3 ausführe, gibt es bei mir (10.7) überhaupt kein NSLog. Mach ich da was falsch? Sollte ja einige NSLogs sehen, wenn ich [self dumpElements]; vor BOOL ok = [self findElements]; einfüge ...

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von Fritz ()

  • Fritz schrieb:

    Ja der Dump ist vom USB-Prober.

    Ich hatte gehofft dass ich mit der Anleitung ontrak.net/xcode.htm etwas weiter komme, aber Bahnhof.
    Mit dem Testprogramm im Anhang kann man zwar feststellen ob der Dongle steckt oder nicht, aber dann viel mehr sagt das auch nicht aus.
    Das Problem wird auch sein festzustellen, wie der Datenaustausch erfolgt. Ohne Tracer ist man da wahrscheinlich aufgeschmissen, oder täusch ich mich da?

    lg. fritz

    BTW wenn ich HID3 ausführe, gibt es bei mir (10.7) überhaupt kein NSLog. Mach ich da was falsch? Sollte ja einige NSLogs sehen, wenn ich [self dumpElements]; vor BOOL ok = [self findElements]; einfüge ...


    Hast Du in HID3 das Matching Dictionary auf dein Gerät angepasst? (HIDCollection.m, startListening).

    Wenn das Gerät sich halbwegs HID-konform verhält sollte das das Protokollproblem weitgehend lösen, HID hat dafür ja einen Standard. Wenn nicht wird man wohl loggen und fummeln müssen.

    Apropos: zerm, gute Frage. Ich habe schon Ewigkeiten nicht mehr unter Windows geloggt. Früher habe ich das immer mit USB Snoopy bzw. SnoopyPro gemacht - nicht sonderlich luxuriös, aber es hat mir das rausgeworfen, was ich brauchte. Keine Ahnung ob die heute noch funktionieren und/oder ob es da mittlerweile was besseres gibt. Wenn ja, wäre ich daran auch interessiert.
    Multigrad - 360°-Produktfotografie für den Mac

  • So in etwa:

    Quellcode

    1. - (void) startListening {
    2. /*NSDictionary* matchDict = [NSDictionary dictionaryWithObjectsAndKeys:
    3. [NSNumber numberWithInt:kHIDPage_GenericDesktop], @ kIOHIDDeviceUsagePageKey,
    4. [NSNumber numberWithInt:kHIDUsage_GD_Joystick], @ kIOHIDDeviceUsageKey,
    5. nil];
    6. */
    7. NSDictionary* matchDict = [NSDictionary dictionaryWithObjectsAndKeys:
    8. [NSNumber numberWithInt:0x6666], @ kIOHIDVendorIDKey,
    9. [NSNumber numberWithInt:0x5555], @ kIOHIDProductIDKey,
    10. nil];
    12. IOHIDManagerSetDeviceMatching(self.hidManager, (CFDictionaryRef)matchDict);
    13. IOHIDManagerRegisterDeviceMatchingCallback(self.hidManager, myPlugCallback, self);
    14. IOHIDManagerRegisterDeviceRemovalCallback(self.hidManager, myUnplugCallback, self);
    15. IOHIDManagerScheduleWithRunLoop(self.hidManager, CFRunLoopGetMain(), kCFRunLoopDefaultMode);
    16. }
    Alles anzeigen


    Aber ich sehe immer noch keinen Output in der "All Output" Konsole. hmmm

  • Das ist eigenartig. Ich habe das Beispiel hier mal unter 10.8 mit vendorID/productID-Matching probiert, funktioniert einwandfrei. Eventuell kannst Du mal mit einem anderen HID-Gerät testen, ob das Beispiel bei Dir überhaupt geht, müsste aber.

    Du schriebst, dass das ontrak-Beispiel bei Plug und Unplug funktioniert? Das ist das eigentlich Eigenartige, denn beide Beispiele verwenden im Wesentlichen den gleichen Mechanismus. Falls das wirklich so ist, sag' bitte Bescheid. Dann müsste ich mir hier mal ein Mockup der Wetterstation basteln.

    Momentan vermute ich, dass für das Gerät gar kein IOHIDDevice-Treiber gematcht und geladen wird, weil die normalerweise im IOKit unterhalb eines IOUSBCompositeDevice hängen. Und die werden typischerweise nur für Device Class=0 und Device Subclass = 0 geladen (so steht's zumindest in /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBCompositeDriver.kext/Contents/Info.plist, ich habe mir allerdings nicht alle Matching-Fälle angesehen, die Wege des IOKit sind unergründlich).

    Wenn die Vermutung stimmt, ist's mit der IOHIDLib für das Gerät Essig. Dann müsste man entweder das IOKit davon überzeugen, den HID-Treiber auch für dieses Gerät zu laden (was schwierig werden dürfte, ich kenne keinen Weg ohne an den kexts oder im Kernel Space herumzufummeln) oder das Ganze über die IOUSBLib nachbauen. Das ist etwas mehr Arbeit, aber es geht aus dem User Space und so wild ist HID auch nicht zu implementieren - insbesondere, wenn man nur ein bestimmtes Gerät unterstützen muss.

    Ich würde erstmal versuchen, an den HID Report Descriptor, der im USB Prober erwähnt wird, heranzukommen und mal nachzusehen, ob das als Report Descriptor einen Sinn ergibt.
    Multigrad - 360°-Produktfotografie für den Mac

  • nochwas nebenbei: Ich finde libusb super, hat einiges Ähnlichkeit mit dem IOKit, aber ich fand die API doch etwas eleganter. Und das beste ist, dass "Treiber" damit auch unter Linux und Windows(!) funktionieren. Weil ich keine vernünftige Doku zu Windows/USB gefunden hatte (und die Windows-API meist eh hässlich ist), habe ich mehr oder weniger erfolgreich mit libusb unter Windows alles zum laufen gebracht bekommen (...und ein Gerät zerstört...- war aber eher mein Fehler).

    Dazu kommt, dass es eventuell schon Treiber fuer Linux fuer Dein Geraet gibt, die dann wahrscheinlich auch libusb verwenden. Dann ist das ganze recht einfach portiert ;)
    ♥C++

  • USB-Traces

    Ich hatte etwas Zeit und habe mit USBcapCMD+Wireshark einige Traces gezogen.

    Das Format der übertragenen Daten dürfte so aussehen:

    aa aa aa aa aa aa aa aa 47 0a aa aa aa aa aa aa aa aa aa aa aa a6 48 13 07 15 19 45
    aa aa aa aa aa aa aa aa 47 0a aa aa aa aa aa aa aa aa aa aa aa a6 48 13 07 15 19 45
    aa aa aa aa aa aa aa aa 47 0a aa aa aa aa aa aa aa aa aa aa aa a6 48 13 07 15 19 45
    47 0a = 47% a6 48 = 24,8° 15.07.13 19:45
    62 0a = 62% a5 72 = 17,2° ....




    Wobei ich mir nicht ganz sicher bin, ob die Messwerte vor oder nach dem Datum/Uhrzeit stehen.

    Anbei sind die Logdateien "first4k" die das Hochstarten vom Anstecken des Dongles bis zum Download-Start zeigen und "datadld" ausschnittsweise die Datenübertragung

    Eventuell kann jemand aus dem first4k- Log rauslesen wie man den Dongle am Mac ansprechen müsste ...

    lg. fritz

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Fritz ()

  • Nochmals ein paar Traces ...

    ... vom Anfang (Einstecken des Dongle bis ersten Datenaustausch) und Teil des Datenaustauschs

    Das Datenformat scheint:

    aa aa aa aa aa aa aa aa 47 0a aa aa aa aa aa aa aa aa aa aa aa a6 48 13 07 15 19 45
    aa aa aa aa aa aa aa aa 47 0a aa aa aa aa aa aa aa aa aa aa aa a6 48 13 07 15 19 45
    aa aa aa aa aa aa aa aa 47 0a aa aa aa aa aa aa aa aa aa aa aa a6 48 13 07 15 19 45

    zu sein.

    Wobei 47hex = 47% Luftfeuchte entspricht

    0xA6 & 0x03 die Zehnerstelle und das oberste Nibble des nächste Bytes die Einerstelle der Temperatur und das untere Nibble die Nachkommastelle der Temperatur liefert.
    Danach folgt Datum und Uhrzeit.

    Die AA's sind wahrscheinlich für die Modulation (Datenübertragung) notwendig.

    Irgendwo in dem Datenwulst ist wahrscheinlich auch die Anzahl der Datensätze (10063) enthalten

    Kann man aus der Startphase erkennen, wie der Dongle grundsätzlich angesprochen werden muss?

  • Hallo,

    ich wollte mal anklopfen und fragen ob sich bei euch seti Juli etwas getan hat? Ich bin nämlich an einem ähnlichen Projekt dran, nur anstatt eines Mac will ich das Ding unter Linux zum Laufen bringen.
    Ein paar Infos kann ich auch dazu beitragen: Ich habe zum Beispiel ein paar mehr Sensoren dran hängen. Bei mir gibt es also keine AAs mehr (also nur am Anfang der Zeile, das liegt aber daran, dass mein Sensor8 keine Luftfeuchte messen kann)

    Das USB Paket schaut dann so aus:

    00 00 B5 01 67 00 40 64 19 D9 14 FC A0 14 FB A0
    AA 42 46 43 43 50 47 50 42 04 37 60 75 48 63 26 26 54 56 24 55 36 29 14 01 14 07 45
    AA 41 46 43 43 50 47 49 42 04 37 61 25 48 63 46 28 54 56 25 55 56 32 14 01 14 07 30
    AA 41 46 43 43 50 47 49 41 04 38 61 65 48 63 66 30 54 56 26 55 56 36 14 01 14 07 15
    AA 40 46 42 42 50 47 48 41 04 38 62 25 48 63 76 31 54 56 26 55 56 39 14 01 14 07 00
    AA 40 46 43 43 50 48 48 41 04 40 62 45 48 63 66 29 54 56 24 55 66 36 14 01 14 06 45
    AA 42 46 44 43 50 48 49 42 04 38 61 15 48 63 06 24 54 56 22 55 06 27 14 01 14 06 30
    2D 9D 63 39 44 01 41 12 6B 71 41 13 03 06 34 56 15 92 AA 4A A4 AA AA 4A A4 AA AA AA
    AA 01 41 13 1F 11 41 13 65 26 74 38 54 46 00 00 00 00 00 00 1B B1 5A 49 58 2B 64 C7
    3D AD CA 0C A5 09 35 98 03 6A 1E E5 31 03 4F F1 14 4F D2 93 9C F6 70 4B 81 8A 8A 88
    1A AF 96 26 75



    Es sind anscheinend immer (maximal) 6 Datensätze in dem Paket drinnen. Der Export von den Klimalogg Programmdaten ist konsistent:




    "Timestamp" ;"TI";"RHI";"DEWI";"T1";"RH1";"DEW1";"T2";"RH2";"DEW2" ;"T3";"RH3";"DEW3";"T4";"RH4";"DEW4";"T5";"RH5";"DEW5" ;"T6";"RH6";"DEW6";"T7";"RH7";"DEW7";"T8";"RH8";"DEW8"
    2014-01-14 06:30:00;"22,7";"42";"9,2";"15,0";"49";"4,4";"22,2";"48";"10,7";"14,5";"50";"4,2";"22,4";"43";"9,2";"23,0";"44";"10,1";"14,8";"46";"3,3";"21,1";"42";"7,7";"3,8";"---";"---";
    2014-01-14 06:45:00;"23,6";"41";"9,6";"15,6";"48";"4,6";"22,4";"48";"10,9";"14,5";"50";"4,2";"22,9";"43";"9,7";"23,6";"43";"10,3";"14,8";"46";"3,3";"22,4";"40";"8,2";"4,0";"---";"---";
    2014-01-14 07:00:00;"23,9";"41";"9,9";"15,5";"48";"4,6";"22,6";"47";"10,7";"14,5";"50";"4,2";"23,1";"42";"9,5";"23,7";"42";"10,1";"14,8";"46";"3,3";"22,2";"40";"8,0";"3,8";"---";"---";
    2014-01-14 07:15:00;"23,6";"41";"9,6";"15,5";"49";"4,9";"22,6";"47";"10,7";"14,5";"50";"4,2";"23,0";"43";"9,8";"23,6";"43";"10,3";"14,8";"46";"3,3";"21,6";"41";"7,8";"3,8";"---";"---";
    2014-01-14 07:30:00;"23,2";"42";"9,6";"15,5";"49";"4,9";"22,5";"47";"10,7";"14,5";"50";"4,2";"22,8";"43";"9,6";"23,4";"43";"10,1";"14,8";"46";"3,3";"21,2";"41";"7,5";"3,7";"---";"---";
    2014-01-14 07:45:00;"22,9";"42";"9,3";"15,3";"50";"5,0";"22,4";"47";"10,6";"14,5";"50";"4,2";"22,6";"43";"9,4";"23,2";"43";"10,0";"14,8";"46";"3,3";"20,7";"42";"7,4";"3,7";"---";"---";


    Interessant wäre jetzt noch was davor/danach gesendet wird. Ob das USB-HID Zeug ist, das da dran ist oder Klimalogg Daten.

    Ich habe eine Python-HID Lib gefunden und werde demnächst mal damit herum spielen. Versuchen ob ich den HID Feature Report 0xD6 auslesen kann. Der sollte eventuell diese Daten beinhalten. Mal schauen was da zurück kommt.
    Und ich hab noch mehr als 500MB Traces aufgezeichnet. Vom Einstecken, Umbenennen von Geräten, von verschiedenen Sensorenanzahlen.

    Wäre cool, wenn wir das irgendwie hinbekommen!

    LG
    koe