asteroidos / asteroid-btsyncd Goto Github PK
View Code? Open in Web Editor NEWBluetooth Low Energy synchronization daemon for AsteroidOS.
License: GNU General Public License v3.0
Bluetooth Low Energy synchronization daemon for AsteroidOS.
License: GNU General Public License v3.0
There is a calendar branch in this repository, what kind of state is it in? I don't know enough c++ to tell what parts are incomplete, but it definitely looks like it's behind on a major restructuring of the codebase.
What would it take to update the current calendar branch and finish it? I am ready to test my additions to AsteroidOSSync (AsteroidOSSync#89) but of course, that's kinda hard when my watch doesn't support it.
Sometimes the device name from the previous device is shown instead of the currently connected name.
An example is probably the easiest way to explain this. Start with the watch disconnected from all bluetooth devices. Using bluetoothctl
as the ceres
user on the watch issue the devices
command and if any devices are shown, remove
them one by one until the list is empty.
If we have two Linux computers named alpha
and beta
, we can connect to the watch from alpha
using bluetoothctl
in the usual way (i.e. scan on
and then connect
). This connection works, the devices are paired and everything works just fine. If we then disconnect
and then connect
again the watch correctly shows "Disconnected" and then "Connected alpha."
Now if we disconnect again from alpha
, and use bluetoothctl
on beta
, we do the same thing. First scan on
and then connect
. At this point we see a "Connected alpha" message again, which is incorrect because we're connected to "beta" and not "alpha."
This is mostly a question born from simple curiosity. I was wondering what would be needed to create a daemon application (say for Ubuntu Touch) that would provide the same function as the Android BTSync application for Asteroid. Would love to try my hand at creating a sync daemon for linux workstations and Ubuntu Touch, but I am unfortunately unsure to where I should begin. What Bluetooth protocols are used, and would it be possible to connect and communicate using a simple Bluez binding for my favorite language? Hell, I'll even take a nice pointing in the right direction as to what part of this and the Android project I should study.
Sorry, I just love how Asteroid is turning out, a little excited to breathe some new life into my G Watch and would like to try my hand working with it.
Apps rely on asteroid-btsyncd to fetch data from external sources. Currently, btsyncd only gets data from a Bluetooth Low Energy connection with a phone app.
However, some watches have WiFi capabilities and could potentially be connected to the internet. In that case, it would be very useful if common btsyncd services (e.g: weather & time) could get data from the Internet.
Since the support of Wifi in Asteroid watches is not a priority for v1.0, this task can be postponed for another release. (eg: v1.1 ?) However, anyone can start working on it right away from QEMU where the network card can already be configured to access the internet.
I do not receive notifications for SMS & MMS messages on dory. My phone is an Android One moto x4 running Android 9.0 and AsteroidOSSync 0.13. I receive all other notifications.
On another note, I tried to ssh into the watch to pull some logs for this post (using ceres and root @ the default IP address), but my connection keeps timing out. I took a pcap of the connection and it was all TCP Retransmissions.
I want to work on this though because I otherwise love AsteroidOS so far. :) Thanks for making!
As mentioned before in the Matrix channel, on my old phone it happened regularly that when my watch connected, it lost connection right away. The AsteroidOS Sync android app would should show either 0% or 100% battery regardless of the actual battery and show the menus as if connected, but of course no syncing would actually happen.
@beroset recently seemed to have the same issue on his laptop, and might be able to debug more.
Currently, transferring data between the watch and paired device requires a dedicated BLE profile. This is a steep learning curve for app developers, as an understanding of BLE and asteroid-btsyncd is needed.
Hi all,
I'm trying to create a unofficial UWP connector for AsteroidOS smartwatches and I've recently encountered a problem with the (amazing documented) BLE exposed services, in particular with the Screenshot Content Service.
The Request's characteristic operation has always successful result, the application can receive the notifications by Content's characteristic, read the first 4-bytes that determines the image size as int32 but after a few chunks of raw bytes, the Smartwatch (in my case a Sony "tetra" SR50) stop sending data.
The strange fact I observed is sent data is always 10 times lower than expected size.
I think that both SR50 and my phone (Lumia 950XL), that are respectively BT 4.0 and BT 4.1, can't manage a chunk bigger than 23 bytes because of SOC's specification/hardware limitations.
I also noticed in this repo that the max output size sent by AsteroidOS GATT server is actually 200 bytes (I'm not a Qt developer but I read the official Qt documentation for QFile.read method).
while (!f.atEnd()) {
m_value = f.read(200);
emit valueChanged();
emitPropertiesChanged();
}
f.close();
I think that is higher of dimensions supported by average consumer devices
Dear AsteroidOS Team,
I really want to add the Health Device Profile for my sportswatch.
https://www.bluetooth.com/specifications/assigned-numbers/health-device-profile/
(Heart BPM)
Not sure if it is important. I baught the LG Watch Urbane W150 and im familiar with bitbake due to a lot yocto development in my job.
I found this through a different bug, but I have figured out that this bug is much more than the one bug. I accidentally was sending an invalid year in trying to implement AsteroidOS support for Gadgetbridge, which led to me sending a technically negative number (> 127). When this is added to 1900 in the year for TimeService, this is subtracted instead, giving a completely invalid year, which crashes the daemon.
QByteArray
is apparently a fancy wrapper around const char*
, but not const unsigned char*
, so many values are incorrectly cast with signedness in mind.
This is done in timeservice.cpp:31, many times in weatherservice.cpp (mainly in the temperature stuff), in mediaservice.cpp:171 and a few others.
I can start writing a fix, but I have no clue how to upload and test this daemon on my watch/emulator, so some guidance there would be appreciated.
Moved from AsteroidOs issues.
I have now made further progress in tracking this error, I believe this to be a better repo to raise the issue.
The local services seem to be able to register correctly to the bluez stack, however on request from remote connections the service discovery results appear to cause the errors below.
This can be reproduced on any pairing and SD session and does not appear to be specific to AsteroidOSsync app.
My fedora based laptop using bluez5 & supported hardware also fails.
On the latest build for dory there seems to be an issue with Bluetooth connection failing. After
numerous attempts, it seemed to successfully pair but seems to fail then disconnect. logs show failure at negotiating services. bluetoothd also reports no cache for device address.
The link below has a gist with logs for hcitrace via btmon and journalctl logs with bluetoothd in DEBUG mode.
there is approximately one connection, pairing , and disconnect in the logs which can be found here:
https://gist.github.com/davnustratbac/e99e46c098cea85796fdb2a91b189a44
Packet dump file of same timeframe:
https://s3-eu-west-1.amazonaws.com/wireshark-bucket/journalctl-debug-bluetoothd-74-105.log
3 packet overview:
ACL Data RX: Handle 64 flags 0x02 dlen 9 #94 [hci0] 86.882368
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x0001
Error: Unsupported Group Type (0x10)
ACL Data TX: Handle 64 flags 0x00 dlen 11 #95 [hci0] 86.882940
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0001-0xffff
Attribute type: Include (0x2802)
further back in time in the logs this request may be involved :
< ACL Data TX: Handle 64 flags 0x00 dlen 11 #89 [hci0] 78.332507
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Secondary Service (0x2801)
According to the current Bluetooth core specification, in Volume 3, Part F, section 3.2.9, it says:
The maximum length of an attribute value shall be 512 octets.
Since a screenshot is typically many kilobytes, our API does not appear to conform. At the moment, we have two characteristics:
Screenshot Service (UUID: 00006071-0000-0000-0000-00A57E401D05)
Screenshot Request Characteristic (UUID: 00006001-0000-0000-0000-00A57E401D05)
This characteristic can be written by the client to any value (for example one byte set to 0) to trigger a byte stream on the Screenshot Content Characteristic.
Screenshot Content Characteristic (UUID: 00006002-0000-0000-0000-00A57E401D05)
This characteristic can be used to be notified of a screenshot content. After a write to the Screenshot Request Characteristic, the first value signaled by the Screenshot Content Characteristic should be made of four bytes containing the size of the data to be transmitted and can be used to show a progress bar during the screenshot download time. The rest of the transmission is made of chunks of raw data to be concatenated by the client in a buffer to reconstruct a screenshot of the watch's screen. The complete buffer should be a valid JPEG file but other formats could also be considered in the future.
While the request characteristic is fine, the Content is always going to be bigger than 512 bytes. I think the way to handle this is to change the API to use multiple characteristics.
If each Chunk were a fixed 16 bytes long, this would allow a 4-byte offset to be communicated with each chunk.
Reading a Chunk Content with a Chunk Offset outside the range indicated by size would simply return zero bytes (not even including an offset). Reading a Chunk Content that was a last partial Chunk (e.g. the end of the file) would return a valid Chunk but with only as many bytes as actually exist to the end of the file.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.