Domoticz

piotrux wrote:Thank you explanation. My stove is old there is no on and off switch. I have custom thermostat build on "let's control it". In that case how can i adjust to make it work? I want a constant temperature in the room thanks to netatmoand SVT.

Well, I use SVT to decide when the heater must go on. Then I manipulate the setpoint of the wall thermostat to go 1 degree above setpoint temperature of SVT. This turns on the heater right away. When the SVT heater turns off, I reduce the setpoint of the wall thermostat to 1 degree below the SVT setpoint. This turns the heater off.

So once again, SVT is in control and does an awesome job to keep the room temperature stable within +-0.1 degree. Since I have seen opentherm system, the manipulate wall thermostat does the actual switching.

I even made the script smarter, so that when I adjust the wall thermostat manually, the SVT setpoint is updated as well.

After restarting the domoticz service, I realized that SVT was not running anymore. Going back through the log I discovered why:

2021-01-07 17:23:35.661 Status: Closing application!...
2021-01-07 17:23:35.661 Status: Stopping worker...
2021-01-07 17:23:35.864 Status: RxQueue: queue worker stopped...
2021-01-07 17:23:36.375 Status: WebServer(HTTP) stopped
2021-01-07 17:23:36.877 Status: WebServer(SSL) stopped
2021-01-07 17:23:36.929 Status: TCPServer: shared server stopped
2021-01-07 17:23:36.929 Status: Stopping all hardware...
2021-01-07 17:23:36.929 Status: HardwareMonitor: Hardware Monitor: Stopped...
2021-01-07 17:23:36.940 Status: OpenZWave: Closed
2021-01-07 17:23:38.662 Error: (SVT) Error calling 'http://127.0.0.1:8080/json.htm?type=dev ... order=Name'
2021-01-07 17:23:38.662 Error: (SVT) No Inside Temperature found... Switching Thermostat Off
2021-01-07 17:23:39.121 MQTT: Topic: domoticz/in, Message: {"idx":397,"nvalue":0,"svalue":"0;166744.3","Battery":100,"RSSI":3}
2021-01-07 17:23:39.123 Status: Pinger: Worker stopped...
2021-01-07 17:23:39.138 Status: PVOutput (Input): Worker stopped...
2021-01-07 17:23:39.143 Status: OTGW: TCP/IP Worker stopped...
2021-01-07 17:23:39.171 Status: Fritzbox: TCP/IP Worker stopped...
2021-01-07 17:23:39.176 Status: P1 Smart Meter: Worker stopped...

Simply enabling the SVT Thermostat Control' (put it into 'Auto' mode) makes it run again. However, during shutdown SVT makes the wrong decision by assuming that during shutdown the 'missing' temp. sensor should result in a shut-off of SVT operation by flipping the selector switch.

EDIT: On the changelog I see that this is solved on 0.4.8, (While I still was on 0.4.7). Excuse me. I updated and this probably won't happen again!

Morning,

I'm using SVT for two years and everything works fine, but the last days I can see a lot of entries in the log like this:
these messages repeat every few seconds

Hi,
Can be possible to add the parameter max heating time? Like min heating time. Why? I have a problem (typically in the morning) when the difference between temperature 'economy' and 'normal' is more (2 degrees). Then heating time can be more than 40 - 50 minutes and the boiler is switch off by a security thermostat after reaching the critical temperature. I would like to avoid the failure of this thermostat.
Thanks

Milan wrote:Hi,
Can be possible to add the parameter max heating time? Like min heating time. Why? I have a problem (typically in the morning) when the difference between temperature 'economy' and 'normal' is more (2 degrees). Then heating time can be more than 40 - 50 minutes and the boiler is switch off by a security thermostat after reaching the critical temperature. I would like to avoid the failure of this thermostat.
Thanks

This means that without svt you have the same problem after a 2 degree increase in setpoint?

You can easily make the change in the code yourself: look for the lines where power is checked for power > 100 = 100. Change both to 80. Restart domoticz and it will work. For self learning code in this script, this is not the best idea, because it will think that the ON time was 100 percent.

Your best bet is to manipulate your setpoint some time before you want to reach the normal setpoint. This will fire the boiler for a shorter period of time

Hello, is it possible, for example, to add in the code so that the stove heats, for example, 0.5 degrees more than agreed? I know that there is a delta max option, but if I set, for example, 20 degrees, it heats up to 19 and I would like it to heat to 20.5 and only turned on when the temperature drops below 20.

