[Feature Request] Airtopia AC Control

[ziogref]

Hi Steve,

Would like to request a feature. I have 2 Daikin AC units that are connected using Airtopia units (I think the company is basically dead now).

My 2 Airtopia units are added to CBUS via Modbus and are in group 250 (I think this is the correct terminology)

In my CBUS webUI, under objects I have the following entries local/User Parameter/Lounge AC Power local/User Parameter/Lounge AC Set Point local/User Parameter/Lounge AC Mode local/User Parameter/Lounge AC Fan local/User Parameter/Lounge AC Vertical Swing local/User Parameter/Lounge AC Protocol ID local/User Parameter/Lounge AC Temperature Sensor local/User Parameter/Lounge AC Current Sensor local/User Parameter/Lounge AC Dry Contact

Is it possible to add these devices to Home assistant? I added the Tag 'AC' to one of the units but in MQTT explorer it showed up outside of the home assistant topic so I couldn't add it.

attached is a screenshot on how they appear in CBUS

I greatly appreciate your work on this, getting my lights added to HA has been a game changer.

[autoSteve]

A fascinating prospect.

There is a HomeAssistant module called "MQTT HVAC", whose configuration should be able to be shoehorned into a 'homeassistant' MQTT discovery topic ex. SHAC to avoid much YAML. Then code could be written on the SHAC to read/write appropriate state/action topics and sync those user parameters to the MQTT broker. I think... It may be reasonably straightforward. Or would be if I had one of those Airtopia suckers to play with.

So if you change the values of the user parameters in CBus does that cause action at the Air Conditioner? i.e. if you set 0/250/3 "Lounge AC Power" to the value of "power on (1)" (presumably) does magic happen at the AC?

Tagging stuff as "AC" with my code is for ESPHome interaction, where I replace the stupid Panasonic "cloud" based WiFi embedded controllers with ESP32 SOCs running code written by other much smart folks, which talk directly to HA. Mostly because Panasonic's cloud service is dodgy and super slow. The AC tagging on my NAC lets me control the devices from both HA and also NAC visualisations/timers. I'm screen bisexual here, with an iPad for NAC viz and also HomeAssistant on PC browser (which mostly is my interface to Google Home). "Hoy Gooogz, turn on the air con, luv, would ya?", or stroll to the iPad if I'm feeling like a work-out and press a button... Or turn the shed AC on automatically to cool the servers on hot days, without Panasonic cloud being down and baking my servers in 40C heat...

[ziogref]

So if you change the values of the user parameters in CBus does that cause action at the Air Conditioner? i.e. if you set 0/250/3 "Lounge AC Power" to the value of "power on (1)" (presumably) does magic happen at the AC?

So setting 0/250/3 "Lounge AC Power" to the value of "power on (1)", the CBUS system contacts the Airtopia black box via MODBUS who then sends signal up to the AC unit which has an IR blaster stuck onto the IR receiver of the Daiken. It's basically a glorified IR blaster. The airtopia unit is completely ignorant to the state of the AC if it changes via the remote, the Airtopia just keeps track of what it last sent as the last known state/setting.

So maybe this will help? Here are the "Levels" in the cbus objects. Each image file name is the Cbus address and name. 0-250-3-power 0-250-5-mode 0-250-7-VerticalSwing 0-250-8-HorizontalSwing

The following items have a "Data Type" of 12. 4 byte unsigned integer 0/250/3 (Power) 0/250/4 (Set point, aka Set temperature) 0/250/5 (Mode) 0/250/6 (Fan) 0/250/7 (Vertical Swing) 0/250/8 (Horizontal Swing) 0/250/9 (Protocol ID)

These are all useable controllable. All are self explanatory except Protocol ID, I believe this is the data base entry for the type of remote the airtopia unit emulates. Not really needed in HA

The following are Sensors and have a "Data Type" of 14. 4 byte floating point 0/250/10 (Temperature Sensor) 0/250/11 (Current Sensor, I believe this is a CT clamp)

