support for Dyson 360 Vis Nav

[Anto79-ops]

hey,

wondering how well support for the 360 Vis Nav is, currently?

thanks

[Anto79-ops]

also, just curious, having a camera, is this local polling or cloud for the images?

[dotvezz]

For images, almost definitely cloud. The camera feed reaches the mobile app via the cloud, and that's what we'd be using (Unless I can find a way to pull directly off the device somehow).

For support, I really need to follow up with a couple of people who mentioned this over in the issues. I don't have a 360 Vis Nav to test with myself, so I'll need a volunteer to help. @Anto79-ops do you happen to have one?

[Anto79-ops]

@dotvezz you bet! I'll be getting one in a few days I'd be happy to help you. Maybe give you a data dump keep you posted

[doncuco]

Hey,
I have one and can assist you. No problem. I would appreciate that.

By the way, adding the 360 bis nav fails. So we definetily would need an update to bring it to work.

[Anto79-ops]

oh thats awesome. I have not received mine yet, hopefully tomorrow but what I was going to connect to it via the mqtt listen tool here:

https://github.com/dotvezz/dyson-mqtt-listen

Maybe you can get a data dump and post here what the machine is broadcasting? Or perhaps this tool won't even work if you cannot add it to the integration but @dotvezz can confirm that, he made the tool!

[dotvezz]

@doncuco nice! Are you able to run a python script? In our libdyson-neon repository, there's a script called get_devices.py.

If you have python installed, you can...

1. Clone the repo
2. cd into the clone
3. pip install -r requirements.txt
4. py get_devices.py

The script will ask you some questions and get you logged in using the Dyson API. Then it'll spit out information about the devices attached to your account. A quick note: When it asks for Region Code, that's a two-digit representation for your country, like "US" or "UK" etc.

@Anto79-ops I love the attitude, unfortunately my mqtt-listen tool is limited to just fans for now. I'm working on a full port of libdyson to Go, along with a big CLI that uses updated APIs to get a lot more information from the cloud side of things, including info about the vacuums and their video streams. It'll be a big improvement over what we currently have for testing new devices. But for now, mqtt-listen and get-devices.py are the best we have.

[doncuco]

@dotvezz so here is the output:
Serial:
Name: Dyson 360 Vis Nav™
Device Type: 277
Credential:

[dotvezz]

@doncuco thanks, this'll be a big help!

[Anto79-ops]

@doncuco you may wish to remove your serial number and credential now.

[doncuco]

Yeah you're right. Tried to pm but GitHub doesn't support that.

[Anto79-ops]

I know! btw, how are you liking the vacuum? People reactions to it seem to be mixed, but mostly bad and its based on the model from 9 months ago. Hopefully this bot is not the same as the one from then. Seems odd they would introduce in Aus/UK back then, and only now its available in Can/US and other countries.

[doncuco]

It does the job. And that’s what’s its intended for. But my Profil is perfect for it. I wanted a good vacuum and a small station. It is for my office and rooms where navigation is easy.
So as it is one of the best vacuums the scenario for me is perfect.
But I haven’t starteten it in bout living area. That would be interesting.

[Anto79-ops]

awesome. Got mine yesterday for home, and so far so good. Does hardwood floors no problem, right now its doing carpeted floor and its taking a charging break :)

I'll see if i can get a test environment up to help you with getting this into HA.

[dotvezz]

@Anto79-ops and @doncuco sorry for the wait with this one! 1.4.0-rc1 is set as a pre-release for you to test as you like. Let me know if anything is weird, I'd really appreciate your help!

One thing I know is that the camera maps don't work. There's another thread with someone who said they've got it working for the 360 Heurist, I'll follow up with them to see if they can open a PR.

[Anto79-ops]

Hey, awesome! Thank you.

I just updated rc1, but I don't see the option for the Vis Nav? I do have the serial and credentials for the machine.

[dotvezz]

@Anto79-ops thanks for catching that. I was so focused on making it talk that I forgot to give it a name for this list 😅. RC2 is available for you to try out, thanks again!

[Anto79-ops]

awesome! Ok I added it sucessfully. Here's what I see:

you have to wake it up first. So all I had to do was just open the app and let the app connect to the vac (i.e when it says ready to clean), and it then I press submit on the config page and it set it up sucessfuly (it didn't work if I didn't wake it up from the app).

