I had high hope that this might have changed…
Re: iTRV not closing.
See my post 2980 for some info.
Having re-read that post, I may not have made sufficiently clear.
Final sequence:-
Do iTRV re-calibration.
Unscrew / remove it.
Put the 1mm shim in place. (Bluetac works wonder for holding in place).
Replaced the iTRV.
Do NOT do another re-calibration.
That was November last year and it is still ok now.
Good luck.
1 Like
I did something similar before in another case, but did the calibration without without screwing the iTRV fully in and after screwing in completely. The result was kinda the same.
I haven’t done this yet again for the valve, as I remember, I did it before.
The main issue is, why the iTRV is getting loose without opening or anything, and why is it unable to close. Obviously the valve is not stuck, because it opens and closes, but most likely the spring is far to tought for the iTRV. I feel that the iTRV is not calibrating correctly, and that causes this issue. And meanwhile the iTRV is not recognising that it has opened the valve. I hope you get what I mean. That’s why a remote valve reset would be great, hence the reason I tagged @jamiebennett as well.
Just to come back on this issue I was having in case it crops up for someone else.
I guess there must have been some changes that I didn’t read up on before upgrading, but the issue seems to be down to the schedules now requiring quote marks for time values, and no longer accepting “off” for temp values.
The requiring quote marks for times after 10:00 has been around quite a while due to yaml changes in HA.
Not aware of the off issue, that maybe new. Are you using “Off”? It looks like case sensitive which maybe not ideal.
Way to test is download one that has an off setting and try and reupload.
1 Like
I was previously using “Off”.
When I download a schedule that had an off setting it was coming in as -20 instead.
Hmm, dont recall that this has changed in a long time but looking at code does look like it downloads -20 but accepts upload of -20 or Off.
Not able to look at this for a bit so just use -20 for now if Off not working and i will investigate and fix for next release.
Would you mind raising github issue to remind me. Thanks
HI,
Has anybody else had an issue since the latest update? I skipped a couple of updates, not sure what one I was at before this but was always working fine. Now I get a “failed to setup, will retry”
In the log
"Logger: androidtv.adb_manager.adb_manager_async
Source: components/androidtv/init.py:123
First occurred: 12:15:44 (6 occurrences)
Last logged: 12:18:58
Couldn’t connect to 192.168.68.110:5555. TcpTimeoutException: Connecting to 192.168.68.110:5555 timed out (1.0 seconds)"
" Logger: custom_components.wiser.coordinator
Source: custom_components/wiser/coordinator.py:187
integration: Drayton Wiser Integration for Home Assistant (documentation, issues)
First occurred: 12:16:03 (5 occurrences)
Last logged: 12:18:54
I can confirm the the wiser app is runniggfine. I restarted home assistant a couple of times but no joy. I didn’t change any setting since the update.
EDIT: THis seemed to sort itself out when I forgot about it for a couple of hours!
Thanks
Hi,
I’ve been trying to create a sensor to display for how many hours the heating (any TRV has been on. I’m using the code below but it seems stuck at 0. Does anyone have any ideas?
- platform: history_stats
name: Heating On Today
entity_id: sensor.wiser_heating
state: "on"
type: time
start: "{{ now().replace(hour=0, minute=0, second=0) }}"
end: "{{now()}}"
I have this, which works
- platform: history_stats
name: Kitchen radiator heating
entity_id: input_boolean.kitchen_radiator
state: "on"
type: time
start: "{{ now().replace(hour=0, minute=0, second=0) }}"
end: "{{ now() }}"
I had to creat a boolean with an automation though. This is the heating
- platform: history_stats
name: Heating on Today
entity_id: sensor.wiser_heating
state: "On"
type: time
start: "{{ now().replace(hour=0, minute=0, second=0) }}"
end: "{{ now() }}"
1 Like
Thanks, I feel really silly, I got caught by case! Changing “on” to “On” and the whole thing worked!
I suspected that, it catches me out all the time
Dear Mark P,
Thank you so much for your work on this integration, its the reason I DIY’d the drayton wiser, I’ve got the kiosk tablet on the wall etc. really great work.
So I took the next step and ordered 5 i trv’s for the upstairs of my 2 zone gas CH system.
Because the rads are on external walls, the i trvs are reporting about 3 degrees LOWER in standby than the ambient temp as measured by my external thermostats (most people seem to have the opposite problem).
I’m looking at your recipe to solve this wiserHomeAssistantPlatform/recipes/manage_temps_v2.md at dd47434d9c567edffea6d768d5fd85ab237403cf · asantaga/wiserHomeAssistantPlatform · GitHub
Would this work?
A related question - anyway to have the thermostat card reflect the external thermostat rather than the i trv one?
Thank you
I dont think so. As you say, most peoples issue is that it reports higher than the room temp and this script keeps boosting until and external sensor reaches the scheduled temp value.
I assume by external thermostat you are talking about a non Wiser one. You could create a template climate sensor and use this external value rather than the one from the TRVs, however it will not make any difference to the functioning of the trv and may look confusing why the room is not heating when it is below the target temp.
Whilst costly, your best solution for this situation is to have roomstats in each room also. They override the TRV current temp value and will ensure your rooms heat to the correct temp (assuming good placement of course!)
2 Likes
I’m trying to catch up on changes in order to use my Wiser Smart Plugs to control lights but am seeing ‘This entity is no longer being provided by the wiser integration’. Has all control functionality been removed?
No, they should all work fine. Do you have any errors in the logs. Have you checked in the devices and services → drayton wiser pages that they havent changed name?
Thanks, it looks like it’s a naming problem:
For example, those without the ‘_2’ appended show the ‘This entity is no longer being provided by the
wiser integration’ error (despite no deliberate renaming by myself?):
switch.wiser_wiser_smart_plug_2_away_mode_turns_off_2
switch.wiser_wiser_smart_plug_2_away_mode_turns_off
switch.wiser_wiser_smart_plug_2_switch_2
switch.wiser_wiser_smart_plug_2_switch
Oddly, both of these elicit the error:
switch.wiser_drayton_wiser_smart_plug_switch
switch.wiser_drayton_wiser_smart_plug_switch_2
Thanks Mark P, frustrating, the 500 euros for stats in every room is not an option right now - the money should really go on better insulation. The inclusion of an offset in the functionality would seem to be an fairly good option but doesn’t seem to be forthcoming from Drayton. I might just go with lower target temps for now. Thanks again.
If you give me a few weeks (not in the country right now), i can probably work out a similar automation to handle this situation.
You could just delete the no longer available entities and then renane your _2 ones.