Temperature step

[clsergent]

Setup

esphome-hlink-ac version: 2025.3
target: RAK-DJ50RHAE / RAK-DJ18RHAE

Rationale

Visual temperature step is supposed to be a multiple of 1. However it seems that the AC can handle 0.5 increments as the IR remote steps are 0.5°C.

In addition, Home Assistant can handle arbitrary temperature steps through customize:

homeassistant:
  customize:
    climate.thermostat_entity:
      target_temp_step: 0.5

Would it be possible to relax this check?

Full error log (ESPHome check):

Configured visual temperature step 0.5 is wrong, it should be a multiple of 1.
  platform: hlink_ac
  name: RAK-DJ18RHAE
  hvac_actions: True
  supported_presets: 
    - AWAY
  visual: 
    min_temperature: 16.0
    max_temperature: 32.0
    temperature_step: 
      target_temperature: 0.5
      current_temperature: 1.0

[lumixen]

Hi @clsergent!

I would be happy to add support for 0.5 temperature steps, although it's not entirely clear how this could be achieved, or if it's possible at all through the H-Link protocol.

In H-Link, the target temperature is an integer value. There might be a way to specify a fractional part, but I would need debug data captured from the device when a target temperature with a .5 value is set. For example, you could use debug sensors for this (target temperature is located at P0003).

Also, do you know if the official Hitachi AirHome 400 dongle or Air Go app supports 0.5 steps?

[clsergent]

I guess I should have read more carefully your documentation about the HLINK protocol. I understand why an integer is requested, it makes sense.

I will dig further by grabbing debug data from my ACs.

To answer your last question, I never used the WiFi dongle stock firmware (but I dumped if, maybe a Ghidra analysis could help)

[lumixen]

What you can try as a first step is to check the value at the P0003 address when you set the target temperature with a fractional part using your IR remote. Normally, P0003 contains the integer hex representation of the target temperature in Celsius (e.g., 0010 → 16℃, 0014 → 20℃).

If it still only provides the integer value, the fractional part might be stored elsewhere at an unknown address (such as P0005, P0012, or another location).

Ideally, it would be helpful to intercept the communication between the AC and the original Hitachi H-Link adapter while changing the temperature in 0.5℃ steps from H-Link dongle, if it's possible at all.

[lumixen]

Hey @clsergent,

Maybe a Ghidra analysis could help.

Also, if you can share the original firmware dump somehow, I could also try to dive into the decompiled firmware - although, frankly speaking, I’m pretty sure it’s not going to be an easy task..

[clsergent]

Hi,

I’ve finally been able to spend some time on this project. Here’s a brief overview of my findings, which I may document in more detail later:

• Endpoint 0003 does not handle half degrees (tested across nearly the entire range 0x0000–0x0FFFF).
• Endpoint 0101 handles indoor humidity (%)—verified by comparing with another sensor in the same room over several days.
• Endpoint 0013 handles FrostWash (the AC must be off before performing this operation).
• My built-in adapter does not use the HLINK protocol; instead, it uses special JSON arrays (sniffed from the UART and also found in dumped firmware). This likely explains why it can handle half degrees (and possibly more precise values).

This means I will need to create a new custom component, which I plan to do once I have a better understanding of this new protocol (HLINK v2 ??).

[lumixen]

Endpoint 0101 handles indoor humidity (%)—this was verified by comparing it with another sensor in the same room over several days.

I believe this can be added as a sensor to the main project, although I have never seen anything other than 7E at this address, unfortunately.

Endpoint 0013 handles FrostWash (the AC must be off before performing this operation).

Hmm, I wonder if this might have a different meaning on different AC units.. In my case, it reacts to swing mode changes (my air conditioner does not have the FrostWash feature).

My built-in adapter does not use the HLINK protocol; instead, it uses special JSON arrays (sniffed from the UART and also found in dumped firmware). This likely explains why it can handle half degrees (and possibly more precise values).

Do you mean it uses the same CN7 port, but a completely different protocol?

[clsergent]

Do you mean it uses the same CN7 port, but a completely different protocol?

Yes, it's JSON, something like (sniffed) {"D1":"RlMd","D2":"MdDtl","D3":"Maint","D4":"Tr","D5":"Hr","D6":"To","D7":"iE","D8":"FltT","D9":"Rair","D10":"HExT","D11":"Comm","D12":"PinR","D13":"Opt1","D14":"Opt2","D15":"Opt3","D16":"Opt4","D17":"Func1","D18":"Func2","D19":"ItW"}}{"ChS":50495}}.

[clsergent]

It's also consistent with what I dumped (ex: {"CMD_IDU": { "OnOf": %d, "Mode": %d, "SetT": %.1f, "Hs": %d, "FanS": %d, "WtmS": %d, "Buzz": %d }).

I still have to understand how it works but it seems less cryptic than HLINK!

[lumixen]

Yeah, it does look like a completely different protocol.

At first glance, I would say it makes more sense to create a new ESPHome component rather than trying to integrate it into this project, as this component is heavily designed around the H-Link communication patterns.

But I'm really surprised that the same port supports multiple, vastly different communication protocols. Perhaps that's what's causing the issues you're experiencing with the "shifted" bytes?