pihome
pihome copied to clipboard
pihome-shc
"Live temperature"
I was thinking about how could a regular thermostat behavior could be implemented, like setting the temperature on the go, no boost, no override or any schedule.
A slider, visible on the zone pop-up window that could update the target temperature, for that zone, in the database or insert a new value and then boiler.php does the job. The hierarchy (boiler.php line 483) could be like it is now and at the end the "live temp".
We have the slider. We need a new database table. Maybe a checkbox to update the state for the slider in the database (on or off) and the submit button.
What do you think?
@sandreialexandru you mean set that temperature for ever? or it would have some time limit?
Having a time limit would only duplicate the functionality of boost. The temperature set with the slider would be target temperature until boost, night climate, override or schedule comes into action. Basic thermostats don't have schedules, but sometimes there is a need to adjust the temperature on the go.
i was only thinking how to limit the run time, setting the X temperature for a zone until next schedule/boost/night climate kick in and stop the slider temperature. I think you need another table for this to function.
This would be a nice addition to PiHOME interface and a great way to control live temperature http://anthonyterrien.com/demo/knob/
we can implement slider on the screen, http://anthonyterrien.com/demo/knob/ looks very fancy and looks nice as well but it need more space on the screen, at the moment screen refreshes after every 15 seconds and any model open get closed same goes for schedules, if we want to implement something we need to have that refresh bit more intelligent instead of hard coded 15seconds.
Maybe another card under OneTouch. This would eliminate the problem of the 15 seconds refresh. Slider or knob to update temperature in another table into the database with a SUBMIT button.
A slider is the simplest to create. I guess the idea is to change the temperature whilst a schedule is running, if so the slider could initialize with the current schedule temperature, then any change of the slider could be used as an override temperature for the duration of the schedule.
Doing it like this would only create a slider for OVERRIDE. Let's say that there are 5 schedules during one day. It means that we would have to readjust the slider for every schedule. My initial idea was to have a slider and adjust a target temperature, on the go, when no any other function would be active (night climate, boost, override, schedule, holiday...). The slider would update "target_c" only if other functions are off. When a schedule or boost were to be activated then target_c would be updated and Live Temperature disabled. The hierarchy would be: Boost>Night Climate>Override>Schedule>Live Temperature
What do you think?
I'm thinking that live-temperature is not attached to any zone and that it takes precedence eg if activated during a schedule or boost then it controls the temperature until the running schedule/boost completes, hence it controls temperature live, further schedule/boost cycles use their existing temperature settings, as these are future events and hence not yet live
If it is not attached to any zone, what schedule will it override, assuming we have more that one zone? Having it like this wouldn't it be like modifying an active schedule? In my opinion, live temperature should be a function of a plain thermostat.
@twa127 your idea to implement something like this is good, but is not what I had in mind and just a simple temperature set slider is what is missing. At this point we are forced to use schedules or night climate.
I was assuming it would effect any currently running heating schedule, or if no schedule is currently running it would act as simple thermostat with a safety cut-off after a set time, and would be cancelled by the next heating schedule to run or would time-out. The thing about a simple set/action temperature slider is that it has no end point, so the system could be left operating indefinitely. Also I don't like the idea that any temperature change made by the slider remains set as an override until it is explicitly cancelled.
"it would effect any currently running heating schedule, or if no schedule is currently running it would act as simple thermostat with a safety cut-off after a set time, and would be cancelled by the next heating schedule to run or would time-out" @twa127 this is a great idea of implementation. I agree with the fact that it should not run indefinitely, altough we have maximum run time for boiler.
I think we are confused how Live Temperature should work,
right now PiHome Smart heating flows:
Frost protection -> Away-> Zone Max C -> Night Climate -> Boost -> Override -> Schedule
this sequence works as it is defined, if you put system into boost it ignores schedule and override and desires temperature and end time coms from Boost, once boost time or temperature condition are meet system continue to function but boost ends and if you have schedule set at that time it switch back to schedule, it works even one zone is running from schedule but you still can boost any other zone and that zone will demand heat until its boost time or temperature condition aren't meet.
How Live Temperature should work:
you will have three options for user to present, enable check box, desired temperature slider, and time in minutes slider, live temperature should sit before boost in PiHome smart heating flow:
Frost protection -> Away-> Zone Max C -> Night Climate -> Live Temperature-> Boost -> Override -> Schedule
instead of this demanding heating for all zones needless it should work zone by zone same way as boost
Wouldn't it be like boost, but with a slider? Maybe the maximum running time could be boiler max time and not have the option to set the time for live temperature. I agree that there should be zones included so we can have control over each temperature.
We could utilise boiler max time or zone max time to timebox the max running time with set temperature.
Designing the heating flow, as @pihome-shc said, means that when night climate ends the boiler starts automaticaly for live temperature, which isn't a great idea if you ask me. Schedule should start the boiler, wich can be overwitten by boost or override. The current heating flow is perfect. I would place live temperature at the end, after schedule and, as @twa127 said, set the end point with a timer, wich could also be the maximum time for the zone.
Hi, I think my last post wasn’t very clear, or i made it more confusing, If you set live temperature it should gets before boost, so if there is any active boost or active schedule for xyz zone but user set the live temperature then live temperature will gets priority, but once live temperature runs out of temperature or time (which ever comes first) it fall back to what ever is active at that time, logic wise live temperature should go as another type of boost but with option to set variable temperature. But definitely not for change in desire temperature for current active schedule, I know people have one ir two schedule for whole day,
On 24 Oct 2020, at 21:52, sandreialexandru [email protected] wrote:
Designing the heating flow, as @pihome-shc said, means that when night climate ends the boiler starts automaticaly for live temperature, which isn't a great idea if you ask me. Schedule should start the boiler, wich can be overwitten by boost or override. The current heating flow is perfect. I would place live temperature at the end, after schedule and, as @twa127 said, set the end point with a timer, wich could also be the maximum time for the zone.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
I interpret what you're saying as - live temp is a temporary change to any active target_c temperature which stays active until -
- the current running schedule finishes
- the current running boost finishes
- the live temperature max run time is reached
If you want a permanent change to any schedule or boost temperatures, then the change should be made in those schedules or boost settings
Have I got that right :-))
I agree that there is no need for another slider to modify boost or override. Boost or override should take over schedules and live temperature be last in the heating flow.
The duration slider doesn't make this like boost? I've been thinking and we can't consider the boiler max time the end point for live temperature. In my opinion, we should not have a slider for live temp time and set the max time as the maximum zone time. If 2 or more zones run one after the other the boiler max time could end, but if maximum time for live temp is the same as zone max temp, then the boiler stops when max zone time is reached.
One schedule running after the other is not an issue, as the second schedule will clear the live_temparature condition and it runs as normal. The reason for the max duration is as a safety cut-out for a future feature where you can manually trigger the heating zone ON/OFF using the live_temperature as for $target_c.
As far as I can see currently neither $zone_max_operation_time or $boiler_max_operation_time are used in any of the control logic
Another point to consider is that when #393 get implemented, dual zone systems will only have 2 zone table entries, one for heating and the other for hot water, all the 'zombie' temperature measurement only zones will disappear ,hence live temperature will normally only effect the single heating zone
If boiler max time and zone max time aren't used in any logic, why keep entries in database and settings of them? I see you point with #393, but live temp would only be active for heating zones. I agree with the safety cut for live temperature, but I shall stick with the argument that if implementing temperature and time control we only build a "manual boost". Controlling the temperature manually but keeping the safety cut with zone max temp is, in my opinion, the best way. Boiler is controlled by /cron/boiler.php wich could, for example, take into consideration the max time set for the zone and the new heating flow. A zone with only live temperature will also have a maximum time(in settings), also for safety cut.
I'd be quite happy using either $zone_max_operation_time or $boiler_max_operation_time and a single slider or some other widget to set the temperature, @pihome-shc am I correct in saying that these 2 table entries are not being used ?
Maybe boiler.php should take into consideration both max times for boiler and zones. It would be a very good safety feature.
I have test night climate with boost, and this is what we have, i have corrected this mistake in flowchart and i'm about to update this on PiHome website as well.
Frost protection -> Away-> Zone Max C -> Boost -> Night Climate -> Override -> Schedule
I still think live temperature should not depend on running schedule or boost time, but zone max time.
