Another way would be a custom script that re-writes the configuration when one of the values changes… Should be doable in your favourite scripting language with a bit of thinking.
Hi @roschi
That’s clear, thanks.
Just what about the dynamic temperature value - in your examples you have the conditions dynamicaly but the temperature value is still static.
If I understood correctly the documentation I will have to write my own module cause inline expressions are not able to handle that, right?
Cheers,
Jarda
Inline expressions are just normal Python code, so they are turing-complete and can potentially do everything. 
Outsourcing code into an external module just makes writing logic a lot easier and more readable.
If you want to have another temperature when the rule mentioned above isn’t active (evaluates to Ignore()), you should just add additional rules below that one to express your needs. Rules are processed sequentially, and the first one that evaluates to a temperature wins.
There are some nice schedule examples that were discussed and reworked throughout this thread. They demonstrate the processing of schedules pretty well… Maybe you want to have a look at them?
Hi @roschi
Thanks for patience so far. I went through the whole thread and in fact the conditions and Ignore clause are quite clear. You example above is self explanatory:
{ temp: 20 if time.hour in range(int(app.get_state("input_number.start_hour")), int(app.get_state("input_number.end_hour")) + 1) else Ignore() }
What I found nowhere so far (thread, documentation) if it is possible to use the value of temperature from HA instead of fixed one. Currently everyone was solving the dynamic times or temperature difference (Add) etc. but the temperature value was always statically present in Heaty conf.
I am not Python expert so not sure if something like this can work (modified your example). Can it?
{ temp: int(app.get_state("input_number.day_temperature")) if time.hour in range(int(app.get_state("input_number.start_hour")), int(app.get_state("input_number.end_hour")) + 1) else Ignore() }
Thanks,
Jarda
Yes, that would work. But you can leave out the int() around the temperature, because Heaty does accept strings as well…
And don’t worry about my patience. It is a pleasure for me to help people integrating and enjoying Heaty in their lifes. As long as I see that those who ask have read the documentation (which I put a lot of effort into exactly for that purpose) asking questions is fine.
I now added this to the docs as well:
1 Like
Hi @roschi
I made a real test and we need to make few cosmetical changes
For setting just temperature, the last rule, it works like this, easy:
{ temp: app.get_state("input_number.bedroom_low_temperature") }
But for the more complex things two problem compared to above occured.
First the whole expression must be closed in ’ ’
Second HA is providing the input_number values as float and the int conversion is not working. It must be double converted:
{ temp: 'app.get_state("input_number.bedroom_high_temperature") if time.hour in range(int(float(app.get_state("input_number.bedroom_hour_second_on"))), int(float(app.get_state("input_number.bedroom_hour_second_off"))) + 1) else Ignore()' }
Ah, didn’t consider that it were floats. The quotes are needed for those single-line YAML mappings enclosed in curly brackets. You could do:
- temp: app.get_state("input_number.bedroom_high_temperature") if time.hour in range(int(float(app.get_state("input_number.bedroom_hour_second_on"))), int(float(app.get_state("input_number.bedroom_hour_second_off"))) + 1) else Ignore()
I updated the docs with your fixes, thanks.
@TriStone The example in the docs is now a little simpler and removes unnecessary type casts, just in case you may want to adopt it.
Hi Robert
I’ve been holding off my heaty implementation until it works with a released (rather than beta) version of Appdaemon 3. I see that AD3.0.1 is now live - is this heaty-friendly?
Did you try AppDaemon 3.0.1 with heaty?
As long as https://github.com/home-assistant/appdaemon/issues/256 hasn’t been resolved, Heaty won’t work. I made a PR and think it’S going to be merged soon.
BTW: Heaty does indeed work with AD 3.0.0/3.0.1 and should be usable without problems, but your log will be spammed with a lot of errors…
Best regards
Robert
For those using heaty with Spirit TRVs do you see in your dev_state the Valve Position being represented in Home assistant.
In my Hass.io configuration with openzwave dev branch config the Spirits work fine but due to some missing patches I am not getting any valve position states.
If you see the state, would you mind sharing your installation type, I would like to enable heat source control but without this value from the valve position it’s going to be unreliable
Cheers
Hello,
How do I install Heaty into Hassbian? How do I view UI (temperature schedule)? Thank you.
The answer to those - and many more - questions can be found by reading this forum post, and the ample and thorough information provided by @roschi on github and the wiki. Enjoy !
Hi @DamianFlynn
I’m not yet sure how to properly implement the control of an energy source. Having it depend on valve positions would be the best I guess, but I think only very few thermostats provide this information.
The approach I was thinking of is to calculate the difference between wanted and current temperature for each room, maybe group rooms by energy source and then report the difference as a sensor entity to HA, where you could then react accordingly, utilizing the full potential of HA automations for applying a hysteresis and so on.
What do you think about such a strategy?
Best regards
Robert
After working with the Honeywell Evohome system for a year, connected to Domoticz, I created a LUA Script which used the Valve position as an indicator of demand for any single TRV, with a Basian to normalise the room. The need here was driven due to poor reliability on communication from the TRV to the Evohome controller, and the additional issues including obstructions like curtains trapping heat and influence the temperature reading.
The Spirit TRV Do feedback valve position as part of thier notifications but only if we have a full implemented dev branch of openzwave With Home assistant which at this point I have totally failed to get working with Haas.io and I believe I will have to implement Home Assistant either as a custom container with the correct compiled version of openzwave or a native python virtual environment installation.
I like and believe the option to combine both valve and temperature with a basian for each room will give a good indication on demand for heat or not
Then each room can be combined to a zone for the pump that supplies the rooms in that zone to be engaged.
If a pump is to be engaged then that indicates heat source is needed, so the logic can then determine what heat source is appropriate to engage if multiple sources are plumbed.
Hope this helps
Damian
What happens if you use the temperature difference from set point to current reading as a control for the heat source? If all rooms have reached set temperature, you can stop heating?
Lars