ADAX - cannot set up heater via local connection
The problem
I am trying to setup the heater as a local device. The integration finds the heater (via bluetooth) but when it is added the are 0 devices or entities. There are no errors.
When I check the heater the wifi light is still flashing.
I have entered the correct wifi AP and password.
What version of Home Assistant Core has the issue?
2024.9.3
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
adax
Link to integration documentation on our website
https://www.home-assistant.io/integrations/adax
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
Hey there @danielhiversen, mind taking a look at this issue as it has been labeled with an integration (adax) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of adax can trigger bot actions by commenting:
-
@home-assistant closeCloses the issue. -
@home-assistant rename Awesome new titleRenames the issue. -
@home-assistant reopenReopen the issue. -
@home-assistant unassign adaxRemoves the current integration label and assignees on the issue, add the integration domain after the command. -
@home-assistant add-label needs-more-informationAdd a label (needs-more-information, problem in dependency, problem in custom component) to the issue. -
@home-assistant remove-label needs-more-informationRemove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.
(message by CodeOwnersMention)
adax documentation adax source (message by IssueLinks)
I'm also having trouble setting up the heater with local connection. Somehow it dropped out after having it offline for a long while and can't be added again. Or rather, it gets added but no entities.
https://i.imgur.com/9N0yfwu.png
I've reset the heater and removed it from HA.
adax: Error on device update!
Traceback (most recent call last): File "/usr/local/lib/python3.12/site-packages/aiohttp/connector.py", line 1073, in _wrap_create_connection sock = await aiohappyeyeballs.start_connection( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/aiohappyeyeballs/impl.py", line 104, in start_connection raise first_exception File "/usr/local/lib/python3.12/site-packages/aiohappyeyeballs/impl.py", line 81, in start_connection sock = await _connect_sock( ^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/aiohappyeyeballs/impl.py", line 166, in _connect_sock await loop.sock_connect(sock, address) File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 641, in sock_connect return await fut ^^^^^^^^^ File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 681, in _sock_connect_cb raise OSError(err, f'Connect call failed {address}') ConnectionRefusedError: [Errno 111] Connect call failed ('192.168.1.126', 443)
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 724, in _async_add_entity await entity.async_device_update(warning=False) File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1300, in async_device_update await self.async_update() File "/usr/src/homeassistant/homeassistant/components/adax/climate.py", line 175, in async_update data = await self._adax_data_handler.get_status() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/adax_local/init.py", line 65, in get_status async with self.websession.get( File "/usr/local/lib/python3.12/site-packages/aiohttp/client.py", line 1353, in aenter self._resp = await self._coro ^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/aiohttp/client.py", line 657, in _request conn = await self._connector.connect( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/aiohttp/connector.py", line 564, in connect proto = await self._create_connection(req, traces, timeout) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/aiohttp/connector.py", line 975, in _create_connection _, proto = await self._create_direct_connection(req, traces, timeout) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/aiohttp/connector.py", line 1350, in _create_direct_connection raise last_exc File "/usr/local/lib/python3.12/site-packages/aiohttp/connector.py", line 1319, in _create_direct_connection transp, proto = await self._wrap_create_connection( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/aiohttp/connector.py", line 1088, in _wrap_create_connection raise client_error(req.connection_key, exc) from exc aiohttp.client_exceptions.ClientConnectorError: Cannot connect to host 192.168.1.126:443 ssl:default [Connect call failed ('192.168.1.126', 443)]``
Logger: aiohttp.server Källa: /usr/local/lib/python3.12/site-packages/aiohttp/web_protocol.py:433 Inträffade först: 11:56:39 (3 händelser) Senast loggade: 12:02:58 Error handling request
Traceback (most recent call last): File "/usr/local/lib/python3.12/site-packages/aiohttp/web_protocol.py", line 462, in _handle_request resp = await request_handler(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/aiohttp/web_app.py", line 537, in _handle resp = await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/aiohttp/web_middlewares.py", line 114, in impl return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 92, in security_filter_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 77, in forwarded_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 26, in request_context_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 85, in ban_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 242, in auth_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 32, in headers_middleware response = await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/helpers/http.py", line 73, in handle result = await handler(request, **request.match_info) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/decorators.py", line 81, in with_admin return await func(self, request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 222, in post return await super().post(request, flow_id) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 74, in wrapper return await method(view, request, data, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 122, in post result = await self._flow_mgr.async_configure(flow_id, data) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 366, in async_configure result = await self._async_configure(flow_id, user_input) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 413, in _async_configure result = await self._async_handle_step( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 516, in _async_handle_step result: _FlowResultT = await getattr(flow, method)(user_input) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/adax/config_flow.py", line 82, in async_step_local device_configured = await configurator.configure_device() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/adax_local/init.py", line 145, in configure_device async with bleak.BleakClient(device) as client: File "/usr/local/lib/python3.12/site-packages/bleak/init.py", line 570, in aenter await self.connect() File "/usr/local/lib/python3.12/site-packages/habluetooth/wrappers.py", line 286, in connect wrapped_backend = self._async_get_best_available_backend_and_device(manager) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/habluetooth/wrappers.py", line 395, in _async_get_best_available_backend_and_device raise BleakError( bleak.exc.BleakError: No backend with an available connection slot that can reach address 3C:E9:0E:A7:C8:AA was found
Hello.
I'm facing with the same issue here. I tried to move from the cloud to a local solution. The heater seems added to HA, but it does not exposes any entities or devices.
Thanks, Balazs
I have two adax heaters the other one connects no problem and the other has the same issue as mentioned above they have different firmwares one that connects is 2.0.1.8(1) the other that doesnt connect to homeassistant via local integration is 2.0.2.26(1). Could be related to firmware differences. Also when tapping on the firmware number on adax app it shows sdk:-128-NOTFOUND on the one that is not working and the working one reads sdk:vps10-firmware-1.0.1.19-test-1-. For now im using cloud integration but its not as reliable. Also contacted adax support with this.
Its a firmware related issue while checking installed firmwares my heater decided to update itself and now it wont connect to homeassistant locally.
I can confirm the same. It's depending on the firmware. I have one heater on version 2.0.2.26 which I cannot use with the ADAX local integration, while the other two devices, on version 2.0.1.8, still can be added. For the time being I've put the two working one to a separate VLAN with no internet connection to avoid firmware update. The wifi indicator on these heaters is blinking (I assume because it has no connection to the ADAX cloud), but I still can control the heaters through the local network with HA.
(The bottom two entries are the heaters added via the local integration, while 327530 is the cloud integration)
Got a response from adax customer support "Hello, we have found problems with device firmware after update that broke local API. You will receive new firmware once it gets fixed."
Have the same problem with one of my Adax via local api (i think). More of a question if someone knows. Does the Adax still update the firmware when its on local API? Sorry for asking the question here since it does not help out the core of the ticket, but if someone knows it might help out how to avoid adding it back to the cloud
I finally made the decision to go from Cloud to Local with a test oven. Setting up as local went smooth once I had the oven close to the HA Pc (bluetooth distance). After the setup I had a new device 'long number' without entities. The oven itself was blinking with the blue wifi led. After I turned off the oven and turned it on again I get one horizontal dash in the LED. I cannot control the temperature anymore. I guess if I reset it again I gain control again. The current firmware of the oven is: 2.02.26
Have the same problem with one of my Adax via local api (i think). More of a question if someone knows. Does the Adax still update the firmware when its on local API? Sorry for asking the question here since it does not help out the core of the ticket, but if someone knows it might help out how to avoid adding it back to the cloud
I have 4 heaters, which were installed directly local to HA two weeks ago. I have not used Adax cloud or app. I haven't noticed any change in heater controls, so i think that firmware has not been updated locally. I purchased heaters in march 2024.
Hi, I am experiencing the same issue with an electric radiator (firmware 2.0.0.26).
EDIT: To confirm - I have just removed and re-added via local in the integration and no entities show. However if I try to add the same device via the cloud api it does add and show entities.
While we wait for the firmware fix, I was playing around with some local traffic dumps
It seems the Adax ios mobile app communicates with the heaters directly over http , not https! (not sure if this has always been the case or a fallback now that port 443 is closed)
http://192.168.x.139/client?command=stat&time=1730758679
Unfortunately it seems that there is a rotating authorisation header in the request, probably a token hashed with the time and ip as that is sent with every request, and we dont know the token without going through the local setup process.
You will receive new firmware once it gets fixed."
Did they say when that would happen? It’s now over month from your message.
You will receive new firmware once it gets fixed."
Did they say when that would happen? It’s now over month from your message.
No they did not.
Anyone got an update from support regarding the firmware? I bought a device today, and after patching HA to add the device without using the server bluetooth, I was met with an unavailable API: https://community.home-assistant.io/t/adax-neo-wifi-modern-electric-wall-heater-home-automation-heating/26832/151?u=metrafonic
Firmware 2.0.2.26.
Worst case scenario is to install esphome on the esp chip. I assume it is some esp32 variant (I did something similar to a mill oven that stopped working: https://github.com/metrafonic/MillHeat-ESPHome)
I got an update from ADAX internal support. They have fixed the bug and will manually push the new firmware to my heaters given that I provide my account ID. I will test and report back.
I’m looking forward to the results… Currently my heaters cannot access the Internet to avoid firmware update.
I got an update from ADAX internal support. They have fixed the bug and will manually push the new firmware to my heaters given that I provide my account ID. I will test and report back.
TLDR: Not quite there yet.
I have tested the new version 2.0.2.29. There is a local API, however the device does not respond to requests to port 443/tcp or 80/tcp after being provisioned with https://github.com/Danielhiversen/pyAdaxLocal (the same used by HomeAssistant).
Port 80/tcp responded however to HTTP requests after being provisioned with the ADAX app. It seems like there are possibly significant changes to the api as I was always getting a response of Nothing matches the given URI using the URL scheme found in the adax_local library.
I may take a stab at sniffing the apps HTTP requests, hopefully observing calls to the local api from the app
Port
80/tcpresponded however to HTTP requests after being provisioned with the ADAX app. It seems like there are possibly significant changes to the api as I was always getting a response ofNothing matches the given URIusing the URL scheme found in theadax_locallibrary.I may take a stab at sniffing the apps HTTP requests, hopefully observing calls to the local api from the app
This sounds similar to the behavior on the normal firmware , I have spent quite a bit of time sniffing the app to heater local calls, and the app to cloud
https://github.com/home-assistant/core/issues/127076#issuecomment-2456545165
I am hoping its different on your firmware though , on my one there is a basic auth header that changes on every request
Only progress I have so far is that it seems to be base64
@metrafonic what Adax heater you exactly have?
I bought four new heaters and Adax support provided new firmware same way as to you, but thermostats failed to be upgraded on every heaters. Adax support suspects that heaters' power supply is not providing enough power. There are at least two generations of heaters and newer S7 variant should have capable power supply. Too bad that my S6 and S7 variants are both suffering the same issue and upgrade fails.
@kailampi I have the gen2 (wifi+bluetooth) CLEA L 10. I think I can confirm the update was pushed as it shows the version in the app.
@metrafonic Thanks for the info. I have NEO (wifi+bluetooth), so there really might be different power supplies.
Port
80/tcpresponded however to HTTP requests after being provisioned with the ADAX app. It seems like there are possibly significant changes to the api as I was always getting a response ofNothing matches the given URIusing the URL scheme found in theadax_locallibrary. I may take a stab at sniffing the apps HTTP requests, hopefully observing calls to the local api from the appThis sounds similar to the behavior on the normal firmware , I have spent quite a bit of time sniffing the app to heater local calls, and the app to cloud
I am hoping its different on your firmware though , on my one there is a basic auth header that changes on every request
Only progress I have so far is that it seems to be base64
Ah yes. I guess we have the same API. I sent the support a mail regarding the API and if it has changed from that found in paydax_local. I guess I'll just have to wait and see. The rotation of the key seems a bit silly on their part as this state must be synced across multiple mobile devices. This also gives hope that there is an alternate mechanism for rotating the key. Maybe reversing the Android app is a viable alternative if support withholds details.
@metrafonic what Adax heater you exactly have?
I bought four new heaters and Adax support provided new firmware same way as to you, but thermostats failed to be upgraded on every heaters. Adax support suspects that heaters' power supply is not providing enough power. There are at least two generations of heaters and newer S7 variant should have capable power supply. Too bad that my S6 and S7 variants are both suffering the same issue and upgrade fails.
I notice a significant and annoying coil-whine in this version, so it is likely that there are changes in power consumption for the ESP chip.
My S6 version of NEO heaters are causing same coil-whine. Adax said that S7 should not and that's indeed so, only S6 versions are noisy and S7 is silent. Retailer should replace them as guarantee. Not yet done that when the firmware issue is still open.
Port
80/tcpresponded however to HTTP requests after being provisioned with the ADAX app. It seems like there are possibly significant changes to the api as I was always getting a response ofNothing matches the given URIusing the URL scheme found in theadax_locallibrary. I may take a stab at sniffing the apps HTTP requests, hopefully observing calls to the local api from the appThis sounds similar to the behavior on the normal firmware , I have spent quite a bit of time sniffing the app to heater local calls, and the app to cloud #127076 (comment) I am hoping its different on your firmware though , on my one there is a basic auth header that changes on every request Only progress I have so far is that it seems to be base64
Ah yes. I guess we have the same API. I sent the support a mail regarding the API and if it has changed from that found in
paydax_local. I guess I'll just have to wait and see. The rotation of the key seems a bit silly on their part as this state must be synced across multiple mobile devices. This also gives hope that there is an alternate mechanism for rotating the key. Maybe reversing the Android app is a viable alternative if support withholds details.
I suspect the basic auth is derived from a possibilty of the following:
- device password that gets requested from the cloud server (not sure if related to the password we used to use for local)
- device ip , or maybe mac address
- each request includes a timestamp in the url , so this looks like it would be involved
I think ill start playing around again after taking a break, I stopped previously as I though the firmware fix would be quick so not worth the effort , will share any more discoveries
ADAX support responded with that the local API should function as before, as described in their API docs.
I assume that the port 80/443 inconsistency is due to the device disabling the local API connectivity when connected to their cloud. I however was unable to connect over 443/tcp after setting up the device for local use.
I will try again tonight using their python example instead of the one provided by pyadax_local.
Once this blows over I think it will be time to show this integration some TLC with a rewrite. Features such as BLE-proxy could really level-up this integration. Also looking at a cloud-local hybrid could be worth investigating. I will take a stab at analyzing the app code to see if I can find the authkey-logic.
EDIT: This should probably be in a different discussion, but I have extracted some of the relevant java code from the app that talks to the heater using jadx here
UPDATE: The new firmware works!
I was able to set-up the heater using the scripts found in their API docs (Note: you must add import urllib.parse to the registration script).
I then added it to HomeAssistant using my ADAX patch found here (due to my host not having bluetooth).
This all sounds very positive! Do we know when they will push out the firmware update?
Thanks for the app files, would be interesting to see how they do the header even if the firmware works :)