Even if Passive Mode is set to Scheduled/Auto? I would have thought you could advance the schedule still then, but not when in Manual.
This is making me think it was changed before the option to have Passive Auto/Scheduled was added? As it makes sense for Passive Manual.
I may be misunderstanding, but Iâm not sure you are you able to change this for something thatâs already recorded in history and would have to wait for it to record the new data. So Iâm not sure how you are able to compare the two same time periods?
Maybe because they are on 2 different instances of HA?
My test instance and my production instance. Although they are on different versions of Wiser there is no other difference to core
Ah, OK. That makes sense now. 
I will keep an eye on mine and see if I see the same. Iâll let you know once I have more data.
just a quick update, here is my unavailable version as of now
And hers is my undefined for the same.
Iâm not sure if itâs possible, without being a moderator, but maybe we should split this off into a new topic, or open a new topic if itâs not possible? Iâm very aware we are are clogging this up with discussion thatâs not based around the integration itself, that others may not be interested in. Otherwise we can discuss via PM. I will need to gather more data before I can work out whatâs going on though.
So, when you select advance schedule, it looks up the next scheduled temp and sets an override temp to that value. This then runs as an override until the next schedule event. The current scheduled temp is sill the same.
When the passive mode automation runs (whatever mode) on each update, it is setting a temp override in exactly the same way to manage not calling for heat or calling for heat with other active rooms.
Thus as soon as you select advance schedule, the automation will run and reset the target temp based on whether any active rooms or what the current room temp is.
You can test this by calling the set preset service and set Advance Schedule and you will see it wont do anything (it may for a second or 2 while automation and updates run)
I totally agree.
PM me when you are ready
Let me gather some more data and do some investigation. Iâll PM you, or open a new topic and link it here if I canât see a way to split this off like the mods do, when I have a bit more to go on.
Thanks for the explanation. Does this mean that the other options are also redundant, other than maybe Cancel Overrides? Basically what I am asking is are the boosts not also overrides?
No the boosts work and override passive mode. Boost is actually a hub function whereas advance schedule is not.
This is making sense now then. I bet if we looked way back up the thread, and I think I am semi-remembering now, we had a similar conversation before Passive Auto was added. I think the fact that you can have Scheduled Passive Mode is whatâs clouded the issue somewhat
I did not realise (or donât remember if youâve said this before) Advance Schedule was not a native Wiser feature.
Damn, I have not read this topic for a while and there are almost 2000 new posts here. One of the most active topics on the whole community forum.
I have a bit technical question regarding a quirk of the TRVs which I am looking for a solution, or some idea if anybody has experienced it and has some stop gap solution.
I have two TRVs which are sitting idle and closed all the time. Recently I even set them to âOffâ, hoping that the situation will get better, but unfortunately no change.
The problem which I am facing, that this two TRVs tends to get open by themselves, without showing any sign in the change of ârequest to heatâ or anything, and they stuck in this open state/position. The only thing what I can relate, that they tend to have a battery percentage drop at the time when they open, but nothing else. The situation is usually noticed from the temperature as it changes, rises, as the radiator gets hot/warm and it stay that way open.
It is unclear for me, why the TRV opens the valve and why not closes back fully, as it supposed to be. And of course, why is it not recognising that the valve is actually open. It is also unclear what triggers this change. Is it a firmware upgrade, or the battery is weak and it just moves a bit the motor or something, I donât know. Or the spring inside the valve is far too strong and the TRV is just too weak for it.
Has any of you had similar issues like that? How did you solve it?
I am tagging @jamiebennett, as he might have some special idea, knowing the system more than any of us, if he is still with Wiser.
Another question to @msp1974 and @Angelo_Santagata. Is there a way to valve reset a TRV from the integration? That would solve partially my problem posted above. Now I just tell my wife to remove batteries and place them back once the issue happens, and that does the valve reset. But would be better, if I could leave her out from the story. Just to improve WAF.
I have no exact solutions for you, but I have had issues with non-compliant TRVs. In my case this was a sticky valve on the rad. I found this issue by swapping this TRV with another TRV from a rad I had no issues with. Its a ball ache, but was the quickest way I found if it was the rad or the TRV
What is your zigbee network like and do you have any features set like window open or passive mode set?
Window open is set but I have no idea about the passive mode. Do you mean Eco mode by any chance? Then the answer is no.
no, passive mode on the integration.
There is no way in the integration to reset the iTRV. Itâs a manual process at the valve itself.
The most likely culprit is going to be a stiff TRV that the motor is struggling to close. As a starting point I would try freeing them up and lubricating them with WD-40. See this short video.
Just a heads up. I know there have been many releases recently and I apologise for that, but trying to solve some issues that I am not experiencing and it is a bit trial and error.
Anyhow, there will be 1 more release today and then likely thats it for a few weeks.
We definitely seem to have differences in how stable hubs are on wifi (no surprise) but also in how they respond to our http requests. It is also very inconsistant on a hub and across hubs in this. Sending exactly the same request can get a different response at the http level on the same hub. As such, there has been a lot of trial and error and the frequent releases is a result of trying to find the right solution and keep it performant.
So now, the update routine will now do the following:
Previously (v3.4.2 and before) it would just query the hub and fail the update if it did not get a good response. Now it will try multiple things to get the response it is looking for before giving up and failing the update.
I hope that all of this will bring stability to the vast majority and those then still seeing timeout issues will probably need to look at their wifi situation.
If you do continue to see issues, I recommend adding debug logging to the aioWiserHeatAPI in your configuration.yaml to see the detailed logging of what is happening (also something I have been adding in these updates). I will certainly ask you for these logs to look at any issues.
The other major change that has been seen is that entities are going unavailable frequently. This is a function of HA when an update fails if coding as per documented standards (something we also changed on this journey). Whilst it is probably good practice to do this, I think with the known issues of the hub, it makes sense to stop it doing this and just log an update failure as it can appear more of an issue than it is, when entities show that they became unavailable in the logbook.
Hope that clears up the why of all the releases and some of the issues being seen.