No power control

[adelomer12]

System Health details

System Information

version	core-2025.3.4
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.13.2
os_name	Linux
os_version	6.12.18-haos
arch	x86_64
timezone	Asia/Hebron
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	4994
Installed Version	2.0.5
Stage	running
Available Repositories	1623
Downloaded Repositories	33

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 15.0
update_channel	stable
supervisor_version	supervisor-2025.03.3
agent_version	1.7.2
docker_version	28.0.1
disk_total	468.7 GB
disk_used	19.8 GB
healthy	true
supported	true
host_connectivity	true
supervisor_connectivity	true
ntp_synchronized	true
virtualization
board	generic-x86-64
supervisor_api	ok
version_api	ok
installed_addons	Advanced SSH & Web Terminal (20.0.1), File editor (5.8.0), Get HACS (1.3.1), Matter Server (7.0.0), Mosquitto broker (6.5.0), Samba share (12.5.0), TasmoAdmin (0.31.5), Terminal & SSH (9.16.0), VLC (0.3.0), lxp-bridge (v0.13.0), lxp-bridge (dev version) (dev)

Dashboards

dashboards	2
resources	20
views	5
mode	storage

Network Configuration

adapters	lo (disabled), eno1 (enabled, default, auto), hassio (disabled), docker0 (disabled), veth2430659 (disabled), veth7231c90 (disabled), vethf88fe08 (disabled), vetha7981f8 (disabled), veth349e7a9 (disabled), vethadf2b95 (disabled), vethaa75b55 (disabled), veth860bc90 (disabled), veth2f0ccb9 (disabled), veth2553459 (disabled)
ipv4_addresses	lo (127.0.0.1/8), eno1 (192.168.55.11/24), hassio (172.30.32.1/23), docker0 (172.30.232.1/23), veth2430659 (), veth7231c90 (), vethf88fe08 (), vetha7981f8 (), veth349e7a9 (), vethadf2b95 (), vethaa75b55 (), veth860bc90 (), veth2f0ccb9 (), veth2553459 ()
ipv6_addresses	lo (::1/128), eno1 (fe80::7bd8:2d0b:5549:a5c3/64), hassio (fe80::a035:28ff:fedd:fea0/64), docker0 (fe80::8058:5aff:fe01:dc50/64), veth2430659 (fe80::783e:cdff:fe4e:956c/64), veth7231c90 (fe80::18f2:d3ff:feea:b5ee/64), vethf88fe08 (fe80::402a:36ff:fe58:33e6/64), vetha7981f8 (fe80::785b:1fff:fe0e:dee5/64), veth349e7a9 (fe80::c863:69ff:fee8:e381/64), vethadf2b95 (fe80::e8ab:4fff:feb9:66f4/64), vethaa75b55 (fe80::4c13:33ff:fee7:60fa/64), veth860bc90 (fe80::f0:dff:fedf:47e9/64), veth2f0ccb9 (fe80::70ca:6fff:fe25:7038/64), veth2553459 (fe80::3818:e1ff:feb6:6d36/64)
announce_addresses	192.168.55.11, fe80::7bd8:2d0b:5549:a5c3

Recorder

oldest_recorder_run	March 18, 2025 at 9:39 AM
current_recorder_run	March 30, 2025 at 12:51 PM
estimated_db_size	1134.65 MiB
database_engine	sqlite
database_version	3.48.0

Checklist

• I have enabled debug logging for my installation.
• I have filled out the issue template to the best of my ability.
• This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
• This issue is not a duplicate issue of any previous issues..

Describe the issue

Thanks in advance
The ignoration is working but there are no power control also when i select cool mode from integration it switch to dry mod

My Tornado Aircon ISKA-INV 16 X WIFI EU
Data Cloud":"Other areas","Firmware":"v52020","IoT Cloud":"SDK":"2.16.31"

Reproduction steps

1. Add tornado-aircon-custom-component url to hacs as Integration.
2. Download an install the integration
3. Configure it as describe login email and password and select usa
   ...

Debug logs

No debug sorry

Diagnostics dump

No response

[romfreiman]

