Fan control UI issue: Changing fan speed shows the previous fan speed in the UI

Odeen · June 29, 2020, 5:57am

Hello! New Home Assistant user, migrating nodes off of my Vera Lite that’s on its last legs.

First of all, I appreciate my Leviton VRF01 fan controller being treated as a “Fan” by default instead of a dimmable light, the way the Vera dealt with it. Thank you for making that bit of magic happen.

I’m running into issue where the Fan Level entity does not have its Speed state updated when I change the fan speed.

To illustrate. Currently, fan is off, speed is “off”:

Setting fan speed to “Medium”. VRF01 status LED is in medium position, actual fan spins at medium speed. Note: In the UI, fan speed state is still “Off”

Setting fan speed to “High”. VRF01 LED and physical fan speed are high. But UI fan speed state is… “Medium”?

Note, at this point, I cannot set the fan to “Medium” speed. Since the entity’s speed state is “Medium”, I cannot set the speed to “Medium” again.

Let’s set it to “Low” as a workaround:

Well, this is weird:
I selected Low.
VRF01 indicator and fan rotation speed are low.
However, the “Speed” drop-down and Speed state are both “High”. It actually changed the option in the drop-down.
After 5 minutes, nothing changes – hardware is at low speed, UI shows high in both spots.

Let’s get it back to Medium. It’s warm here.

Hardware is at medium. I think the UI has settled into a pattern of reporting the previous fan speed.

Selecting “Medium” again synchronizes the hardware and the UI:

Let’s select “High” again, just for a good measure…

…eh? Hardware is on, speed is high, UI thinks is… off?

Back to medium we go:
(Forgot to capture a screenshot here, but the actual fan turned off)

Anyways, it seems like fhe fan state is not updated at a proper time after the fan speed is changed. Sometimes this discrepancy is pushed back into the drop-down, sometimes the drop-down selection stays per the user input, but the fan speed state does not change.

This occurs in Chrome, Firefox, and in the Home Assistant Android app.

Using the physical controls of the VRF01 propagates changes to the UI within 5 seconds or so. Both drop-down selection and speed state get updated.

Is this a UI bug that can be fixed? Should I create some kind of workaround where the Zwave node is polled every few seconds, or add automation steps to update the entity after changing the fan speed?

Thanks!

Alex

myle · June 29, 2020, 7:34am

well bro you need some template training

I have

I want to read the IPaddress ( could be anything)

let go to the state page and find it

now I Know that
open new TAB goto the Template Page and lets start playing

ok cool we can pull stuff out of the "attributes"

now this where the rules change on what manual user you lession to

me I like to make a sensor template

so what working in templates


  - platform: template
    sensors:
      lounge_ip:
        value_template: >-
          "{{ states.light.shelly_lounge.attributes.ip_address}}"

do the config check and restart pray

it work I have a sensor

so now the automation bit

- id: 'ipaddress change'
  alias: IPaddress change
  trigger:
  - entity_id: sensor.lounge_ip
    platform: state

  action:
  - data: 
      entity_id: switch.lava_lamp
    service: switch.turn_off

I have done my bit

want to see what you have done

Odeen · July 1, 2020, 11:33pm

Thanks!

I was able to get a sensor going, and I’m going to try to tackle the automation part.

It seems silly, though, it’s a bog-standard Leviton multi-level switch from a product line that’s 10+ years old… I believe I’m either setting it up incorrectly, or there’s a bug in the fan handling. Since you know far more about HA than I, would you consider what’s happening a bug worth reporting?

Odeen · July 2, 2020, 6:53am

The problem is (mostly) resolved if I take the fan.leviton_vrf01_1lz_quiet_fan_speed_control_level entity and set its polling intensity to 1.

The fan speed is reflected in the UI within a few seconds. Still seems silly, though, if Leviton dimmers and switches update in the UI immediately, why not the fan controller…?

Maybe it’s actually a Zwave issue, not a UI one… thank you again for your help.

Odeen · July 8, 2020, 9:49pm

Update: BOO Leviton.
As it turns out, when asked for a speed / level change, the VRF-01 happily reports back its old level, not the new or target level requested.