johnny86 wrote: ↑Saturday 30 January 2021 15:28 Hello, is it possible, for example, to add in the code so that the stove heats, for example, 0.5 degrees more than agreed? I know that there is a delta max option, but if I set, for example, 20 degrees, it heats up to 19 and I would like it to heat to 20.5 and only turned on when the temperature drops below 20.

Give it some time, it is after all a SMART thermostat. It needs to learn your isolation and heating characteristics.

The way you describe it, it can be done with a switch at the boiler and a simple script, based on a thermometer. On/Off

With the low outside temperature SVT didn't manage to keep the temperature inside stable. Obviously the ConstT too low. I can read the value from the variables in domoticz, but last time when I reduced the counter from 50 to 10, the counter was reset to 50 at the next calculation interval. So, these values are stored somewhere else and those values are used for the plugin input.

Where can I manipulate these values, instead of waiting for the automatic learning (that will only weigh 1/50 of the new supposed constT value)

jake wrote: ↑Sunday 31 January 2021 11:56 With the low outside temperature SVT didn't manage to keep the temperature inside stable. Obviously the ConstT too low. I can read the value from the variables in domoticz, but last time when I reduced the counter from 50 to 10, the counter was reset to 50 at the next calculation interval. So, these values are stored somewhere else and those values are used for the plugin input.

Where can I manipulate these values, instead of waiting for the automatic learning (that will only weigh 1/50 of the new supposed constT value)

You need to disable the svt hardware before you change the variable, then after you've changed it, re-enable the hardware: svt still has the value in memory and adds one to to that value, then stores it (over your changed value).

jake wrote: ↑Tuesday 19 January 2021 14:04

Milan wrote:Hi,
Can be possible to add the parameter max heating time? Like min heating time. Why? I have a problem (typically in the morning) when the difference between temperature 'economy' and 'normal' is more (2 degrees). Then heating time can be more than 40 - 50 minutes and the boiler is switch off by a security thermostat after reaching the critical temperature. I would like to avoid the failure of this thermostat.
Thanks

This means that without svt you have the same problem after a 2 degree increase in setpoint?

You can easily make the change in the code yourself: look for the lines where power is checked for power > 100 = 100. Change both to 80. Restart domoticz and it will work. For self learning code in this script, this is not the best idea, because it will think that the ON time was 100 percent.

Your best bet is to manipulate your setpoint some time before you want to reach the normal setpoint. This will fire the boiler for a shorter period of time

If you start making changes to the code anyway, I suggest to also INCREASE the value for self.deltamax. It is by default set to 0.2 in the current code. I suggest to set it to for example 2.0. The thermostat needs to learn how fast your house cools down too, not just how fast it heats up. If you cut it short at 0.2 degrees, it will no longer learn when the inside temperature goes more than 0.2 degrees over your setpoint, causing it to learn about the cooling down of your house only in those rare occasions when you turn down the thermostat, and only this once, because the next time it will be "overshot" again. By allowing a little more overshoot, you enable the thermostat to learn about cooling down as well.

I learned this, because I added a 'power' device to my svt, showing the actual power applied value (so I could log it into my influxdb) and noticed that this went from some high % to 0% all the time. It was behaving like an on/off thermostat instead of a smart thermostat.

rrozema wrote: ↑Wednesday 03 February 2021 9:57 If you start making changes to the code anyway, I suggest to also INCREASE the value for self.deltamax. It is by default set to 0.2 in the current code. I suggest to set it to for example 2.0. The thermostat needs to learn how fast your house cools down too, not just how fast it heats up. If you cut it short at 0.2 degrees, it will no longer learn when the inside temperature goes more than 0.2 degrees over your setpoint, causing it to learn about the cooling down of your house only in those rare occasions when you turn down the thermostat, and only this once, because the next time it will be "overshot" again. By allowing a little more overshoot, you enable the thermostat to learn about cooling down as well.

I learned this, because I added a 'power' device to my svt, showing the actual power applied value (so I could log it into my influxdb) and noticed that this went from some high % to 0% all the time. It was behaving like an on/off thermostat instead of a smart thermostat.

