Domoticz

Posted: **Sunday 11 April 2021 12:38**

Is there a way ( using scripting ) to update the setpoint for a zone until the next switch point in the schedule? I've been using a HGI80, the integration for which seems to have no concept of scheduled changes, BUT I notice that the web API does show this information. I'd sort of assumed that passing no time until value to a temporary override would work, but it seems not ( you get an error because of an invalid time. )

Posted: **Sunday 11 April 2021 16:14**

Just as a follow-up... I've obtained the/my desired behaviour with this simple patch:

Code: Select all

diff --git a/hardware/EvohomeWeb.cpp b/hardware/EvohomeWeb.cpp
index e2d0262f8..b111617a2 100644
--- a/hardware/EvohomeWeb.cpp
+++ b/hardware/EvohomeWeb.cpp
@@ -445,6 +445,13 @@ bool CEvohomeWeb::SetSetpoint(const char *pdata)
        if ((pEvo->mode) == 2) // temporary override
        {
                std::string szISODate(CEvohomeDateTime::GetISODate(pEvo));
+               if((!pEvo->year) && !pEvo->hrs)
+               {
+                       std::string szsetpoint;
+                       zone* hz = get_zone_by_ID(zoneId);
+                       if ((!hz->schedule.isNull()) || get_zone_schedule(zoneId))
+                               szISODate = local_to_utc(get_next_switchpoint_ex(hz->schedule, szsetpoint));
+               }
                return set_temperature(zoneId, s_setpoint.str(), szISODate);
        }
        return false;

Not sure if this is the best way or if there's already a way to do it?

Posted: **Sunday 11 April 2021 16:50**

sidepipe wrote: ↑Sunday 11 April 2021 16:14 Just as a follow-up... I've obtained the/my desired behaviour with this simple patch:

Not sure if this is the best way or if there's already a way to do it?

Looks good but what do you send to domoticz (API or command) to activate it?

Posted: **Sunday 11 April 2021 17:02**

waaren wrote: ↑Sunday 11 April 2021 16:50 Looks good but what do you send to domoticz (API or command) to activate it?

Just the normal API call for a temporary override but without specifying a time, so for example in dzVents:

Code: Select all

	    domoticz.devices(1873).updateSetPoint(12, "TemporaryOverride")

Posted: **Sunday 11 April 2021 17:50**

sidepipe wrote: ↑Sunday 11 April 2021 17:02 Just the normal API call for a temporary override but without specifying a time, so for example in dzVents:

I applied your patch and tried the command but it does not work on my system. It shows something like below until the next cycle and then return to the schedule known to evoHome.

: temperature.jpg (18.03 KiB) Viewed 2076 times

Posted: **Sunday 11 April 2021 18:14**

waaren wrote: ↑Sunday 11 April 2021 17:50 I applied your patch and tried the command but it does not work on my system. It shows something like below until the next cycle and then return to the schedule known to evoHome.

Odd... That time is completely invalid, so it should generate an error in the existing code anyway by the looks of it. To be honest I don't know too much about the workings of the Domoticz code and am not a c++ programmer, so I wouldn't be surprised if there's a glaring error in what I've done, but having said that similar code to the code I've used is used elsewhere, the main thing i wasn't sure about was how to know when there's no time passed in.

I'd suggest you add a log line or two to try to work out what's going on ( unless someone who knows the code better than I can jump in. ) If you need this functionality and can't see what's happening then drop me a message and I can give you some pointers to try to debug it. I'm assuming the device ID you're passing is the one for the setpoint from the web API rather than from anywhere else ( such as the scripts or a hgi80? ) Only the web API one will work.

Posted: **Sunday 11 April 2021 18:29**

waaren wrote: I applied your patch and tried the command but it does not work on my system. It shows something like below until the next cycle and then return to the schedule known to evoHome.

temperature.jpg

Actually I've just spotted something strange.... I was looking at my hgi80 device, which works... Ie I update the equivalent web API device and observe on the hgi80 version... and all seems well. However, if I look at the web API device it's messed up in the same way yours is. I'm afraid I don't know enough about the code to know why that might be. It's worth checking your Honeywell app, or the controller itself, because both of those are correct for me too, it's just the web API Domoticz device that's wrong.

