Beta for Hysen thermostats powered by broadlink

Thank you @uss! Problem was on my side, something went wrong while replacing the file. deleted and readded the file + restart fixed it.

Thank you @uss for pointing me in the direction of this.

I have 1 small snag, randomly the thermostat seems to get a call from homeassistant and lights up, this is a problem for my wife as the thermostat is located in the bedroom and she’s a light sleeper.

Any idea’s how to prevent it doing this?


I do.
Please comment (put a # in front of each line) the last 8 lines in, starting with:

        _weekday = int(dt_util.as_local('%w'))

like this:

#            _weekday = int(dt_util.as_local('%w'))
#            if self._device_available:
#                if _weekday == 0:
#                    _weekday = 7
#                if (self._hysen_device.clock_weekday != _weekday) or \
#                   (self._hysen_device.clock_hour != int(dt_util.as_local('%H'))) or \
#                   (self._hysen_device.clock_min != int(dt_util.as_local('%M'))):
#                    await self.async_set_time_now()

reboot Home Assistant and you’ll be fine.

Those lines auto sync the device’s clock.


Thank you @uss that’s a great help.

HI Guys. I’m struggilng to get running FLOUREON FL-TH-012. The device is exactly like below

I’m using custom component hysen together with Raspbian installation. The configuration is below
- platform: hysenheating
name: Pastuszkowy
mac: ‘84:0D:8E:94:XX:XX’
timeout: 10
scan_interval: 10

New entity is visible in states view - but it is still unavailable. I connected it to my wifi by “weback” application - so the thermostat is accessible via Chinese servers but in logs I can see authentication error each time the component wants to update :(((

Question is - is this thermostat working with hysen ?? or this is not the way??
Any comments and help is welcome.

Try to restart the Home assistant.
Can you please check the log?


Hi guys,
everything worked extremly well here until I updated to 0.92 in

I have the newest in custom_components/hysen/
When adding:


  • platform: hysen
    name: Fussbodenheizung
    host: 192.168.0.xx
    mac: “34:ea:34:9f:xx:xx”

to my config and I click “Check configuration” I now get:
Integration hysen not found when trying to verify its climate platform.

I can’t make heads and tails of that as everything worked extremly well before. What am I missing?


Updated to 0.92.0 Integration Manifest.


I am actually getting the following error when trying your version:

Traceback (most recent call last):

Error doing job: Task exception was never retrieved

File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/”, line 365, in _async_add_entity
await entity.async_update_ha_state()
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/”, line 225, in async_update_ha_state
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/”, line 256, in _async_write_ha_state
attr.update(self.device_state_attributes or {})
File “/config/custom_components/hysenheating/”, line 557, in device_state_attributes
ATTR_SCHEDULE: str(HYSEN_SCHEDULE_TO_HASS[self._hysen_device.schedule]),
KeyError: 0

How can I solve this?

I have rechecked the code. It looks fine and is working on my system.
There are 2 things you need to check:

  1. try to rename the folder
    and also:
    ‘- platform: hysen’
    ‘- platform: hysenheating’

  2. when you get the files from github, please use raw, select all, copy and paste into a text editor. It is known that github direct download sometimes gives strange typo errors.


Hi us, thank you for your quick reply!

I actually have it in that format already, I just messed up copy&paste. I also copy&pasted the RAW data from github into newly created files using the configurator, but that didn’t help. The exact same error still shows up, it says “message/error first occured at xx:xx and showed up 72 times” - the error seems to be repeating in horrible pace.

If it matters, this is the thermostat I use:

As said, Wifi connection etc. is all fine and so is my hassio installation. It all worked great with the original broadlink hysen version from Mark Carter until I upgraded to 92.0…


The error looks like:

  1. Typo error. Not the case, as you have done the copy paste from raw.
  2. self._hysen_device.schedule has a value outside the 1, 2 or 3 values. We need to check that.
  3. Starting with 0.92.0 the Integration is finished. I have updated the files in the github repository. If you didn’t update, please do so and post the result.


P.S. The device you have is a hysen oem device. It should work.

I’ve had something like this before, it’s happened when the device is set in auto and home-assistant expects to find it in manual or visa-versa.

I had to change the thermostat to manual last time I think and restart home-asisstant and it worked okay after that.

I have a problem with mine, but I think it’s the unit, it wont go into the 1234567 schedule, I’ve tried direct on the unit and through home assistant, it seems locked into the 12345,67 schedule. I might have to let it talk to the www and see if there is a firmware update or something.

So my version is still working for me on 92.2, did have to add manifest/services file to build.

@uss / @IGregl, regarding the loop_mode , maybe the same problem I had with this calling the underlying self._broadlink_device.set_advanced(mode_byte, sensor, osv, dif, svh, svl, adj, fre, poweronmem) function

It broke the loop_mode, so I added the fix at line 785, to correct before I called the broadlink function if this helps.

Sorry mate. I don’t understand the problem.
“How HA expects to find it in manual when it is in auto?”
The very first thing HA does is calling from async_update which calls async_get_device_status which calls from get_device_status.
Thus, it reads the actual operation mode (the current one).
If one calls from async_set_operation_mode, he is actually calling from set_operation_mode.
The device does not know how to write a single byte, but only aligned words.
Thus, writing ONLY operation mode is not possible.
One has to write also the second byte.

# 0x01, 0x06, 0x00, 0x02, 0xlm, Sen
# m = Operation mode, 0x00 = Manual, 0x01 = Auto
# l = Loop mode, Weekly schedule, 0x01 = 12345,67, 0x02 = 123456,7, 0x03 = 1234567
# Sen = sensor, 0x00 = internal, 0x01 = external, 0x02 = internal control with external target

The operation mode is in the low 4 bits, first byte.
The high 4 bits, first byte, is Loop mode.
The second byte is sensor.

In order to avoid writing wrong info when only one info has to be changed (e.g. operation mode), I call self.get_device_status() first, to get the actual values for the Loop mode and sensor.
I pack the new operation mode with the real time info for the Loop mode and sensor and then I write the 2 bytes.
I don’t see any mistake.
Please check.


P.S. I didn’t forget the changes you have asked me to do. I have a strong excuse.
My second child is born a couple of days ago. :smile:
As soon as things are settled I’ll continue to write the requests.

@uss @mark.carter I’ve swapped over to marks platform.

I’m no coder and struggle enough just getting home assistant set up, so will leave Mark’s version on over the week and see if this fixes the loop issue.

If it doesn’t it’s my unit… :wink:

@uss Congrats on the new baby, busy times, hope it’s a good sleeper.

That’s great on the change and I totally understand :). I may have misunderstood but the loop problem I have had a couple of times on various functions in the One on set-advanced and one on setoperation-mode if I didn’t pass in the current one each time auto/manual was changed it screwed it up. maybe not the same issue but worth a check?
I will take a look this weekend!!!

I am very interested in changing my old dumb thermostats for smart ones.

Would the following thermostat work with this hysen component module?:

Thanks a million for all your work!

Unfortunately that doesn’t look like Hysen OEM models I know.
I would be surprised if it would work.
Check on and see which model suits you. Then aliexpress.


1 Like

Thanks for letting me know!