For myself I have set the deltamax to 0.9. With >0.2 above setpoint, the heating cycle would be skipped. The next heating cylce would be too late to avoid a temperature below setpoint.
This will cover my needs: with an internal temperature of 20'C en outside temperature of -10 (and my ConstC and Const T values) the deltamax of 0.9 will still calculate a positive power need. Since the power result is positive, my house obviously need the 0.9 to not dip below setpoint.

The deltamax is only used to decide whether or not run the script or apply power. Above setpoint + deltamax heating will be skipped and also the learning will be skipped indeed, bot for ConstC and ConstT

I don't follow your arguments about learning about heating up, cooling down.
ConstC is about capacity of the heating system to heat up the room
ConstT is about the insulation value of the room, how quickly the room cools down.

Both parameters are recalculated in normal circumstances (except ConsT when the outside temperature is higher than setpoint. very rarely of course)

jake wrote: ↑Wednesday 03 February 2021 13:20

rrozema wrote: ↑Wednesday 03 February 2021 9:57 If you start making changes to the code anyway, I suggest to also INCREASE the value for self.deltamax. It is by default set to 0.2 in the current code. I suggest to set it to for example 2.0. The thermostat needs to learn how fast your house cools down too, not just how fast it heats up. If you cut it short at 0.2 degrees, it will no longer learn when the inside temperature goes more than 0.2 degrees over your setpoint, causing it to learn about the cooling down of your house only in those rare occasions when you turn down the thermostat, and only this once, because the next time it will be "overshot" again. By allowing a little more overshoot, you enable the thermostat to learn about cooling down as well.

I learned this, because I added a 'power' device to my svt, showing the actual power applied value (so I could log it into my influxdb) and noticed that this went from some high % to 0% all the time. It was behaving like an on/off thermostat instead of a smart thermostat.

For myself I have set the deltamax to 0.9. With >0.2 above setpoint, the heating cycle would be skipped. The next heating cylce would be too late to avoid a temperature below setpoint.
This will cover my needs: with an internal temperature of 20'C en outside temperature of -10 (and my ConstC and Const T values) the deltamax of 0.9 will still calculate a positive power need. Since the power result is positive, my house obviously need the 0.9 to not dip below setpoint.

The deltamax is only used to decide whether or not run the script or apply power. Above setpoint + deltamax heating will be skipped and also the learning will be skipped indeed, bot for ConstC and ConstT

I don't follow your arguments about learning about heating up, cooling down.
ConstC is about capacity of the heating system to heat up the room
ConstT is about the insulation value of the room, how quickly the room cools down.

Both parameters are recalculated in normal circumstances (except ConsT when the outside temperature is higher than setpoint. very rarely of course)

with a very small deltamax overshoot will be set to true almost every time the heater is switched on and no learning will take place when overshoot equals true. Meaning that when ConstC is to big, every time the heater switches on, the next cycle the thermostat will be in overshoot mode and no learning takes places while cooling down. It's kind of like when raising a child : if you always keep it away from fire, it will never know what is to burn himself and thus it will not learn to be careful with fire. Likewise: You need to allow the thermostat to make some error in order for it to learn from those errors.

B.t.w. I don't think ConstT represents the cooling down factor. It represents a correction on the cooling down factor based on the difference between the inside and outside temperatures. This is also why I think it is wrongly implemented in this code to compare against the setpoint value. It should have compared the outside temperature against the inside temperature, not the setpoint. Luckily the difference between the inside temperature and the setpoint is rather small most of the time. The amount of heatloss does not depend on the intended temperature, it depends on the actual temperature.

Yes, I agree that 0.2 is way too low. Especially for floor heating, since the deltamax not only decides overshoot calculation, but also whether or not a heating calculation is exectuted.

I think the deltamax parameter is there to deal with other heat sources in the house, like the sun or a wood stove. Their influence should not adapt the ConstC and T values.

The calculation of ConstC is not to difficult to follow and makes sense. The ConstT calculation I find a lot harder to understand, especially since heating up inside and cooling down to the outside takes place at the same time. This would be easier to calculate in cycles where no heating is required.

Btw for myself I have updated the code a little because of the following:
Normal heating is done by floor heating, a very slow process with a lot of energy accumulated in the floor. Therefore I had to extend the calculation cycle to 120 minutes to prevent drastic overshoot. This works fine now and SVT is able to keep the inside temperature within 0.1'C most times, a very good result with floor heating in my opinion.

