Beta for Hysen thermostats powered by broadlink

Ok, it is a funny thing.
I don’t understand exactly why is happening but it looks that my device accepts either 1 or 3 as auto.
And I know for a fact that other oem devices returns 3.
I’ll look deeper later.
Anyway, to solve your problem change the line 28 in hysenheating_device.py

HYSEN_HEAT_MODE_AUTO = 1

Delete the__pycache__ folder and restart HA.

@uss, ok that got it up and running, I am going to test all the commands, first issue I hit was power, got the error

 Log Details (ERROR)

Mon Mar 11 2019 11:04:55 GMT+0000 (Greenwich Mean Time)

[192.168.0.201] Error in turn_on: 'HysenHeatingDevice' object has no attribute 'powerstate'

Look like line 316 power_state | (self.powerstate & 0xFE)) should be power_state | (self.power_state & 0xFE))

@mark.carter
You’re right. Thank you.
Typo mistake. I have modified in running code, but forget to change it on the git.
I’ll do the change now.

@uss, Ok :), so would you consider the requests below?
Also to complete the code would you consider adding the following, things I have done and was going to do:

  1. The wifi setup service, something like what I have in my code
  2. dns based lookup of devices
  3. mac discovery of devices, when ip is not fixed
  4. handle ip of device changes once device is setup and running
  5. remove reliance on broadlink.py so the code is self contained
  6. probably for at least scheduling have add a single service where all can be set.

By the way the services.yaml does not show the hints in the service tab on my HA any idea why?

@mark.carter
Sorry for the delay, been in a meeting.
I’ll look into the requests and I’ll check your code.
for:
5. I was ready to push a PR to


for both devices, heating and hvacr.
It came after I noticed an error in broadlink hysen few days ago and ptd006 asked me to PR.
The advantage would be to move to an internal HA component instead of a custom one.
6. I thought about that. Easy to do. I had it done in a previous version. But it was difficult to use. I can put it back if you think it’s helpful.
And yes, neither in my system the services.yaml doesn’t show. I suspect they did not look for it yet. The last change from 0.89 should force one to put everything related to the base component inside the custom_components folder. It looks like they miss this file. Should someone raise an issue.

Cheers,
us

@uss, please take/change what even code from my version, would like to get to one version we all can agree on, (does not require the external supplied app) that could be a candidate to go into HA as internal.

The other couple of additions I was working on way away_mode which currently just turns the device off, but I was going to get it to accept a different min temp, I trigger this by geolocation currently.
also:
implement a timed boost function that allowed to set a temperature for a period of time.
and finally I hate the hysteresis range on these stats. so I was going to do a hysteresis override function that monitored the thermostat and kept in within 0.5 degrees instead of the 1.5 currently.
Let me know what you think

@mark.carter
First of all, I have a technical question.
Line 828

    time.sleep(random.uniform(0.1, 0.5))

Why do you need this?

Ok put that in as when running with multiple thermostats, broadlink.py seemed to barf sometimes if all the update functions got called at once, it was a test to see if it stopped the problem.

 
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity.py", line 221, in async_update_ha_state
    await self.async_device_update()
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity.py", line 349, in async_device_update
    await self.hass.async_add_executor_job(self.update)
  File "/usr/lib/python3.5/asyncio/futures.py", line 380, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/usr/lib/python3.5/asyncio/tasks.py", line 304, in _wakeup
    future.result()
  File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
    raise self._exception
  File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/home/homeassistant/.homeassistant/custom_components/hysen/climate.py", line 858, in update
    self._current_operation = STATE_UNAVAILABLE
  File "/srv/homeassistant/lib/python3.5/site-packages/broadlink/__init__.py", line 648, in get_full_status
    payload = self.send_request(bytearray([0x01,0x03,0x00,0x00,0x00,0x16]))
  File "/srv/homeassistant/lib/python3.5/site-packages/broadlink/__init__.py", line 612, in send_request
    request_payload.append(crc & 0xFF)
TypeError: unsupported operand type(s) for &: 'NoneType' and 'int'
```

Oh, I see.
I had the same problem but is not from what you think it is :slight_smile:
Took me ages to find out why.
Actually it is from here:

from PyCRC.CRC16 import CRC16
crc = CRC16(modbus_flag=True).calculate(bytes(input_payload))

PyCRC.CRC16 has a problem. Sometime it returns crc = None.

I’ve done an workaround:

    for i in range(1, 3):
        crc = CRC16(modbus_flag = True).calculate(bytes(input_payload))
        if crc == None:
            _LOGGER.error("[%s] CRC16 returned None, step %s.", self._host, i)
        else:
            break

It never done more than 1 step

1 Like

@mark.carter

About HA internal.
From what I’ve seen in HA architecture they want to access the device driver as a library.
In my case, hysenheating_device.py and hysen2pfc_device.py respectively should be, separately or together, presented as library(s).
Thus, we will change the broadlink library with whatever library we’ll have.
And the broadlink is already accepted by HA.
That won’t change anything in the component part of the code.
It’s either way…

All that can be done using automation at the higher level.
It’s up to the user.
Our job is to expose the values and to provide the services.

btw. if you put the hysteresis 0.5 you will shorten device’s life. The relay will click like hell :wink:

btw. if you put the hysteresis 0.5 you will shorten device’s life. The relay will click like hell

Well maybe 1.0, currently even though mine is set at 1.0, it seem to have to get to 1.5 before the thing switched. so for 20degrees set it swings from 18.5 to 21.5 its naff!!!

To be honest I’m thinking of ditching this thermostat and building my own based on esp8266 and dht sensor:)

I suppose your right on the other bits, wish I could get into the firmware of the device and make it do a lot more without HA lol :slight_smile:

Do you have the one with external sensor?

@uss, just another thing noticed you represent the state of the entity as on/off not the operation mode, and you only have heat/auto as modes, this don’t work with Alexa integration.
My code had the current mode as the state i.e. heat/auto/off and that does work.

Yep I do have one with external sensor but use that for outside temp as I’m using the device to run a boiler not underfloor heating.

Never tried Alexa. I hate those devices because they send info to google, amazon etc. even if you shut them off.
My brother in law stayed with us, until he repaired his home, for a week. After that he received ads for baby stuff LOL. He is not even married. But his phone recorded discussions about our child.
Anyway I’ll look into the code to see what I can do with the off thing.

If you want 0.5 hysteresis you can use the external sensor limit temperature as the upper value of the hysteresis.

Well Alexa or Google home, their all watching us LOL, it is nice though being able to voice control the thermostat its a wife requirement of mine :smile:

Thanks God mine doesn’t speak english :rofl:

1 Like

So how on using external for hysteresis, so use the external to measure temp? and that gives better ? or are you saying set mode 3 and then set external_limit_temp at 0.5 higher?