just curious about the language, the app uses auto, quick, quiet, boost for vac modes(?), is thag available, too?

[dotvezz]

I copied over the modes from the Heurist model, but sounds like there are modes that are specific to the Vis Nav. I'll get those modes added too. Will let you know when I have another RC ready for you!

This probably won't make it into this release unless I figure something out, but I also want to try to find a way to send the wake-up signal from this integration.

[Anto79-ops]

sounds great! let me post some app photo.

also, saw this in the logs

Logger: homeassistant.components.binary_sensor
Source: helpers/entity_platform.py:356
integration: Binary sensor (documentation, issues)
First occurred: 8:49:15 AM (1 occurrences)
Last logged: 8:49:15 AM

Error while setting up dyson_local platform for binary_sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 356, in _async_setup_platform
    await asyncio.shield(awaitable)
  File "/config/custom_components/dyson_local/binary_sensor.py", line 40, in async_setup_entry
    g(device, name),
    ^
NameError: name 'g' is not defined

[Anto79-ops]

Some photos here from the app

[Anto79-ops]

also, did a couple of test with voice commands (via google assistant/Nabu Casa):

to start: "Hey Google, Start the Dyson Vacuum robot"
to stop (return to dock): "Hey Google, Return home Dyson Vacuum robot"

both commands worked as expected!

[Anto79-ops]

saw another log error here:

This error originated from a custom integration.

Logger: homeassistant
Source: custom_components/dyson_local/vendor/libdyson/dyson_vacuum_device.py:20
integration: Dyson (documentation, issues)
First occurred: 8:42:42 AM (1 occurrences)
Last logged: 8:42:42 AM

