I'm using a relatively recent version of Domoticz ( Compile Date: 2023-07-31 10:10:02, dzVents Version: 3.1.8 ) but this has been going on for some time ( not sure when it started or if it has always been the case. ) I also don't know if it's a problem with the core Domoticz code or dzvents itself ...

Just in case anyone's interested, I wrote this little script to take data from forecast.solar and feed into 24 sensors which represent the forecasted output for each of the next 24 hours ( so you end up with 24 graphs, the first an hour ahead, then two, etc etc. ) It uses the first level paid for ...

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 ...

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 :D ) so I'll see what I can do. Thanks for taking the time to try it ...

I wrote that part of dzVents so I am pretty sure it is used when you give the updateSetPoint command. You'd know then... :D 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 ...

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 ...

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 ...

I now get a Error: (Evohome) ignored zone temperature override because of invalid 'time_until' value When I send SetSetPoint:489 = 12#TemporaryOverride or SetSetPoint:489 = 12#TemporaryOverride#nil from dzVents Not sure what those code fragments represent? The validation is performed on the string ...

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 ...

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 ...

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 ...

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:

Just as a follow-up... I've obtained the/my desired behaviour with this simple patch: 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 ...

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 ...

I've got a similar problem with a phantom node that's "sleeping," so OZW never tries to send messages to it, it just queues them. It's been an issue for a very long time as far as I can tell. Also, it seems the zwcfg_xxxx.xml file no longer exists? Is there an equivalent workaround that can be used?

Do I need to make any other changes apart from https://github.com/domoticz/domoticz/pull/2864/files and restart domoticz? No, but bear in mind you might have cache issues. I'm not sure what the best way to clear the cache for a given page is, but on Chrome I did the following: Go to the hot water ...

Ok, found the error and submitted a pull request.

It seems like it has the wrong data type. It shows % instead of temperature. Yep, so it looks as though the device was created with incorrect parameters by the EvoHome subsystem. Question is, how do I fix it? I've had a quick look at the database and it does seem to be recording the information ...

In reality you have many options if you're willing to put the effort in. You could use a Z-Wave boiler relay and thermostat for example, though a better bet would be to also use controllable TRV's. I once spent ages writing control routines for multi-zone heating using Z-Wave TRV's, thermostats and ...

I've been using EvoHome via an HGI80 for some time now and have to say the integration's been brilliant. However, I've just added the hot water kit, which includes a temperature sensor for the cylinder. The sensor's showing up in Domoticz, but there's no log. This is the same on the "devices" tab or ...