Most recent activity
-
I'm glad to hear you got something to work, @nienno!
I think you're right about missing a companion app that accepts a Web request over BLE. The Android app on this thread might be able to do it, by making a Web request itself to http://127.0.0.1:17580, and then publishing that. While I don't think I can give many details on that, I can get you started with https://developer.android.com/training/vÂolley/simple
It also might might sense to do this as a "push" action rather than a "pull" one. As in, maybe it would be too slow to make a Web request in order to respond to a BLE request and then give the answer. You can tell xDrip to send a "Broadcast Intent" every time it receives a new reading. The BLE app could then pick up those broadcast intents, and use them to publish the value.
Again, I can only get you started, but you enable the broadcast intents by going to Settings -> Other Settings -> Inter-app settings -> Broadcast locally. There's some documentation at https://developer.android.com/guide/compÂonents/broadcasts, and it starts with probably-confusing overview, then gets to showing you actual code at the "Receiving broadcasts" heading.
Let me know if you'd like me to try to expand on any of this!
-
Sadly I have let this languish (in part because I finally got ControlIQ for my insulin pump which has made knowing the moment-to-moment number a bit less pressing).
But, I do want to do it, and in fact hearing that there's someone else who could directly use it helps reinvigorate me! It will still take some time but hopefully not another 8 months.
-
That app is great! You're much faster than me.
It could even do what I want, since xDrip can run a local Web server, so it could just be pointed to that. And I love the idea in general!
However, the 15 minute limitation probably does stop this method from working for me. Updates coming every 5 minutes are about as slow as I can handle for this.
xDrip is already running constantly (persistent notification and everything), so I'm investigating having it advertise the data in its broadcast method. It doesn't help the Bangle.js ecosystem as much, but will still teach me things.
Thanks for the continued attention!
If a Bangle.js "companion app" for Android starts being developed, I'll still definitely want to help with that if I can.
-
Working great so far!
My current plan has 3 steps:
- I'll write a small Android app that can be configured to accept broadcast Intents and advertise the contained data with BLE.
- A Tasker profile can receive the broadcast Intents from xDrip and broadcast a new one in the form useful for the advertisement app (yes, I could encode that in the app, but I'd rather make it more general-purpose).
- A watch face or widget will poll for the advertisement every 5 minutes and update the display.
I'll link the Android app here when I have it. It will be open source, of course.
- I'll write a small Android app that can be configured to accept broadcast Intents and advertise the contained data with BLE.
-
No problem @Abhigkar, and in fact that's just where I was going next! So please do start that thread, and I'll be there.
Gordon, thank you for the continued direction! I had been hoping to test it out before writing a little app, but didn't know about nRF Connect, only nRF Toolbox. I haven't had a chance to try and follow your steps yet but I'm about to start.
-
Thank you, this is really good detail!
Interesting to hear about Gadgetbridge's reasoning. I can definitely respect it. I'll keep an eye out for updates, but won't wait on them.
You're right that a notification would be easiest, but I do hope to avoid it, because I get notifications when the number I care about goes out of bounds (too high or too low), and so also having them for ordinary values (which I want to check idly from time to time) would become too busy.
I didn't realize that the phone could advertise the data and the Bangle.js could pick it up. That sounds very promising. I don't actually care about privacy for this case. Even though it's technically medical information, I honestly am perfectly fine with someone else (someone would would have to be near me, even) knowing it. I mean, I actually publish the data to a website, I just don't share that URL too much. Convenience way outweighs privacy for me for this particular case. I'll take a look at this route. I assume that I'll need a (tiny) Android app to advertise the data. Oh, and if I ever decide I really do care about security, I'll set up a one-time pad or something to encrypt the data.
I'm constantly surprised by Bluetooth semantics. The Bangle.js connecting to the phone is definitely interesting. I agree it's a pain, but, assuming it doesn't cost too much for either of their batteries, I might look at that long-term. If I could make it work then I could have a general pipe for data between them and that sounds fantastic.
Thanks again! I don't know if any of this will become an app that would make sense to publish, but I'll at least update this thread with my findings in case anyone else comes looking.
-
Hi!
The two most important features of a smart watch, for my personal use, are displaying notifications, and displaying a particular integer that my phone knows that is updated every 5 minutes (it's my blood sugar, retrieved by xDrip+, but that's not a terribly important detail).
Notifications seem to be easy, thanks Gadgetbridge!
The display of the integer is where things get difficult, and I'm trying to figure out a good starting approach. My experience with Bluetooth has been that it's really easy to get caught in confusing dead ends where you can't tell whether you have some small bug or your whole approach is wrong, so I'd appreciate some direction before I dive in too deep.
The phone can publish the data in a few ways: it's send out as a broadcast Intent in Android, and it can be accessible through a local Web server, so I can write an Android app that hooks into either of those methods and forward it along to any other method, like advertising with Bluetooth.
Then, I'd write a widget or custom watch face in the Bangle.js that listens for that advertisement and displays the value.
However, if I'm reading things right, then this would interfere with other NRF functions, so Gadgetbridge would stop working? I'd really like to know this before I've written the two ends of this system.
It seems like another approach could be to modify Gadgetbridge, to use the channel it already has set up, but to make a special kind of "notification" that is intercepted in the Bangle.js app and interpreted to mean "save these data into storage." Then my widget could just read from storage and display the value there. Of course, this would mean either maintaining my own fork of Gadgetbridge, or getting my code path merged in for this specific, personal need, neither of which seems great.
Does anyone have any insight or suggestions? There's lots of help for using the sensors built into the Bangle.js, but I haven't found anything clear for doing something like this.
Thanks in advance!
-
It worked! Thanks again for the voltmeter suggestion, I'm glad I didn't spend time trying to debug other things about it. Watch looks like it's working great. Now to see if I can make the custom watch face that I'm planning on.
-
It's good to know that attaching the cable backwards won't damage it, I had worried about that.
I do have a voltmeter, and don't know why I didn't think of it! Also that has made the problem clear. The cable is giving something like 0.1V when plugged in. That would, indeed, do it. I never see the screen do anything or the heart rate monitor LEDs on the back, but then I wouldn't, with essentially no power coming through.
So, thanks for the suggestion! I'll just wait until my replacement cable comes in, and hopefully everything will work out then.
he/him
I've used the ESP8266 a fair amount, but just barely touched Espruino so far. I have a neglected Bangle.js watch.