Error doing job: Exception in callback Entity.async_write_ha_state()
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 998, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1119, in _async_write_ha_state
    state, attr, capabilities, shadowed_attr = self.__async_calculate_state()
                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1056, in __async_calculate_state
    state = self._stringify_state(available)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1004, in _stringify_state
    if (state := self.state) is None:
                 ^^^^^^^^^^
  File "/config/custom_components/dyson_local/vacuum.py", line 146, in state
    return DYSON_STATES[self._device.state]
                        ^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/dyson_local/vendor/libdyson/dyson_vacuum_device.py", line 20, in state
    return VacuumState(
           ^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/enum.py", line 744, in __call__
    return cls.__new__(cls, value)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/enum.py", line 1158, in __new__
    raise ve_exc
ValueError: 'MACHINE_OFF' is not a valid VacuumState

for this error above, the vacuum became unaviable in HA.

and there is another log error (I reported above already)

Logger: homeassistant.components.binary_sensor
Source: helpers/entity_platform.py:356
integration: Binary sensor (documentation, issues)
First occurred: 8:49:15 AM (1 occurrences)
Last logged: 8:49:15 AM

Error while setting up dyson_local platform for binary_sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 356, in _async_setup_platform
    await asyncio.shield(awaitable)
  File "/config/custom_components/dyson_local/binary_sensor.py", line 40, in async_setup_entry
    g(device, name),
    ^
NameError: name 'g' is not defined

[dotvezz]

@Anto79-ops thanks, all that info is really helpful. Turns out there's a few new twists to the Vis Nav, cool! Here's a new RC

I've updated the Vacuum State sensor to handle the MACHINE_OFF state we get from the device, which should help with the big scary log you showed earlier today. Also fixed a the bug I introduced which caused your smaller, less-scary log.

For the vacuum mode, I've made some assumptions about the mapping for the 4 modes. Could you test and let me know if they work correctly?

[Anto79-ops]

@dotvezz thanks so much for trying to figure this out! Installed rc3 and I see this in the logs:

Logger: homeassistant.components.vacuum
Source: helpers/entity_platform.py:580
integration: Vacuum (documentation, issues)
First occurred: 7:56:33 PM (1 occurrences)
Last logged: 7:56:33 PM

Error adding entity vacuum.360_vis_nav_robot_vacuum for domain vacuum with platform dyson_local
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 580, in _async_add_entities
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 881, in _async_add_entity
    await entity.add_to_platform_finish()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1334, in add_to_platform_finish
    self.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 998, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1119, in _async_write_ha_state
    state, attr, capabilities, shadowed_attr = self.__async_calculate_state()
                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1058, in __async_calculate_state
    attr.update(self.state_attributes or {})
                ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/vacuum/__init__.py", line 267, in state_attributes
    data[ATTR_FAN_SPEED] = self.fan_speed
                           ^^^^^^^^^^^^^^
  File "/config/custom_components/dyson_local/vacuum.py", line 256, in fan_speed
    return VIS_NAV_POWER_MODE_ENUM_TO_STR[self._device.current_power_mode]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: <VacuumHeuristPowerMode.QUIET: '1'>

and

Logger: homeassistant.components.binary_sensor
Source: helpers/entity_platform.py:735
integration: Binary sensor (documentation, issues)
First occurred: 7:56:33 PM (2 occurrences)
Last logged: 7:56:33 PM

Platform dyson_local does not generate unique IDs. ID [redacted]-battery_charging already exists - ignoring binary_sensor.360_vis_nav_robot_vacuum_battery_charging
Platform dyson_local does not generate unique IDs. ID[redacted]-bin_full already exists - ignoring binary_sensor.360_vis_nav_robot_vacuum_bin_full

unfortunately, I cannot test it out because its unavailable

[Anto79-ops]

Another log for you.

This error originated from a custom integration.

Logger: homeassistant
Source: custom_components/dyson_local/vacuum.py:256
integration: Dyson (documentation, issues)
First occurred: 8:06:18 PM (6 occurrences)
Last logged: 8:07:39 PM

Error doing job: Exception in callback Entity.async_write_ha_state()
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 998, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1119, in _async_write_ha_state
    state, attr, capabilities, shadowed_attr = self.__async_calculate_state()
                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1058, in __async_calculate_state
    attr.update(self.state_attributes or {})
                ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/vacuum/__init__.py", line 267, in state_attributes
    data[ATTR_FAN_SPEED] = self.fan_speed
                           ^^^^^^^^^^^^^^
  File "/config/custom_components/dyson_local/vacuum.py", line 256, in fan_speed
    return VIS_NAV_POWER_MODE_ENUM_TO_STR[self._device.current_power_mode]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: <VacuumHeuristPowerMode.QUIET: '1'>

[doncuco]

Hello,
Thanks for the implementation. RC2 worked for me too. I see the same issues as above mentioned. Since RC3 it is unavailable. Going back to rc2 didn't fix it. I try to delete and readd the device.

[doncuco]

So I removed rc3 and tried rc2 again but I wasn't able to add the vis nav again. Same error as with rc3. Any idea how to fix this?

[Anto79-ops]

@doncuco can you share some logs? especially if they are different than the ones I posted, as it could give more information. Thanks for the warning. I have not deleted the vac. Maybe if you try Rc1 and then add the vac, then upgrade to rc3 but rc2 had it semi-working without the modes.

[doncuco]

I started a cleaning process and tried to add it but this didn't work.

[doncuco]

Reassigning a new fixed ip with rc3 didn't fix it.

[doncuco]

Resigning ip and rc1 as well.

So how can I provide you the logs for these attempts?

[Anto79-ops]

yeah, i've not been able to make my machine connect for a while now. Its been unavilable since RC3. It might be do to the waking up on connect, or something else. Not sure what has changed. Im going to try something on next restart of HA, wake it up or connect with the machine using the app and then restart HA immediately. Post later what happens...

[doncuco]

That would be great. For me nothing has improved. I restart home assistant normally once a day or so because I am currently creating my dashboards and am working much with integrations and so.
Perhaps you might find some trick. And do you know how to get the logs of the failed integration atemptions?

[Anto79-ops]

for the logs, just check out the core logs (settings, system, logs >) and look for those mentioning the Dyson Integration.

[Anto79-ops]

ok, on HA restart and with the vacuum awake, I get this error

This error originated from a custom integration.

Logger: custom_components.dyson_local
Source: custom_components/dyson_local/__init__.py:149
integration: Dyson (documentation, issues)
First occurred: 2:15:16 PM (1 occurrences)
Last logged: 2:15:16 PM

Failed to connect to device W4J-CA-[redacted] at 192.168.1.107

[doncuco]

And did you get it to reconnect?

[Anto79-ops]

No, I'm tempted to delete and add it again, but then it floods my logs with errors. Hopefully, dotvezz gets around to it.

[dotvezz]

@doncuco This might be a silly question, but are you able to confirm whether the device's IP Address is still 192.168.1.107?

[doncuco]

i am using fixed IPs and I changed to 192.168.1.113.
Should I change it back?

Last thing I tried was deleting the integration. Restart my VM of HASS and reinstalling the integration. No luck.
All with the new IP.

[dotvezz]

@doncuco @Anto79-ops Sorry for the long delay! It's not much of an excuse, but I got overwhelmed with my day job for the past several weeks. Things are a bit more stable now thankfully.

@Anto79-ops I've got 1.4.0-RC4 that addresses part of the stuff you posted from your logs. Let me know if it helps at all when you have a chance. I'm looking at the rest of the posts/logs here as well to see what else needs to be done.

[Anto79-ops]

@dotvezz please, no need to apologize to me!

I'll give the new version a try. But I also wanted to let you know that sometimes even the app has issues connecting with the robot. I have to wake it up manually and then use the app. So this could be either my network connection or Dyson. I guess we're all learning as we go. Ill posts an update later. Thanks for the update!

[Anto79-ops]

updating to RC4, and rebooting, the device was still unaviable (it was doing a clean and was accessible via the app). I removed the device and tried to add its back with the serial number and credentials, and even tried with the IP address (which is suprisingly, still the same 192.168.1.107), and it won't add anymore.

There are some error message here, not sure if this one is when I deleted the device:

Logger: homeassistant.config_entries
Source: config_entries.py:774
First occurred: 8:45:38 AM (1 occurrences)
Last logged: 8:45:38 AM

Error unloading entry 360 Vis Nav robot vacuum for dyson_local
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 774, in async_unload
    result = await component.async_unload_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/dyson_local/__init__.py", line 190, in async_unload_entry
    device = hass.data[DOMAIN][DATA_DEVICES][entry.entry_id]
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
KeyError: '96def923f76282a473d08278daa797a1'

also this same one:

This error originated from a custom integration.

Logger: custom_components.dyson_local
Source: custom_components/dyson_local/__init__.py:149
integration: Dyson (documentation, issues)
First occurred: 8:35:18 AM (1 occurrences)
Last logged: 8:35:18 AM

Failed to connect to device W4J-[redacted] at 192.168.1.107

when trying to add the device, the UI gives this error message (with or without IP address inserted)

On RC1, it added no problem. Should I try RC1 again and then try RC4?

[dotvezz]

Hmm, RC1 and RC4 shouldn't have any significant difference in establishing the connection. But don't let my assumption stop you if you're feeling adventurous 😅. If you happen to get it to connect on RC1 then definitely let us know here.

[Anto79-ops]

ok, something strange is happening. I downgraded back to RC2 (not RC1 because that does not have config option for 360 Vis Nav), and unfortantly, I cannot add the robot back to the integration.

I thought perhaps the credentials on the machine changed (is that even possible?), so I used my packet capture app on Android, and get this, the moment the app is running to listen to MyDyson app, the app cannot connect to the robot either. The moment I turn off the packet app, I can connect. So I cannot get the credentials anymore (but I have them from before, so unless they changed, they should still be valid).

Same issue with Dyson Cloud. The devices show up as discovered, but when I press submit, it cannot add the robot back.

Here's my concern, theree have a been at least a few FW updates on the robot vac, is it possible that Dyson just locked all 3rd parties out?

[Anto79-ops]

Oh no, I hope that's not the case. But I wouldn't be surprised?

For the fans, maybe I should also disable my firmware updates. But do you know how often they get updated?

For the app, I'm using the Android version of the app. I do have access to an iPhone if that would be better? I have no idea how to get logs from either platform. Do you?

[mundschenk-at]

There have been no updates to fan firmwares in a while (at least for the older fans like the TP04).

[dotvezz]

@Anto79-ops sorry for the confusion, I was referring to the packet-capture app you mentioned.

[dotvezz]

If Dyson does go full cloud, it's a bummer but not the end of the world. I'll just have to update this integration to use the cloud MQTT connections as a secondary. It'll be less-local, but still work.

[Anto79-ops]

thats good to know! but yeah, guess I should disable my FW updates, soon as we figure out what changed/happened. I'm using packet capture v1.7.2 https://play.google.com/store/apps/details?id=app.greyshirts.sslcapture&hl=en_CA&gl=US

[Anto79-ops]

There was an update for the 360Vis nav yesterday, so I thought perhaps I could try again adding it to the integration. Unfortunately, it's still not adding. However, I do have a new error message for you.

This error originated from a custom integration.

Logger: root
Source: custom_components/dyson_local/vendor/libdyson/discovery.py:37
integration: Dyson (documentation, issues)
First occurred: 3:01:13 PM (5 occurrences)
Last logged: 3:10:52 PM

Uncaught thread exception
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/threading.py", line 1073, in _bootstrap_inner
    self.run()
  File "src/zeroconf/_services/browser.py", line 783, in zeroconf._services.browser.ServiceBrowser.run
  File "src/zeroconf/_services/browser.py", line 702, in zeroconf._services.browser._ServiceBrowserBase._fire_service_state_changed_event
  File "src/zeroconf/_services/browser.py", line 712, in zeroconf._services.browser._ServiceBrowserBase._fire_service_state_changed_event
  File "src/zeroconf/_services/__init__.py", line 56, in zeroconf._services.Signal.fire
  File "src/zeroconf/_services/browser.py", line 290, in zeroconf._services.browser._on_change_dispatcher
  File "/config/custom_components/dyson_local/vendor/libdyson/discovery.py", line 81, in add_service
    self._dyson_discovery.device_discovered(info)
  File "/config/custom_components/dyson_local/vendor/libdyson/discovery.py", line 37, in device_discovered
    if info.type == TYPE_DYSON_360_EYE:
       ^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'type'

Please tell me this is the cause of the connection issues :)

