Notices

Hey there!

At first I want to thank you for the amazing work you did with Rockpool. I really like my Pebble and it's great that it works with my Jolla.
I would like to ask if there currently is a way of communicating with a Jolla app. Specifically I think it would be great if we could show direction instructions from apps like Poor Maps.

Could we map the API Pebble provides for companion apps to DBus interfaces?

Best
Max

As of the latest update, Saera has an option for opt-in cloud-based speech recognition as well as on-device recognition.

what would be that cloud-based service?
If there's something ready the feed the voice with simple API - we can of course link it as a PoC and then we can formulate what would be the best api for us to implement in saera.
As of now the only PoC i can do is to dump voice to /dev/null and send some stub text in response.

Hi, rockpool supports (almost) full JSKit API, including XHR and WS, so the fastest way to communicate to local app I can see is to fire up a WS or HTTP endpoint on the loopback and speak to it from jskit.
There's an effort (currently WiP no ETA) to extend JSKit API by DBus interface, which may allow one to spare some time coding WS - although i don't think it's that complicated, qtwebsocketserver is quite straightforward one.

I have to say that I _really_ doubt the devices are BLE-only, mainly because of bandwidth constraints. If they plan to still keep the "applications-uploaded-on-demand" charade, I'm quite sure they still use normal Bluetooth for that; otherwise the delay to use a program would more than annoying.
If you have any more confirmation about that than CEO-speak it would be interesting.

In fact bandwidth is the main reason that so far no smartwatch has actually been "BLE-only". I only know of some editions of the Metawatch, and some fitness bands.

And I used to connect the BLE Metawatch happily with my Nokia N9, which had a kernel that was even older kernel than the Jolla
On the N9, the kernel had a limitation regarding BLE Random addresses, but that's no longer present on the Jolla, and random _static_ addresses work fine (right now my Jolla is connected to a Garmin Fenix without problem).



If it turns out that the newer Pebbles are BLE only, or that some functionality is only accessible via BLE, as mentioned, you might want to use a "mostly user-space" BLE stack, such as Gato or backport Qt Bluetooth 5.4 (which was partially based in Gato).

With both approaches you have the same limitations as described in https://together.jolla.com/question/...th-le-support/ .
To summarize:
* Scanning for devices is difficult because it requires root access. Maybe a small setuid binary or something like that to trigger the scan.
* No "peripheral" role (i.e. Jolla must connect to the watch, not viceversa).
* Pairing is possible, but not safe: LTKs are _not_ stored by Bluez, so MITM attacks are possible. However, BT4.0 has confirmed security holes, so MITM attacks are technically possible even if LTKs were stored.

(On the Jolla, Bluez4 will not scan for LE devices because it thinks it's not on a BLE device. I've managed to confuse it enough so that it actually scans for BLE devices, but it's ugly. )

Please note that there's not much Jolla can do about this since we're about the only platform (other than ChromeOS) where there's any interest in using Bluez4/5 stack with BLE+GATT. Updating the kernel will not help anything, unless they update it to extremely recent version alongside a extremely recent version of Bluez (which has upstreamed the ChromeOS GATT patches), and then fix QtBluetooth, and then recertify the device, and then...

In any case I suggest waiting to see if the newer Pebbles are BLE, and if they are, "how much" BLE they are before any move.

I first heard about it from Katharine Berry on the ubuntu pebbler's group, then found the earlier statement from the CEO to back it up. She also said that the Pebble Time Round has been BLE only on iOS since it launched.

I found that: https://gist.github.com/alotaiba/1730160

Thanks Boke, looks like good way to proof the concept.


Aside from that, I'm switching to gui mode now, and meanwhile posting alpha on beta that is 1.0-alpha1timeline2 - with following items:
* Added websync to the timeline
* Added (rather implemented) timeline API to the JSKit.Pebble - except account token - which is still randomly generated.
* Added canned messages for jolla messaging center (telepathy) which allows replying to SMS and IM.


All these elements require initialization to start working, which in absense of GUI could be done a always via DBus.

Set OAuth token
Set canned messages

nope, Saera currently uses Wit.ai as the optional speech recognition engine - google and AT&T are planned as options but not yet implemented.

edit: the reason for using wit.ai is because it has an official Python client, whereas the google voice recognition is a hack that might break at any time.

Hello,

Now that I've been using this excellent app for a while, I have repeatedly noticed one issue about the connectivity (daemon ?).

I tend to turn off the BT from Jolla in the evening and turn it on again in the morning. In my Pebble the BT is on all the time. The phone and the watch get connected perfectly (almost) every time, but the Rockpool app usually says "Disconnected" - and the notifications won't work - until I restart the service from Developer Tools (thank god for that ! ).