and lastly, 1 more sensor that has a "Data Type" of 12. 4 byte unsigned integer 0/250/12 (Dry Contact)

Not sure what the last one is? maybe compressor state? Dunno.

Is this info helpful?

[autoSteve]

Most helpful. Out of interest, what model is your Daikin A/C? Does it have an S21 port?

[ziogref]

Most helpful. Out of interest, what model is your Daikin A/C? Does it have an S21 port?

I have a RXS25LVMA / FTX525LVMA And RXS71LVMA / FTXS71LVMA

No idea what an S21 port is.

[autoSteve]

The FTXS71LVMA seems to have an S21 protocol connector. And if you made a typo, then the FTXS25LVMA also does.

I have seen a fascinating project on Github relating to S21. https://github.com/joshbenner/esphome-daikin-s21. This uses an ESP32 device with ESPHome to plumb in Daikin A/Cs to HomeAssistant. Some soldering seems to be required... plus acquisition of quite cheap ESP32 WiFi devices. A very similar solution to what I do with my Panasonic A/Cs.

[ziogref]

Huh. I will have to disassemble my daikens cause I have NO IDEA how the airtopia units intergrate.

However the airtopia units to get the current of the device, that would be super handy to have for power monitoring in HA.

[autoSteve]

Using S21 would gain the ability for HomeAssistant to know the precise state of each A/C, regardless of remote control use. This occurs with my Panasonics, where I see an update in HA when I turn on using the remote.

What you would lose is the power monitoring, as S21 protocol doesn't do that as far as I know.

I will continue to have a crack at Airtopia for you in my spare time.

If you do investigate S21 then you could likely use both that and Airtopia, with the latter just providing consumption info.

[ziogref]

Ok, so pulled apart the bedroom AC and it looks like it has an S21 port

And it is just a CT clamp getting the consumption information.

But because of all the extra CBUS/airtopia wiring in the Unit it was a complete cunt to put back together.

I think S21 would be excellent in the future (probably I would get the faiken esp32 for $60aud) as my airtopia doesn't support quiet mode, which would be amazing to have.

But I don't have $120+shipping at the moment. So maybe Christmas time.

Thanks for investigating the option to use Airtopia. I had a look at the code and was immediately lost. Lua makes no sense to me (I dabble in BASH, Powershell and python)

[autoSteve]

LUA. I hear you. Python is my day job, and the number of times I stuff up not-equal != / ~= syntax when I've been doing LUA of an evening don't bear counting. 🤦🏻

[autoSteve]

Ugh. I just typed a giant message that went "poof" for some reason 🤦🏻. So a short version...

I've added limited experimental Airtopia support @ziogref.

Supports power, mode and target temperature only, no sensors. Check out the comments at top of script, and ping if you get stuck. Should only need sa= (suggested area) for just one user param (but MUST be included for at least one.)

I want to know whether basic set temp/mode/off work as expected with a Daikin. Then I'll take it further with sensors/etc.

Here are my basic examples... Power user param ... AT, dev=test, sa=Bathroom 1, func=power, Temp user param ... AT, dev=test, func=target_temperature, Mode user param ... AT, dev=test, func=mode,

More deets: Adds/modify/change is seriously broken for changes at the mo, so don't rely on it. Make changes to user param keywords, then if needed stop/start script. MQTT Explorer is your friend to see what's going on.

More: There is a new script "AT", which must execute on the keyword "AT". This script pushes changes from CBus to the Mosquitto broker.

[ziogref]

@autoSteve Works like a charm, except multi-device appears to not be working.

If I add the bedroom, it does not appear in HA, however it will start taking all the commands for the living room.

If I have just the living room configured in CBUS, that unit receives all the commands. Power on works as soon as a mode is selected (and off), the unit receives all the modes and the temp changes also work.

[autoSteve]

Good to hear. For multiple devices, maybe they are ending up with the same 'dev' name? If they were both called 'Daiken' or 'A/C' that would cause a collission. I can avoid that with some code...

[ziogref]