[Anto79-ops]

@dotvezz we're running a clean now and tried to connect to it via MQTT Explorer while cleaning, and no go :(

As a test, I tried to connect to a fan using the creds from your Go program and the IP address, and it connected immediately via MQTT Explorer. Something it is not right with the 360 Vis Nav.

[dotvezz]

@Anto79-ops thanks for going to all this trouble, really. I fear this might mark the beginning of the end for easy local connectivity on Dyson devices. I'll get to working on that AWS IoT scheme tonight, hopefully it won't be too different from the MQTT signals. Will let you know if I have anything else for you.

Hopefully the next message you get from me will be a new test build of the integration.

[Anto79-ops]

@dotvezz ahh, that's not cool, but at least its something if cloud is the new way. I have already disabled FW updates on my other Dyson products. I cant believe we this just happened! We had it working for like a week or two in April. Maybe if I try to try track down what FW update made this change.

[dotvezz]

@Anto79-ops

Alrighty, I've managed to get some time this weekend to dig around in the AWS IoT side of things, and I have mostly good news!

Good news first:

1. The information we get from the API is indeed everything we need to connect to IoT.
2. The IoT side uses the same topics and message formats as the normal built-in MQTT broker.
   • At least for my fans, that is (you can help test this for your robot, more below)
3. AWS IoT should always* be reachable.
   • * As much as anything on the internet is always reachable, at least.

