A/C control: Daikin Mobile Controller

Lounge Australia
#1

Hi All,

My 2 new Daikin Split Wall Units each have a wifi controller BRP072A42, which is managed by an app "Daikin Mobile Controller." The app however is very basic and at best can managed a fixed timer, no better than the IR remote controller that comes with the system. So...Hubitat integration is the question. It appears these wifi controllers have an accessible API, the HomeAssistant community have managed it Daikin AC - Home Assistant and their repo core/homeassistant/components/daikin at dev · home-assistant/core · GitHub

So, i know very little about HomeAssistant but only assume that if they can do it, so we can we :slight_smile: I'm not a dev so not sure how difficult it is to convert their python(?) DH to Groovy?

Has anyone tried this?

1 Like
#2

May try porting this over and see if it works?

1 Like
#3

thanks @at9! i keep forgetting to check the ST forums...

#4

There are 2 instances of physicalgraph that need to be changed to hubitat and the driver will save and not throw errors in the logs, but it doesn't work properly.

It will read all attributes properly, but can't control the thermostat modes in HE. If you're on heat and select cool, it will go to cool. If you try to put it back to heat it switches then goes right back to cool. The ST DTH mapped all the tiles and defined all the commands for the tiles, and HE doesn't supports that. As soon as you define the thermostat capability, it will use the standard "heat" command and have all of the HE thermostat tiles whether they are used or not.

Although I believe it's possible with a parent/child driver setup to map them on the child driver. But that would require a complete re-write. I've left it on ST for now and use HubConnect to bring it in. There's also native integration for Daikin on Home Assistant which could be brought over to HE using that route as well.

#5

Yes I've been looking at the HA implementation..I'm not a developer though :frowning:
Step 1 is connection...turns out I have the BRP072C42 not the BRP072A42, which is the secure version. So to do anything, being a "secure" wifi adapter the first step is to Authorise my hubitat to the Wifi module. The HomeAssistant guys do this by using Curl on their hub. On the assumption the Curl command needs to be un by the device to be authorised, I will shut down my hub, change my PC's IP address and mac to emulate the hub's, and run the Curl command. If that works, then I'll try to bluster my way through the DH provided. I have already changed the simple stuff (i.e. physicalgraph etc) but the harder part will be how to change URLs to suit the secure adapter...

#6

OK, with thanks from the various nerds over at HA forum, I have successfully polled my wifi controllers using Curl after authorising my PC (and Hub).