Good to hear. For multiple devices, maybe they are ending up with the same 'dev' name? If they were both called 'Daiken' or 'A/C' that would cause a collission. I can avoid that with some code...

Of course.

My dumbass read dev=test As devolopment=test Not device.

[autoSteve]

Right. Some further experimental code in a commit...

1) You will most certainly need MQTT Explorer based on your current broker topics. Go and kill the existing airtopia/cbusmqtt{dev} topics with delete. And the homeassistant/climate topics. Otherwise you will get duplicates in the HomeAssistant lovelace UI... The reason is that I have changed airtopia naming to {suggested area}_{device}. This means you can name each dev= as something like 'Daikin', and as long as the rooms are different this will work. i.e. Lounge, Daikin and Bedroom 1, Daikin. If you're stuck on this, reach out.

2) I have added support for current_temperature ... but how to do current consumption well is currently a head-f, so still to-do.

3) I have added support for swing modes. func=vert_swing and func=horiz_swing. Tag the SHAC objects, and once done select the swing mode in the lovelace settings for the Airtopia object.

4) Most changes on CBus are not properly reflected in HomeAssistant yet... TODO. So this is mostly a HA->CBus thing at the moment, and most changes in CBus will not be picked up by HA.

Feedback requested.

[autoSteve]

I have also noticed that some MQTT topics do not appear 'persistent' for me, notably the discovery topics. So on a re-start of HomeAssistant the climate entries will show as 'unavailable'. I currently have no idea why this is, as the code sets a PERSIST flag for these topics, but seems to be ignored. Ugh. Restart the MQTT send / receive script to get them back after a HA restart. I'd be interested to learn if this is not an issue for you ... i.e. restart HA, do the Daikin's show as available or does it require a script restart to get to them again?

[ziogref]

Funny thing. I already had MQTT explorer open (ESPresense setup) Updated the script, rebooted all scripts and its cooked. MQTT explorer is showing CBUS as offline. Made sure the MQTT details were correct in the lua config.

Reverted back the code you pushed to github 2 days ago and CBUS is back online again

[autoSteve]

How odd. Were there any SHAC error logs thrown? Works fine for me.

[ziogref]

How odd. Were there any SHAC error logs thrown? Works fine for me.

Resident script:909: attempt to concatenate global 'dev' (a nil value) stack traceback: Resident script:909: in function 'func'

---

Stacks of these

(learning more about cbus every day atm)

[autoSteve]

My bad. New commit. Oops.

[ziogref]

Ok, so swinging is working.

I have power, mode, swing and desired temp

2. I have added support for current_temperature ... but how to do current consumption well is currently a head-f, so still to-do.

current temp cant see how to tag that. I can see that you have it in the code but cant see what to tag it as.

Also a note on the power consumption, its in amps, not watts. I can do the conversion in HA if it can be passed through as a sensor (My solar reports the current voltage. so volts x amps = watts)

Both the temp sensor and current sensor are both 32bit floating points so are they just not the same configuration since they are just passing numbers through?

4. Most changes on CBus are not properly reflected in HomeAssistant yet... TODO. So this is mostly a HA->CBus thing at the moment, and most changes in CBus will not be picked up by HA.

Thats fine, im not phased over this, I intend on using JUST HA for AC control. I actually disconnected both my AC units from cbus for a while, as it was giving me issues as I attempted to write python code to integrate the units into HA and failed. I have been using the airtopia website, which I fear is going to die soon.

[autoSteve]

For current temp, try something like "AT, dev=mydaiken, sense=current_temperature, "...

The MQTT HVAC has discovery for the current temperature built in. It displays it as a big number in the middle of the dial. For current I need to work out a sensible name for the discovered sensor. Getting it in to MQTT is relatively easy, just need to cope with tagging adds/moves/changes. How about "mydaiken Power Consumption"? so "{device name} Power Consumption", which would get a discovery topic under homeassistant/sensor/{uid}/. The unit_of_measure would be "A". Tagging like "AC, dev=mydaiken, sense=power_consumption, ".

