Additional Control

[cdnninja]

Thought I would start a thread on where I am at. I have the data for cards and device IDs working. Authentication is also good.

Next up is device control / real status data. What I know so far:

1. MQTT is required for this. Key login details are here: https://github.com/yotoplay/yoto-sample-app/blob/0a5568ce0b450fcbfe9e03f17674d91f6cc6205b/src/utils/yotoMqttClient.js#L85-L101

We just need to pass the variables already available.

Now I don't know MQTT so what I am trying to figure out:

1. Can I implement my own mqtt broker within my API python? Will this impact HA event loop?
2. Can I use the built in MQTT in HA. My concern on this is all examples I have found show manual config of the broker. The username and password aren't really known without this integration. So setup would be a pain and each time the access_token changes it would break.

[cdnninja]

Have this working in a GUI interface. Just not sure how to turn this to code:

[cjb0001]

I previously did some digging into this topic, and likewise was able to use a GUI tool (MQTT Explorer) to connect and subscribe to /events, /response, and /status to get nearly real-time updates regarding the player, and strongly feel it's the right approach to use from HA.

On your questions, (2) I tried using the add-on mqtt mosquitto by creating a .conf file for bridging mosquitto but as you said, it's all manual config so not a realistic solution given the context, which leaves us with solution (1) using a mqtt broker for the HA integration. I did some extensive searching for existing integrations that mimic what we're trying to accomplish (a) authenticate via API then (b) switch to using mqtt over websockets for status updates from AWS. There are several python libraries that support mqtt over ws, including paho, websockets, and aiohttp (which is the one used by HA to expose HA data).

The closest example I located is the sound machine / light appliance Rest. The integration authenticates to an API, then using the awsio library uses mqtt over ws for updates. Here is the HA Integration, and here is the API.

Hope this helps.

[cdnninja]

Yes it helps for sure! I am very tempted to pull the mqtt up a level to the HA component but also was hoping to keep them split. By keeping them split others can consume this python API for other uses. With the APIs you provided I am going to spend some time focused on that before I loop back to fixing MQTT. Leaving anything that can be done on MQTT for that. APIs will be focused on items I don't think can be done elsewhere.

[davidbb]

I thought I might chime in with another integration that works the same way (MQTT). It's called hassio-ecoflow-cloud and it appears to do the same authentication flow and then switching to MQTT for updates.

The way many of these IoT apps are built today, is that the vendors run a large MQTT broker (e.g., on AWS), and then client applications connect to the broker to receive updates. It appears Yoto is doing this, so as you've seen connecting to the broker results in receiving near-realtime updates about the status of the players. This is much more efficient than polling some REST endpoint every few seconds or minutes.

But I did want to clarify that you probably do not need to implement a broker. Yoto runs the broker, and the integration will be a client. It's just a matter of figuring out how to get an authentication token and then subscribe to the MQTT broker and listen for updates on the correct topics. You two have already done most of the legwork on this, so it looks like the last part is integrating with home assistant entities and such. Take a look at the ecoflow integration code to see if that clarifies things.

And again thanks for the excellent work!

[cdnninja]

Thank you! I will take a look at that one as well. I am wondering if I can leave the MQTT within the API package I have built but can that client in the HA side. My goal is to have an API package that can be consumed on other platforms as well. I will need to do some testing to see if that works. This is a bit more advanced than my skills so learning as I go.

[cjb0001]

In preparation for using mqtt for updates, I've compared the keys in the status API vs the mqtt status topic. It seems appropriate to first populate the HA sensors with the API values when authenticating, then switch to the mqtt values.

MQTT /status	API $device/status	Comments
{	{
"status": {
"activeCard": "none",	"activeCard": "none",
"aliveTime": 2564650,
"als": 0,	"ambientLightSensorReading": 0,
"battery": 4164,
"batteryData": "0:0:0",
"batteryLevel": 100,	"batteryLevelPercentage": 100,
"batteryLevelRaw": 100,
"batteryProfile": "JY734352",
"batteryTemp": 0,
"bgDownload": 0,	"isBackgroundDownloadActive": false,
"bluetoothHp": 0,	"isBluetoothAudioConnected": false,
"buzzErrors": 0,	"buzzErrors": 0,
"bytesPS": 0,	"averageDownloadSpeedBytesSecond": 0,
"cardInserted": 0,	"cardInsertionState": 0,
"charging": 0,	"isCharging": false,
"chgStatLevel": 0,
"day": -1,	"dayMode": -1,
"dayBright": 100,
"dbatTimeout": 60,
"dnowBrightness": 100,
"errorsLogged": 8,	"errorsLogged": 8,
"failData": 0,
"failReason": 0,
"free": 3858224,
"free32": 66694,
"freeDisk": 6395712,	"freeDiskSpaceBytes": 6395712,
"freeDMA": 56706,
"fwVersion": "v2.17.6",	"firmwareVersion": "v2.17.6",
"headphones": 0,	"isAudioDeviceConnected": false,	0 = not connected; 1 = connected
"missedLogs": 0,
"nfcErrs": "0.00%-n/a",
"nightBright": 100,
"nightlightMode": "off",	"nightlightMode": "off",
"playingStatus": 0,	"playingSource": 0,	0 = not playing; 5 = playing
"powerCaps": "",	"powerCapabilities": null,
"powerSrc": 5,	"powerSource": 5,	0 = battery; 5= usb
"productType": "mini",
"qiOtp": 0,
"sd_info": "0xad, 0x4c53(LS), USD00, 16, 896843272, 11-2022, 1, 0, 1461, 50000000",
"shutDown": "nA",
"shutdownTimeout": 1800,
"ssid": "MyWifi",	"networkSsid": "MyWifi",
"statusVersion": 3,
"temp": "0:0:0",	"temperatureCelcius": "0",
"timeFormat": "24",
"totalDisk": 15441920,	"totalDiskSpaceBytes": 15441920,
"twdt": 0,	"taskWatchdogTimeoutCount": 0,
"upTime": 32222,	"uptime": 32222,
"userVolume": 50,	"userVolumePercentage": 50,
"utcOffset": 0,	"utcOffsetSeconds": 0,
"utcTime": 0,	"utcTime": 0,
"volume": 55,	"systemVolumePercentage": 55,
"wifiRestarts": 1,
"wifiStrength": -37	"wifiStrength": -37
}	}
}	In API but not in MQTT
	"deviceId": "ABCDEFG",
	"isOnline": true,
	"updatedAt": "2024-04-25T07:51:57.853Z",

[cdnninja]

I am very much struggling with how the architecture should look to get MQTT going. Anyone with more mqtt, HA and async experience than I how could mock it up? Once the client is functional in HA I am sure I can keep expanding it.