And now for the bad news:

1. The IoT credentials don't last forever; they expire after an unknown amount of time. So in order to add it to the integration, I'll also need to take expiry and refreshes into account.
   • This is expected and not a huge deal. But still kinda annoying lol
2. The fact that we've even reached this point highlights the cracks in the spirit and core design of libdyson and this integration.

I've also added a bit more capability to the Go tool, and released it with a new name: opendyson. Unlike my old dyson-mqtt-listen tool, opendyson is an official project under the libdyson-wg org and I plan on using/improving it a lot - if for no other reason than the fact it can makes things a lot easier to debug issues and investigate new products/features.

If you'd like to give it a shot, can you install it (it has downloadable executables for most OSes on the release page) and run opendyson listen your-serial-number -iot? (you can get the serial number from opendyson devices, and it may force you to login one more time, but will save your login information properly this time)

[Anto79-ops]

thanks @dotvezz for your hardwork!

I was able to login to the machine using your new app, here's what I see

C:\Users\atoms\Downloads\opendyson_Windows_x86_64>opendyson listen [redacted] --iot
Subscribing to 277/[redacted]/status/current
Subscribing to 277/[redacted]/status/fault
Subscribing to 277/[redacted]/command
Command:  {
  "g": "277/[redacted]A/command",
  "mode-reason": "RAPP",
  "msg": "REQUEST-CURRENT-STATE",
  "time": "2024-07-08T04:12:21Z"
}
Command:  {
  "g": "277/[redacted]/command",
  "mode-reason": "RAPP",
  "msg": "REQUEST-CURRENT-STATE",
  "time": "2024-07-08T04:12:21Z"
}
Command:  {
  "mode-reason": "RAPP",
  "msg": "REQUEST-CURRENT-STATE",
  "time": "2024-07-08T04:12:21Z"
}
Command:  {
  "g": "277/[redacted]/command",
  "mode-reason": "RAPP",
  "msg": "REQUEST-CURRENT-STATE",
  "time": "2024-07-08T04:12:51Z"
}
Command:  {
  "g": "277/[redacted]/command",
  "mode-reason": "RAPP",
  "msg": "REQUEST-CURRENT-STATE",
  "time": "2024-07-08T04:12:51Z"
}
Command:  {
  "mode-reason": "RAPP",
  "msg": "REQUEST-CURRENT-STATE",
  "time": "2024-07-08T04:12:58Z"
}
Command:  {
  "g": "277/[redacted]/command",
  "mode-reason": "RAPP",
  "msg": "REQUEST-CURRENT-STATE",
  "time": "2024-07-08T04:12:58Z"
}
Command:  {
  "g": "277/[redacted]/command",
  "mode-reason": "RAPP",
  "msg": "REQUEST-CURRENT-STATE",
  "time": "2024-07-08T04:12:58Z"
}

