Having just got my HE installed over the holiday break I am eager to integrate my Dyson TP07. I was really hoping to not have to go the virtual switch route and have something native working. Is there any alternative to get the newer fans that dont have a products SSID and password?
Hello, any chance that the multi-factor authentication mechanism be added to the driver? I have a TP04 device without the SSID sticker and can't therefore connect it to Hubitat.
I saw that Home Assistant now has support for it in case it helps => Integrating the Dyson TP04 Air Purifier in Home Assistant - Automate The Things
For @Hardax, @debarryl , @peterbrown77.pb and others...
First - just a reminder - I only own an HP02 and really have no way to test any other models, so what I'm about to describe is really a best guess. Just as the driver code for those other models is really just a best guess and might not work.
I just updated the drivers on github and to do what I'm about to describe you will need this latest driver which contains a new configuration option for setting a "b64 credential" instead of a password.
Next, another github user "shenxn" has solved this this problem for home assistant in Python and it seems we can use that on a computer to obtain the data to configure the groovy driver for hubitat.
Here is how to obtain your device password without a sticker:
- you will need python (at least version 3.7+). and make sure the install is working. try python -V or python3 -V (or on Windows: py -V)
- You need to
git clone https://github.com/shenxn/libdysonor alternately go to the same URL, click the code button and download a zip of the code, then extract the code - in a terminal or command prompt, go to the cloned/downloaded "libdyson" folder
- In that folder run the following commands in this order:
- macOS/Unix:
python3 -m venv envalternately Windows:py -m venv env - macOS/Unix:
source env/bin/activatealternately Windows.\env\Scripts\activate - macOS/Unix:
which pythonalternately Windowswhere python
- verify the results of the last command, It should be in the
envdirectory - now, install the required modules:
python -m pip install -r requirements.txt - Before this next step, you will likely need to temporarily log out from the Dyson mobile app. You can log back into the mobile app after this is complete the next few steps. Take note of the email address associated with your dyson account when logging out.
- run
python get_devices.py - capture your device information, serial, device type, and Credential.
- you can run
deactivateto exit the virtual python environment
(Update: Mar 9, 2023) The WiFi-SSID will require the serial and device type from step 9, formatted as DYSON-serial-devicetype: DYSON-XXX-US-XXXXXXXX-DDD where the DDD is the device type and may be 3 or 4 in length (e.g. 455 or 455A).
Now, when using the driver that I just updated, enter the respective information. Enter the Credential in the password field and then for "Password Type" select "b64 Credential"
1 Like
Thanks, @dpasirst, this was so helpful. Having successfully found the Serial and Credential for my HP04 using the steps above, and entering them into the driver, apparently I now have a different problem: in the logs, I get an error saying the WiFi SSID could not be parsed.
Screenshot 2023-03-08 at 6.51.53 PM|690x37
I've assumed that the Serial returned by the python script is the WiFi SSID to be entered into the driver. It has the format: XXX-US-XXXXXXXX. Is my assumption correct? If not, I don't see anything else that would be an SSID.
Any insight would be most appreciated!
Hi @cassidain,
I have a few thoughts. The full SSID should be in the form of DYSON-XXX-US-XXXXXXXX-XXX[X] Where US would be replace with another country code and the last [X] may or may not be present.
The last 3 or optionally 4 X's are a numeric representation of the model. Google says an HP04 is a Dyson Pure Hot+Cool. Therefore, the last part of the serial would be 527 or 527E. Right now, I handle both the same in the driver. So assuming you are using the DYSON PURE HOT COOL DRIVER (not the "LINK" one), you can try setting the WiFi SSID with serial number to: DYSON-XXX-US-XXXXXXXX-527 or DYSON-XXX-US-XXXXXXXX-527E (fill the X's with your number).
Including "DYSON" and the Device Type worked. So simple. I have been giddily turning the heating on and off virtually - as I'm sure you know, the "feature" of turning on a heater to, like, heat is disabled in the HP04 unless you are physically present. I wonder if shenxn wouldn't consider also displaying a constructed SSID as part of the python script's output. In any case, merci mille fois!!
Great to hear @cassidain! I updated the post above (the one using shenxn's script) just after step 10 with this finding.
Thank you, the driver works perfectly with my HP02. I would like to duplicate the functionality of the power (on/off) switch on the remote. I don't need to change the states of the fan, heat/cool, etc., I'd just like to have a switch tile on a dashboard to turn the device on and off (I am using virtual buttons to control all the various functions like heat mode, etc.) Is it possible to add "switch" capability, or maybe it is already there and I'm missing something?
Is it possible to add "switch" capability...?
So, yes, it's possible but I'm a little cautious to do it without some experimentation. Specifically, without a specification for the unit, I have not found a way to simply turn the unit on to the prior state (like the physical remote would) via the network. While there is a common off command, I did not see an exact on to prior state. Instead, you may see that there is a setFanMode command that has off, fan, and auto where the latter 2 are effectively types of turning the unit back on. Thus, adding "switch" with an on function may not be obvious as to what will result...
GREAT driver, thanks so much! Apologies for the late bump. The only minor issue I have is that I use Maker and the api to control devices from my website. I had to add a bit of code to handle the non-standard use of "FAN/OFF" for the power state (fanState) instead of the usual "on/off" strings. Otherwise 
@Wysocki - I'm don't use Maker and thus I'm not familiar. Would you mind sharing more regarding what you did? I'm curious if it is something I should include...?
@BorrisTheCat - there is a chance that it might as a quick google search makes it look like the HA implementation uses a similar approach and does claim to support both Dyson 360 Eye robot vacuum and Dyson 360 Heurist robot vacuum. That said, I don't own one so I don't have a means explore and test.
I have the heurist. They work well but need good lighting to see. So the ability to turn on lights of needed would be great.
So if you have something for me to start with I can tweak and test 
@BorrisTheCat - well, I suppose something to start with will depend on your (or someone's) ability to code... it will take quite a bit of time to get to "Tweak and Test" - here is what I think would need to be done for you or anybody else interested in taking this on:
In looking at it, it appears the repo linked above some people already did the heavy lifting/reverse engineering so the effort should not be too difficult but likely time consuming because all the attributes and commands for the vacuum are obviously different than air treatment.
(It would likely be overly time consuming for someone to do this without having at least one vacuum unit on hand for testing - which is why I'm not ready to directly commit.)
So, this means, in my drivers linked above, these functions can likely be reused with little to no change:
preferences(), connectToUnit(), disconnectFromUnit(), parse(String message), mqttClientStatus(String message), mqttDate(), requestStateUpdate(), mqttConnectAndPublish(String destinationTopic,String payload), pollState(), setConfiguration(Map configParams), ... possibly others with minor modification
these would need to be updated: processMessage(Map dysonJSON), processMessageState(Map productState, boolean isUpdate)
and a new set of "setXXXXXX()" functions would need to be created along with structures/objects/etc for all the available settings, states, constants, etc.
given a quick scan, it looks like the relevant code to base a translation into a Hubitat driver would be:
vacuum.py, dyson_vacuum_device.py, dyson_360_heurist.py, and dyson_360_eye.py.
with some references in const.py
1 Like
I'm don't use Maker and thus I'm not familiar. Would you mind sharing more regarding what you did? I'm curious if it is something I should include...?
@dpasirst - No big deal, but just noting that because I wrote my own dashboard with html/javascript and my code was written to look for the standard "on" and "off" as the values to determine if an appliance is running. Using your api via Maker, the Dyson's fanState variable returns "FAN" and "OFF" values for those conditions. Just took a couple lines of code to handle that.
Thanks again for a great tool!
I know this driver is a few years old but hoping someone may have some insight. On version 2.3.8.118 and have been running this driver for my Dyson fan for a while now with no issues. Recently though, it's been very intermittent and looks like it's getting disconnected randomly.
Various errors in the log such as:
org.eclipse.paho.client.mqttv3.MqttException: MqttException (method poll)
DYSON MQTT: Error: send error: Client is not connected
DYSON MQTT: Error: send error: Timed out waiting for a response from the server
Is there anything that can fix this or is this an issue with the Dyson servers?
Is there anything that can fix this or is this an issue with the Dyson servers?
The driver communicates directly from the hub to the Dyson device. In this case the "server" is the Air Treatment device itself. It is possible that Dyson updated the firmware and it behaves differently. But there are other things as well, like the Hubitat version could behave differently or even Wifi interference / changes.
I recently updated my C7 to 2.3.8.125, I did not see any errors but I was not looking. I'll keep an eye out now accordingly.
Every so often (~4-8 months), I notice that my Dyson Air Treatment may need a "reboot" - as it starts having strange wifi issues - pull and plug the power from the wall and turn the unit back on, then everything is happy again.
Ok will try that and thanks for the additional information on how it works. I did test on a c5 running ver 2.3.8.118 and a c8 on 2.3.8.125 and both had the errors but haven’t fully tested on the c5 to see if the intermittent issues were there as well. Also errors may have been there for a while and I just never noticed, just the intermittent issues caused me to check the logs.
