Nice that you spend so much of your time pimping your node!
I'm still struggling with understanding the vertical ramps, like e.g. in your simulation example:
Have been reading some articles last week, but I just don't get why a vertical ramp is used
When looking at the other ramp (04:00 - 08:00), then the blue line is able to follow the ramp. This makes sense to me, since the ramp offers some time to the system to heaten up (or cool down).
However the heating system can never follow the vertical ramp at 19:00, unless you inject rapidly liquid nitrogen into your living room So please enlighten me, because I haven't a clue ... Or does it perhaps just mean: "go as soon as possible to the new temperature".
P.S. if anybody is wondering why I'm so focussed on the vertical ramps: in this 0.7.1 version, the profile is validated (to intercept faulty user input). But two different temperatures at the same time are still allowed. This means a vertical ramp is allowed...
This node can be used as an excellent profile generator, where there may be no need for the thermostat feature and the profile may not be temperature. There would be no point in preventing what some users may find useful.
Even with room temperature control, however, if one needs a particular temperature till a particular time, at which point the room will be unoccupied, a step down in temperature may be appropriate followed by a ramp up to the next time the room will be used. That way the heating will be off until need again.
First let's see how a programmable (mechanical) thermostat works, generally we can set the day/night temperature and the start/end time. There are several types but the basic function is almost similar to all.
The chart shows the target temperature for following settings:
day time: 07:00 until 19:00
day temp: 20°C
night time: 19:00 until 07:00
day temp: 18°C
This means that at 07:00 the target (setpoint) is set to 20°C until 19:00 where the target is set to 18°C.
But the actual temperature is obviously not the same as the target, the actual temperature will increase/decrease until the actual temperature is equal to the target one.
How long it takes, depends on the house construction and on the outdoor temperature. So the chart may look as follow:
How does the ramp-thermostat work?
It works like a programmable thermostat with an additional ramp (gradient), generally used when the heating is turned on.
In the morning the heating will start at approx. 06:15 and takes approx. 2 hours to reach 20°C until approx. 08:00.
Scenario B)
When the outdoor temperature is lower the room temperature is also lower in the morning because of the greater temperature difference and therefore the greater thermal loss.
So the heating has to start earlier in the morning e.g. at approx. 04:30 and takes approx. 3.5 hours to reach 20°C until approx. 08:00.
Our goal is to reach a room temperature of 20°C at 08:00 independently of the outdoor temperature.
In the evening the target is set to 18°C, that means the actual temperature decreases until 18°C. How long it takes, depends again on the house construction and on the outdoor temperature.
We want also to save energy during the night and not to reach the target temperature of 18°C as soon as possible.
Thanks a lot!!! Very clear. Just like reading a book for dummies ...
Ok, that is the weather compensation you were discussing in this Github issue.
Are my following assumptions then correct?
I assume that the ramp degree is based on your experience (of how quickly your room heatens)?
I assume that - since the ramp degree is fixed - you use the worst-case ramp degree, to make sure that your rooms gets its temperature on time even on the coldest days of the year.
I assume that self-learning heating systems calculate the ramp degree based on the measurements from the past. So the ramp-degree becomes variable in that case, depending of the outside temperature? I.e. a steeper slope when outside temperature is higher, to take into account that the room heatens more quickly.
Right, its just an example, you have to use it and find out, what is the best for you. It depends obviously on the heating system (radiator, floor heating, etc).
Right, e.g. at 08:00 the temperature is more or less 20°C.
That's the next step. As soon as you have used it for let's say a heating season you can think about self-learning and use setProfile to input different profile accordingly.
But heating control is a never ending story, that means there are so many factors influencing the control circuit like house construction, windows open/closed, how many people are in a room, how old are the residents, are they ill? or have they fun? etc.
thank you for that detailed explanation...this node looks like something I've been looking for (planning on using it for a hot-water boiler, driven by a heatpump).
I am new to node-red and new to the forums as well...is is OK to ask questions specific to this node in here or should I open a new thread?
OK, Thanks...actually I have a lot of questions, but these are the most prominent two:
where/how can I set the gradient adjusted to my situation?
AFAIU the ramp steepness or gradient is a constant, declaring how much heat the "system" (heating element of your choice) can deliver into your "environment" (room/boiler/pool/fishtank,...).
It will depend on your individual situation/setup but for each setup it is considered a constant, isn't it.
In your scenarios given above, heating from 18 to 20 dC during a period of time from 04:00 til 08:00 means the gradient is 2dC/4hrs or 0.5dC/h.
In my situation, my heatpump can deliver 3dC/h...how can I adjust the gradient in the node?
Will your algorithm work across the midnight line or across profiles?
A profile runs from 00:00 to 23:59. What will the node do, if the ramp points to a time into the past day (tomorrow might even be another profile from today, like switching from SUN to MON profile at midnight)?
Example: desired heat target is 24dC at 07:00 tomorrow but today at 22:00 the real temp is 20.5dC.
With the gradient being 0.5dC/h, it will take 8hrs to heat from 20dC to 24dC, so the heater must start at approx. 23:00 today to reach target at 07:00 tomorrow.
Edit: and in the scenario, where profiles would switch at midnight, the 24dC setpoint at 07:00 tomorrow will not be part of the profile active today.
Have a look at the README The profile consists of several points whose connections build a sequence of lines. You can also set the gradient by setting the points e.g. "04:00": 18 until "08:00": 20 or "03:00": 18 until "08:00": 20 or whatever you need (geometry: a line is defined by two points). The algorithm calculates the target for every line you have set at the time you trigger the node (send a new temperature value to the input).
The profile is for a 24 hours period, it works across the midnight and starts again at 00:00.
Typically if you set a new profile for a new day, you set the new profile at 00:01.
In your case I would try to change the profile in the evening at 23:00. At the time you change the profile the target is calculated by the new profile.
One hint: install the ramp-thermostat and experiment with e.g a temperature sensor like the ds18b20 and a simple actuator switching a light bulb. Place the temperature sensor near the light bulb. Experimenting is the best way to find out what you can do and learn more about the ramp-thermostat.
Thank you for your fast response and that information.
I think, that I misunderstood the usecase for the ramp / gradient initially.
By defining the gradient based on left-temperature and right-temperature you are "mimicking" a sort of "low-tec" PID controller, which tries to follow the ramp.
My usecase is a bit different. What I need is to determine the right time when to switch on the heat in order to match the target (right-side) at the (future) time.
But the left side has no target, only the actual, real temp is of importance and the actuator, once activated must stay ON until the target is reached (at the desired time).
My gradient is always the same (like 3dC/h) and controlling the left-side temp is of no use. It is always the actual temp from now() and I cannot have the "PID" effect that would switch the actuator on/off during heating.
..I will try and experiment, as you suggested...maybe I can "trick" the node into my usecase.
An additional note: the purpose of the ramp-thermostat is to control individual room temperature, e.g. I use a ramp-thermostat for every room reading the room temperature via a wireless temperature sensor and controlling the water valve (floor heating) for each room by a wireless actuator.
But the ramp-thermostat can be also used for a central heating.
I suppose you currently switch on/off your boiler/heating pump depending on the outdoor temperature and a time switch?
Thanks, yes, this is what I gathered now.
No, my usecase is not for room heating. It is for warm water tap/supply only with a small heat-pump and central heating is done with an extra, larger heat-pump. Both have individual controllers.
The controller for warm water used to be an intelligent one, with a weekly calendar schedule and able to learn the optimal switch-on timings...but it is gone to meet its maker and there is no replacement on the market
It was not perfect, as it was a controller for electric floor heating, so I thought I could even try to improve things.
Well, after I tackled the basics, which is where I am now
My ultimate target is an optimum between these goals:
comfort-1: to have the hot-water supply ready whenever it is scheduled for,
which means to determine the time for switching it on, in order to have reached the desired temp at the configured time
comfort-2: maintain maximum comfort when supply is used
When at the plateau (water is hot), increase hysteresis to allow to use of as much water as possible (when water is used, cold water will flow back into the tank, however tank construction will prevent it from stirring/mixing. so only (re-)start the heating when the water is considered too cold)
energy: maintain maximum efficiency at the same time
no need to keep the tank hot all times. maximize the runtime of the heatpump instead, letting the water cool down to cold level if not in conflict with comfort-1/2 goal
and usability features, like:
weekly calendar with 3-5 on/hot-water-supply events for each day-of-week, weekdays, weekends
@hominidae,
I see, I'd first use the core nodes (function node -> javascript) to achieve your goals and maybe later on you can optimise your flows using some contrib-nodes.