At the moment the name is case sensitive so must match what you called it exactly. I know on the buttons on the front page we capitalise these but think we dont if you go into the schedule. We may need to make it case insensitive.
I would also say, it is possible to have more than 1 schedule with the same name which could give unpredictable behaviour. I’ll look at how we make this simpler before final release of 3.2.
We could look at an alternate layout option. We chose this layout as the card can be very long as a list with many schedules but if you do not have many then this is a workable alternative.
Thanks for the explanation, agree case insensitive would be ideal.
Hadn’t thought about clashing names as it wasn’t something I thought would make sense but now you mention it, good point. Users would need to be aware that if you go with case insensitive you can’t have two names that only differ by case as well.
Understand, perhaps another option is to show the ID before the name but keep the cloud style? So have the text as ID:name. Would enable people to quickly see the ID number on this screen.
@msp1974
I’m back testing the last 3.2 beta3
Schedules : I only use your schedule card for that, as it so easy of use, awesome!
my start situation: 4 shutter have the same schedule
I want to assign this schedule to the fifth as in the previous release
Extract of the frame (wireshark):
Explain more the issue?
@msp1974, the issues on lights and shutters are fixed with the v3.2.3 beta3 as the log file from the hub is OK now
Sorry for not be clear Mark.
I was testing the schedule card.
My origin situation was as shown in the first screen copy (4 shutters with the same schedule).
I want to assign the same schedule to the fifth (as we can do it in the previous release 3.1.7) and then this action (select) the “volet” erase the schedule for the 4 other shutter, result in the second screen copy.
In a simpler way, it’s no more possible to assign the same schedule to more than one device (maybe it would have been more understanding expressed this way)
Ok, let me have a look at that.
3.2.0beta working great for me now – thanks Mark!
Unfortunately I had two two-hour hub dropouts last night though (one lasted 1hr 59 min, 55 sec, the other 1hr 59 min, 56 sec according to ping). I have noticed that there seems to be a correlation with TRV battery level – when the hub drops out for two hours like this, the battery level on one or more TRVs is lower afterwards. This raises two possibilities: perhaps the hub drops out and then the TRVs waste their batteries trying to communicate it, or perhaps the TRV-hub link gets into a bad state that wastes the TRV batteries and also crashes the hub.
@LGO44 can you try beta4. The different ids needed for lights and shutters continues to cause me confusion!
There has been a change to TRV battery level reporting in this 3.2.0beta. We made a change before due to an issue and I think we got the % remaining slightly too high (we convert from voltage of battery from hub). As such, we have dropped it a little when the battery is low.
Original (volts v %)
{ 3.0:100, 2.9:80, 2.8:60, 2.7:40, 2.6:30, 2.5:20, 2.4:10, 2.3:0 }
Now
{ 3.0: 100, 2.9: 80, 2.8: 60, 2.7: 40, 2.6: 20, 2.5: 10, 2.4: 5, 2.3: 0 }
Good to know. I think it doesn’t explain my battery drops which have all been from 100% to 80% (I have owned the system only for a few weeks).
The issues are fixed by this beta4
I’m sorry to answer you so late but I have had an alteration of my database (historics…)
I have made another test on beta4:
I have deleted the Wiser integration
and try to reinstall it
The integration asks me the IP address of the hub and the secret key
the answer is
When the system discover the integration when I give the secret key the response is
What is my mistake or is it an issue?
here are the logs:
2022-10-22 18:28:10.269 INFO (SyncWorker_7) [aioWiserHeatAPI] WiserHub API v0.1.4 Initialised - Host: 10.0.0.18, Units: Metric
2022-10-22 18:28:10.289 ERROR (MainThread) [custom_components.wiser.config_flow] Unknown error connecting to Wiser Hub
Traceback (most recent call last):
File “/config/custom_components/wiser/config_flow.py”, line 158, in async_step_zeroconf_confirm
validated = await validate_input(self.hass, user_input)
File “/config/custom_components/wiser/config_flow.py”, line 56, in validate_input
wiser = await hass.async_add_executor_job(
File “/usr/local/lib/python3.10/concurrent/futures/thread.py”, line 58, in run
result = self.fn(*self.args, **self.kwargs)
File “/usr/local/lib/python3.10/site-packages/aioWiserHeatAPI/wiserhub.py”, line 107, in init
self._wiser_rest_controller = _WiserRestController(
File “/usr/local/lib/python3.10/site-packages/aioWiserHeatAPI/rest_controller.py”, line 54, in init
session = aiohttp.ClientSession()
File “/usr/local/lib/python3.10/site-packages/aiohttp/client.py”, line 227, in init
loop = get_running_loop(loop)
File “/usr/local/lib/python3.10/site-packages/aiohttp/helpers.py”, line 288, in get_running_loop
loop = asyncio.get_event_loop()
File “/usr/local/lib/python3.10/asyncio/events.py”, line 656, in get_event_loop
raise RuntimeError(‘There is no current event loop in thread %r.’
RuntimeError: There is no current event loop in thread ‘SyncWorker_7’.
It has no trace on wireshark from HA to the Hub.… so that make me think about an issue
Noob question, is there a way to see how many hours each zone/hot water has been on each day?
You can create a sensor using the history_stats platform:
- 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() }}"
There are more examples in the recipes folder for this integration.
Hi, I’ve been using your integration for a while now, I’ve recently noticed with the latest version that the hot water boost function does not appear to be working, I have had it so it works with an automation with my shower pump, so when the shower pump is on the hot water is boosted by 30minutes but recently it has not been working 
Just to say, the latest version is still a beta release and there could be a few things not yet working. In the backend this is a significant rewrite and restructure of a lot of code and basically, I make a lot of mistakes! 
I am aware of this issue and will be releasing an update that will fix it tomorrow, along with the errors when configuring the hub raised by @LGO44 and a few other things I have found while testing.
You can go back to v3.1.7 for now if you want as downgrading should still work.
Thanks for raising.
@msp1974 
, it’s not a problem for me I have a test platform on a virtual machin and a raspberry platform to use HA, so no consequence…
Bugs in a beta version is normal. Testing your beta versions is my way to contribute to the evolution of our preferred integration.
Only those who do nothing, make no mistake