interesting to know, I had to do the first part opendyson devices (even though I had the serial number already) in order for the listen step to work.

I'm happy/sad that this is working though!

[lvanness7690]

[dotvezz]

Hi @lvanness7690!

Quick note: I took the liberty of deleting some sensitive values in your paste. The values are still visible in the edit history, so you may want to delete this comment to be safe.

For your question: it appears as though Dyson is not allowing direct connections to the Viz Nav devices anymore. There was a brief time when this was possible, and for some reason (perhaps after a firmware update?) it stopped working altogether.

However, we may be able to use the cloud connection through AWS IoT. The current challenge is that this integration is focused on being local-only and not relying on cloud connectivity for actually controlling devices. Using IoT isn't something I want to do unless I have to, for several reasons.

For now I'm planning on watching to see how Dyson moves. If future devices don't allow local MQTT connections, then I'll need to make a choice.

[lvanness7690]

@dotvezz thanks for the quick response and the update! I'll delete my post to be safe. Sounds good I will keep an eye on this thread for updates.

[daknightuk]

So I wonder whether is possible to turn back on the MQTT functionality using a prefs.txt file on a USB stick?

Seems there are options you can configure like disable wifi \ enable wifi \ factory reset and set up offline just by having a file on a usb stick with a line of text example ENABLE_WIFI

Maybe some guessing what it might be would work, i.e ENABLE_MQTT, ENABLE_LOCAL, ENABLE_DEV, ENABLE_DEVELOPER

I haven't tried this bit of a long shot? anyone think it could work?

[dotvezz]

OOOH this is interesting! I had no idea this was a thing. That Set-up Offline OVERRIDE_OOB option looks promising as well.

The support page where those downloads are available describes the offline setup with a line that's particularly interesting...

We recommend connecting to the MyDyson™ app . . . If you do not wish to connect, press your robot's LCD touchscreen for two seconds. When the power menu appears, scroll down and select 'Update with USB'. Then follow the instructions below.

If you're willing to play around with those files on your device, I would be VERY interested in learning what you experience experience. I won't pressure you though, it's ultimately your very expensive device and I don't want to make you mess around with it on my behalf.

[daknightuk]

@dotvezz I’ve made several attempts to resolve this issue using the available commands, following the Dyson site instructions closely. However, I keep encountering an "update failed" message. I also tried reverting the firmware to an older version (the old versions are accessible but not hyperlinked). By modifying the download link with the older version numbers, I gave it a shot, but every attempt via USB failed. I tried different pen drives, capacities, and strictly followed Dyson’s instructions.

It’s possible the text files may have changed at the same time as MQTT, or maybe there’s a specific requirement for a Dyson pen drive? You might need to use one formatted to FAT32 or MS-DOS (FAT). You can contact Dyson to request a genuine USB stick, which will be formatted correctly and is the right size.

