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

[daknightuk]

@dotvezz so Dyson claim that the reason is they are complying with the PSTI act 2022
PSTI ACT 2022.pdf

[dotvezz]

@daknightuk something smells weird here... Am I understanding correctly that you asked someone at Dyson, and this was their answer? If so, it seems likely that they didn't understand the scope of the question.

PSTI Act 2022 requires compliance with ETSI EN 303 645, specifically referencing provisions in section 5. The relevant part of section 5 for our discussion is in the provisions 5.1-1 and 5.1.2:

Provision 5.1-1 Where passwords are used and in any state other than the factory default, all consumer IoT device
passwords shall be unique per device or defined by the user.
. . .
Provision 5.1-2 Where pre-installed unique per device passwords are used, these shall be generated with a mechanism
that reduces the risk of automated attacks against a class or type of device.
. . .
As a counter-example, passwords with incremental counters (such as "password1", "password2" and so on) are easily
guessable. Further, using a password that is related in an obvious way to public information (sent over the air or within
a network), such as MAC address or Wi-Fi ® SSID, can allow for password retrieval using automated means.

In this sense, the changes needed for compliance began in late 2021 with the release of the xP07 and xP09 devices, for example. Note that there are no restrictions for local connectivity in the regulatory text, and all of the xP07 and xP09 devices (and even more recent ones such as BP01/BP03 which were released at the same time as the Vis Nav) are fully supported by this integration.

For further information supporting the above statement, I'll point at Dyson's published statements of compliance, where you note that devices I specified above (wi-fi connected devices released after 2021) cite compliance as such:

Dyson Technology Limited have complied with the applicable security requirements in Schedule 1 of The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023.

The specific regulation there is a mouthful, it's also known as UKSI 2023 No. 1007, and Schedule 1 is available here. This regulation builds on top of PSTI 2022 and has very similar requirements.

(2) Passwords must be—
(a)unique per product; or
(b)defined by the user of the product.
(3) Passwords which are unique per product must not be—
(a)based on incremental counters;
(b)based on or derived from publicly available information;
(c)based on or derived from unique product identifiers, such as serial numbers, unless this is done using an encryption method, or keyed hashing algorithm, that is accepted as part of good industry practice;
(d)otherwise guessable in a manner unacceptable as part of good industry practice.

Now you'll note that the Vis Nav is among the devices that claim compliance with UKSI 2023 No 1007 (page 12 of the Statements of Compliance link I provided above). Even though it was released at the same time as BP01 and BP03, and over a year after the HP07 and HP09, we're still able to fully support those other devices.

So based on the following:

• Vis Nav is not the only Dyson device which is compliant with PSTI 2022, but it is the only one we're not able to connect to.
• Neither PSTI 2022 nor its successor UKSI 2023 No 1007 has any requirements that restrict the availability of local connectivity.

I feel pretty confident saying that if the disabled MQTT broker was a deliberate choice, the rationale for it was not compliance with PSTI 2022.

[dotvezz]

TL;DR: The problem we're having has nothing to do with passwords. The device itself just doesn't accept connections as a broker anymore.

[daknightuk]

@dotvezz thanks for the response, I didn't fully understand the regulation but from what youve said it makes perfect sense so I have passed this back to the UK customer escalations team (who are basically James Dyson's email respondent) It took them a week to get that answer so maybe if we wait a few more weeks we will get somewhere with them. I always find it really dissapointing when a huge corporation gets to the size where customer support is just plain bad and you have to be emailing the MD but its just part of the course I suppose.

[daknightuk]

Whilst we wait I read today that you can send App notifications from Android apps to Home assistant so I now have the MyDyson app sending its notifications to home assistant via the companion app [(https://youtu.be/TvvGs668tAw] )I don't recall seeing many notifications on the mydyson app but maybe that would help as a workaround for some owners.

I combined it with your opendyson code (edited) which is something I'm still working on and this is what I see so far with both the app notification and the cloud MQTT data.

I think all this combined with a bit of code could have the potential to help.

I also used alexa media player to send the start dyson robot and stop dyson robot so I can control it (if a bit limited) has anyone got a full list of the alexa voice commands as dyson seem to keep it a real secret?

[daknightuk]

@dotvezz Hi there, so I'm stuck with trying to get the vis nav to work, dyson have chosen to ignore my email into them regarding the MQTT connection so I don't think its going to be possible to do local control. I rewrote part of the opendyson code, specifically the module \cmd\funcs.go so its got my details built into it and its quite happy (on a PC) to sit there polling the dyson server and feeding back the result to MQTT. I would like to develop this into a seperate home assistant integration but I'm really stuck on where to start having not done this type of development before. How do you take the .go code and make it into a HA integration? is it an easy process. Any guidance, videos etc would be appreciated as I intend to host the finished integration on my github. Thanks in advance David

P.S regarding the app notifications into HA which was a nice find, I added a value template into my configuation.yaml as the app notifications aren't that frequent so after an hour the message now changes to "No recent updates from the Dyson Robot"

#Dyson Robot Status

      dyson_robot_notification:
        friendly_name: "Dyson Robot Notification"
        value_template: >
          {% set title = state_attr('sensor.sm_s908b_last_notification', 'android.title') %}
          {% set text = state_attr('sensor.sm_s908b_last_notification', 'android.text') %}
          {% set timestamp_ms = state_attr('sensor.sm_s908b_last_notification', 'post_time') %}

          {% if timestamp_ms %}
            {% set timestamp_s = timestamp_ms / 1000 %}
            {% set current_time = now().timestamp() %}
            {% set time_difference = current_time - timestamp_s %}
            
            {% if time_difference <= 3600 %}
              {% set formatted_time = timestamp_s | timestamp_custom('%Y-%m-%d %H:%M:%S', true) %}
              {{ title if title else 'No Title' }}: {{ text if text else 'No Message' }} ({{ formatted_time }})
            {% else %}
              No recent updates from the Dyson Robot
            {% endif %}
            
          {% else %}
            No recent updates from the Dyson Robot
          {% endif %}

[dotvezz]

dyson have chosen to ignore my email into them regarding the MQTT connection so I don't think its going to be possible to do local control.

Sounds about right tbh.

I would like to develop this into a seperate home assistant integration but I'm really stuck on where to start having not done this type of development before. How do you take the .go code and make it into a HA integration?

Home Assistant integrations are written in Python. You'd need to either port it to Python, or do something to integrate the Go code with a Python wrapper. One way of doing stuff like this is by using sockets to communicate between running processes, and that's pretty doable in both Go and Python.