As a result, Home Assistant’s Zwave integration gets back a report that the “new” level is same as the old level, passes this wrong / outdated information to Home Assistant, and HA helpfully updates the entity state to the wrong /outdated level that the Zwave hardware reported.

There’s a workaround for Z-Wave light dimmers that do not report, or report wrong level changes. Adding refresh_value and delay settings to a Z-Wave device’s configuration in configuration.yaml will re-poll them a specified number of seconds after requesting a level change:

zwave:
......
device_config:
light.kitchen_pendants:
refresh_value: true
delay: 1

However, this is restricted to “light” entities only, and is ignored for “fan” entities, despite both being Z-Wave multilevel switches “under the hood”.

Ended up re-implementing this functionality as an automation:

alias: UpdateFan
initial_state: 'on'

trigger:
  platform: event
  event_type: call_service
  event_data:
    service_data:
        entity_id: fan.leviton_vrf01_1lz_quiet_fan_speed_control_level
        domain: fan
    service: set_speed

  - delay: '00:00:01'
  - service: zwave.refresh_node_value
    data:
      node_id: 15
      value_id: 72057594294403073

So, after we call the service to set speed on this fan, we wait 1 second, then poll the fan controller for its new level value.

The interesting thing is that polling the entity (not the node) doesn’t work:

#does not work: 
service: zwave.refresh_entity
entity_id: fan.leviton_vrf01_1lz_quiet_fan_speed_control_level

Calling the homeassistant.update_entity service doesn’t work either:

#does not work
service: homeassistant.update_entity 
entity_id: zwave.leviton_vrf01_1lz_quiet_fan_speed_control

Calling either of those services does not cause Openzwave to actually poll the fan controller. Refresh_node or refresh_node_value do cause a poll to be sent. It’s a matter of going to Developer Tools / States, and finding the correct node id and value id – because why make this easy.

So, this now works. I’d still love to know why zwave.refresh_entity service does nothing, but, for the moment, I’m chalking it up to still running stock Openzwave 1.4 instead of the 1.6 beta.

Thank you for that nudge to go and learn about automations.

I’m writing kind of a detailed response because, if someone else happens to run into this same problem with a non-light Zwave multilevel switch, I want them to find this post and not bang their head against the wall like I did. Eh, on to the next issue, let’s see if I can get custom cards to work…

Ambidexter · July 18, 2020, 10:03pm

I seem to have the same issue with my Honeywell type=4944, id=3131 fan dimmer. (still reports as “Unknown” product due to new ZWave designation not understood with existing stack.

I can set the fan to “on” (or fast really), and it didn’t seem to work…it just “popped back” from on to off, when on was toggled.

I used Integration configuration screen to heal, shutdown, restart stack, and that didn’t help. The Fan saw my commands, but the returned value was “off”, so the UI went to off.

This didn’t happen a few releases ago, I’ve only just upgraded from a 0.100.? to 0.112.4 a few days ago.

I’m not keen on deleting and re-adding it. I can see that the node sees my commands and can reply. It’s just the stack doesn’t parse it?

Regards,

Ambi

Odeen · July 19, 2020, 11:45am

I have a bunch of Monster Cable (!!!) dimmers that I bought ~9 years ago, and HA’s OpenZwave fork didn’t know about them either. I beat my head against the wall here for ages.

Ultimately, my solution was:

Download the entire open-zwave 1.4 repository from GitHub - home-assistant/open-zwave: a C++ library to control Z-Wave Networks via a USB Z-Wave Controller. and unzip it. All the files should be in (unzip dir)/open-zwave-hass.
Then, using your favorite SFTP utility:
Create directory /config/custom_components/zwave on your HA server.
Copy the contents of (unzip dir)/open-zwave-hass to /config/custom-components/zwave, except open-zwave-hass/config directory.
Download, unzip, etc, the latest OpenZwave from GitHub - OpenZWave/open-zwave: a C++ library to control Z-Wave Networks via a USB Z-Wave Controller.. Unzip the archive, and you should end up with (unzip dir)/open-zwave-master
Create /config/custom_components/zwave/config directory
Copy the contents of (unzip dir)/open-zwave-master/config to /config/custom_components/zwave/config.

You should end up with HASS’ OpenZwave 1.4 but with the latest and greatest Zwave device definitions.
Make sure that, once you’re done, the path to manufacturer_specific.xml file on the HA server looks like this:

Make sure that you haven’t ended up with, say, “zwave/zwave” as part of the path, or with any directory names that start with “open”

Once you set up the directory correctly:
8) Stop the server
9) Delete file /config/zwcfg*.xml
10) In configuration.yaml, in zwave: section, add a line that says:
config_path: /config/custom_components/zwave/config
My zwave: section ends up looking like this:

