Better us the release files, in the zip-file here: Release Fixes to make selecting work · plugwise/plugwise-beta · GitHub
Ok, I have it installed an will be using it for the coming days. So far it looks fine (but it looked fine before that to me as well). Switching schedules works and I see no errors in the log or obvious issues out of the gate.
Good news, thanks for the testing feedback 
I have put a select in one of my views and I’m getting the following error every now and then while opening the interface (but definitely not every time I open the GUI):
Logger: homeassistant.components.websocket_api.http.connection
Source: components/select/__init__.py:53
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 09:09:48 (3 occurrences)
Last logged: 15:59:17
[139903112970048] Option not valid for Lisa Woonkamer Select Schedule
[139903043889952] Option not valid for Lisa Woonkamer Select Schedule
[139903045840960] Option not valid for Lisa Woonkamer Select Schedule
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 192, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1636, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1673, in _execute_service
await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 668, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 931, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 705, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/select/__init__.py", line 53, in async_select_option
raise ValueError(f"Option {option} not valid for {entity.name}")
ValueError: Option not valid for Lisa Woonkamer Select Schedule
It looks like it is trying to set an empty option for some reason, not sure why. To be clear, I’m not trying to change the schedule at all.
I’ll have a look, I think I know what’s wrong.
Please test v0.22.0a6, looks like it’s working over here.
Please note: this update also adds a means to set the maximum boiler setpoint:
Don’t use the slider, it’s not accurate.
Click on the thermometer icon, then click on the control icon (3 sliders) and then it shows a better means to set.
Sadly my boiler for some reason doesn’t report the maximum setpoint to the adam (I can only change it by hand), so I can’t test that function. I haven’t seen the error with the select again, so that appears to be fixed.
Ok, yes, the OpenTherm communication by Plugwise is not great.
Also, thanks for retesting, good to hear that the schedule selections now works
Sorry, I’m back with more bug reports (although I’m unsure if one is even related) 
- Somehwere laong the day the
selectsomehow returned to an empty state (it had no schedule even though it was set) and the error returned in the log. The error wasn’t shown on the GUI however. - It has been quite warm here so my heating has been off for more than 24h. I have a switch that controls the pump of my floor heating. I’m getting spammed with global hass notifications that plugwise will run the pump for 2 minutes to prevent rust and blockages. This happened correctly, but somehow the message is ‘stuck’ (i didn’t receive it at all before and this situation already happened before as well). If I dismiss it it will come back in a few seconds.
[edit] I just went back to my GUI and the select was again set to empty, this time with the error, so I must’ve missed it before.
No problem, I’m glad that you are testing
Regarding the select error, please post the error-text that is shown in the LOGBOEK. Hopefully it contains a pointer to what’s wrong.
Regarding the spamming, I haven’t noticed this yet myself.
But it could be that the message is still present on the Smile. As long as it is present on the Smile, it will be displayed in HA. Once the message has disappeared from the Smile, then you can press DISMISS and it won’t return.
It is the same error as before:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 192, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1636, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1673, in _execute_service
await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 668, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 931, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 705, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/select/__init__.py", line 53, in async_select_option
raise ValueError(f"Option {option} not valid for {entity.name}")
ValueError: Option not valid for Lisa Woonkamer Thermostat Schedule
Regarding the message. There’s no notification on the adam interface. The notification sensor shows that it was there during the pump-cycle, but it was also directly switched to off afterwards.
What is your plugwise-beta version?
It’s at v0.22.0a6
Ok thanks.
Regarding the message, I think I see why it keeps sticking. I’ll put the fix in pw-beta v0.22.0a7
Regarding the select-error, when does the error happen? What are you (an automation?) doing that results in this error? Are there any other errors in the LOGBOEK that were happening at the same time?
Please update to pw-beta v0.22.0a7
It happens (like I said sometimes, not always) when I’m opening a View that has an entities card with the select in it. So to be clear, I’m not trying to set it to anything at all, it can be as simple as changing my browser tab (so it was open in the background).
@sophof if you go to /developer-tools/state, look for the select entity and press the (i) button and look at the history, do you see ‘empty’ spots in there? (And or the more detailed one at /history?entity_id=select.anna_select_schedule&start_date=2022-03-23T23:00:00.000Z or likewise`?
Hmm, actually no, it has been stable on the same schedule for the past few days according to that. I thought I had changed it during that timeframe, but apparently not.
For some extra testing I just tried to change it and it correctly shows the new schedule. However, it picked the wrong setpoint that is not at all in that schedule? Trying it again this behaviour only repeats for one of my schedules, it simply appears to pick the wrong setpoint. So this looks more like a plugwise bug. I suspect because the first setpoint change for the day is after the current time.
Changing the schedule from the plugwise interface correctly changes the select in hass.
Does the setpoint correct itself (change to the expected schedule temp) after (up to) one minute of time?
You can double-check this by looking at what’s happening on the Plugwise App.
It is really unreliable. I’ve been switching back and for the past few minutes and saw that once. I’ve tried adding a setpoint explicitly for the morning, but whatever I do, it will usually be on the ‘home’ setpoint. I also see the behaviour for other schedules, so the first one was a fluke.
This is really weird…