Moinmoin, vorab - ich habe mich bislang noch nicht mit Bluetooth einhergehender beschäftigt. Ich hätte eine generelle Frage zu den Konnektivitätsmöglichkeiten der oben genannten Bluetooth-Module. Ich möchte damit ein Endgerät abfragen, das über einen BLE 4.0-Chip verfügt (Chiptyp nicht bekannt) und die Daten mit einem AVR/8051 anzeigen und auswerten lassen. Bei Testversuchen unter Linux auf einem Laptop, der ein BT4.0-Interface integriert hat, und dem Bluepy-Helper kann ich auf das ensprechende Gerät über svcs/char/rd/wr zugreifen. Die Dokumentation, die ich mir bislang über den HM-10 gesichtet habe, gibt mir wenig Aufschluss darüber, wie denn nun eigentlich eine Kommunikation von/zur einer "Fremd-UUID" (in dem Fall 128 Bit) von statten geht. D.h. nicht, wie gewöhnlich, das beispielsweise eine Smartphone-App einen Controller über das HM-10-Modul steuert, sondern das der Controller über den HM-10 die Kommunikation zu einer nicht-CC254X-UUID händelt. Laut Dokumentation soll das möglich sein. Ab einer gewissen HM10-Firmware hat man allerdings die direkten Befehle an eine UUID gestrichen, dafür eine Self-Learning-Funktion implementiert, was bei mir immer noch die Frage offen lässt, wie nun die eigentliche Kommunikation an ein / zwei UUIDS außerhalb von CC254X-Modulen von statten geht....spezielle AT-Kommandos oder dergleichen... Man mag mich gerne korrigieren - der Bluepy-Helper spuckt mehrere UUIDs aus dem verbundenen Gerät aus und dazu passend eine HStart- und HEnd-Addresse. Das heißt, die Adresse, auf die ich zugreifen will, wird an eine bestimmte UUID gekoppelt. Auf diese Adressen kann ich per "wr" und "rd" im Helper zugreifen. Jetzt stellt sich halt für mich ganz simpel die Frage, wie ich über AT-Kommandos an das HM-10-Modul Zugriff auf diese Adressen und eine Response vom Endgerät bekomme. Nebebnei habe ich nach langer Suche eine Tabelle aus einer Android .apk / .dex "extrahiert", die zur eigentlichen Steuerung/Abfrage des BLE-Devices dient. Die Kommandos sind jeweils 6 Bytes lang (allerdings als HEX-String einer jeweiligen Konstante zugewiesen). Das würde aber implizieren, das ich dieses Kommando irgendwie mit übermitteln müsste. Wie, da bin ich völlig überfragt. Für jede Aufklärung bin ich sehr dankbar! Beste Grüsse
:
Bearbeitet durch User
Ich kann dir zwar nicht helfen, aber vielleicht hilft dir die Info, dass an diesem Modul schon ein paar andere hier gescheitert sind. Ich kann mich an keinen einzigen Fall erinnern, wo jemand letztendlich Erfolg gemeldet hat. Die Dokumentation ist offenbar unzureichend. Aus Neugier hatte ich mal heraus finden wollen, wie man die Serielle Port Emulation mit Bluetooth 4 verwenden kann. Früher hieß es mal, dass das mit BLE gar nicht geht, da nicht spezifiziert. Dann kamen aber Module samt Beispielprogrammen auf den Markt, die es doch konnten. Nur habe ich keine ausreichende Doku gefunden, um selbst Android Apps dafür zu programmieren. Das gleiche Spiel mit Bluetooth (ohne LE) war für mich hingegen kein Problem.
Wie gesagt, das Modul soll die Möglichkeit besitzen, auf eine Art und Weise mit anderen BLE-Geräten zu kommunizieren - außerhalb von den "hauseigenen" Modulen. Es gibt, soweit ich das bislang herausfinden konnte,je nach Baujahreszeitraum und Firmwarerevisionen auch Dokumentationen, wo tatsächlich zusätzliche Befehle aufgeführt werden. Ich weiß halt nicht, wie ich die Thematik sonst lösen könnte, ob es irgendwleche Module gibt, die vielleicht weniger schwer zu händeln sind. Klar wäre eine Option, vllt einen RPi mit BLE-Adapter zu nutzen und dann über den Helper und eigenem Python-Programm+LCD+Knöppe mit dem Device zu kommunizieren, aber das wär schlicht oversized für die Aufgabe. Ums kurz zu machen: Es geht um einen MPPT-China-Laderegler, der bislang nur mit der hauseigenen App kommunizieren kann (die ohne Standortzugriff im übrigen auch ihren Dienst verweigert) und bis auf BLE keine andere Schnittstelle besitzt. Ich hätte aber gerne dauerhaft Information angezeigt und ggf geloggt, ohne dafür jedes mal das Smartphone zücken zu müssen. Ich empfinde das einfach als unkomfortabel - wenn sich alternativ mit einem Blick auf ein zugewiesenes Gerät alle Parameter sichbar erfassen lasse könnten - und vor allem trennt die App regelmässig die Verbindung zum Gerät. Ich hoffe, ich bekomme das schon irgendwie hin. Fast 30 Jahre MCU-Programmierung muss ja irgendwie auch mal zu was zu nutze sein... :-)
Stef schrieb: > jedes mal das Smartphone zücken zu müssen. Ich empfinde das > einfach als unkomfortabel So geht es mir inzwischen auch. Als Android Smartphones erschwinglich wurden, war ich Feuer und Flamme für die Idee, statt herkömmlicher Bedienfelder das Smartphone zu benutzen. Das hat sich zumindest für mich aber als Flop heraus gestellt. Für eine Konfigurations-Seite die man nur selten benutzt ist es noch OK, aber nicht für den Alltag. Und Bluetooth nervt von allen Standard-Schnittstellen am meisten. Immer geht irgendwas nicht richtig. Will ich gar nicht mehr haben.
Steve schrieb: > Und Bluetooth nervt von allen Standard-Schnittstellen am meisten. Immer > geht irgendwas nicht richtig. Will ich gar nicht mehr haben. Warum versuchst Du den auch zwanghaft dieses BLE Modul zu verwenden um es dann mit einem 8051 zu verbinden? Die allermeisten moderneren µCs mit BLE peripheral haben mindestens einen Cortex M0, meistens eher einen Cortex M4 Kern. Meine Empfehlung: nimm einfach einen nRF52 und implementiere alles darauf.
Danke für die Antwort. In der Tat, das wäre interessant gewesen - kann Cortex-M allerdings (wie den Rest) nur auf Assemblerebene programmieren, dann bislang nur einen spezifischen - und wie hoch der Aufwand schlussendlich ausgefallen wäre, weiß ich nicht. Das hat sich aber auch insofern erledigt, als das das Device, das diesen BLE4.0-Chip hat und das ich abfragen wollte, durch ein anderes ersetzt wurde, das neben BLE auch einen simplen seriellen (RJ12)-Port hat. Der letzte Deal wäre gewesen, das ich einfach die Kommunikation im betreffenden Gerät zum BLE-Chip direkt an dessen RX-Pin abgefangen hätte; dummerweise sendet das Gerät aber die interessanten Parameter erst dann, sobald die Bluetooth-Verbindung steht - nicht Sinn der Sache...
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.