I should be able to have a go at that tonight.

[ziogref]

For current temp, try something like "AT, dev=mydaiken, sense=current_temperature, "...

The MQTT HVAC has discovery for the current temperature built in. It displays it as a big number in the middle of the dial.

this works!

For current I need to work out a sensible name for the discovered sensor. Getting it in to MQTT is relatively easy, just need to cope with tagging adds/moves/changes. How about "mydaiken Power Consumption"? so "{device name} Power Consumption", which would get a discovery topic under homeassistant/sensor/{uid}/. The unit_of_measure would be "A". Tagging like "AC, dev=mydaiken, sense=power_consumption, ".

I should be able to have a go at that tonight.

Yeah sounds good, I have done a bit of research to gets actual useful data from that sensor it needs to update as frequently as possible. I will be able to grab the volts of my house from my solar inverter which I can get a read out in KW how much each AC is using. I can then throw that into a HA meter and get kWh readings. I understand the timing from CBUS --> MQTT --> HA is not instant and can get seconds, but as frequent as you can would be amazing.

[autoSteve]

CBUS --> MQTT --> HA is not instant and can get seconds, but as frequent as you can would be amazing.

The script should update the broker in near real time. The "AT" script will fire as soon as any change in value is detected on the SHAC, and this sends a socket message to "MQTT Send Receive", which (unless its busy doing something else) will publish to the broker. HA is subscribed to the sensor topic, so should also update without delay. MQTT is pretty quick.

I have no idea how often the Airtopia sends to modbus, but that might be the appreciable delay.

[ziogref]

CBUS --> MQTT --> HA is not instant and can get seconds, but as frequent as you can would be amazing.

The script should update the broker in near real time. The "AT" script will fire as soon as any change in value is detected on the SHAC, and this sends a socket message to "MQTT Send Receive", which (unless its busy doing something else) will publish to the broker. HA is subscribed to the sensor topic, so should also update without delay. MQTT is pretty quick.

I have no idea how often the Airtopia sends to modbus, but that might be the appreciable delay.

Just tested turning on the AC from HA (from work, so over 5g on my phone) and checking my cbus on my work laptop and its was instant. So I guess we can assume instant. Will be very interesting ff the value changes much, but even if it does spam the broker, the MQTT broker it can handle it. That things is being smashed with 100's of updates every second from ESPresense.

[autoSteve]

Give "sense=power_consumption" a go, @ziogref. It'll create a discovery topic for a sensor called "{device name} Power Consumption". Well, it should.

[ziogref]

Give "sense=power_consumption" a go, @ziogref. It'll create a discovery topic for a sensor called "{device name} Power Consumption". Well, it should.

well it works, maybe a little too well

this is the value in in HA 0.0399999991059303 A

Would it be hard to round it to say 4 decimal places?

[ziogref]

I have also noticed that some MQTT topics do not appear 'persistent' for me, notably the discovery topics. So on a re-start of HomeAssistant the climate entries will show as 'unavailable'. I currently have no idea why this is, as the code sets a PERSIST flag for these topics, but seems to be ignored. Ugh. Restart the MQTT send / receive script to get them back after a HA restart. I'd be interested to learn if this is not an issue for you ... i.e. restart HA, do the Daikin's show as available or does it require a script restart to get to them again?

yes I have the same issue, had to restart the script

[autoSteve]

Sooo...

Add dec=4 as a keyword to the power sensor and you'll get four decimal places. And scale=1000 to get milliamps. Might need a script restart to get the initial rounding for existing sensor value.

yes I have the same issue, had to restart the script

Glad it's not just me. But not glad that I have no idea why discovery is not persisting. I ask the broker to do it...

[autoSteve]

Note that scale was not working as expected, so removed. unit= also removed accordingly. So the only option is dec= for decimal places. I'll work on scale and unit later when I'm not trying to do things so quickly.

[ziogref]

@autoSteve don't worry about the scale, turns out the power use is only for the inside unit. (which makes sense) I got it all working in HA.But the inside unit will only ever pull a few hundred watts.

