Gadgetbridge can be configured to perform an action when a
Huami device is taken off or the user was detected to fall asleep or
wake up. This functionality was specific to Huami devices, but this
changeset moves this upstream to the AbstractDeviceSupport class in
combination with new GBDeviceEvents.
Now that the ADS has centralized support for this functionality, the
same logic can be used for other devices. In this case, an
implementation is added for supported Xiaomi devices.
Works:
- notifications
- call notification
- set time
- setting brightness
- setting 24h/12h format
- sending weather
Note
- this is implemented using using the classic bluetooth serial protocol, the
device can do BLE, but I don't know how to use it, as I did not have the
offical app to sniff.
- The information about the protocol comes from here
https://github.com/jfroehlich/node-p1x3lramen/blob/main/source/devices/pixoo.js
TODO:
- Enable beep? Possible? I heard it beep once at least when switching it on
- Getting out of factory mode? Why does it always play animations even when I
switch to the clock?
- Implement switching modes (can be done with the button)
- Implement sending own images and animations
- Firmware update?
- ...
Because the reporting of battery state is inconsistent between different
models, the device's battery state was not correctly processed in GB.
For at least the firmware on the Xiaomi Watch S1 Active, the charger
state is broadcast through a separate message from the message
containing the battery level. Even though the battery level was
requested by GB upon receiving this broadcast, the charger state got
discarded as it was expected to also be included in the result of the
subsequent request.
This patch changes the name of the `Charger` message to `DeviceState`
and includes more fields that may be presented by some device models.
Furthemore, the broadcast is cached so that the charger state can be
processed from this cache instead of the battery level response message.
Exceptions raised while handling actions in the device's support class
may result in the DeviceCommunicationService crashing as a whole and not
being started again until the user forces GB to make a connection by
pressing the device from the list.
This change is made, because Xiaomi devices make use of proto2 messages,
where optional fields cannot be set to null values as that will make it
throw NPEs.
This will prevent uncaught exceptions that occur during the
parsing of activity data from breaking up the activity fetching
chain and causing the task to never get completed.
The activity parser may return null pointers in case the version
of the data structure is not supported. Not checking for null here may
result in the activity fetching task may never complete and cause
further communication with the device to grind to a halt.
