[FYT Android Head Units] AxesofEvil:
So I wanted to implement something like TeslaMate for my UIS7862. The idea being to be able to visualize trips, and various vehicle stats from Grafana (and maybe a live location tracker).

My original plan was to use TorquePro to log vehicle stats + GPS location, and then to send those logs to a listening webserver for storage in Prometheus and display via Grafana. I found an Automate script to hook this into HomeAssistant here: here. However, I wanted a few additional items:

I don't have a SIM card in my radio and do not normally have it connected to my phone as a hotspot, so internet connection is intermittent and I didn't want to lose data

I wanted to be able to upload to different IP addresses depending on whether I'm connected to the home network (i.e. at home) or otspot (i.e I'm driving)

I wanted to be able to store stats from the media canbus (like fuel level) that don't seem to be available on OBD-II (at least I haven't found them for my GTI)

I wanted to learn Kotlin and write a 'real' Android app

I was successful in writing an app that would send all unsent Torque data to my home server once it connects via wifi (basically reproducing Rob's Automate script), but getting the canbus data out of the radio required more work.

I decompiled 190000000_com.syu.canbus.apk and set about learning how it worked, and trying to connect my own app.

What I found so far:

Unlike the MKC/D units which appear to communicate with the canbus module via a serial port, the FYT radios seem to use I2C

The com.syu.ms.apk is responsible for the hardware communication

the com.syu.canbus.apk connects to the com.syu.ms.toolkit Intent to access hardware data.

This Service provides a getRemoteModule() procedure which seems to provide 4 different interfaces:

0: the 'Main' interface

4: the Sound interface

7: the Canbus interface

14: the 'CanUp' interface (no idea what this is)

each interface (IRemoteModule) provides 4 commands: cmd, get, register, unregister

The 'register' command registers a callback to a specific ID. That callback will be called when the value at the ID changes.

For instance, on my GTI, ID '6' of the canbus module is the fuel-level. I can register a callback at ID=6, and that callback will be called whenever the value changes

I haven't spent time to look at the other modules, nor what the 'get' or 'cmd' functions do

With the above, I now have a rudimentay application that will fetch the Fuel level from the radio (via the Canbox). My plan is to incorporate this with the OBDII capture to create a composte data-set to upload to my prometheus database. Interestingly, the com.syu.ms.toolbox only responds back to me if I use the 'com.syu.ipc.[IModuleCallback|IRemoteModule|IRemoteToolkit' descriptor.

I will make everything above available on GitHub once I've cleaned it up a bit. It should be possible to extract any canbus data the radio has (along with other internal state depending on what the other modules expose). However, what I've learned is that every CanBox has a different interface and presents diferent data, so the effort to make a generic interface would be very high and beyond the scope of what I plan to do. There are about 2500 unique CanBoxes listed in FinalCanbus. I see about 600 unique classes implementing these modules, each of which implements a different set of registerable IDs.

I plan to add an interface to register any ID if you know what you are looking for to my app. I think @surfer63 could do the same to FytHwOneKey if they were so inclined, but without a table of which features are available it would only likely benefit programmers.

I'll update this post with a GitHub link once available, but I thought there might be some interest in the canbus analysis stuff.

Here is the GitHub repository for the Canbus access library: https://github.com/AxesOfEvil/FYTCanbusMonitor