Adax Panel Heater with Wifi Thermostat connected to openHAB using the HTTP Binding

Tutorials & Examples Solutions
,
1

Hi,

Recently I got a bunch of Adax Neo Wifi Panel Heaters (electric radiator). These heathers come with a wifi enabled thermostat and a remote and a local api, and Adax provides some python scripts to interact with these api’s. Using those scripts makes hooking up the radiators to a wifi network and enabeling the local api quite a easy task. I’m not interested in yet an other cloud based smart thing/whatever solution, so I happily went for the local intergration.
When the radiators (thermostats) are hooked up and when the local api is enabled, the next step is to get them playing nice with openHAB. This is also quite easy, no dedicated Adax Binding is needed, the HTTP Binding is sufficient.
Below I’ll provide all the UI code that’s needed to get the whole thing going, I guess y’all know how to deduct the relevant information from it.

UID: http:url:4b5db98dd2
label: PH | HL | 02
thingTypeUID: http:url
configuration:
  authMode: BASIC_PREEMPTIVE
  headers:
    - Authorization= Basic 0123456789
  ignoreSSLErrors: true
  baseURL: https://10.47.3.242:443
  delay: 10000
  stateMethod: GET
  refresh: 60
  commandMethod: GET
  timeout: 5000
  bufferSize: 2048
channels:
  - id: adax_ph_02_temp_current
    channelTypeUID: http:number
    label: PH 02 Current Temperature
    description: null
    configuration:
      stateExtension: /api?command=stat&time=%1$ts
      stateTransformation: DSL:|(transform("JSONPATH", "$.['currTemp']",
        input.toString))∩DSL:|(Float::parseFloat(input.toString)/100)
  - id: adax_ph_02_temp_target
    channelTypeUID: http:number
    label: PH 02 Target Temperature
    description: null
    configuration:
      commandTransformation: DSL:|((Float::parseFloat(input.toString)*100).intValue)
      stateExtension: /api?command=stat&time=%1$ts
      commandExtension: /api?command=set_target&value=%2$s&time=%1$ts
      stateTransformation: DSL:|(transform("JSONPATH", "$.['targTemp']",
        input.toString))∩DSL:|(Float::parseFloat(input.toString)/100)

Some remarks:

  • This setup works quite well and is stable enough, the refresh interval is a factor that can provoke some instability, don’t set it to short.
  • Once in a while the connection chokes up, based on the http code the thermostat is returning in that case, I’ve got the impression that the api can throw a tantrum once in a while, powering the radiator off and then on again is enough to let it play nice again. UPDATE 03/02/2025: I succesfully countered this annoyance by relocating my iot-accesspoint (by just 30cm/1ft), I had no issues since.
  • Little easteregg on 29/03/2028; the Adax dev people managed to sneak a leaptimebug in to the local api stack, unless they manage to remove the bug by a firmware upgrade, you’ll have to reregister/integrate the heaters, it’s a bit anoying but it’s a once in a four year chore…

Link to Adax scripts:
https://adax.no/wi-fi/api-development/

Best regards,
Jesse

3 Likes
2

Thank you for the information. I am considering purchasing one of these heaters, but wanted to check if the local API has been working well with openhab since then, if the leap time bug has been fixed yet, and if not… is there any plans to fix it? Are the firmware in the heaters upgradable?

Thanks in advance.

3

Hi Sean,

The api is working well enough with openhab for my use case. The Adax heaters can become unresponsive once in a while, I never figured out why and I never detected any patern, I just switched the radiator off and then on again to makes them responsive again. I created a rule that informs me when the heater becomes unresponsive.
I don’t know if the leaptime bug has been fixed, I contacted the Adax costumerservice department about it but I never got a substansive response.
I also do not know if and how the heaters firmware can be upgreded.

Best regards,
Jesse

4

Thanks so much for the information.

I actually bought one of these yesterday. I was a bit disappointed that you seemingly cannot use the cloud api and the local api at the same time. Are you able to use the adax app on smartphones at all with the local api enabled? When registering with the mobile app, the local api (https on port 443) is not available at all, even though there is a local web server (non-https) operating on port 80 that just says “This URI does not exist” when I try it. It would be terrific if I at least could read the temperature sensor that way, but I don’t know if it is possible…

I get the impression that the local api is not being prioritized by Adax, as the help pages for the local api is not even visible unless the language on the web page is set to Norwegian, even though the text on that page is in English. Could also be a memory leak in there, if the oven becomes unresponsive over time. I am staying a lot of the time out of the country, so having to go to the physical location to restart the oven is not very practical. Seems they don’t have any watchdog or other mechanism to make sure the oven stays operational.

I am also speculating that the entire operation with the local api is very different, in that you have to feed it the current time with API all the time. Perhaps a very much simpler codebase is running with the local api, where no NTP time sync is implemented (and no real-time clock in the hardware), as it is supposed to work perhaps even without an internet connection at all. Strange that they couldn’t manage to get such a simple thing to work reliably.

So with that in mind, I am trying out the cloud api now to begin with. Also with the cloud api the documentation is pretty strange. They have a python code example on the web page with zero indenting, meaning it will never work, and there are also several spelling errors in there. After fixing it, the code seems to work fine (as well as it can only after 10 hours of running…)

How often does the local API become reasonable? Is it every month, or every year kind of thing? For me right now, I believe I only will use the local api in the case where Adax goes bankrupt and their cloud servers are no longer running.

Lastly can I ask you what your firmware version is? Mine is “2.0.1.8 (2)”.

Thanks in advance,

  • Sean
5

Ha Sean,

Thanx for your reply.
I’ve never used the remote api and/or the Adax app, I really try to avoid these cloud based solutions, so I never bothered to use it in this case. I’m just using the local api together with openhab.

The local api is very rudimental indeed, I find it hard to imagine how such a simple api can become unresponsive, you’d expect these things to just keep going. Unfortunattely it does become unresponsive a couple of times a month, I never detected a patern in there.
The behaviour is a bit confusing, I can think of a some causes for this:

  • The code for the local api is just buggy or just incomplete, the lack of any whatchdog or the lack of any fault-tolerancy might point to that. If this the case Adax should fix that with a new firmware release (they can also fix the leaptime bug while they’re at it…).
  • The hardware is buggy. I do doubt this though; you mentioned that the remote api seems to be stable, that makes me assume it is not an hardware issue (and Adax is capable of providing a stable api).
  • The local api is very picky about the requests it receives. I’ve got the impression the device doesn’t want to be polled to often; it took me a while to find a practical and reliable interval. Maybe the less it get polles the longer it keeps operating. I wonder how that compared to the remote api. How often do you poll the deive thru the remote-api? Multiple times a minute, hourly or just on demand?

I’m not sure what the firmware version of my panels is, the local api does not provide that information. It is interesting to know though, I suppose I’ll need to use the app and remote api to find out.

It would also be interesting to have a chat with one of the Adax developers, just to know what they’re up to, I haven’t managed to get an hold on one of them though.

Anywho, goodluck with testing and researching your Adax heaters.

Best regards, Jesse