However, when we use the wood stove, the accumulated energy in the room is very little, since most of the heat is done by hot air. Therefore, after the wood stove is off, the temperature in the room drops much faster and than 120 minutes is too long for the next calculation.

So, I added the line to the code in the part where 'power == 0' that the next calculation cycle is 0.5 x the cycle time as given in the hardware section of the plugin. In my case 60 minutes. So, in my case it will be a 60 minute interval until heat is necessary, then it will continue with the normal 120 minutes. This killed another un-expected drop in temperature below setpoint.

When my wife starts cooking in the kitchen, this heats up the kitchen significantly. The average temperature on my ground floor will then rise quickly without the heater applying any heat. This will un-regulate the thermostat to both under- and overshoot for a long time.

To fix this I have set up a 10 minute cycle so that the thermostat can react quickly to both rising and falling temperatures. However the fixed 50 cycles memory was too short for my 10 minute cycles, so I changed the number of cycles into a calculated value of 2 days / calculation_period, resulting in the thermostat having a built-up memory over always the last 2 days' behavior.

And one other thing I changed was the averaging of the inside and outside sensors. Instead of looping over the temp devices to see if it is in the list of sensors I loop over the list of sensors to see if it is in the list of temp devices. This allows me to put the living room sensor's idx in the list twice, while the kitchen sensor's idx is in there only once. The result oif this is that the temperature in the living room counts twice in the averaging of the (now) three listed devices, and thus the impact of the kitchen sensor's value on the average temperature is now only 1/2 of that of the living room temperature sensor.

Thank you, Logread for this plugin. While the original idea isn't yours, like you've stated several times, the effort to make this available on Domoticz is.

There are two things I think should be added to Wiki, and/or at least to the Github page for this plugin:
DeltaMax. I know, it's new'ish.
Multiroom setup. Thanks to a comment way back in this thread I finally realized this plugin works just fine with multiroom.

TSkar wrote: ↑Sunday 07 March 2021 17:00 Thank you, Logread for this plugin. While the original idea isn't yours, like you've stated several times, the effort to make this available on Domoticz is.

There are two things I think should be added to Wiki, and/or at least to the Github page for this plugin:
DeltaMax. I know, it's new'ish.
Multiroom setup. Thanks to a comment way back in this thread I finally realized this plugin works just fine with multiroom.

Could you point mo to the multiroom post? interested in that

They deltamax i will read up on in the post above

The multiroom is pretty simple really, I just never thought to try outta fear of breaking everything.
Just add a new device in Hardware, same way you installed SVT in the first place. It adds the stuff needed to run SVT all by itself, but based on the name you chose for the hardware device.

I guess it could be argued that it isn't truly multiroom, since it doesn't pull data from one room's calculations to use for other rooms calculations. ..but it is multiple rooms.. For me it made a lot of difference in getting rooms stable temperature wise, I have quite different heating and temperatureloss in the few rooms I got.

Edit: and to be clear, by installed, I ment added in Hardware page ..not the copy-plugin-into-folder part.. you use the same plugin script to add multiple devices in the Hardware page.
..it's late, sorry..

TSkar wrote: ↑Monday 08 March 2021 0:46 The multiroom is pretty simple really, I just never thought to try outta fear of breaking everything.
Just add a new device in Hardware, same way you installed SVT in the first place. It adds the stuff needed to run SVT all by itself, but based on the name you chose for the hardware device............

Ah ok.. i've alreay got that part but still looking for a nice way to switch on the heater based on the request per room.

Skippiemanz wrote: ↑Monday 08 March 2021 10:21 Ah ok.. i've alreay got that part but still looking for a nice way to switch on the heater based on the request per room.

Unless I completely misunderstood you, that is exactly what you get. It functions like two (or several) different SVT's, with different temperature sensors, heat switches, on/off/auto/pause/eco/normal temperature settings, and independent calculations. If the end goal is zones or rooms with very low temperature variations, I think it's the way to go.

..if you ment it as in predicting the requests, or automating the controls, I think that's beyond the range of what SVT (or any heat system) should do. It calculates need for heating, and triggers it, based on inputs. Like a cog on a cogwheel, or a module in a larger system.
For complete prediction based automation of everything, Bayesian Sensor scripts got me closer, but still not there. ..yet.

Hello,
the version i have is 0.4.11 is this the last one on this moment

Gerwin