At that point, either
10) SSH into the Home Assistant server
11) type HA CORE START to restart Home Assistant
or
10a) Powercycle the danged thing.

This will not change your existing node names, but any subsequent devices you add will be configured as per the latest OpenZwave. So, you could unpair the misnamed device, then re-pair it, and it should be correctly detected.

If you’re as OCD as I am, unpair everything, factory reset the Zwave controller, and start your network over, so that your node numbers start with 1.

Note: I’m not 100% sure what voodoo Home Assistant does to realize that a given Zwave “dimmer” is actually a fan controller. My VRF01 got classified as a fan controller automatically, I don’t know if yours will as well, or if you just end up with a perfectly correctly named dimmer.

I believe it’s not the stack’s fault, it’s the fan controller’s. What happens is that, when asked to change level, the fan controller returns its current level back rather than the new / target level.

Go to the Zwave configuration, scroll to OZW Log, and open up a 100-line tail so you can watch the Zwave traffic in real time. At the switch, turn on the fan and set it to medium speed.

Now try setting fan speed to “low” using the UI and watch the Zwave traffic. Mine ends up looking like this:

2020-07-19 04:13:21.212 Info, Node015, Received SwitchMultiLevel report: level=41
2020-07-19 04:13:21.212 Detail, Node015, Refreshed Value: old value=41, new value=41, type=byte
2020-07-19 04:13:21.212 Detail, Node015, Changes to this value are not verified
2020-07-19 04:13:21.212 Detail, Node015,   Expected reply and command class was received
2020-07-19 04:13:21.212 Detail, Node015,   Message transaction complete
2020-07-19 04:13:21.212 Detail,
2020-07-19 04:13:21.212 Detail, Node015, Removing current message
2020-07-19 04:13:21.212 Detail, Node015, Notification: ValueChanged

Note how the fan controller reported its new value as 41, same as the old value.
Now, now go to Developer Tools \ Services screen and
Issue zwave.refresh_node command with service data node_id: xx where xx is your fan controller’s node ID. Here’s mine:

Click the “Call Service” button and go back to the OZW Log window. Near the bottom of the log, you should see the result of that refresh_node command:

2020-07-19 04:21:10.416 Info, Node015, Response RTT 37 Average Response RTT 37
2020-07-19 04:21:10.416 Info, Node015, Received SwitchMultiLevel report: level=1
2020-07-19 04:21:10.416 Detail, Node015, Refreshed Value: old value=41, new value=1, type=byte
2020-07-19 04:21:10.416 Detail, Node015, Changes to this value are not verified
2020-07-19 04:21:10.416 Detail, Node015,   Expected reply and command class was received
2020-07-19 04:21:10.416 Detail, Node015,   Message transaction complete

NOW it tells us that level = 1. The Home Assistant UI should update to indicate fan speed “low”.

Check my “Boo Leviton” post above for an explanation of what’s going on and an automation I had to create to force a level refresh after change.

I seem to have the same issue with my Honeywell type=4944, id=3131 fan dimmer. (still reports as “Unknown” product due to new ZWave designation not understood with existing stack.

-Alex
Note: I purposely went overboard with directions and explanations in order to make this post as easy to search for and find, and as simple to follow for any future HA users regardless of their experience level. I’d like to have this thread help as many people as possible.

My next project is, having zero Javascript or Python experience, to try to modify the existing light card into fan controller card with fixed level presets. Wish. Me. Luck.

Fan control UI issue: Changing fan speed shows the *previous* fan speed in the UI

Fan control UI issue: Changing fan speed shows the previous fan speed in the UI