The only thing missing from this now is fan speed.

[autoSteve]

Yeah, nah. The pedant in me has resurrected scale and units. Commit. 😅

[autoSteve]

You didn't give any details for what the acceptable fan speed values are. Happy to add, but I don't have any detail to go on.

(edit) Sez Interweb...

fan_modes:
  - "1"
  - "2"
  - "3"
  - "4"
  - "auto"

But does "auto" = 5 or zero? Who can tell...

[ziogref]

You didn't give any details for what the acceptable fan speed values are. Happy to add, but I don't have any detail to go on.

(edit) Sez Interweb...

fan_modes:
  - "1"
  - "2"
  - "3"
  - "4"
  - "auto"

But does "auto" = 5 or zero? Who can tell...

So it's just unassigned integer 32bit (same as set point)

You are correct it's 1-4 and auto. Trying to work out what auto is

[ziogref]

I was never happy with the CBUS integration of Airtopia and have always used their online portal. Turns out, after almost 4 years, controlling the fan speed inside cbus doesn't work.

updating the online portal or sending command line commands does not update the modbus values (even known working ones like mode or power)

I have emailed the company that owns CBUS and provided me with some API documentation a little while ago to see if they can provide me documentation on how to set it up instead of paying my integrator.

[autoSteve]

Should I "bin" the potantial fan control? (Or rage at the sky a while longer?) Other values would indicate 1=auto, 2=1, 3=2, 4=3, 5=4.

Do let me know what you find out.

[ziogref]

Maybe just mark it as un-tested. I had a look at the documentation and its appears my setup is actually correct. I suspect something else is not right. I will need to talk to my integrator but I suspect he won't be able to help since AIrtopia seems to be dead.

[autoSteve]

The timing of when I publish the Airtopia discovery topics seems to be at play with the 'retain' flag not being set on publish to the broker, resulting in HA showing the devices as 'Unavailable' status after restart. Weird. The latest commit fixes it in a brutally simple way. Note that the variable checkForChanges must be set to true.

I could have solved it in another way, avoiding checkForChanges, but that would have required a lot more code. That's on the "to do" list (and mught just stay there 😆)...

[ziogref]

Will try the new code but 2 nights now my CBUS system has freaked out. seems like after midnight something breaks and I need to delete all the topics out of the MQTT broker to fix it. Lights, fans, Airtopia etc all broke

This is in the CBUS error logs

Resident script:1414: bad argument #2 to 'format' (number expected, got nil)
stack traceback:
 [C]: in function 'format'
 Resident script:1414: in function 'outstandingMqttMessage'

I will add the new code you uploaded 20 hours ago and see if the issue pops up again

[autoSteve]

This section of code is now commented out. I think that's where the error is occurring... (Have not double checked, but the line number looks approximately right. The last commit on the 14th took out this code.) I do not have an Airtopia, so am just using placeholder user parameters, which do not change, so possibly some message loop?

I should not have been setting the user parameters when the broker sent a message about them, because that doesn't make any sense for state topics.

    elseif parts[1] == 'airtopia' and parts[3] == 'state' then
      --[[
      device = parts[2]..'-'..parts[4]
      local net, app, group

      if atDevices[device] then
        alias = atDevices[device]
        local p = string.split(alias, '/'); net = tonumber(p[1]); app = tonumber(p[2]); group = tonumber(p[3])

        if ignoreCbus[alias] and os.time() - ignoreCbus[alias] > ignoreTimeout then -- Don't worry about older 'ignore' flags
          ignoreCbus[alias] = nil
          if logging then logger('Ignoring older CBus ignore flag for '..alias) end
        end
        if not ignoreCbus[alias] then -- Only set the CBus status/level if this script did not initiate the change, and if it is different to the current value
          local set = false
          local extant = GetUserParam(net, group)
          local e = tonumber(extant)
          if e ~= nil then
            if string.format('%.3f', e) ~= string.format('%.3f', tonumber(payload)) then SetUserParam(net, group, payload); set = true end
          else
            if extant ~= payload then SetUserParam(net, group, payload); set = true end
          end
          -- Setting CBus here will result in the AT event script requesting publication of the state using 1() above.
          -- This is undesired, so ignoreMqtt[alias] is used to ensure that the CBus change received does not publish to MQTT.
          --if set then ignoreMqtt[alias] = os.time() if logging then logger('Setting ignoreMqtt for '..alias..', oldState='..extant..' payload='..payload) end end
        else
          ignoreCbus[alias] = nil
          if logging then logger('Ignoring CBus publish for '..alias) end
        end
        at[alias].state = payload
      end
      --]]
    end

