core: "Error while setting up homematic platform for cover" after HA Restart

The problem

I get this error message after restarting HA: Error while setting up homematic platform for cover

Then the state of the HMIP-BROLL window covers is unavailable. However this does not effect my HMIP-PSM plugs, which keep on working as desired. I am running Home Assistant Supervised on Debian 10 and Debmatic on the same host The only way to get the covers working in HA again is to restart Debmatic AND THEN restart HA again. (Alternatively restarting the entire Host does the same) But as soon as I restart HA afterwards (e.g. due to changes in configuration.yaml) the error message is back and the covers are unavailable. This happens for 3 out of 4 homematic window covers. One however, works as it should be, even after HA restart.

Environment

Home Assistant Core release with the issue: 0.114.4
Last working Home Assistant Core release (if known): n/a
Operating environment (OS/Container/Supervised/Core): Supervised
Integration causing this issue: Homematic
Link to integration documentation on our website: https://www.home-assistant.io/integrations/homematic/

Problem-relevant `configuration.yaml`

homematic:
  interfaces:
    ip:
      host: 192.168.10.170
      port: 2010

sensors.yaml:
- platform: template
  sensors:
    arbeitszimmer_cover_position:
      value_template: '{{ state_attr("cover.xxxxxxxxxxxxxx1", "current_position") | int }}'
      unit_of_measurement: '%'
      friendly_name: 'Schlafzimmer - Cover Position'
    schlafzimmer_cover_position:
      value_template: '{{ state_attr("cover.xxxxxxxxxxxxxx2", "current_position") | int }}'
      unit_of_measurement: '%'
      friendly_name: 'Schlafzimmer - Cover Position'
    wohnzimmer_links_cover_position:
      value_template: '{{ state_attr("cover.xxxxxxxxxxxxxx3", "current_position") | int }}'
      unit_of_measurement: '%'
      friendly_name: 'Wohnzimmer links - Cover Position'
    wohnzimmer_rechts_cover_position:
      value_template: '{{ state_attr("cover.xxxxxxxxxxxxxx4", "current_position") | int }}'
      unit_of_measurement: '%'
      friendly_name: 'Wohnzimmer rechts - Cover Position'

Traceback/Error logs

  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 192, in _async_setup_platform
    await asyncio.gather(*pending)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 301, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 397, in _async_add_entity
    supported_features=entity.supported_features,
  File "/usr/src/homeassistant/homeassistant/components/cover/__init__.py", line 219, in supported_features
    if self.current_cover_position is not None:
  File "/usr/src/homeassistant/homeassistant/components/homematic/cover.py", line 45, in current_cover_position
    return int(self._hm_get_state() * 100)
ValueError: invalid literal for int() with base 10: ''

Additional information

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 15 (4 by maintainers)

Most upvoted comments

Could somebody please test what happens when the following modification is applied here?

Before:
return int(self._hm_get_state() * 100)
After:
try:
    return int(self._hm_get_state() * 100)
except ValueError:
    return None
I’m especially interested to know how this impacts startup (do the entities get created?), and in case we’re dodging the problem this way, if the state of the entity gets correctly updated during runtime if the device is being used (either manually or via automation).

I implemented your suggestion and it’s working. Entities are recognized now, which have been greyed out before. (HM-IP BROLL)

During startup HA now shows this warning message:

Logger: pyhomematic.devicetypes.generic
Source: /usr/local/lib/python3.8/site-packages/pyhomematic/devicetypes/generic.py:212 
First occurred: 11:59:37 AM (13 occurrences) 
Last logged: 11:59:39 AM

HMGeneric.getValue: RSSI_PEER on 00111BE9A418BD:0 Exception: <Fault -5: 'Unknown Parameter value for value key: RSSI_PEER'>
HMGeneric.getValue: RSSI_PEER on 0014DBE997840D:0 Exception: <Fault -5: 'Unknown Parameter value for value key: RSSI_PEER'>
HMGeneric.getValue: RSSI_PEER on 00111BE9A4188A:0 Exception: <Fault -5: 'Unknown Parameter value for value key: RSSI_PEER'>
HMGeneric.getValue: RSSI_PEER on 000B5BE9993719:0 Exception: <Fault -5: 'Unknown Parameter value for value key: RSSI_PEER'>
HMGeneric.getValue: RSSI_PEER on 00111BE9A4198E:0 Exception: <Fault -5: 'Unknown Parameter value for value key: RSSI_PEER'>

Information for customizing: Copy the whole “Homematic” folder from “core/homeassistant/components/” ( GitHub ) to HA “/config/custom_components/” change “cover.py” as you suggested and also add ‘“version”: “1.0”’ to “manifest.json”

greewoo on Jul 9, 2021

Having the same issue with 3 FROLL actors since some months already. They haven’t moved for some days and were a 0%. When restarting HA I run into the described problem if the actors lost the real percentage in the CCU:

channel 3 has unknown real height of cover
channel 4 displays it with ‘??’

Driving the covers down and up returns correct values to the CCU, then a restart of HA also (temporarily) fixes the integration error.

Hope someone can invest on danielperna84’s idea as it seems to fix at least the integration itself (although the real positions of the covers might not be correct)…

Could somebody please test what happens when the following modification is applied here?

Before:
return int(self._hm_get_state() * 100)
After:
try:
    return int(self._hm_get_state() * 100)
except ValueError:
    return None
I’m especially interested to know how this impacts startup (do the entities get created?), and in case we’re dodging the problem this way, if the state of the entity gets correctly updated during runtime if the device is being used (either manually or via automation).

N3rdix on Feb 10, 2021

Could somebody please test what happens when the following modification is applied here?

Before:

return int(self._hm_get_state() * 100)

After:

try:
    return int(self._hm_get_state() * 100)
except ValueError:
    return None

I’m especially interested to know how this impacts startup (do the entities get created?), and in case we’re dodging the problem this way, if the state of the entity gets correctly updated during runtime if the device is being used (either manually or via automation).

danielperna84 on Oct 14, 2020