Starship doesn't recognize connected watch.

[haelge]

As mentioned in the Matrix channel, reported here to keep track on this issue.

Opposing to the build by @GeoffTearle, the automated build is not able to detect my connected watch.

Testenvironment:
SailfishOS 4.3.0.12 on Xperia 10
Fresh Install of prebuilt AsteroidOS (22.12.2021) on bass

Conspicuous logentries
[W] unknown:0 - Could not connect to asteroidsyncserviced. [W] unknown:0 - Could not connect to asteroidsyncserviced. [W] unknown:0 - Could not connect to asteroidsyncserviced. [W] unknown:0 - Could not connect to asteroidsyncserviced. [W] unknown:0 - Could not connect to asteroidsyncserviced. [D] initService:79 - Service file version ( 1.0 ) is not equal running service version ( ). Restarting service.

[comsorg]

I confirm, I also have a Starship doesn't recognize connected watch.

Testenvironment:
SailfishOS 4.3.0.12 on Xperia 10 II
harbour-starship-1.0-1.aarch64.rpm
LG G Watch R (lenok)

[GeoffTearle]

Did some digging this morning, and as far as I can tell Starship is no longer working due to the version of bluez used by SailfishOS no longer supporting the old bluez4 dbus api's.

Here's the output of dbus-send while attempting to introspect the old management interface:

[defaultuser@Xperia10II ~]$ dbus-send --system --dest=org.bluez --type=method_call --print-reply /org/bluez/Manager org.freedesktop.DBus.Introspectable.Introspect
method return time=1642289101.571521 sender=:1.2874 -> destination=:1.2888 serial=53 reply_serial=2
   string "<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
</node>
"

Unfortunately I was unable to find out how my old test build was at least partially working.

There's an issue here to track the bluez5 upgrade:
AsteroidOS/asteroidsyncservice#36

[GeoffTearle]

Well, after a bit more digging I found that the issue was not due to a bluez5 incompatibility, but rather a casing issue when attempting to identify if a connected device is an AsteroidOS watch.

I have a PR here to resolve the underlying issue: AsteroidOS/asteroidsyncservice#39
And will work on getting it into Starfish once its merged.

[comsorg]

Sounds great. I understand that if you manage to solve the problem, a new release of Starfish will appear. I'm looking forward to checking it out. Thanks!

[direc85]

I remember having to handle the uppercase/lowercase UUID strings, too, in my futile attempt to get Bluez 5 support up and running...

[GeoffTearle]

@direc85 The sync service seems to be consistently detecting my watch after the UUID casing fix, were there other issues you were seeing?

For me not all notifications are being sent to the watch, and Starship isn't picking up on battery changes from the watch (it does get an initial battery reading however).
I was planning to have a look at these once I'd converted Starship to use cmake.

[direc85]

I tried it again some time ago, and the behavior doesn't change, if the watch is actually connected or not... So there's still something else going on.

That was the case with my own build back in the link above times... That was kinda why I went public, if someone else has a clue

[beroset]

There have been a number of changes to the asteroidsyncservice project, including this AsteroidOS/asteroidsyncservice#44. I don't have a starship-compatible device on which to test. Can someone verify that it now builds as expected for starship?

[GeoffTearle]

@beroset Sorry for falling off of the face of the earth, I'll get the cmake conversion for watchfish finished this weekend, get the sync service changes integrated with my cmake branch, and let you know if theres any build issues.

[beroset]

@GeoffTearle It's no problem at all! Let me know if I can help. Also, I think the missing battery notifications may be due to a change in BlueZ. See AsteroidOS/libasteroid#13

[direc85]

Well, FWIW, I can now connect my LG G Watch R aka. Lenok with my X10 II with the 1.0 release of Starship. At least the connection seems to stay up, and the battery level updates nicely now that the watch is charging. I'll try with my XA2 next.

I'm having difficulties with getting the project build, but I guess I'll wait until the cmake conversion gets pushed, and then try again.

[GeoffTearle]

@beroset I'm getting a couple of build errors unfortunately.

The first two I can work around by pointing to the file in the parent dir, but possibly needs the target_include_directories tweaked.

• asteroidsyncservice/asteroidsyncserviced/main.cpp:21: error: 'asteroidsyncservice_config.h' file not found
• asteroidsyncservice/asteroidsyncserviced/dbusinterface.cpp:20: error: 'asteroidsyncservice_config.h' file not found

I think the following ones are possibly related to how Sailfish is currently using QT 5.6

• SailfishOS/mersdk/targets/SailfishOS-4.3.0.12-aarch64.default/usr/include/qt5/QtCore/qglobal.h:1019: error: ‘const class std::unique_ptr<BluezClientPrivate>’ has no member named ‘data’ ... SailfishOS/mersdk/targets/SailfishOS-4.3.0.12-aarch64.default/usr/include/qt5/QtCore/qglobal.h:1019:112: error: ‘const class std::unique_ptr<BluezClientPrivate>’ has no member named ‘data’ template <typename Wrapper> static inline typename Wrapper::pointer qGetPtrHelper(const Wrapper &p) { return p.data(); }
  Trying to dig into these now

[beroset]

I know this error because I had the same one on the Raspberry Pi. I fixed in on the Pi by altering one line of the Qt header, but there is probably a better way to do it. I'll fetch the exact change I made and post it here and maybe together we can come up with a better fix.

[beroset]

I made a patch to the qglobal.h file:

template <typename T> static inline T *qGetPtrHelper(T *ptr) { return ptr; }
#define BEROSET_PATCH 1
#if BEROSET_PATCH
template <typename Wrapper> static inline typename Wrapper::pointer qGetPtrHelper(const Wrapper &p) { return p.operator->(); }
#else
template <typename Wrapper> static inline typename Wrapper::pointer qGetPtrHelper(const Wrapper &p) { return p.data(); }
#endif // BEROSET_PATCH

#define Q_DECLARE_PRIVATE(Class) \
    inline Class##Private* d_func() { return reinterpret_cast<Class##Private *>(qGetPtrHelper(d_ptr)); } \
    inline const Class##Private* d_func() const { return reinterpret_cast<const Class##Private *>(qGetPtrHelper(d_ptr)); } \
    friend class Class##Private;

Later versions of Qt use exactly this. So rather than altering a system include file, another way to do it would be to check the version of Qt and if it's earlier than a certain version (I'll check which one) and provide an equivalent macro for Q_DECLARE_PRIVATE. I'll experiment and post results here.

[beroset]

The PR just submitted should fix both build issues.

[GeoffTearle]

@beroset you sir, are a gentleman and a scholar.
I'll check it out after work

[GeoffTearle]

@beroset I pulled your changes into my cmake branch and it compiles beautifully!!!
Great work!

Now I need to go finish converting libwatchfish 😅

[direc85]

I haven't yet tested with the fresh commit yet, but I couldn't get my Lenok work with my XA2 Ultra, but it did work with X10II... I'll try to rebuild the new stuff today and test again.

[comsorg]

I probably won't wait for the release of Starfish.
Can someone write in detail how to get the assembly for the watch yourself. I'm no expert in this. But I was struggling to find one simple guide, I believe there's more like me who are also looking for something like this.

[beroset]

@comsorg This isn't really the place to ask for general help. Better would be to go to https://asteroidos.org/ and look through the documentation and contact information there.

[comsorg]

beroset Sorry, I made a typo. I was asking about Starship

[beroset]

Is there any remaining reason this can't be closed?