Edit: the web API device then fixes itself next time it's read from the server.

Sent from my SM-F916B using Tapatalk

Posted: **Sunday 11 April 2021 19:00**

sidepipe wrote: ↑Sunday 11 April 2021 18:29 Edit: the web API device then fixes itself next time it's read from the server.

I have the web API and the until time get removed in the next cycle but the fix set it to the state set by my schedule.
The domoticz code has no information on the date/time of the next switch time.

Posted: **Sunday 11 April 2021 20:03**

waaren wrote: ↑Sunday 11 April 2021 19:00 I have the web API and the until time get removed in the next cycle but the fix set it to the state set by my schedule.
The domoticz code has no information on the date/time of the next switch time.

Ok, I've found the issue - hadn't realised I needed to write the updated values back to the pEvo struct for the local version of the update to work correctly. Hopefully the below will work for you.

Code: Select all

diff --git a/hardware/EvohomeWeb.cpp b/hardware/EvohomeWeb.cpp
index e2d0262f8..2bc8af09e 100644
--- a/hardware/EvohomeWeb.cpp
+++ b/hardware/EvohomeWeb.cpp
@@ -445,6 +445,22 @@ bool CEvohomeWeb::SetSetpoint(const char *pdata)
        if ((pEvo->mode) == 2) // temporary override
        {
                std::string szISODate(CEvohomeDateTime::GetISODate(pEvo));
+               if((!pEvo->year) && !pEvo->hrs)
+               {
+                       std::string szsetpoint_tmp;
+                       if ((!hz->schedule.isNull()) || get_zone_schedule(zoneId))
+                       {
+                               szISODate = local_to_utc(get_next_switchpoint_ex(hz->schedule, szsetpoint_tmp));
+                               if (!szISODate.empty())
+                               {
+                                       pEvo->year = (uint16_t)(atoi(szISODate.substr(0, 4).c_str()));
+                                       pEvo->month = (uint8_t)(atoi(szISODate.substr(5, 2).c_str()));
+                                       pEvo->day = (uint8_t)(atoi(szISODate.substr(8, 2).c_str()));
+                                       pEvo->hrs = (uint8_t)(atoi(szISODate.substr(11, 2).c_str()));
+                                       pEvo->mins = (uint8_t)(atoi(szISODate.substr(14, 2).c_str()));
+                               }
+                       }
+               }
                return set_temperature(zoneId, s_setpoint.str(), szISODate);
        }
        return false;

Posted: **Sunday 11 April 2021 21:15**

sidepipe wrote: ↑Sunday 11 April 2021 20:03 I now get a
Code: Select all
Error: (Evohome) ignored zone temperature override because of invalid 'time_until' value
When I send
Code: Select all
SetSetPoint:489 = 12#TemporaryOverride 
or
Code: Select all
SetSetPoint:489 = 12#TemporaryOverride#nil
from dzVents

Posted: **Sunday 11 April 2021 21:27**

waaren wrote:
sidepipe wrote: ↑Sunday 11 April 2021 20:03 I now get a
Code: Select all
Error: (Evohome) ignored zone temperature override because of invalid 'time_until' value
When I send
Code: Select all
SetSetPoint:489 = 12#TemporaryOverride 
or
Code: Select all
SetSetPoint:489 = 12#TemporaryOverride#nil
from dzVents

Not sure what those code fragments represent? The validation is performed on the string which hasn't changed since the original version, so presumably you're doing something different to what you were?

Sent from my SM-F916B using Tapatalk

Posted: **Sunday 11 April 2021 22:12**

sidepipe wrote: ↑Sunday 11 April 2021 21:27 Not sure what those code fragments represent? The validation is performed on the string which hasn't changed since the original version, so presumably you're doing something different to what you were?

