Domoticz

sorry for all the posts but learning as I use this.

so what I thought was SVT dealing with my oversized heater seems to have been a quirk of the learning process as overnight it has reverted to on/off cycles at the 5 min minimum and as expected this is resulting in an overshoot on temperature higher than I want to see.

I dont see this as a fault as this was not a scenario that it is designed for but is there a reason for the 5 min minimum? I have amended "self.calculate_period" to 1 as a trial but is there any issue with this or might I be better disabling the self learning completely for this particular situation?

now waiting impatiently for the sensors when we get post again here once the snow melts so I can try this on a more normal system but so far it looks to do the job really well

I'm trying to use the SVT as the controller for a meat smoker, and have the same question: what would be the optimal settings for something like that?

blauwebuis wrote: ↑Wednesday 07 March 2018 17:51 I'm trying to use the SVT as the controller for a meat smoker, and have the same question: what would be the optimal settings for something like that?

Trial & error is my best advise... I never imagined such an application... i assume thermal inertia of the meat smoker is less than a room or full house, so calculation period might be lower (i.e 15 mins ?)

I tried setting everything to the lowest possible, and it kinda worked. As a test I put the heating element in my oven, and tried to let it heat up to 50 degrees. Originally it swung between 50 and 80 degrees, but later calmed down to between 48 and 58. So it worked! It seemed to have a granularity of 10 seconds.

I just wanted to understand how I could make it even more precise.

well my thermostat modules finally arrived so I now have 3 instances SVT running.

1 controlling an electric heater and the other 2 controlling the 2 zone heating for my home. I sort of get the pause button now but would still appreciate any insight into my adjustment of "self.calculate_period" as described above. It seems to have helped smooth out the overshoot but there may be unintended consequences I have not considered.

I am fascinated to see how SVT handles my heating as its wet underfloor heating downstairs as one zone and radiators upstairs as the other both heated by gas boiler. its all working but will have to see how the learning deals with these over the next few days as it does its job.

thank you again for the SVT it certainly seems to be a great tool.

first problem this morning. woke up to a cold house.

not sure what went wrong as the heating mode was correct but the switch had not been activated?

only thing i can see is that i use weather info downloaded from Wunderground for my outside sensor and although its working now
there is an error of no data from a couple of days ago.

is there any better log than the one in the setup menu of Domoticz as it does not go back far enough?

other than this its been working great and so much better than expected. i cant believe how good a job it manages with the underfloor heating which is slower to react so a "normal" thermostat would always overshoot but this works perfectly again great work

opentoideas wrote: ↑Sunday 18 March 2018 8:20 first problem this morning. woke up to a cold house.
not sure what went wrong as the heating mode was correct but the switch had not been activated?

if all the temperature sensors that feed the plugin happen to time out, then the plugin will switch off as for safety. This behavior has been explained in an earlier post. If this is not the case, then we need more info to troubleshoot.

other than this its been working great and so much better than expected. i cant believe how good a job it manages with the underfloor heating which is slower to react so a "normal" thermostat would always overshoot but this works perfectly again great work

You are welcome, glad it works as well for you and others as it does for me.

Logread wrote: ↑Sunday 18 March 2018 18:43 if all the temperature sensors that feed the plugin happen to time out, then the plugin will switch off as for safety. This behavior has been explained in an earlier post. If this is not the case, then we need more info to troubleshoot.

the problem is I don't think I can tell.

I do have a error logged for the wunderground data not updating but if that had been the problem then it should have caused a problem for all 3 instances as they all use the same data for the outside reading and this was not the case. only one of the instances failed to start

any pointers as to how I could troubleshoot? I have since restarted the PC but the problem was the log was only going back about 1 hr and it was 3 hours after the event when I noticed so I had nothing to show where the issue may be.

that Zone did switch from auto to off but I don't know when or why

I may put in a script to check that the system is on each morning as while I like the idea of it defaulting off if a sensor fails I would prefer it to come back on if the sensor reappears after a temporary fault.

opentoideas wrote: ↑Sunday 18 March 2018 19:29

