Poll: Should we combine the "Dyson Local" and "Dyson Cloud" integrations?

[dotvezz]

TL;DR: New devices need the cloud integration anyway, why don't we just merge that cloud functionality into this repo? Vote in the poll!

While preparing to open a PR against HACS to make this and ha-dyson-cloud default HACS Repositories, I started wondering about the ergonomics of the two repos. They were "separated" a long time ago, before I adopted the project, in order to offer the promise a local-only home automation setup. It made perfect sense at the time, but these days it's a bit more complicated. It's also become a source of confusion for some users.

It made perfect sense at the time, but these days...

This project started in early 2021. At the time, the only features that actually needed any cloud connectivity were (to my knowledge) the video feed from the 360 Eye Vacuum cleaner. Although you could use the cloud connection to help set up your device in Home Assistant, it wasn't necessary.

Everything else could (to my knowledge) be done 100% locally without ever needing to hit the Dyson API. The fan devices like the HP04 used a common WiFi-Enabled IOT strategy: They had a makeshift "pairing mode" using a built-in WiFi hotspot. These devices shipped with a sticker that included WiFi information so you could connect your phone to the fan and configure it. Those WiFi credentials can be really easily decoded into MQTT credentials. You still needed to use the MyDyson mobile app to connect your device to WiFi, but literally everything else could be done locally using just that sticker.

Ironically, just a few months later around the summer of 2021, Dyson started releasing updated products that did away with the local hotspot functionality. They also stopped shipping with those WiFi information stickers. The HP07, which replaced the HP04, is one of these devices. The devices still communicated using MQTT, but the only way for the MyDyson mobile app to get the credentials was by querying the Dyson App API. Without using Dyson's API at some point or another, it became impossible to get the necessary MQTT credentials for connecting to the devices.

About that HP07...

Many of you are likely aware that your device has its model number, but it also has an internal product code. For example, the HP04's product code is 527. That product code is actually really important for making the devices work in Home Assistant for a couple of reasons. It plays a part in identifying devices, but also in communicating with them; that code is actually incorporated into the MQTT messages and if we have it wrong, we don't get anything. (This is an oversimplification, but suffice to say it's hard to decouple ourselves from this product code).

When Dyson released the HP07, it was just an updated version of the HP04. It got the code 527K. Oh, and also 527E for some reason.

Around the same time, Dyson released the HP09, which is a more-expensive version of the 527K and also incorporates a solid-state Formaldehyde sensor, which is very cool. It got the code 527K. Oh, and also 527E for some reason.

Hang on, what?

Suddenly our super-important unique identifier was neither unique nor an identifier. We needed it, we still need it, and we need it to be correct, in order to connect to the updated and upgraded devices. It used to be conveniently part of the WiFi sticker. But the only way to get it now? That's right, the Dyson App API.

It's also become a source of confusion...

It's a little bit confusing to have two separate repositories. Sure, we can clarify the difference in README.md files. But I'm going to say RTFM is a troubleshooting step, and shouldn't be an actual barrier to entry. We have people who have quite reasonably installed only the Dyson Cloud integration and get confused when it crashes without the Dyson Local integration.

This isn't an issue since v0.20.0, but we've had tons of people troubleshooting their Home Assistant's venv because of libdyson version mismatches (#26 for example) when they quite reasonably updated either the Local or CLoud integration, but not both - because HACS only checks for updates on a timer, it's totally possible to accidentally update only one. But they share that virtual environment, and can 100% break each other if not updated together.

And I'm constantly struggling to make it easy for people to learn whether they need the Cloud integration. These days, most people probably need the Cloud integration at least once, since those 2021+ devices are getting more and more common. What used to be an "if you want it" feature has become increasingly necessary, but people struggle to discover the Cloud integration. I've seen people on Reddit and Discord trying to figure out how to add their devices, but confused because they don't know what the heck the WiFi sticker is - because their device doesn't have one to begin with.

[dotvezz]

There's a new Beta release which combines the Cloud and Local functionality: v1.0.0-beta.

If anyone would like to test it and/or provide feedback, that would be great!

[codyc1515]

They should be combined for all of the reasons you mentioned but especially, for a volunteer project, for maintenance & support first and foremost. I see no issue with this - it just makes sense. I'll give it a test now. Tuya devices functionality similarly with the Local Tuya integration - connect to the cloud once, then store the keys and config locally to never contact the cloud ever again.

[codyc1515]

Updated to the beta - my (existing) device continued to work seamlessly with no issues. Then went Add Entry and selected MyDyson - set-up with no issues. My only recommendation would be with the decision of Dyson not to include the Wi-Fi label any longer to make the MyDyson the first listed option and to maybe flag the Wi-Fi / manual ways as not recommended or vice-versa.

[codyc1515]

Oop - just got an error pop-up. I do not have a Dyson camera. I just have the HP07.

Logger: homeassistant.setup
Source: setup.py:379 
First occurred: 20:08:37 (1 occurrences) 
Last logged: 20:08:37

Unable to prepare setup for platform dyson_local.camera: Platform not found (No module named 'custom_components.dyson_local.camera').

[dotvezz]

Ahh, so I can explain part of that: The cloud integration actually uses camera entities to show cleaning maps for the 360 Eye. That should honestly be refactored a bit to allow devices themselves to spin up relevant entities instead of tying it to the account entity. But for now, it's what we have.

I'll look into why we're throwing an error on setup here, though. I probably just missed something when I was moving files over. Thanks for the heads up!

[dotvezz]

v1.0.0-beta2 should address the camera setup issue. I don't love that it had me taking cloud stuff out of the cloud-specific package, but there's little I can do in the circumstances.

In the future, I still want to keep the spirit of being local-by-default, cloud-opt-in but do it in a way that's a bit less cumbersome.

[ehn]

If I previously had both integrations installed through HACS, can I safely remove the cloud integration after upgrading to 1.0.0? Can I also remove the custom repository if the one remaining integration is now available in HACS proper?

[dotvezz]

@ehn great questions!

If I previously had both integrations installed through HACS, can I safely remove the cloud integration after upgrading to 1.0.0?

Yes! Although you will want to re-configure your MyDyson account if you happen to need it at some point.

Can I also remove the custom repository if the one remaining integration is now available in HACS proper?

It's not available in HACS proper yet, but I'm working on that. When it becomes available, that will also be a yes. I don't know how long it will take; I see other requests have been sitting still for months.

[codyc1515]

It's now a default HACS repo :D hacs/default@fde1d55

[Silther]

Nice, do you have to change somthing if you installed it via custom repo?

[codyc1515]

Nope, although you could just simply remove the custom repository from HACS.