[Model Support Request] Support for "Dyson Solarcycle Morph"

[MichaelProjects]

Hello,

I'm genuinely impressed with your project and its capabilities. Currently, I have a Dyson product that I'd love to integrate into my smart home setup. However, I prefer not to use the Dyson app on my GrapheneOS Pixel for this purpose. Instead, I'm interested in controlling it via Home Assistant, which I have hosted on-premises.

Would it be feasible to add support for this model in your project? I'm quite keen on contributing to this enhancement. If you could provide some insights into how your project interacts with the Dyson API, I would be more than happy to develop a pull request.

I'm excited about the possibility of collaborating on this and look forward to your response.

[dotvezz]

Oh this is interesting! I'd love to add support for the Solarcycle Morph. This integration relies primarily on MQTT to communicate wiith devices, and only uses the API for initial setup/discovery, and vacuum cleaning maps. I'm hoping that the Solarcycle Morph also uses MQTT (it would definitely make sense!)

Would you be able to help me with a few steps to investigate connectivity on the light? The first thing is running the get_devices.py script which you can find on the libdyson-neon repository. It will use your Dyson Cloud login to pull all the devices and some information about them, hopefully including credentials to connect to the Morph over MQTT.

Let me know if you have any questions!

[MichaelProjects]

Hey @dotvezz, so I tried that script but somehow the script isn't returning or printing anything after i enter the otp code, so maybe they changed something for this product category or I setup the device wrong up, which would be a bit funny.

[dotvezz]

Thanks for running that. I looked at the account code to see if I could find out why it isn't giving you any data. Looks like it's related to this comment from Shen a few years back. Unfortunately, it looks like he didn't add support for Lightcycle (and now Solarcycle devices) because he wasn't able to get local credentials for them.

I can't speak for Shen's reasoning, but my assumption is that his reasoning was related to the strict segregation of cloud and local support which he followed. I've chosen to go a different way, and the reasoning for that is explained in #49 if you'd like to read about it.

Looks like the Solarcycle is only controlled through the API. If it's running an MQTT broker like the fans, we can't connect to it. But we can likely reverse-engineer the API. Sadly I don't think I can convince my wife to let me drop $650 on a desk lamp (as much as I want to; I saw one at the store yesterday and it's REALLY cool).

But that's where you come in! I'm making another blatant assumption here, but my hope is a GrapheneOS user would be pretty technical. If you're comfortable doing it, would you be willing to MITM yourself for the sake of science and feature support? I run mitmproxy. You can use that, or if you have another preference then that works too! But for mitmproxy, the process is...

0. Run mitmproxy using your preferred method (container for me)
1. MITMProxy generates a CA cert. Install it on your Android device.
   • Recent Graphene builds seem to be based on AOSP 14, which makes CA cert installation a bit more intricate.
2. Set your Android system proxy to your mitmproxy host/port.
3. Using your UI of preference, set a filter for "dyson"
4. Use all the features of your SolarCycle in the app. The API requests should start showing up on the mitmproxy interface.
5. After you're done, export the filtered set of flows from mitmproxy and share them.
   • Since you're privacy conscious, I'd definitely recommend confirming that the export doesn't contain any sensitive information before sharing. If you wish to gpg-encrypt it and attach it to a comment here, my pubkey is here: pubkey.txt

If you prefer another method for intercepting your Android device's traffic, as long as you can export the filtered requests and tell me how to open it, that'll work for me.

[rubyroobs]

I have 2 of the Solarcycles (or rather, a lightcycle and a desk solarcycle but I think they are the same thing just renamed?) and they only have Bluetooth connectivity unfortunately.

[dotvezz]

Ahhh, if they're Bluetooth only that would definitely throw a wrench in the works. Just for the sake of completeness, can you confirm the app is unable to control the lamps when Bluetooth is disabled? If you're able to provide a screenshot illustrating this, that would be especially nice just so I have something material to reference if this question arises in the future.

[rubyroobs]

Sure!

[dotvezz]

Really appreciate that! It's a bummer but I don't believe I'll be able to support these lights. I'll happily invite anyone who is an expert in reverse engineering Bluetooth connections, and try to learn about it myself too. But for the time being this is sadly outside of my skill set if it's even possible.

[mundschenk-at]

If those are indeed BT controlled, it would be better to write a separate integration for them based on standard HA BT support (so that it can take advantage of proxies etc.) - no conceivable overlap with this MQTT-based integration.

[dotvezz]

@mundschenk-at For what it's worth, if someone is willing to help reverse-engineer the bluetooth signals used to control the lights, I think it'd be perfectly acceptable to include them in this integration. We already have features for the robot 360 Eye/Heurist devices which don't use MQTT.