Logread wrote: ↑Sunday 18 March 2018 18:43 if all the temperature sensors that feed the plugin happen to time out, then the plugin will switch off as for safety. This behavior has been explained in an earlier post. If this is not the case, then we need more info to troubleshoot.

the problem is I don't think I can tell.

I do have a error logged for the wunderground data not updating but if that had been the problem then it should have caused a problem for all 3 instances as they all use the same data for the outside reading and this was not the case. only one of the instances failed to start

any pointers as to how I could troubleshoot? I have since restarted the PC but the problem was the log was only going back about 1 hr and it was 3 hours after the event when I noticed so I had nothing to show where the issue may be.

that Zone did switch from auto to off but I don't know when or why

I may put in a script to check that the system is on each morning as while I like the idea of it defaulting off if a sensor fails I would prefer it to come back on if the sensor reappears after a temporary fault.

will switch off for safety, does not start when temperature is updated again ?

tontze wrote: ↑Sunday 18 March 2018 20:52
will switch off for safety, does not start when temperature is updated again ?

I assume not from the prior posts back on page 2 or 3 I think. It seems to stay off after it trips off from loosing a sensor if that is what happened to me. Will try to add a flag somewhere so that I can see that there has been a problem. Dont just want to reset without knowing something went wrong.

To supply weatherunderground with a city name rather than a specific station, you can replace the personal weather station name (pws name) with the name of the city instead. (Amsterdam -> amsterdam_netherlands.
This is described in the wiki on domoticz at the FAQ: https://www.domoticz.com/wiki/Virtual_w ... ces#5._FAQ

Less cool than the direct input of the weather station further down the street, but more consistent. Weatherunderground will use several city pws's to supply the requested weather information. Therefore you are not dependent on the uptime of that single pws.

Yes you can use location rather than a station but even if it does not drop out Domoticz can still give an error if the data is the same for more than 30 min which is what I had.

I dont think this was the problem though as only one instance of SVT stopped and all 3 I have running use the same outside temp so something else must have happened.

Given this is an iot system I think Logread was quite right to make sure it fails safe. I just think the occasional dropout is to be expected so may add a little fault tollerance for my use.

This is minor though and down to preferance. Its what SVT does thats most important and what it does is control heating really, really well

Minimum heating per cycle:

The Domoticz wiki states that the set value will turn on the heater every cycle, even while there is no need for it. I found this strange, especially when the room temperature is above the setpoint, something that will happen most of the time in the summer period.

On the original website, the minimum heating cyle is explained different:
"PowerMin:% minimum heating if the module believes it is necessary to heat (according to the temperature inside and outside)"

Based on the word 'believes it is necessary', I changed the setting to 20% yesterday, because I had seen some very short heating cycles that don't make sense with my floor heating. This morning I was very surprised to see that all night the boiler had been indeed turned on 20% of the time, even while for most of the time, the room temperature > setpoint.

Is this (correctly described) behaviour in Domoticz ideal? I like the described behaviour for the Vera plugin a lot better. I read that one as "if the heater is on, leave it on for the minimum period of time"

jake wrote: ↑Saturday 31 March 2018 10:37 Minimum heating per cycle

Your comment is interesting... When I initially ported the Vera plugin, the logic under domoticz was the same as in the Vera: the minimum heating period being the minimum time a heater is on when heating is required.
However, I changed the logic after discussions with forum user @napo7, who explained the benefit of having his floor heating heat a minimum periodically even if there is a room temperature overshoot (say in on very sunny day in a room exposed to the sunlight) so as to avoid the floor cooling too much and therefore having too high an inertia when heating is needed again (say after sunset).
If you/users of the plugin think it could be beneficial to have both logics available within the configuration of the plugin, I am willing to consider implementing this, though this may add complexity to the configuration parameters, but this will have to wait until after the Easter break I am afraid

Logread wrote: If you/users of the plugin think it could be beneficial to have both logics available within the configuration of the plugin, I am willing to consider implementing this, though this may add complexity to the configuration parameters, but this will have to wait until after the Easter break I am afraid

Having both would be nice, I'd assume another variable in the list of variables in the hardware tab?

The current application might be OK for those hours during the hours that the sun shines in the house, for the the rest of the day it might go way out of control. With the normal thermostat it takes 1.5 hours to compensate for heat loss and increase the temperature +0.5'C. The system then can run for 3, 4 hours without additional heating.

Wording the additional variable might be difficult since the meaning is almost the same, I propose the following:

1: force heating on during every calculation cycle (1, or 0)
2: minimum % heating per cycle (0 to 100)

WIth dzVents LUA scripting I can add a 'checkfirst' to a command, to avoid unnecessary firing of commands to devices that are already in the desired state. At the moment the SVT heater on gets an "off" command every hour, no matter if the heater was "on" or "off". Can you add a check to your code as well?

jake wrote: ↑Saturday 31 March 2018 19:14 Having both would be nice, I'd assume another variable in the list of variables in the hardware tab?

May be not... there might be a possibility to have one more field that could be a drop down with the logic you describe below.

Wording the additional variable might be difficult since the meaning is almost the same, I propose the following:
1: force heating on during every calculation cycle (1, or 0)
2: minimum % heating per cycle (0 to 100)

I like that. Thanks.

WIth dzVents LUA scripting I can add a 'checkfirst' to a command, to avoid unnecessary firing of commands to devices that are already in the desired state. At the moment the SVT heater on gets an "off" command every hour, no matter if the heater was "on" or "off". Can you add a check to your code as well?

I know about that, but without going into details python plugins cannot (by design of the framework, and for valid reasons) access domoticz devices they do not « own » as easily as the events system can. I could have implemented that check-first functionality but at the expense of significant extra coding. Given that this « unnecessary command » is only sent once every calculation cycle (one hour for you it appears), I settled for that imperfect trade-off.
But if you can code in python and are willing to contribute to the GitHub repository of the plugin, please send me a pm and I’ll give you pointers on how to implement this. Alternatively I can implement that myself but this will be low on my priority of projects and my spare time is not as extensive as I wish it were.

Logread wrote: I know about that, but without going into details python plugins cannot (by design of the framework, and for valid reasons) access domoticz devices they do not « own » as easily as the events system can. I could have implemented that check-first functionality but at the expense of significant extra coding. Given that this « unnecessary command » is only sent once every calculation cycle (one hour for you it appears), I settled for that imperfect trade-off.
But if you can code in python and are willing to contribute to the GitHub repository of the plugin, please send me a pm and I’ll give you pointers on how to implement this. Alternatively I can implement that myself but this will be low on my priority of projects and my spare time is not as extensive as I wish it were.

Understood, I didn't know that Python plugins have limited access to Domoticz. I appreciate your invitation, but since I am not a professional coder, I am happy that I can scrape my LUA scripts together. I will leave you to it and understand the low priority for such a thing as preventing the unnecessary 'off' commands.

jake wrote: ↑Saturday 31 March 2018 23:34 I appreciate your invitation, but since I am not a professional coder, I am happy that I can scrape my LUA scripts together. I will leave you to it

It’s a hobby for me. My day job has nothing to do with coding or more generally with IT

That being said, I played with the code while on the go for the Easter break and implemented all these changes.. I still need to test when I am back though and should publish a new version within the next few days.

Thanks, you did a great job already. We'll wait for your testing. 'Playing' with heating of the house is quite different from 'playing' with lights from WAF perspective

New version 0.4.1 is available !

It incorporates the changes discussed by @jake as well as some code clean-up further to the ongoing upgrades to the domoticz plugin framework. Compared to version 0.3.8, the changelog is as follows:

• Passwordless access to domoticz is no longer necessary: you can specify a user/password (thanks to @SoaR245)

• add option to force or not minimum heating per cycle even if target temperature is already reached (thanks to domoticz forum user @jake)

• check heater(s) switch status before an update to avoid issuing unnecessary switching commands (thanks to domoticz forum user @jake)

The wiki at https://www.domoticz.com/wiki/Plugins/S ... ostat.html is updated accordingly

Though the changes have been tested by myself, please exercise caution when upgrading a production system and report any bugs/issues I might have overlooked !