|
So for what it's worth, I hand-patched all the code that wasn't phone-related, and figured out the code to insert into the Mojo phone code to make it work based on the Enyo patch.
I've been tinkering and experimenting, using the Gadgetbridge code as a guideline. So far I've extended the phone-related functionality:
- Before when a call came in to the Pebble, it used to ring for a fixed 10 seconds and then quit. It now rings until the call stops ringing.
- If you answer the call, the Pebble shifts to "answered" mode and starts a call timer.
- If a call is missed or ignored, a "missed call" notification will be pushed to your notifications, with a missed call icon.
- Unknown and blocked IDs are properly listed in the ringing notification and the missed notification.
- New voicemail alerts (total unlistened count) are also pushed to notifications.
I made some changes to the e-mail patch to use the e-mail name instead of the e-mail address when sending a notification. I also added code to capture the volume up/down commands from the music player section, but while they are recognized by the mWatch app, I have no idea how to tie them into the phone and control the volume.
I have tried to get started on the notification sub-commands ("dismiss", "open", etc) but there seems to be something weird going on with the way the data is read from the Pebble. I suspect because the mWatch read code was originally written for the MW watches and they communicated via JSON (or a similar text-based method) that the Pebble's byte-based data stream is getting mangled when it's captured. Using some basic debugging I can see where the Pebble might send three separate messages that are captured in a single read of the Bluetooth data stream and only the first one is acted upon. I think to really make it work, the incoming data will have to be handled as some sort of byte-stream and parsed in chunks based on the Pebble protocol. Gadgetbridge uses a buffer... I'm not sure if a similar thing exists in JavaScript.
Also... there are 16-bit bytes showing up among the 8-bit bytes. It's almost always 0xfffd and I can't find a pattern for when it shows up... but sometimes when the code considers 0xfffd the high-byte of a 16-bit big-endian number it makes really BIG numbers! ^_^
I'm going to keep on tinkering. I suppose if I had all the time in the world, I'd love to translate all the Gadgetbridge Pebble calls into JavaScript that could be used on webOS, but for now I'm taking it a piece at a time.
Cheers!
James
|
|
|