[BUG]: Error setting up entry Anna for plugwise - type conversion
bouwew opened this issue · comments
Describe the bug.
When starting Home Assistant, I get a type error in the Anna plugin log. The integration is not set up. For exact error message, see the error log below.
I have been using the integration for a long time. In the 2022.3 release, it is not working anymore.
Expected behavior
A working system.
What version of Home Assistant Core has the issue?
2022.3
What type of installation are you running?
Home Assistant Supervised
How and which version of the integration do you have installed?
Home Assistant Core
What kind of Plugwise device is having issues?
Smile: Anna
What firmware version is your Plugwise product at?
4.2.1?
Home Assistant Logging (optional)
No response
Diagnostics information
No response
Additional information
Logfile of Anna integration:
Logger: homeassistant.config_entries
Source: components/plugwise/gateway.py:53
First occurred: March 8, 2022, 10:35:28 PM (1 occurrences)
Last logged: March 8, 2022, 10:35:28 PM
Error setting up entry Anna for plugwise
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 335, in async_setup
result = await component.async_setup_entry(hass, self)
File "/usr/src/homeassistant/homeassistant/components/plugwise/init.py", line 13, in async_setup_entry
return await async_setup_entry_gw(hass, entry)
File "/usr/src/homeassistant/homeassistant/components/plugwise/gateway.py", line 53, in async_setup_entry_gw
api.get_all_devices()
File "/usr/local/lib/python3.9/site-packages/plugwise/smile.py", line 106, in get_all_devices
self._all_device_data()
File "/usr/local/lib/python3.9/site-packages/plugwise/smile.py", line 60, in _all_device_data
data = self._get_device_data(device_id)
File "/usr/local/lib/python3.9/site-packages/plugwise/smile.py", line 201, in _get_device_data
device_data = self._get_appliance_data(dev_id)
File "/usr/local/lib/python3.9/site-packages/plugwise/helper.py", line 897, in _get_appliance_data
and self._outdoor_temp > data["cooling_activation_outdoor_temperature"]
TypeError: '>' not supported between instances of 'NoneType' and 'float'
@bart1970 let's continue the detailed discussion w.r.t. your problem here.
Hi Bouwe,
Here are (after edit were) the files. The cooling is turned on (with dipswitch).
Small remark related to the instructions anonymisation. The appliances, domain_objects and direct_objects files also contained the IP address in one of the <measurement lines. Updated the IP address there also to 127.0.0.2.
Thanks! I've downloaded them, you can remove them from the above message.
Bart, a question, how did you end up with Elga as a device-name? Did you rename the OpenTherm device?
You mean the device name in HA I assume. I'm not aware that I have changed this. I don't think I can find that back, can I?
Yes, device name in HA. The thing is, we expect to see OpenTherm as device-name, not Elga.
A quick update, we have found why you see the error, now we need to think about how to solve it...
Good you found it. Hope you can solve it. If I need to do any tests, please let me know.
Just checked some backups. 1.5 year ago, it was already called Elga. So if I changed it, it was already a long time ago.
Yeah OK, makes sense. Due to the HA unique_id, then the name / sensorname stay the same. But I realize now that this does not cause the bug.
We have it working in our test-environment. And we will test in plugwise-beta.
You could help us testing by installing plugwise-beta as a custom_component. Would that be an option for you?
Plugwise-beta can replace Core plugwise 1-to-1, you would only need to install plugwise-beta and restart HA. Plugwise-beta should pick up the existing Plugwise integration so you would not need to do any additional configuration.
Anyway, I'm turning my PC off for today, time to relax :)
@bart1970 @bouwew pw-beta https://github.com/plugwise/plugwise-beta/releases/tag/v0.21.3a1 is available for testing from plugwise/plugwise-beta#248
@bart1970 are you able to test the updates for us?
There are 2 options:
- Install plugwise-beta v0.21.3a2
- Change the plugwise version in the HA Core files to 0.16.7
We're happy to provide help for both options, if needed.
Was working until an hour ago. I will give it a try now and let you know if I managed.
What will you try?
I copied manually the files (using the file editor) in the custom folder and restarted HA.
Message I get now in the logs look like the old one, but just a little different:
022-03-11 20:41:45 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Anna for plugwise
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 335, in async_setup
result = await component.async_setup_entry(hass, self)
File "/config/custom_components/plugwise/init.py", line 16, in async_setup_entry
return await async_setup_entry_gw(hass, entry)
File "/config/custom_components/plugwise/gateway.py", line 74, in async_setup_entry_gw
api.get_all_devices()
File "/usr/local/lib/python3.9/site-packages/plugwise/smile.py", line 92, in get_all_devices
self._all_device_data()
File "/usr/local/lib/python3.9/site-packages/plugwise/smile.py", line 54, in _all_device_data
data = self._get_device_data(device_id)
File "/usr/local/lib/python3.9/site-packages/plugwise/smile.py", line 226, in _get_device_data
device_data = self._device_data_climate(details, device_data)
File "/usr/local/lib/python3.9/site-packages/plugwise/smile.py", line 172, in _device_data_climate
if not self.cooling_active and self._outdoor_temp > device_data.get(
TypeError: '>' not supported between instances of 'NoneType' and 'float'
Which plugwise-version is shown in the manifest.json file?
"version": "0.21.3a1",
plugwise==0.16.7 <-- that's the plugwise version I'm looking for.
Probably looking at the wrong file. I have in:
/config/custom_components/plugwise/manifest.json
{
"domain": "plugwise",
"name": "Plugwise Beta",
"version": "0.21.3a1",
"documentation": "https://github.com/plugwise/plugwise-beta",
"after_dependencies": ["usb", "zeroconf"],
"requirements": ["https://test-files.pythonhosted.org/packages/97/dd/c03345f77a98bdabd24ff1a8ac60eaf6be3c086126228074f7f66f0ed06e/plugwise-0.16.7a9.tar.gz#plugwise==0.16.7a9"],
"codeowners": ["@CoMPaTech","@bouwew","@brefra"],
"iot_class": "local_polling",
"config_flow": true
}
0.16.7a9, that should work. Why doesn't it work...
We'll try some other things.
@bart1970 I think we have solved your issue. Meaning, it works in our testing with the xml-data you provided.
Can you please test with https://github.com/plugwise/plugwise-beta/releases/tag/v0.21.4a1
Thanks! Initialisation works again. Looks fully working.
I do have a question, why are some entities in the configuration tab "sensors" (like elga outdoor temperature) and other entities "diagnostics" (like elga return temperature). Looks like a little artificial difference (maybe due to HA, not due to your integration). The diagnostic information page: https://www.home-assistant.io/integrations/diagnostics/ doesn't help a lot.
Thanks for you feedback!
As for the entities, ran into that myself as well while writing another integration: It's a fairly recent functionality called entity category that does this (see https://developers.home-assistant.io/blog/2021/10/26/config-entity?_highlight=categ#entity-categories). The diagnostics integration 'just dumps' the JSON data, so they are related but not the same thing.
Indeed, thanks, that's good news :)
Also great feedback, is appreciated. We'll consider changing this sensor to the diagnostics category.
We would like to ask you to test the cooling-related operation of the Plugwise-beta integration in detail, when the outdoor temperature is rising and the cooling mode becomes active, if this is possible for you.
We are wondering if our code is working correctly. It is mostly based on assumptions, we really need someone to test the correctness of these assumptions for us :)
If you can, please look at all the details: for instance, are all the climate.anna states shown correct in relation to what the Plugwise App shows? Please note, there is a time delay between what is show in the APP vs what is shown in HA.
About your feedback, we have decided to not change for now.
Reason: the outdoor_temperature sensor can be available on both on the OpenTherm as the Smile (Adam/Anna) device.
On the OpenTherm device it should be a diagnostics sensor but on the Smile device it shouldn't be one.
Due our implementation it's not possible to separate between the sensors. The only way to fix this is by changing one of the sensor names but this will complicate the implementation in the python code.
The cooling part is at this moment hard to test. For the heating part, some observations.
When the system is heating
- The heating icon on the anna HA (Thermostat Card) is off. The status line on the card is "Heating - Home" which is correct. (See picture below)
If I have other observations, I'll let you know. What is the best way to contact you?
The other observation was already in one of the other tickets. On HA, I can update the temperature (since this release) in steps of 0,1. On the Anna, only in steps of 0,5. Don't think is this is real problem.
On the diagnostics sensor, when I take some time to look at it, it's not so hard :) More later.
On your observations:
The four icons on the climate card indicate the hvac_mode, from left to right:
- auto, means a schedule is active, heating or cooling happens based on a schedule
- heating, the heating is based on the manually set setpoint
- cooling, the heating is based on the manually set setpoint
- off, this is artificial mode, a mistake in my view, should not be there
Heating and Home, refer to hvac_action and selected preset.
From this perspective, your card is showing everything correctly.
Why shoud the outdoor_temperature on the OpenTherm device a diagnostics sensor but on the Smile device not.
One is the real outdoor temperature (OpenTherm), the other I aassume based on some internet weather site?
On the pictures, all looks as I would expect.
On the outdoor sensor, on the gateway there is one single sensor, it's common to show it as a plain sensor, like the Illuminance sensor on the Anna:
Best way to contact me: just keep posting in this topic. I receive a notice when somebody adds a new message to an existing topic, also when it's closed.
Ah, I think I now understand the icons. Don't know if I find it logical however. If I read it correct, always only one icon is active.
I would expect:
- One indication on how you configured your thermostat (for example auto, heating, off, cooling)
- In case of auto, the name of the program (for example: Home, Holiday, )
- One indication on what the system is really doing: Idle, cooling, heating.
Looks like they are now a little mixed up.
Agree, I share your opinion. That's why I use the Simple Thermostat card instead: https://github.com/nervetattoo/simple-thermostat
I can share my configuration for this card if it helps.
On the control on the HA climate card or the Simple Thermostat card, the Plugwise integration can only turn the schedule off or on. So when you have a schedule active and the cooling mode is off, you could click on the cooling-icon/button and in the end the heating-icon will be shown as active :)
This issue has been solved in v0.21.4 therefore closing this issue.
@bart1970 Can you please test Plugwise v0.23.3a0?
I've made some changes that are specific with Anna connected to a device with cooling capability:
hvacmodesareheat_cooland `auto'- Attributes
temperaturereplaced bytarget_temp_highandtarget_temp_low - These two target_temps are displayed in the HA climate card.
Are these changes working in your system?
Hi @bouwew
Yes i can test, but my NUC running Home assistant crashed two weeks ago. Needed to buy one and now make sure everything get working again first... Not much at home, so can take some time.
@bart1970 Thanks for getting back to me, and sorry to hear about the server-problems.
Ok, please get back to me when you are for some testing :)
@bart1970 Plugwise-beta v0.26.0 contains the latest Anna + Elga related updates. According to user huub66 all is working.
When you are up and running again, please let me know if you find anything out-of-order.