[autoSteve]

Adding experimental fan speed support.

Hey @ziogref. My assumption is that atfans = {'Auto', '1', '2', '3', '4'} equals set the fan user parameter to {0, 1, 2, 3, 4}. Seems consistent with the rest of the Airtopia.

Keywords I used for the user param: "AT, dev=test, func=fan, " With dev being the name of my non-existant testing device.

Happy testing.

How'd you get on with the system freak out post-midnight? All good now?

[ziogref]

Adding experimental fan speed support.

Hey @ziogref. My assumption is that atfans = {'Auto', '1', '2', '3', '4'} equals set the fan user parameter to {0, 1, 2, 3, 4}. Seems consistent with the rest of the Airtopia.

Keywords I used for the user param: "AT, dev=test, func=fan, " With dev being the name of my non-existant testing device.

Happy testing.

How'd you get on with the system freak out post-midnight? All good now?

Thats a fair assumption.

Well lights are working so that's good. As for AC it hasn't been working for a few days even rolling back to known code. Something somewhere is funky just havent had time to jump into MQTT Explorer and find the broken link.

I'm also moving to a new device for HA (HP mini pc instead of a Pi4) my poor pi4 is just sitting at a constant load of 80% on the cpu mainly due to security cameras.

Im going to rebuild my HA instance from the ground up. My pi4 was a backup from my pi3 which was my very first use of HA and there is some super dodge stuff in that.

Will probably get it all migrated this weekend.

As for the Airtopia fan control, after digging into the documentation I found that if some function is not supported you contact your intergrator and then they work with Airtopia to get it working, with Airtopia being dead, I'm not going to bother going down that road. I will probably look at replacing them with the Faikin as you suggested when I get some spare dough, home loan interest rates have me righting my belt.

[autoSteve]

Faikin = win.

[ziogref]

So Airtopia hasn't been working for a while. Cant figure it.

I updated all the code to the latest version. Stop the scripts, launched MQTT explorer and deleted everything, started the cbus scripts and It all imported into HA. Changing the settings in HA show up in MQTT. Changing in CBus shows in MQTT but it appears Cbus is not reading the updates settings from MQTT.

After a bit of research this might make things easier for you. In CBUS, under MODBUS you can "add device" use the profile airtopia and mimic these settings

You should be able to see everything and you should be able to change values (power, mode, temp etc). It appears it doesnt really care that the device doesnt physically exist.

[autoSteve]

I am a bit of a half wit at times. Try this latest code out, @ziogref. Previous work on stability broke this, because wanting your lights to stop going mad.

[autoSteve]

Take 2. When setting 'off' the mode should not be set in CBus... Yup, Half wit at times.

[ziogref]

Thanks mate, looks good.

[autoSteve]

Excellent. Re-open if there's further issue, @ziogref. I think this feature has run its course in the absence of fan speed testing, so have updated the readme and called it "supported".

[autoSteve]

I couldn't let it go... checkForChanges is no longer required for Airtopia, @ziogref. The latest commit should queue Airtopia devices for publishing discovery topics with a broker immediately upon script restart. Checking for changes should ensue...

[autoSteve]

Actually, hold off @ziogref. I think I've broken it...

[autoSteve]

I did broke it, but looks okay after latest commit. Some optimisation required for init for tomorrow or so, but it appears working, @ziogref.