@adelomer12 not sure what you mean by no power control. I use it every day :). Can you please elaborate and provide screenshot if possible?

[ofirzh]

@adelomer12 , i also use it on daily basis and I able to turn on and turn OFF.
Do you mean Power Limits like in ACFreedom?

[MarcDev01]

The Power Limits within AC freedom I think. This is an extra function within the AC Freedom app, there you can set a cap so the AC will not use more energy than for example 60%. Would it be possible to set this cap in HA as well?

[henk-ie]

@ofirzh @MarcDev01 yes, this is exactly the ACFreedom Power Limit function. I dug into where it sits in the code and the data turns out to be already available — no API or protocol work needed, only an entity layer. Posting the trace here in case it helps.

1. The parameters are already defined. climate.py:60, in PARAMETER_VALIDATION:

"pwrlimitswitch": {"type": int, "range": (0, 1), "required": False},
"pwrlimit":       {"type": int, "range": (0, 100), "required": False},

Side note: a grep across the component shows PARAMETER_VALIDATION occurs only at its definition — it does not appear to be referenced anywhere.

2. All parameters are already fetched. aux_cloud/__init__.py:536 calls get_device_params(dev) without a parameter list, which becomes an empty list at lines 590-591, and lines 813-814 build the dict from every key the cloud returns.

3. Confirmed in a debug log from my APZ-FR35. With the unit off, dev["params"] on every poll contains:

DEBUG [custom_components.tornado.climate] Coordinator fetched data:
... 'params': {'temp': 300, 'ac_vdir': 0, 'ac_hdir': 0, 'ac_mark': 0, 'ac_mode': 0,
'ac_slp': 0, 'pwr': 0, 'ac_astheat': 0, 'ecomode': 0, 'ac_clean': 0, 'ac_health': 0,
'scrdisp': 1, 'mldprf': 0, 'pwrlimitswitch': 0, 'pwrlimit': 0, 'comfwind': 0,
'sleepdiy': 1, 'childlock': 0, 'ac_tempconvert': 0, 'tempunit': 1, 'envtemp': 259}

4. The values track the app setpoint. After setting the power limit to 50% in the app, the next poll returns:

'pwrlimitswitch': 1, 'pwrlimit': 50

So pwrlimitswitch is the on/off flag and pwrlimit the percentage, both already arriving on every coordinator update.

5. The device advertises both. The base64 cookie field contains an intfsList capability list which includes pwrlimit and pwrlimitswitch alongside ac_mode, envtemp and the others.

6. The write path accepts them. set_device_params() (aux_cloud/__init__.py:597-616) derives the parameter list from values.keys(), so there is no whitelist blocking these keys.

What is missing is only the entity layer: _handle_coordinator_update() (climate.py:252-278) reads seven fixed keys out of device_params and ignores the rest. This is the same underlying gap as #31 (ecomode) — a generic way to expose additional params keys would cover both.

Suggested implementation

• number entity for pwrlimit, writing through the existing _set_device_params({"pwrlimit": value})
• switch entity for pwrlimitswitch, same path
• Read both back in _handle_coordinator_update() so the entities reflect changes made from the app

One open question: PARAMETER_VALIDATION states a 0-100 range, but the app only appears to offer 30-100. If 30 is the effective minimum, the number entity should probably use that as its lower bound.

Why it matters

I use this unit as primary heating and for cooling on solar surplus. Measured with an independent power meter, power scales roughly linearly at about 12 W per percentage point (verified at 30% and 50% in cooling), spanning roughly 360-1200 W. Without the limit, the only lever from Home Assistant is on/off, which short-cycles the compressor whenever available solar surplus is below the unit's full draw. The same applies to hourly-priced electricity contracts, where modulating power against the hourly price beats a binary run/don't-run decision.

@romfreiman happy to test a branch against real hardware and report back with logged power measurements in both cooling and heating mode. If you would rather not spend time on it, I am willing to open a PR. And if you prefer this tracked as a separate feature request rather than in this thread, let me know and I will move it.

[romfreiman]

@henk-ie sure thing. Please open a pr. Just try to limit to minimal required changes, since currently the integration is very stable