Clay breaks companion app communications. Used to work 10 years ago, doesn't work with new Pebble app

Watchapp Development
1

There is a serious issue with Clay, the Pebble app, and my watch face. Note, this all worked fine with the original ( and google upgraded) Pebble app, it has only become an issue with the (re)Pebble app as far as I know.

I have a watch face that communicates with a companion app. When using the face with the old Pebble app, I could configure settings and the face would communicate with the companion app fine.

With the new (re)Pebble app, I can either have the Glay configuration work, or the communications work but not both.

If I build the face with Clay implemented correctly, I can alter the persistent settings find, but the face cannot communicate with the companion app.

If I build the face with Clay “broken”, the communications with the companion app work, but the Clay configuration refuses to open (obviously as it is broken) in the (re)Pebble app.

This is a serious issue I need resolved, and all attempts to report this bug through the (re)Pebble app have failed to gain any traction.

How can I get this reported and worked on as some priority? I need to resurrect the watch face with full configuration via Clay working AND the communications with the companion app working at the same time.

I am willing to assist in any way I can.

The broken Clay implementation is here but you will need a CGMS supported by xDrip+ and an install of xDrip+ (Android) to test.

The path to the Clay source is incorrectly stated in this as src/pkjs/. Changing it to /src/js/ will make Clay work and break companion app communications.

Any assistance gratefully appreciated, and any things I can try to help diagnose I am willing to undertake.

1 Like
2

Are you sure this used to work?

As far as I remember, having JS code would disable PebbleKit Android. Even official documentation states so:

PebbleKit JS cannot be used in conjunction with PebbleKit Android or PebbleKit iOS.

It sounds like a bad idea anyway, as it means that both JS and PebbleKit Android would communicate with the watch simultaneously, causing conflicts (they would also not be aware of each other, so, for example, Android app could not easily get the config without the watchapp acting as a proxy).

Can’t the Android app simply provide the settings UI? Why the need for extra Clay?

1 Like
3

Yes, it definitely worked previously, and for over 8 years after Pebble sold to Fitbit. I used this watch face continuously until the LiPo started to lose charge, and moved to a different smartwatch. I’ve resurrected my PTS whole I await delivery of a PT2.

Clay, at the time, was supposed to replace internet based websites for C binary watch faces and apps, and it definitely worked for me.
Cheers

John Stevens
“You are how you live, not what you have.”

4

I would also add that Clay is meant to be completely separate from PebbleKit.js so that it can be used to configure all apps. I get why PebbleKit.js disables PebbleKit.Android as you don’t want both communicating with a watch. But Clay is meant to be about persistent settings held in the Pebble app and should not impact communications between a face/app and PebbleKit.Android.

So, perhaps I have something wrong with my wscript configuration that is enabling PebbleKit.js to enable Clay, and it shouldn’t? Is there a way to configure wscript to only use Clay for settings, and not expect a PebbleKit.js code to run comms to a watch?
Cheers

5

Originally worked using this as guidance.
https://developer.rebble.io/blog/2016/06/24/introducing-clay/#:~:text=Introducing%20Clay%20%2D%20App%20configuration%20made%20easy,the%20matching%20messageKeys%20from%20the%20config%20above.
Cheers

6

OK, I thought I had found the issue. I had enableMultiJS=true in my package.json, rather than false which is required for Clay to be used with a C watch face/app.
This did not fix the issue. With Clay not broken, settings work, but comms to the companion app fail. With Clay broken the face comms with the companion app fine.
Still at a loss.
Cheers

7

Clay IS PebbleKit.JS. It uses PebbleKit.JS to send settings to the watch. There is no magic that could magically create/send settings without creating JS.

8

Ok, I get that. But Clay is meant to be able to be used to save persistent settings in the Pebble app for C built binaries to use. That is how it worked years ago, but now including Clay breaks comms. Perhaps a change in the Pebble app changed this at some point, but it used to work fine.
I feel that Clay used to be separate from Rocky.js which was based on PebbleKit.js. Not being able to save persistent settings will make the watchface unconfigurable, and it needs to be. Obviously, I need it to be able to communicate with the companion app to retrieve data to display, and in future with a Pebble app version, to send data to the companion app. I understand a lot of other developers have not had this issue, but this used to work and was important to allow the end user to customise the watch face to their liking. It would be great to get this working again.
Cheers

9

But if the Pebblekit2 is already communicating with the watch, you can put the settings there. And you avoid the user’s confusion for having settings in teo aces (Clay and companion app)

10

But the companion app is not built with PebbleKit2 yet. I am trying to get that done, but having issues with Ilikel) the older android studio it is using, all th older code libraries it is including etc. So it is still using the original pebblekit, and we really want the watch face/app user to be able to configure it in the Pebble app using Clay. There is no alternative other than to recruit the watch face (no app yet, but planned) in Pebblekit.JS, which then cannot talk with the companion app.
It is rather complex to describe in e-mail.

The companion app is very feature rich and talks with multiple diabetes management technologies. Many years ago I created a watch face, based on the Nightscout one, taht a person living with Type 1 diabetes could use to manage their condition. The companion app does the majority of the work, with the Pebble acting as a remote display.

Back then, I introduced Clay to allow the user to customise the watch face outside of the companion app. The aim now is to support all the new Core devices and old Pebbles and simplify the process of configuring the watch face (or soon to be app) by allowing it to specify the settings the user wants, so they get the information they feel is valuable on the watch face. Every person manages their tech differently, so it makes sense that they would want to only display information they are interested in.

The plan is to make a framework (which I started more than 10 years ago) so all these variations can coexist with the user configuring the watch with what they want to see, and the companion app being told by the watch what to send it. This was working at least until the old Pebble app was no longer supported by Android. The new Pebble app does not allow the Clay settings and the communication with the companion app to coexist any longer, so that kills the framework. It would be really good if Clay and a C based watch binary could work again with the companion app.
Cheers

1 Like
11

Hi,
I have not been able to work on this for a while, but I have been thinking about it.
With the original Clay implementation in the Pebble app, for C-based binaries to use Clay the following settings needed to be in the package.json for the watch face/app.
“pebble”: {
“enableMultiJS”: “false”,
…
}

I do not know for sure, but enableMultiJS set to false may have disabled PebbleKit.JS except for the Clay component, thus allowing the communications between the face/app and the companion app.
If it were set to true, then PebbleKit.JS and Clay would run together? Not sure, but there must have been a reason this had to be set to false in package.json for C-based binaries.
Cheers

1 Like
12

According to this, there shouldn’t really be any difference: Multiple JavaScript Files // Pebble Developers

1 Like