maemo.org - Talk - [SailfishOS] [Announce] Rockpool

maemo.org - Talk (https://talk.maemo.org/index.php)

- Applications (https://talk.maemo.org/forumdisplay.php?f=41)

- - [SFOS] [Announce] Rockpool - Pebble daemon for Sailfish (https://talk.maemo.org/showthread.php?t=96490)

Re: [Announce] Rockpool - Pebble daemon for Sailfish

Quote:

Originally Posted by P@t (Post 1503654)

Regarding the timeline, do you mean the logs available in 'developer tools' ? I have opened it but is not meaningful to me ;)

Not really. In RockWork it could be used to send phone logs (what is actually needed) and pebble logs. On Jolla services log to journald so you cannot just pick the file and send, need to add certain _dumper_ interface to extract it from journald first.
So currently in rockpool you can only send pebble logs.
That means to extract phone logs you need to ssh to phone and start /usr/bin/rockpoold manually (disable service prior to this in the app) and collect the output.

Re: [Announce] Rockpool - Pebble daemon for Sailfish

Quote:

Originally Posted by ruff (Post 1503680)

You could also grep journalctl -la for the app name, except we've not set it yet. I should do that too, it's was there in the pebbled debug calls.

Re: [Announce] Rockpool - Pebble daemon for Sailfish

I guess you need devel-su for it? It logs to system journal, even for user session.

Re: [Announce] Rockpool - Pebble daemon for Sailfish

Quote:

Originally Posted by P@t (Post 1503626)

- during the night i usually put my phone and watch in flight mode. Sometimes it does not reconnect in the morning and I have to use the 'disable service' in the developer tools...

It did occur to me that using the standby-mode, connection can take longer. Probably due to

Code:

        qDebug() << "Attempting to reconnect in 15 minutes";

        m_reconnectTimer.start(1000 * 60 * 15);

in watchconnection.cpp. After long standby-time, in which the phone was still active and tried to reconnect, the reconnection attempt interval can go up to 15 minutes.

How costly, in terms of energy, is it to try to reconnect more often? I.e. what impact would it have to try to reconnect every 15 seconds, instead of every 15 minutes?

Also, I wonder if this is the only or best strategy. When the watch' bluetooth connection becomes active, it seems it merely makes itself discoverable. I'd assume it would try to reconnect itself at least once. What strategy does the android app use?

Re: [Announce] Rockpool - Pebble daemon for Sailfish

15 mins is too long I agree. But we could also detect when the bluetooth adaptor is re-enabled and try to connect immediately.

Re: [Announce] Rockpool - Pebble daemon for Sailfish

Ok, this is a start (not related to conversation above, just a dev connection)

Code:

$ pebble ping --phone jolla -vvv

INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): 209.118.208.39

DEBUG:pebble_tool.util.analytics:Queueing analytics data: {'platform': 'native_sdk', 'data': {}, 'event': 'invoke_command_ping', 'identity': {'sdk_client_id': 'e69fce62-a758-43ed-b84f-55c96c539e0b', 'user': u'56b6bd9e33376500234f0b00'}, 'sdk': {'host': {'platform': 'Linux-4.5.0-x86_64-with-glibc2.2.5', 'python_version': '2.7.11', 'is_vm': False}, 'version': u'3.11.1', 'tool_version': '4.2.1'}}

DEBUG:libpebble2.communication:-> WatchVersion(command=None, data=WatchVersionRequest())

DEBUG:requests.packages.urllib3.connectionpool:"HEAD / HTTP/1.1" 301 0

INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): td.getpebble.com

DEBUG:libpebble2.communication:<- WatchVersion(command=1, data=WatchVersionResponse(running=WatchFirmwareVersion(timestamp=1459810639, version_tag=v3.11.1, git_hash=4a040a3, is_recovery=False, hardware_platform=11, metadata_version=1), recovery=WatchFirmwareVersion(timestamp=1440968436, version_tag=v3.2-prf5, git_hash=5354924, is_recovery=True, hardware_platform=11, metadata_version=1), bootloader_timestamp=1436823217, board=spauld13, serial=Q554445E018Y, bt_address=29c2f548b4b0, resource_crc=2271546058, resource_timestamp=0, language=ru_RU, language_version=3, capabilities=2047, is_unfaithful=False))