I’m speaking with a contact at Dyson UK next week and hope they can provide more insight. I’ve also posted in the Dyson community, though I understand there’s just one person responding selectively.

I’ve explored tools and code on several GitHub sites for connecting to Dyson, and so far, the only one that’s worked for me is the OpenDyson tool. I know you're focused on local Dyson support, but you’ve also done great work with OpenDyson. I think if the output from OpenDyson (IoT) could be rebroadcast as local MQTT, it could be a great solution, even if I need to log in occasionally. I’d be more than happy to run this on a Windows VM and connect it to Home Assistant via MQTT.

I wonder whether the new firmware has something coded which recognises the client on MQTT? I tried MQTT explorer with every conceivable combination of the password, serial number, credentials, token signature, etc

I’m confident that with everyones expertise, a solution is within reach and I would have taken a shot at coding something to pull the data from the Dyson IOT myself if I had the experience.

[daknightuk]

@dotvezz have you any objections to me reusing your code from opendyson I am considering how the data could be sent straight to home assistant, I have a lot of testing to do, just a few simple mods gave me a cloud to MQTT although I don't get the topic formats and its very basic. Actually uses less data than having the app open (which constantly queries status) I think dyson might introduce subscription model for cloud features in the future as I read their user agreement and it mentions a 3rd party server company

[dotvezz]

Feel free! While I'm hesitant to add the cloud connection to this integration, I'm happy to hear my other project can still help you!

As for the third party servers, it's almost certainly AWS that the license is referencing. The cloud MQTT connection goes directly to AWS IoT. But I'm curious if there's anything else I might be missing! Does the AWS tidbit feel like it fits the description for the third party servers, or do you think there might be something else there?

[daknightuk]

Something is missing, I can see the APP sending REQUEST-CURRENT-STATE status requests to Dyson (lots of them!) I can see also when ALXA (Alexa) commands are invoked and I can see when the cleaning mode is based on an area what is missing though is docked \ undocked \ charging \ stopped \ clean complete which I would have expected to be sent all I have seen is START, ABORT, PAUSE, RESUME but no stopped which is kind of annoying as my whole point in doing this is to turn off motion sensors in HA until my clean is complete. Also am missing any errors like missing bin, return machine to dock etc, unless there is a secret code somewhere. I'll have a further look tonight. What information do you get on the working "local" connections as I'm thinking it shoudn''t be much different to that?

[daknightuk]

@dotvezz unfortunately no solution yet for LOCAL but using opendyson as a basis for coding I am now in a position where I am getting information from IOT into MQTT explorer,

I think I'll have to do some work on my configuration.yaml file at some stage as I'm having difficulty in passing state attributes to home assistant but I have got a very basic state in there so far from a topic I created called Status which only updates if the message does not contain REQUEST-CURRENT-STATE which spams me otherwise.

Sadly the actual "working status" of the visnav is not possible, you can only see the status which triggered the vis nav which is usually from Alexa or the App so I am only seeing START, ABORT, PAUSE, RESUME and maybe some information about the zone \ cleaning program which is added to the topics when the programs are run.

I have a call Friday from Dyson who are reaching out to one of their robotics engineers who will give me an official answer on whether they will be doing any future support of MQTT local and letting me know officially what their final answer is.

[dotvezz]

@daknightuk I haven't had the opportunity to inspect the IoT messages for any of the vacuums so I'm kinda curious. Does the status topic have a state or newState property in messages?

If it matches the messages from local MQTT, you should (in theory) be able to use those properties to work backwards into a Home Assistant vacuum state. Here's the mapping that Shen made a few years ago if it helps.

[daknightuk]

Unfortunately NOT, It subscribes to the same 3 topics as my Dyson fan from IOT but with the Vis Nav there is no where near as much data as the fan, the fan picks up a lot more commands. The 3 topics are the same across both devices:

Here is pretty much all I can see using my current code you can see only BASIC things. In my final code I ignore REQUEST-CURRENT-STATE

As you can see the data I am sending to MQTT is also just as basic

Am I missing something here?
I notice that with wireshark I can see my dyson has the MQTT service running, does this information help with the LOCAL connection you are trying to achieve @dotvezz