Hallo
Ich bin auf die fixe Idee gekommen mein Inkbird BBQ Bluetooth
Thermometer
unter Linux auszulesen. Mich interessiert eigentlich nur der
Temperaturwert.
Erstaunlicherweise gibt es anscheinend so gut wie keinen Code mit dem
sich jemand schon mal daran versucht hat. Auf Github
(https://github.com/sworisbreathing/go-ibbq) gibt es nur ein kleines
Projekt das aber auf "GOLANG" basiert und dazu noch auf ein anderes
GOLANG BLE Code Fragment (https://github.com/go-ble/ble), komplett ohne
irgendwelche Dokumentationen...
Also habe ich versucht selbst tätig zu werden und mit dem Teil
kommuniziert und Pakete mit der Android internen HCI-SNOOP Funktion
gesnifft während ich die BBQ App auf dem Smartphone verbunden habe. Dann
das ganze in Wireshark angeschaut, insbesondere das ATT Protokol. Dort
habe ich diverse Pakete gefunden "Rcvd Handle Value Notification" die
einen Value zurückgeliefert haben der die Temperatur sein könnte.
"dc000000" = dezimal 220 also vermutlich 22°C die auch das Thermometer
anzeigt.
Später habe ich den Fühler berührt und der Wert änderte sich mit der
Zeit auf
"22010000" = dezimal 290 = 29°C.
Das scheint schon mal zu klappen. Die Frage ist nun wie bringe ich das
Gerät dazu diese Value Notification zu senden? Ziel wäre für mich am
besten die Werte mit einem Python Skript abzufragen.
Da ich unter Linux bin habe ich das Gerät erstmal mit gatttool
abgefragt.
1
primary
2
3
attr handle: 0x0001, end grp handle: 0x000b uuid: 00001800-0000-1000-8000-00805f9b34fb
4
attr handle: 0x000c, end grp handle: 0x000f uuid: 00001801-0000-1000-8000-00805f9b34fb
5
attr handle: 0x0010, end grp handle: 0x0022 uuid: 0000180a-0000-1000-8000-00805f9b34fb
6
attr handle: 0x0023, end grp handle: 0xffff uuid: 0000fff0-0000-1000-8000-00805f9b34fb
Das Temperatur Paket scheint also mit der Service UUID 0xFFF0 und mit
dem Characteristic UUID 0xFFF4 und dem Handle 0x0030 zusammen zu hängen
(siehe Bild). Hat jemand Ahnung von dem ganzen was ich denn jetzt mit
gatttool senden muss damit er mir die Temperatur ausgibt?
Hallo Paul,
eine GATT Characteristic besteht aus mehreren Attributes. Damit ein GATT
Server Dir Notifications für eine Characteristic sendet, musst Du Dich
auf diese subscriben. Innerhalb des Handle-Bereichs Deiner
Characteristic muss es einen Client Characteristic Configuration
Descriptor (das ist ein Attribute) mit der UUID 0x2902 geben. Notfalls
könntest Du mal das Bonding zu dem Gerät löschen und dann das Pairing
mit-sniffen.
An diese Characteristic musst Du den Wert 1 schreiben, wenn Du mit dem
Gerät verbunden bist.
Edit: Oder Du probierst es mal auf gut-Glück mit dem Handle 0x0031
mfg Torsten
Ah ja, danke. Das deckt sich mit dem was ich gestern noch gelesen habe
(https://stackoverflow.com/questions/15657007/bluetooth-low-energy-listening-for-notifications-indications-in-linux).
Der Notification Prozess muss erst aktiviert werden, nennt sich glaube
ich CCCD (Client Characteristic Configuration Descriptor)...
Ich bin mir jetzt nicht sicher ob das Gerät dazu ge-paired sein muss.
Ich versuche gerade das Thermometer mit dem PC zu pairen aber
bluetoothctl will eine Pin von mir obwohl ich das Pairing mit dem
Smartphone überlicherweise nur mit einem Knopf bestätige...
Wenn du es erstmal etwas vereinfacht probieren willst kann ich dir auch
die Android-Version von nRF Connect sehr empfehlen, damit kann man sich
sehr einfach auf eine Characteristic subscriben und schauen ob dadurch
Notifys gesendet werden. :-)
Danke Torsten, ich hatte 2902 schon mal ausgelesen:
1
gatttool -b 0C:AE:7D:XX:XX:XX -I
2
> connect
3
[LE]> char-read-uuid 2902
4
5
handle: 0x000f value: 02 00
6
handle: 0x0026 value: 00 00
7
handle: 0x002d value: 00 00
8
handle: 0x0031 value: 00 00
Und auch versucht zu setzen aber an den Values hat sich bisher nix
ändern lassen. Aber seit dem ich das Thermometer vom Smartphone
un-bounded habe steht nun im 0x000f eine Zwei drinn.
Wie es in Python oder mit dem gatttool funktioniert, kann ich Dir nicht
sagen.
In Node.js mit installiertem "simble"-Paket für Bluetooth-Unterstützung
würde vermutlich folgendes kurzes Programm genügen:
In Python unter Linux würdest Du vermutlich die "bluepy"-Library für die
Bluetooth-Kommunikation nehmen.
(http://ianharvey.github.io/bluepy-doc/notifications.html#example-code)
Mit der habe ich keine Erfahrung, daher kann ich Dir kein fertiges
Code-Fragment nennen, aber der grundsätzliche Ablauf dürfte eh immer
gleich sein:
1. Du verbindest Dich mit dem gewünschten Gerät (bzw. dem GATT-Server
des Geräts), also in diesem Fall Deinem Bluetooth-Thermometer.
2. Du forderst davon den Service 0xFFF0 an
3. Du forderst davon die Characteristic 0xFFF4 an.
4. Du "subscribst" auf diese Characteristic
5. Immer wenn ein Update dieser Characteristic kommt, parst Du die als
Byte-Array gelieferten Daten
Pairing oder so ist meiner Erfahrung nach bei fast keinem
Bluetooth-LE-Gerät nötig.
Paul G. schrieb:> Ich bin mir jetzt nicht sicher ob das Gerät dazu ge-paired sein muss.> Ich versuche gerade das Thermometer mit dem PC zu pairen aber> bluetoothctl will eine Pin von mir obwohl ich das Pairing mit dem> Smartphone überlicherweise nur mit einem Knopf bestätige...
Das wird Dir das Gerät, beim Versuch, auf den CCCD zu schreiben selbst
sagen (mit einem entsprechenden ATT-Fehlercode).
Der Tipp von Philipp ist auf jeden Fall gut. nRF Connect gibt es auch
für iOS (und OS/X).
Die Auswahl der Pairing-Methode hängt an den Möglichkeiten, beider
Geräte. Vielleicht hat Dein Telefon da vorher etwas nicht richtig
gemacht.
Ich habe mal ein wireshark log angehangen, da ist (sollte) der
Pairing-Prozess enthalten sein. Die letzten wiederholenden ATT Pakete
sind allein die Temperatur Readings (dc000000).
Ich steh gerade etwas auf dem Schlauch. Mit dem Pairing, also das
Display des Thermometers hat ein Wifi-Ikon das fängt an zu blinken wenn
ich per gatttool oder nRF verbinde. Die Verbindung wird aber immer nach
4 bis 10 Sekunden unterbrochen und ich muss neu connecten. Wenn das
Thermometer mit dem Smartphone gepaired wird dann geht das Ikon vom
blinken in dauerleuchten über nachdem mich die App aufgefordert hat den
Knopf zu drücken. Das tut es aber nur wenn ich es mit der BBQ App
paire...
Wenn ich versuche per bluetoothctl zu pairen fragt er mich nach einer
PIN und da habe ich schon alle wie 0000,1234,9999 ausprobiert und
schlägt fehl.
Nachdem ich das Thermometer aus der App gelöscht habe war ich dann in
der Lage die Handles des "2902" mit gatttool zu setzen:
gatttool -b 0C:AE:7D:XX:XX:XX --char-write-req --handle=0x0031
--value=0100 --listen
handle: 0x000f value: 02 00
handle: 0x0026 value: 01 00
handle: 0x002d value: 01 00
handle: 0x0031 value: 01 00
Wobei sich der erste handle nur auf 0200 oder 0000 setzen ließ. Nach
jedem setzten Befehl hab ich gewartet ob da eine Antwort kam, aber nix.
Mit der nRF App weiss ich nicht so recht was ich machen soll. Ist zwar
schön übersichtlich aber ich kapier nicht was ich dort senden oder
abfragen soll, vor allem kann ich in der App ja nicht sehen ob er die
Temperatur Pakete auch wirklich sendet, mit "gatttool --listen" müsste
das ja gehen.
Joachim S. schrieb:> 1. Du verbindest Dich mit dem gewünschten Gerät (bzw. dem GATT-Server> des Geräts), also in diesem Fall Deinem Bluetooth-Thermometer.> 2. Du forderst davon den Service 0xFFF0 an> 3. Du forderst davon die Characteristic 0xFFF4 an.> 4. Du "subscribst" auf diese Characteristic> 5. Immer wenn ein Update dieser Characteristic kommt, parst Du die als> Byte-Array gelieferten Daten
Ja, die Frage ist wie "fordere" ich einen Service/Characteristic an bzw
subscribe etwas mit dem gatttool.
Ich habe dort nur:
char-read-hnd <handle> Characteristics
Value/Descriptor Read by handle
char-read-uuid <UUID> [start hnd] [end hnd] Characteristics
Value/Descriptor Read by UUID
char-write-req <handle> <new value> Characteristic Value
Write (Write Request)
char-write-cmd <handle> <new value> Characteristic Value
Write (No response)
Mir ist das ganze Konzept Service/Characteristic/Handle völlig abstrus.
Paul G. schrieb:> Mir ist das ganze Konzept Service/Characteristic/Handle völlig abstrus.
Das Grundprinzip ist eigentlich simpel:
Vereinfacht gesagt ist jedes Bluetooth LE-Gerät unterteilt in mehrere
"Services", die das Gerät anbietet, und jeder dieser "Services" ist
wiederum unterteilt in eine Reihe von "Characteristics".
Jeder Bluetooth-Herzfrequenz-Sensor bietet beispielsweise den
standardisierten (GATT-)Service "Heart Rate Service" mit der (UU)ID
0x180D an. Zu diesem Service gehören zwei Characteristiken: Die
Characteristic "Body Sensor Location" mit der (UU)ID 0x2A38, die
Auskunft gibt, an welcher Stelle am Körper der Sensor angebracht ist,
und die "Heart Rate Measurement"-Characteristic mit der (UU)ID 0x2A37,
über die permanent der aktuelleste Herzfrequenz-Messwert gesendet wird.
Diese "Characteristics" sind das, womit man es fast ausschliesslich zu
tun hat; die "Services" sind im Grunde nur die Gruppierung inhaltlich
zusammengehöriger "Characteristics" unter einem Dach.
Jeder Service und jede Characteristic hat eine eindeutige (UU)ID, über
die es referenziert werden kann. Die Temperatur-Daten Deines Gerätes
bspw. werden offenbar über die (nicht standardisierte) Characteristic
mit der ID 0xFFF4 gesendet.
Es gibt aber noch eine andere Möglichkeit, Characteristics zu
referenzieren: Über ihre "Handles".
Grob vereinfacht gesagt sind die Handles dazu da, um die Menge der zu
übertragenden Daten zu minimieren. Da die IDs der Services und
Characteristics UUIDs sind, können sie nämlich bis zu 128 Bit lang sein.
Müsste man jedes mal, wenn man eine bestimmte Characteristic
lesen/schreiben will, deren komplette 128 Bit-UUID übertragen, wäre das
viel unnötiger Overhead. Die Handles hingegen sind 16-Bit-Werte. Daher
läuft es in der Praxis ungefähr so ab: Nachdem man die Verbindung zu
einem Bluetooth LE-Gerät aufgebaut wurde, werden daher am Anfang oft
sinngemäss einige Anfragen a la "Hallo Bluetooth LE-Gerät, ich möchte
auf die Characteristic mit der (UUID) xy zugreifen. Wie ist denn das
zugehörige Handle?" ausgetauscht. Und statt über die lange (UU)ID
verwendet werden die Characteristics fortan über das kurze Handle
referenziert.
Die Handles sind also eigentlich gar nicht nötig; sie sind eher eine Art
low-level-Implementierungsdetail, um die Menge der zu übertragenden
Daten zu minimieren. Bei vielen High-level-Bluetooth-LE-Libraries kommt
man mit diesen Handles gar nicht mehr in Kontakt; die Characteristics
werden ausschliesslich über ihre feste (UU)ID referenziert, um die
benötigten Handles kümmert sich die Bluetooth-LE-Library von selbst.
Auch in der nRF-Toolbox, die Du ja bereits benutzt hast, sind die
Handles höchstens irgendwo versteckt zu finden, normalerweise wird nur
die feste (UU)ID der Services und Characteristics angezeigt.
Das von Dir verwendete "gatttool" hingegen ist ziemlich low-level, daher
musst Du Dich da viel mit Handles herumplagen.
Vielen Dank für die Erklärung Joachim.
Ich werde nochmal den Verkehr sniffen und zwar nur bis zu dem Punkt wo
ich die Taste am Thermometer zum Pairen drücken soll, mal sehen ob ich
dann im Nachhinein die Kommunikation Paket für Paket mit dem gatttool
nachspielen kann, denn ich werde das gefühl nicht los das ich ohne
Pairing keine Daten bekommen werde...
Paul G. schrieb:> Ich habe mal ein wireshark log angehangen, da ist (sollte) der> Pairing-Prozess enthalten sein. Die letzten wiederholenden ATT Pakete> sind allein die Temperatur Readings (dc000000).
Da sind ja auch schon Value Notifications drinnen. Das mit dem
Subscriben hat also schon mal geklappt.
Für mich sieht das so aus, als käme der Disconnect von Deiner Seite
(Event 585).
> Wobei sich der erste handle nur auf 0200 oder 0000 setzen ließ. Nach> jedem setzten Befehl hab ich gewartet ob da eine Antwort kam, aber nix.
Das liegt wahrscheinlich daran, dass die erste Characteristic
Indications sendet (Notifications mit Handshake).
> Mit der nRF App weiss ich nicht so recht was ich machen soll. Ist zwar> schön übersichtlich aber ich kapier nicht was ich dort senden oder> abfragen soll, vor allem kann ich in der App ja nicht sehen ob er die> Temperatur Pakete auch wirklich sendet, mit "gatttool --listen" müsste> das ja gehen.
Du must bei der Characteristic, auf die Du Dich subscriben möchtest,
neben dem CCCD auf den Pfeil drücken, dann solltest Du Notifications
bekommen. (Oder auf die 3-fach Pfeile).
Torsten R. schrieb:> Da sind ja auch schon Value Notifications drinnen. Das mit dem> Subscriben hat also schon mal geklappt.
Das Logfile enthält nur den Traffic zwischen meinem Android (BBQ APP)
und dem Thermometer, da gehe ich davon aus das das klappt ;)
ERFOLG :)
Nachdem ich mir das btsnoop log nochmal Paket für Paket angeschaut habe,
habe ich parallel dazu alle write-req mit dem gatttool an das
Thermometer
gesendet:
Mit dem folgenden Paket scheint sich mein Linux mit dem Thermometer
zu pairen, das Antennenlogo blinkt nun nicht mehr und leuchtet
dauerhaft. Ausserdem disconnected das Gerät nicht mehr.
Jetzt muss ich das ganze nur noch handlich in ein python script packen.
Um den Batteriestatus und den zweiten Temperaturfühler kann ich mich
später mal kümmern, brauch ich aber im Moment nicht.
> Mit dem folgenden Paket scheint sich mein Linux mit dem Thermometer> zu pairen, das Antennenlogo blinkt nun nicht mehr und leuchtet> dauerhaft. Ausserdem disconnected das Gerät nicht mehr.>
Ich bezweifle ehrlich gesagt, ob es sich dabei wirklich um ein Pairing
im eigentlichen Sinn handelt.
Ich gehe momentan eher davon aus, dass das einfach eine Art
Initialisierungssequenz ist, die jedes Mal nach dem Verbinden mit dem
Thermometer durchgeführt wird/werden muss.
Möglicherweise ist es übrigens nicht ausreichend (oder sinnvoll), die
immer gleiche Byte-Folge 2107060504030201b8220000000000 zu senden.
Mir ist nämlich folgendes aufgefallen:
Mit
>
1
> char-write-req 0x0026 0100
2
>
wird zunächst auf die Characteristic 0xFFF1 subscribt.
Dann wird mit
>
die Characteristic 0xFFF2 auf 200706050403020101010101000000 gesetzt.
Dann vergehen erst einmal ca. zwei Sekunden - und direkt bevor er wie
von Dir gepostet dann per
>
die Characteristic 0xFFFF2 auf 2107060504030201 b822 0000000000 setzt,
empfängt er noch eine Notification von der Characteristic 0xFFF1, auf
die ja subscribt wurde, mit dem Wert "20 b8 22 00 00 00".
Da die Byte-Folge 0xb8 0x22 in beiden Paketen vorkommt, und der
Write-Request unmittelbar nach dem Empfang der Notification rausgeht,
scheint es mir so zu sein, dass die App die Byte-Folge
2107060504030201b8220000000000 als unmittelbare Reaktion auf den Empfang
dieser "20 b8 22 00 00 00"-Notification gesendet hat, und die gesendete
Byte-Folge vom Inhalt dieser Notification abhing.
Tipp: Ich würde an Deiner Stelle noch ein paar zusätzliche btsnoop-Logs
erzeugen und die miteinander vergleichen, ob bzw. was sich direkt nach
dem Verbindungsaufbau ändert etc. Wenn es sich wirklich um ein Pairing
handelt, dann sollte dieser Pairing-Schritt in den späteren logs ja z.B.
nicht mehr vorkommen, weil Smartphone und Thermometer dann ja bereits
gepairt wären.
Blau schrieb:> Paul G. schrieb:>> char-write-req 0x0029 200706050403020101010101000000>> Kann man vielleicht einen Temperaturalarm am Gerät via app> konfigurieren?
Wie kommst du darauf?
Ja, es gibt verschiedene Temperatur Profile (Steak blutig, Steak
steinhart...) und man kann selbst die Zieltemperatur eingeben aber der
das Teil ALARM schreit und vibriert, mich interessiert aber nur die
aktuelle Temperatur.
Noch ein kleiner Tipp, der Dir mglw. helfen könnte:
Du hast ja im Eröffnungsposting bereits auf eine in Go geschriebene und
auf Github veröffentlichte Software verlinkt.
Da gibt es diese Datei hier mit Konstanten:
https://github.com/sworisbreathing/go-ibbq/blob/master/ibbq/const.go
Da finden sich z.B. Hinweise darauf, für was die verschiedenen
Characteristics offenbar genutzt werden:
Characteristic 0xFFF1: SettingResult (NOTIFY)
Characteristic 0xFFF2: AccountAndVerify (WRITE)
Characteristic 0xFFF3: HistoryData (NOTIFY)
Characteristic 0xFFF4: RealTimeData (NOTIFY)
Characteristic 0xFFF5: SettingData (WRITE)
Weiterhin finden sich dort auch einige Byte-Sequenzen, um z.B. zwischen
Celsius und Fahrenheit umzuschalten, den Batteriezustand abzufragen usw.
Auch die Byte-Folge "21 07 06 05 04 03 02 01 b8 22 00 00 00 00 00"
findet sich da 1:1 wieder, und wird dort als "login credentials"
bezeichnet. Wobei ich mich ein wenig wundere, wieso diese "login
credentials" offenbar eine Konstante und bei jedem Exemplar identisch
sind.
Im Grunde reicht es sogar aus wenn ich nur diese beiden Pakete sende,
und ich hatte das Thermometer vorher mit dem Android gebunden und die
Bindung wieder gelöscht:
char-write-req 0x0029 2107060504030201b8220000000000
char-write-req 0x0034 0b0100000000
und sofort sendet er mir meine Temperatur...
Hallo in die Runde,
ich hoffe, Ihr seid noch da, und das Thema ist noch aktiv, zumindest für
mich ;-)
Ich will von meinem Raspi einfach nur (ab und zu) die Temperaturwerte
von einem IBT-2X auslesen.
Mein erster Ansatz war, mit Hilfe von Python (bluepy) zu arbeiten.
Hier bin ich jedoch am connect mit dem Inkbird gescheitert (trotz
zahlreicher Tips aus dem Netz).
Dann hab ich mich eine Ebene tiefer begeben, gatt + bluetooth und Co,
wobei das komplettes Neuland für mich ist.
Mit gatttool scheitere ich komplett beim connect:
1
pi@force:~ $ sudo gatttool -I -t random -b 24:56:00:00:05:F1
Und ab jetzt beginnt mein Problem, ich hab keine Idee, wie ich was und
mit welchem Kommando setzen muss, um die Temperaturwerte zu erfragen.
Ich hänge mal meine Erkenntnisse aus der nRF Connect App mit dran.
Ich wäre für ein paar Hinweise von Euch wirklich sehr dankbar...
Schönen Sonntag noch
Steffen
Hallo,
ich nochmal, ich hab die Informationen aus der nRF Connect App mal
ver-excelt, aber so richtig ein Licht ist mir dabei nicht aufgegangen.
Ich bin wirklich gespannt, ob einer von Euch hier anspringt...
Viele Grüße
Steffen
Die Temperatur wird wahrscheinlich in einem der Characteristiken im
"Unknown Service" mit der UUDI 0xfff0. Bei allen Charakteristiken in dem
Service, subscribe Dich mal auf Notifications und Indication und dann
ändere mal die Temperatur und guck' Dir an, ob das irgendwo mit den
Notifications / Indication korreliert.
Hi Torsten,
danke für die schnelle Reaktion!
Gut, die von Dir erwähnten Characteristics wären dann:
1
Unknown Characteristic FFF1 Notify
2
Unknown Characteristic FFF3 Notify
3
Unknown Characteristic FFF4 Notify
Wenn Du jetzt noch für "bluetooth" eine (zumindest beispielhafte)
Kommandosequenz hättest (wie ich hier konkret verfahren sollte), wär das
toll.
Wie zu Beginn erwähnt, das ist fremdes Territorium für mich.
Danke und schönen Restsonntag
Steffen
Steffen R. schrieb:> Wenn Du jetzt noch für "bluetooth" eine (zumindest beispielhafte)> Kommandosequenz hättest (wie ich hier konkret verfahren sollte), wär das> toll.
Du möchtest was mit Bluetooth Low Energy machen. Zum Verständnis gibt es
einige Quellen, in denen Du Dich einlesen könntest (Hier z.B. die ganz
gute Doku von Apple:
https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/AboutCoreBluetooth/Introduction.html)
(Die wichtigsten Begriffe sind GATT, Service, Characteristic)
Deine PC, ist ein GATT Client (Central) und Dein Thermometer ist ein
GATT Server (Peripheral). Das unverbundene Thermometer wird Advertising
Data senden. Danach must Du suchen (scanning) und Dich dann Verbinden.
Dabei must Du dann anhand der Advertising Data des Thermometers
erkennen, dass das das Gerät ist, mit dem Du Dich verbinden möchtest. Am
einfachsten wäre es über die MAC Adresse. Ansonsten sucht man
typischerweise nach etwas, dass einen bestimmten Service anbietet
(Service-UUID).
Sobald dein PC mit dem Thermometer verbunden ist, stößt der BLE
(Bluetooth Low Energy) stack Deins PC ein service and characteristic
discovery an und dann solltest Du in Deiner BLE Library irgend wie
darauf zurück greifen können. Sehe es mir bitte nach, dass ich mich
jetzt nicht durch die Dokumentation von Bluepy lese.
HTH Torsten
Guten Morgen,
letzter Versuch...
Was ich gemacht habe:
2 ESP32, je als Server und Client, Read, Write und Notify erfolgreich
implementiert und getestet.
Dann den Server durch das IBT-2X ersetzt...
Folgender Stand:
09:46:58.859 -> Forming a connection to 24:56:00:00:05:f1
4
09:46:58.859 -> - Created client
5
09:46:59.289 -> - Connected to server
6
09:46:59.994 -> - Found our service: 0000fff0-0000-1000-8000-00805f9b34fb
7
09:47:00.042 -> - Found our characteristic: 0000fff4-0000-1000-8000-00805f9b34fb
8
09:47:00.090 -> !!!!!!!!!!!CAN_NOTIFY!!!!!!!!!!!(do before activating indication)
9
09:47:00.090 -> We are now connected to the BLE Server.
10
09:47:00.090 -> !!!!!!!!!!!NOTIFIES!!!!!!!!!!!
Sprich, ich konnte das Inkbird connect-en, habe Service und
Characteristic gefunden, welche die Property Notify unterstützt.
Und jetzt hatte ich erwartet, hiernach die ersehnten Temperatur-Values
zu empfangen:
1
// Activate the Notify property of the Characteristic
UPDATE:
Wenn ich das Inkbird temporär mit der App verbínde, diese dann
disconnect-e, kann ich anschliessend TempValues via Notification am
ESP32 Client empfangen ;-)
Sobald ich das Inkbird neu starte (Batterie raus), ist es wieder vorbei.
Meine Idee,
1
Credentials = []byte{0x21, 0x07, 0x06,
2
0x05, 0x04, 0x03, 0x02, 0x01, 0xb8, 0x22,
3
0x00, 0x00, 0x00, 0x00, 0x00}
via nRF Connect App an die
1
Characteristic 0xFFF2: AccountAndVerify (WRITE)
zu schicken, hat nicht den gleichen Effekt gehabt, seeeeehr schade...
Cheers Steffen
Wo würdest Du die Fehlermeldung sehen, wenn dabei etwas schief gegangen
ist? Laut BT Core spec. 5.3. Vol 3. Part G, Kapitel 3.3.3.3 (Tabelle
3.11), ist der korrekte Wert für "Notification" Bit 0 und damit 1 (und
nicht 2).
Immer Fehler-Rückgabewerte prüfen, oder zumindest ausgegeben!
Guck Dir das auch mal mit einem Sniffer an. Ansonsten waren da auch noch
2 andere Characteristics mit Notification Attribute.
HTH Torsten
So sieht es jetzt aus:
Nach Connect via App (muss irgendwie wie zuvor erähnt mit den
credentials zu tun haben)...
...kann mein kleiner ESP32 Client jetzt auch ;-)
1
12:45:27.008 -> Notify callback for characteristic 0000fff4-0000-1000-8000-00805f9b34fb of data length 12
Steffen R. schrieb:> Die "2" ist meinem Verständnis nach die Längenangabe, oder?
Ja, dann sollte das so passen.
Bist Du mal an den Hersteller heran getreten und ihn um Dokumentation
gebeten? In der Regel haben die ja durchaus ein Interesse daran, dass
man ihre Produkte benutzen kann.
Thread beobachten
Seitenaufteilung abschalten