DEBUG:libpebble2.communication:-> PingPong(command=None, cookie=187190662, message=Ping(idle=False))

DEBUG:libpebble2.communication:<- BlobResponse(token=44287, response=BlobStatus.Success)

DEBUG:libpebble2.communication:<- BlobResponse(token=31638, response=BlobStatus.Success)

DEBUG:libpebble2.communication:<- PingPong(command=1, cookie=187190662, message=Pong())

Pong!

DEBUG:requests.packages.urllib3.connectionpool:"POST /td.pebble.sdk_events HTTP/1.1" 200 0

INFO:root:Spent 0.516337 seconds waiting for analytics.

Re: [Announce] Rockpool - Pebble daemon for Sailfish

Quote:

Originally Posted by abranson (Post 1503701)

15 mins is too long I agree. But we could also detect when the bluetooth adaptor is re-enabled and try to connect immediately.

The host's adapter? Seems to be the case already. In the same file:

Code:

case QBluetoothLocalDevice::HostConnectable:

case QBluetoothLocalDevice::HostDiscoverable:

case QBluetoothLocalDevice::HostDiscoverableLimitedInquiry:

    …

     scheduleReconnect();

Indeed, when the watch is connectable and I disable flight mode on the phone, Rockpool reconnects immediately.

Re: [Announce] Rockpool - Pebble daemon for Sailfish

Now almost usable:

Code:

$ pebble install --phone jolla -vvv

INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): 209.118.208.39

DEBUG:pebble_tool.util.analytics:Queueing analytics data: {'platform': 'native_sdk', 'data': {}, 'event': 'invoke_command_install', 'identity': {'sdk_client_id': 'e69fce62-a758-43ed-b84f-55c96c539e0b', 'user': u'56b6bd9e33376500234f0b00'}, 'sdk': {'project': {'sdk': u'3', 'is_watchface': True, 'type': 'native', 'uuid': 'e8ff74f0-b103-4d99-8b3f-ee7d02b6f4b9', 'app_name': u'Petorial'}, 'host': {'platform': 'Linux-4.5.0-x86_64-with-glibc2.2.5', 'python_version': '2.7.11', 'is_vm': False}, 'version': u'3.11.1', 'tool_version': '4.2.1'}}

DEBUG:requests.packages.urllib3.connectionpool:"HEAD / HTTP/1.1" 301 0

INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): td.getpebble.com

DEBUG:libpebble2.communication:-> WatchVersion(command=None, data=WatchVersionRequest())

DEBUG:requests.packages.urllib3.connectionpool:"POST /td.pebble.sdk_events HTTP/1.1" 200 0

DEBUG:libpebble2.communication:<- WatchVersion(command=1, data=WatchVersionResponse(running=WatchFirmwareVersion(timestamp=1459810639, version_tag=v3.11.1, git_hash=4a040a3, is_recovery=False, hardware_platform=11, metadata_version=1), recovery=WatchFirmwareVersion(timestamp=1440968436, version_tag=v3.2-prf5, git_hash=5354924, is_recovery=True, hardware_platform=11, metadata_version=1), bootloader_timestamp=1436823217, board=spauld13, serial=Q554445E018Y, bt_address=29c2f548b4b0, resource_crc=2271546058, resource_timestamp=0, language=ru_RU, language_version=3, capabilities=2047, is_unfaithful=False))

Installing app...

DEBUG:libpebble2.communication:<- BlobResponse(token=52545, response=BlobStatus.Success)

App install succeeded.

INFO:root:Spent 0.001549 seconds waiting for analytics.

Re: [Announce] Rockpool - Pebble daemon for Sailfish

Quote:

Originally Posted by abranson (Post 1503658)

Wow I haven't seen those before - they must be the watch logs that ruff fixed last time! It's the rockpoold logs we need, but I don't think they're part of that yet. We'll have to add something to pull those out of the journal and include them. Log extraction would be very handy.

'About' on the pulley menu of the RockPool main window. Version should be at the top. Occasionally I've forgotten to update it when building a new package, but not very often :o

about the timeline sync, i have just realized that the events I do not see are those from caldav accounts. when using gmail calendar it works ok!