As I said before, thanks a lot @clementTal
Component works great and I’m very happy it is local, fast and with no cloud requirements.
That said, I’m not sure I would have the scheduling part embedded in this component.
It feels ‘wrong’ from a design point of view. The purpose of this component should be to just expose thermostat sensor values and actuation (that is, turning the heater on/off).
To me, any scheduling should be managed in automations, or from some other generic component, but not here. Otherwise you would end up having all climate components implementing their own (different) scheduling logic.
You might say “hey, the component exposes those functionality! why loosing them?”. To me it would be in the name of genericity and not having duplicated/different code to deal with basically the same problem across ha.
Please, take this just as my 2 cents, and feel free to ignore me.
I agree, for most of users, schedule conf is not usefull.
In the next release, I’ve separate it from the config, and made it available through services only (as for advance configuration).
The reason I let it available, is because the thermostat is part of what I call “sensitive” part of my home automation. I do not want it to fail if there is a wifi/HA/network failure.
It do not block the use of HA authomation (by setting the mode to “manual” and set the target temp at distinc times.
Yes. But it doesn’t work well. I have electric floor heating. Some temperature is showing in HA but I can’t identify what is it. Thermostat target temperature settings in 1deg C steps? Nothing for me.
Problem is in Tuya component, resp. pytuya library. It is not ready for such kind of thermostat. So the reasonable integration is not possible.
But I think the biggest problem is in thermostat firmware! When the floor temperature meets the set limit (for example 35deg C) the thermostat switch the relay 3 to 5 times (it seems it can’t decide to shiwtch or not). The relay will wear out quickly I guess and it is uncomfortable at night.
I recommend don’t buy it even if you see it with good discount. BHT-002-GBLW http://bit.ly/2zscERh
I am using Devireg 550 units in my house, these are “set and forget” devices. I wanted to replace it with something what I can integrate in HA but it seems I will need to write my own component
I’ve downloaded it, but before I break everything…
Can I use it still with 0.83.X or do I have to go to 0.84 before ?
I don’t use the schedules, so I understand I’m safe keeping the same config ?
Hi, thank you so much for the work, it works very well!
I’ve seen in the entity state attributes that there is an “away_mode”, is it possible to use it in HA?
you are right: ‘name’ is not needed, I very likely run the ‘Config checker’ BEFORE restarting hassio,
and the new config was being checked against the old broadlink.py implementation, resulting in an error
as per the component lacking the current and target temp controls, I had some wifi connection issue (while testing I had the thermostat moved in the basement and wifi is poor there)
can I ask you why using ‘friendly_name’? was a request from the HA pull request gods?
because every other component I have in my config uses simply ‘name’, and I see ‘friendly_name’ used only in the customize.yaml