The SetSetPoint lines are from dzVents debugging in the log.
the one with nil is the original and the other one is stripping the # and untildate completely out. Maybe the diff you send is not the complete change to the cpp file?
Can you please share the complete one (or even better create a PR against domoticz development branch so it can be easily tested?

Posted: **Sunday 11 April 2021 22:35**

waaren wrote: ↑Sunday 11 April 2021 22:12
The SetSetPoint lines are from dzVents debugging in the log.
the one with nil is the original and the other one is stripping the # and untildate completely out. Maybe the diff you send is not the complete change to the cpp file?
Can you please share the complete one (or even better create a PR against domoticz development branch so it can be easily tested?

Definitely is the whole thing... Really is quite a small patch, and definitely works for me... missing out the third parameter to the function completely... I.e.

Code: Select all

domoticz.devices(123).updatesetpoint(12, "TemporaryOverride")

Don't have any time to look more now and looking on my phone so it's possible there's something wrong but can't see what.

Posted: **Sunday 11 April 2021 23:33**

sidepipe wrote: ↑Sunday 11 April 2021 22:35 Definitely is the whole thing... Really is quite a small patch, and definitely works for me... missing out the third parameter to the function completely... I.e.
Code: Select all
domoticz.devices(123).updatesetpoint(12, "TemporaryOverride")

the updateSetPoint method for evoHome setpoint devices is handled by below function in the device-adapter evohome_device.lua

Code: Select all

function device.updateSetPoint(setPoint, mode, untilDate)
				return TimedCommand(domoticz,
					'SetSetPoint:' .. tostring(device.id),
					tostring(setPoint) .. '#' ..
					tostring(mode) .. '#' ..
					tostring(untilDate) , 'setpoint')
			end

If you give the above updaetSetPoint command, dzVents does send

Code: Select all

SetSetPoint:123 = 12#TemporaryOverride#nil

in the commandarray back to domoticz

Posted: **Sunday 11 April 2021 23:39**

waaren wrote: ↑Sunday 11 April 2021 23:33
the updateSetPoint method for evoHome setpoint devices is handled by below function in the device-adapter evohome_device.lua

I don't believe that's used at all for the web API version of the EvoHome hardware... only the old script stuff. I might be mistaken - certainly no expert, but as I said it works for me so...

Posted: **Monday 12 April 2021 0:26**

sidepipe wrote: ↑Sunday 11 April 2021 23:39 I don't believe that's used at all for the web API version of the EvoHome hardware... only the old script stuff. I might be mistaken - certainly no expert, but as I said it works for me so...

I wrote that part of dzVents so I am pretty sure it is used when you give the updateSetPoint command.
You can verify the command send by dzVents to domoticz by activating debug logging for dzVents

Also tried it with the API

Code: Select all

http://<domoticz IP:domoticz port>/json.htm?type=setused&idx=489&setpoint=12&mode=TemporaryOverride&used=true

result

{
   "status": "OK",
   "title": "SetUsed"
}

but in the domoticz log

Code: Select all

2021-04-12 00:45:07.471  Error: (Evohome) ignored zone temperature override because of invalid 'time_until' value

Again please share the complete modified source file or prepare a PR so it can be tested.

Posted: **Monday 12 April 2021 8:12**

waaren wrote: ↑Monday 12 April 2021 0:26 I wrote that part of dzVents so I am pretty sure it is used when you give the updateSetPoint command.

You'd know then...

waaren wrote: ↑Monday 12 April 2021 0:26 Also tried it with the API

Ok, I also tried with the API and got the error ( but dzVents works for me. ) I obviously made the mistake of assuming that the pEvo struct date fields were zeroed if no until time was specified ( since they appeared to be for me ) but adding a quick debug log shows that not to be the case - when I run from the API for my test year is indeed 0 but hrs is 168, meaning that my additional code doesn't run because it assumes an until date was specified.

I could spend hours trying to work out how these parameters are passed and where they're initialised - do you know how/where that happens? What I need is some way to check to see if an until date was actually specified or not from within CEvohomeWeb::SetSetpoint

waaren wrote: ↑Monday 12 April 2021 0:26 Again please share the complete modified source file or prepare a PR so it can be tested.

As I say, no point really because the patch I posted was the whole thing ( and the above is obviously why it didn't work. ) I didn't want to make a PR at this point because I suspected there might be something glaringly wrong and thought someone in a position to quickly check it might be better first ( and thanks for doing that. ) If you can point me to where in the code the pEvo struct is generated in the first place so I can at least zero the uninitialised fields then that would help... then I'll sort a PR once it seems to work.

Posted: **Monday 12 April 2021 8:51**

sidepipe wrote: ↑Monday 12 April 2021 8:12 I could spend hours trying to work out how these parameters are passed and where they're initialised - do you know how/where that happens? What I need is some way to check to see if an until date was actually specified or not from within CEvohomeWeb::SetSetpoint

Sorry but I am not fluent in c++. Maybe @brucemiranda can help you out?

Posted: **Monday 12 April 2021 9:33**

waaren wrote: ↑Monday 12 April 2021 8:51 Sorry but I am not fluent in c++. Maybe @brucemiranda can help you out?

No worries... if nobody chimes in I'll see if I get a chance to load the code in an IDE which should help. I think this is a useful addition ( at least for me

) so I'll see what I can do.

Thanks for taking the time to try it out.

Posted: **Monday 12 April 2021 10:56**

Ok, that took less time than I'd feared. Turns out it was exactly what it looked like - there was a bug which meant some uninitialised values were used.... didn't matter if you assumed an until time was always given other than the very slim chance that a valid date could randomly appear!

I'll sort out a pull request because hopefully this is ok now and useful to people who still want to control their schedule with EvoHome but with the occasional override from Domoticz. For me, I'm now on a time of use electricity tariff, so if using a heat pump is cheaper than natural gas because the cost per kWh is reasonable OR my solar PV is making up the difference, I'll lower the EvoHome setpoint and turn on the air source heat pump in a room.... it's pretty cool what you can do when everything is linked

Whilst I'm sorting the PR, here's the updated patch if you want to give it a go:

Code: Select all

diff --git a/hardware/EvohomeBase.h b/hardware/EvohomeBase.h
index 9366e0c3f..cbc2d3d67 100644
--- a/hardware/EvohomeBase.h
+++ b/hardware/EvohomeBase.h
@@ -390,6 +390,8 @@ class CEvohomeDateTime : public CEvohomeDataType
        template <class T> static void DecodeISODate(T &out, const char *str)
        {
                unsigned int y, m, d, h, n;
+               if(!str[0])
+                       return;
                sscanf(str, "%04u-%02u-%02uT%02u:%02u:", &y, &m, &d, &h, &n);
                out.year = static_cast<uint16_t>(y);
                out.month = static_cast<uint8_t>(m);
diff --git a/hardware/EvohomeWeb.cpp b/hardware/EvohomeWeb.cpp
index e2d0262f8..2bc8af09e 100644
--- a/hardware/EvohomeWeb.cpp
+++ b/hardware/EvohomeWeb.cpp
@@ -445,6 +445,22 @@ bool CEvohomeWeb::SetSetpoint(const char *pdata)
        if ((pEvo->mode) == 2) // temporary override
        {
                std::string szISODate(CEvohomeDateTime::GetISODate(pEvo));
+               if((!pEvo->year) && !pEvo->hrs)
+               {
+                       std::string szsetpoint_tmp;
+                       if ((!hz->schedule.isNull()) || get_zone_schedule(zoneId))
+                       {
+                               szISODate = local_to_utc(get_next_switchpoint_ex(hz->schedule, szsetpoint_tmp));
+                               if (!szISODate.empty())
+                               {
+                                       pEvo->year = (uint16_t)(atoi(szISODate.substr(0, 4).c_str()));
+                                       pEvo->month = (uint8_t)(atoi(szISODate.substr(5, 2).c_str()));
+                                       pEvo->day = (uint8_t)(atoi(szISODate.substr(8, 2).c_str()));
+                                       pEvo->hrs = (uint8_t)(atoi(szISODate.substr(11, 2).c_str()));
+                                       pEvo->mins = (uint8_t)(atoi(szISODate.substr(14, 2).c_str()));
+                               }
+                       }
+               }
                return set_temperature(zoneId, s_setpoint.str(), szISODate);
        }
        return false;

Domoticz

Temporary Override Until Next Switchpoint

Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint

Re: Temporary Override Until Next Switchpoint