-
So, I updated to the latest version of iOS integration (v0.08) and Messages (v0.18), but still the message doesn't open when a new notification comes in. It just wakes up the screen, shows the widget icon, buzzes, it even clears the notification when it is cleared on the phone...but the app doesn't show up.
-
-
Well, I recompressed the background image to an "Optimal 2 bit" palette and removed the icons rendering, and it seems to run. Obviously the visual is not optimal and it has to be resized to the larger screen of the Bangle 1, but functionally at least there's nothing stopping it.
If you manage to draw the background as shapes instead of a pixel image, then it would totally work I think.
-
-
So, just found out about the Messages app and it's great. I can successfully pair my Bangle.js 1 with my iPhone and receive notifications. But it seems the app is supposed to pull up the new message on reception and switch back to the clock after some time of inactivity? On my Bangle the messages app never opens, I have to navigate to it through the app launcher. Everything is on the latest version. Is that normal?
-
-
-
-
-
-
Ok thanks, the source code makes it much clearer.
I'm a little confused still when you say "you can just create a new Bangle.setUI and now every app will use that". Isn't that Bangle.setUI local to the app that is currently running? So if I specify a callback, that function would have to be defined in the same app or clock? Or can other apps use a callback function that is defined in another app?
-
I noticed that Gordon changed a number of clock apps to use Bangle.setUI("clock") instead of setWatch() to open the launcher (incl. my own). But looking at the documentation I fail to understand what that function does. When I test the change it behaves as intended (i.e. BTN2 still opens the launcher), but I don't know how. If "clock" is the callback, why does it open the launcher? How does it know to use BTN2?
Can anyone explain what that function actually does?
-
-
-
Does the 'key stuck on' problem happen more often than just the missed key?
I don't think so - I would say the repeated key is just more noticeable than an initial keypress missed, but I could be wrong.
What exactly happens when an HID report is sent? Is there some sort of handshake or request/response with the receiver to make sure the packet has been received? Or is it just fired out in the hope the paired device receives it? From your comment I seem to understand there is a difference between the callback being triggered and the report actually being sent out / received?
-
What Gordon says about packets not being sent makes sense to me - when a keystroke is missed it's the "press" that is not sent, and when it's keystrokes repeating it is the "release" missing. That is also confirmed by the fact that it can usually be stopped by pressing the button again once or twice.
I also have the impression it depends on distance between the Bangle and the BT dongle. As soon as I get 2 or 3 m between the watch and the dongle it seems there is slightly more latency, and the misses/repeats become more frequent. @Franzo: Do you have a lot of distance between your watch and the BT receiver when this happens?
I can try with a Windows machine and see if there's any difference.
-
-
Hi,
as I hinted in my previous post, I fixed a problem that I had which seemed to influence also the stability of Bluetooth HID by "Installing Default Apps" from the App Loader. I can't say what exactly the problem was, I somehow messed up the storage and maybe some important firmware parts with it, but afterwards it was much more stable.
That said, I still occasionally encounter these same issues (repeated keystrokes or no keystrokes registered at all), like maybe once out of 10 times. It's not the reliability of a wired solution connected via USB for example. I never used a Bluetooth device before, but my assumption is that's just how Bluetooth works and not necessarily a fault of the Bangle.
-
Hello,
try connecting to the Bangle with
espruino
when it is not paired to your machine!I tried the same in the beginning, and I succeeded to start espruino in server mode to have the IDE connect to it. I just tried it again, but I had to unpair the device from the Bluetooth manager. Only then you will find it with
espruino --list
. I then connect to it using
espruino -d Bangle.js
I have not tried uploading to it from the terminal then however.
-
Okay, so I tried the hidjoystick app. Just a heads up for anyone else trying this, after changing the HID setting to "Joystick" it seems I had to completely disconnect (read: unplug the BT dongle) and reconnect the Bangle for it to be recognized as joystick, before it was still seen as keyboard. Now it works fine.
-
-
I see there is an HID keyboard module for the Bangle, but none for a gamepad apparently.
If I wanted to implement that, is this still my best bet, or is there something better now?
As a side question: I see in the code for the hidkbd app for example that there is neither a call to
require("ble_hid_keyboard")
nor toNRF.setServices()
as in all the documentation I can find on the subject. There is only ever theNRF.SendHIDReport()
. Apparently that works, but why?Thanks.
-
So, to follow up...after I sorted out my other problem with the storage I thought I'd give BLE HID another try, and whaddayaknow...it works much better now! Virtually like I expected it to.
-
You can use all the methods of the Javascript Date object I believe, but obviously you need to know what the actual time is. Since a Pico does neither have a battery-buffered RTC nor a GPS it has no way to set the time automatically or store it permanently. Bangle only does it as long as the battery is connected.
The only (simple) way is to synchronize the time from a PC that it is connected to, but you would need some software on that PC that does it. The Espruino Web IDE does that I believe, but again, the time would be lost once your Pico is unplugged.
I see...I didn't get that, thought you were updating the Messages app. I tried with another clock in the meantime as well and it worked fine, so I figured it must have been an issue with the clock app.
Thanks Gordon.