Steps:
install Curl on your PC/WorkstationOfChoice
Generate a UUID4 (https://www.uuidgenerator.net/ is one way to do it). eg. 7b9c9a47-c9c6-9876-1234-848e67cc7edd

Strip the hyphens from the UUID. eg. 7b9c9a47c9c698761234848e67cc7edd

Grab the 13-digit key from the sticker on the back of the controller. eg. 0123456789012

Register your UUID as a valid token:

curl --insecure -H "X-Daikin-uuid: 7b9c9a47c9c698761234848e67cc7edd" -v "https://XX.XX.XX.XX/common/register_terminal?key=0123456789012"

test connection:
curl --insecure -H “X-Daikin-uuid: 7b9c9a47c9c698761234848e67cc7edd” -v “https://XX.XX.XX.XX/aircon/get_sensor_info"

1 Like
#7

now for the DH :thinking: and i will need help from someone who actually knows something about creating/editing DH's hint hint nudge nudge :blush:

fredrike at HomeAssistant forum has his DH which supports the BRP072C42 here:
https://bitbucket.org/mustang51/pydaikin/branch/BRP072C42#diff
..but how to change a python DH for HA into Groovy for Hubitat is well beyond me.

#8

You'd have to re-write it in groovy. Unfortunately no simple way, they're 2 different languages. If you have a HA setup, you could integrate it there and use MQTT for bi-directional control.

The reason ST DTH's can port over, usually with no or just minor changes, is because they're both written in groovy so it becomes very simple.

Sounds like you're about to go down the road of learning groovy :stuck_out_tongue:

#9

thats what i'm afraid of... my A/C units would likely be obsolete before i became a proficient enough programmer to do it properly. i was hoping that seeing Daikin is one of (if not the) most popular A/C vendors in Australia that there would be someone could help knock out a DH in the knowledge that over time it would help a bunch of folks..i'd be happy to help with testing etc

#10

I'm not a groovy connaisseur (yet!) and though the port works, there are some quirks in that driver or hubitat, or the connection to the module itsself.

I'm using it to control 7 different modules.
They've got static IP's, all is well, I can command them to do the things I want, which is great!

The issue I'm having is that sending a certain command once, usually doesn't suffice. I have to spam the button 3 to 10 times for the command to hold. It changes it with 1 click and immediatly reverts to the previous setting. Anyone had this issue? Or even better, a solution?
As a workaround I'm writing Rule engine rules that keep running (spamspamspam) till the value I want holds.

#11

What port are you referring to? That app is for ST so it may not work directly with Hubiatt and that is likely why you are seeing errors. I'm surprised it even saved without modifying it.

#12

Have you tried looking in the logs and / or turning on debug logging, if available?

I've been writing / using a driver I wrote for my Mitsubishi a/c. I had similar behaviour, turned out mostly to be a conversion issue when trying to change the temp, which was evident as soon as I checked the logs.

What I thought the problem was, which may be your issue, could be the refresh of details from the unit / cloud trumping changes you request from say a dashboard tile. E.g. you request a change, while the http api call is made a refresh of the state is done, which reverts say a temp change back to the original value. Turned out the Conn's were quick enough and the decimal conversion fix was enough for me, so I never pursued this any further. All that said, I would think this kind of behaviour would have presented itself for users in ST, so there's a good chance this is not the cause.

1 Like
#13

The port works fine, it's just the two changes MRobi suggested.
You can get it all to work that way, although there are some issues.
Fan mode only (I use this to vent the AC unit after it's been cooling to get rid of the condensation) is available as a thermostat State, while the other modes: Cool, heat auto etc... are thermostat modes.
There's no thermostat state on the template, so workarounds are needed.
But it is working, if you spam buttons :wink:

#14

I'll revert to the logging tomorrow. I did see some odd things there. As stated, I'm no groovy expert. Looking through the code I can see stuff in the driver that can't be used in hubitat, like the layout of the ST tile etc.
But I'm still somewhat overwhelmed by the way the building blocks are made up and how they correlate. I'm a sysadmin, I know my VB and powershell, but that's as far as it goes for now. I am interested to learn.

1 Like
#15

What do you mean by "Get rid of condensation"? If you pass more air through the unit you are, in fact, creating more condensation. Not getting rid of it. Even if the compressor is off, the difuser is still cold and will produce condensation inside the unit.

Are you getting any errors in the logs? Saying you have to spam buttons doesn't really help anyone fix it.

#16

Yes, I had this exact same issue. Another thing, after having support look at my hub this port throws a whole ton of errors in the background that don't show in the regular logs. Back then I ended up removing the driver, put it back on smartthings, then used hubconnect to bring it into hubitat. Now I just have it connected directly into home assistant and control it with node red.

#17

John,

As far as the condensation goes, most of it is drained automatically,but there's always a tiny bit of water left in the unit. So when an AC has run during the day, I'll vent it at night to get rid of that bit of excess. When it ran at night, I do it during the day.

In the logs I'm not getting any real errors, but it's flaky. When lowering the setcoolpoint for example, 1 push would fail, sending "Executing 'updateEvents' with null, 23.5 and true". When pushing it twice it will send out the correct command, being "Executing 'updateEvents' with cool, 23.5 and true" (so we start at 23°C, doubleclick it and then it goes back to 23,5) I'm assuming cool is the mode, 23,5 is the desired temperature and true is telling the unit that temperature has changed. In the first click it doesn't give the mode and it reverts.

I'll play around with it some more.

#18

MRobi,

I don't really feel like using ST for the purpose. It would take me back to "online" control, while with the hubitat it's all local. As you stated, had I owned an ST hub already I'd do it like that too until I find a solution.

Are you now using HA and hubitat together? Or is that fully HA? I could consider a rpi if I can't get this fixed, but I'd rather not.

#19

If things are not working but there are no errors generated then it's time to add some logging to the driver or app you are using. If something doesn't work, then there is most likely some info generated by the system for that. Whether or not that info is logged is up to the app or driver. Is there a debugging option for the driver? If so, turn that on and see what else gets logged.

#20

I'm using HA with the hubitat integration, so all my zigbee and zwave devices are on HE while the rest is on HA. This way only gives you control of the Daikin in HA.

I believe this specific driver doesn't follow the standard thermostat protocols used by HE. The logs just show it changing then changing back. In the logs only visible by support it spits out tons of "com.hubitat.hub.service.LanService - Unknown HubAction: delay 500".