Can you log this for me on github and provide a diag so I can test. Won’t be urgent fix (and I know youre not asking), but thanks.
How often does the sensor.wiser_heating update.
I can hear the heating kicking in, but it feels quite a while for it to actually register a state change?
Thanks
The default is every thirty seconds for the hub, but the update interval can be set in the integration configuration, in case you changed it from the default?
Ok, firstly sorry for the issues with v3.4.4.
I have (hopefully) fixed these in v3.4.5 that has just been released.
2 Likes
Okay thanks.
It looks like it’s set to the default 30 seconds, however I’m positive this takes multiple minutes to see changes. Sometimes it comes on and off and I never see the state change.
Is there any point changing it to less than 30 seconds or are there restrictions how often the wiser hub can update.
Thank you 
Personally I wouldn’t reduce the refresh below 30 seconds. There is a possibility of overwhelming the hub with requests.
1 Like
30s should be ok, as @robertwigley said, you can go lower but if it is taking minutes, then I don’t think this is the issue.
Are you seeing any update errors in your logs? It maybe that the hub is dropping off wifi frequently.
EDIT: maybe also any json decode errors before v3.4.4. v3.4.4 attempted to fix an issue for a few people who were reporting these errors and (without going into the dark technical world I found myself trying to fix this) this will also fail an update.
2 Likes
@msp1974 Sorry to bring up another issue. I’m sure @Duke_box will notice it soon enough though. 
It looks like it was introduced in 3.4.5 while fixing the Preset Mode slider icon issue under Passive Mode, which is fixed. 
The “Advance Schedule” preset option has disappeared, but only under Passive Mode. I can open a GitHub issue if you want me to?
Yep, I noticed that on 3.4.4 but didn’t give it much thought as I assumed it didn’t apply to Passive ( I don’t use schedules for Passive).
Edit. Advance Schedule option doesn’t appear to be there for Passive.
I can’t find it in v3.4.3, 3.4.4 or 3.4.5
I think you are correct. 0C produces strange results in the History Explorer card.
Edited it back toundefined- see what tomorrow brings
I wonder if this should now be changed to be unavailable. When Alex said to use undefined I don’t think we had the changes in the UI that made unavailable states invisible in history.
I’ll test this and see.
I believe i tried this and undefined was the only option that produced the bars. Unavailable and 0C gave the fill under the graph as a curve.
The thick lines before 18:00 are when set to 0C, the curved bit after 18:00 is unavailable and the rest are after I set it back to undefined.
1 Like
Is there nobody using the CCRFR6400 without Wiser’s hub?
unavailable seems to be working the same as undefined for me. I changed it this afternoon and the heating came on to react to the half degree rise in temperature at 18:00. The fill on the graph looks the same to me.
The only difference between your code and mine (other than I have a separate binary sensor for designating it being on or off) is I haven’t set unit_of_measurement: °C.
I removed the UOM when I realised it was causing the template to give incorrect results in the graph. So I then started to narrow it down by just changing the “else” statement.
If your getting good results I’ll try it again.
Thanks for the feedback
Probably not on this thread as it is for the integration which relies on the hub. There is another thread somewhere where there are discussions about using it with ZHA and z2mqtt
1 Like
This was how it worked before as i also noticed this. I cant exactly remember why we took it off in passive mode and i cant either think of a good reason why we would as i think you could advance the schedule in passive mode?
If you open a git issue (i mean i am trying to clear them as fast as they are being logged! 
), we can add this back.
2 Likes
I have added the UOM in and my graph completely fails to display with it set.
I will keep an eye on it, but so far unavailable seems to be working. I doubt it would have worked before the change to history (when this was originally written).
Just in case it’s configuration of the card, here’s an except of the code I am using for my graph:
graphs:
- type: line
entities:
- entity: sensor.living_room_climate_temperature
name: Temperature
- entity: sensor.living_room_climate_target_temperature
name: Target Temperature
lineMode: stepped
color: orange
- entity: sensor.living_room_heating_graph
name: Living Room Heating
color: rgba(205,62,62,0)
fill: rgba(205,62,62,0.5)
Sorry Mark. I know you’re trying to clear them and they seem to be getting opened as fast as you’re closing them today.
I can’t see a reason for it not being available under Passive Mode either. I also can’t remember a reason for it being removed and would also assume you can advance the schedule still. I’m not able to test it though, as the option is not available to do so.
I’ll open an issue then. It’s certainly not urgent.
Ive just had a moment of clarity. You cant have advance schedule in passive mode as it is not a real function but sets an override of the target temp to the next schedule temp. Passive mode will then just override this.
1 Like
Hi
So this is what my graph looks like with the template {% else %} set to unavailable
And this is what it looks like with undefined
Caveat: the first is running on HA 2024.2.5, wiser v3.4.5. the second is running on HA 2024.2.5, wiser v 3.4.3
I know that the Conservatory wasn’t calling for heat all the time it shows it was in the first image.
And here is the stock history graph that shows the same period.
Here’s my code snippet which isn’t much different to yours.
graphs:
- type: line
entities:
- entity: sensor.conservatory_target_temp
lineMode: stepped
color: darkorange
- entity: sensor.conservatory_temp
color: rgb(0,0,255)
fill: rgba(30,144,255,0.075)
- entity: sensor.conservatory_heat_graph
fill: '#f08080
EDIT: replied to myself which was dumb!