cgarwood / homeassistant-zwave_mqtt

Limited Pre-Release of the new OZW1.6 Z-Wave component. Currently has limited platform support. Check the README for more details.
72 stars 8 forks source link

Light platform: All service calls to turn on or off lights fail. #52

Closed ghost closed 4 years ago

ghost commented 4 years ago

Environment:

Zwave modules:

Issue:

Cannot turn on or off any lights. Doesn't work with any of the 2 different zwave modules listed above. I have tried via the UI and manually calling a service. Doesn't matter if a transition: value is passed in the service data. Also fails with homeassistant.turn_on/off service calls.

Error code below is produced by trying to turn off a light via the UI.

2020-02-01 12:43:51 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.140579229614544] 'NoneType' object has no attribute 'value'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 134, in handle_call_service
    connection.context(msg),
  File "/usr/src/homeassistant/homeassistant/core.py", line 1226, in async_call
    await asyncio.shield(self._execute_service(handler, service_call))
  File "/usr/src/homeassistant/homeassistant/core.py", line 1251, in _execute_service
    await handler.func(service_call)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 201, in handle_service
    self._platforms.values(), func, call, service_name, required_features
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 335, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 357, in _handle_service_platform_call
    await getattr(entity, func)(**data)
  File "/config/custom_components/zwave_mqtt/light.py", line 124, in async_turn_off
    await self.async_set_duration(**kwargs)
  File "/config/custom_components/zwave_mqtt/light.py", line 86, in async_set_duration
    if self.values.dimming_duration.value is None:
AttributeError: 'NoneType' object has no attribute 'value'
marcelveldt commented 4 years ago

Are you running the latest ozwdaemon and did you restart it after all lights were initially imported ? Would be nice to get a dump of you mqtt data to debug this one. For now all I can conclude is that your dimmer does not support transitioning/fading to a new state, is that correct ?

ghost commented 4 years ago

The ozwdaemon is the latest docker build. It has been restarted since the lights have been initially imported. I don't think the dimmer supports a configurable transitional fade period. With the stock OZW 1.4 implementation of hass changing the "transition" value in the service service call doesn't have any effect on the speed it takes to change brightness.

A CSV dump of the mqtt is attached below. One of the leviton zwave dimmers is node 2 and the linear z-wave dimmer module is node 19.

mqtt_dump-20.02.01-15:47.txt

ghost commented 4 years ago

I was able to get the lights to work by changing line 86 of sensors.py to the following:

*** light.py    2020-02-01 18:23:32.184741809 -0500
--- light.py.orig       2020-02-01 17:41:48.472209916 -0500
***************
*** 83,89 ****
          0x80-0xFE = 1 minute to 127 minutes
          0xFF      = factory default
          """
!         if self.values.dimming_duration is None:
              if ATTR_TRANSITION in kwargs:
                  _LOGGER.debug("Dimming not supported by %s.", self.entity_id)
              return
--- 83,89 ----
          0x80-0xFE = 1 minute to 127 minutes
          0xFF      = factory default
          """
!         if self.values.dimming_duration.value is None:
              if ATTR_TRANSITION in kwargs:
                  _LOGGER.debug("Dimming not supported by %s.", self.entity_id)
              return

Looking more closely, None of my zwave dimmer modules have COMMAND_CLASS_SWITCH_MULTILEVEL index number 5, aka INDEX_SWITCH_MULTILEVEL_DURATION so the object self.values.dimming_duration.value was never initialized.

Fishwaldo commented 4 years ago

This is likely due to a bug in OZW currently. See https://github.com/OpenZWave/open-zwave/issues/1981

The fix is very involved so may take some time to test properly before I push it to master.

marcelveldt commented 4 years ago

Thanks for your info. Issue indeed identified as a typo which you spotted yourself. Issue fixed in the code.