core: OZW light transition values are no longer compatible when using OpenZWave addon v0.5.2

The problem

The OpenZWave addon v0.5.2 was updated to use the latest version of open-zwave. The latest open-zwave code has changed the API for dim duration values, so the light integration needs to be updated as well.

Environment

Home Assistant Core release with the issue: All OZW versions, with OpenZWave addon v0.5.2. Standalone docker users with build-150 are not affected. Build-150 and later have the same problem.
Last working Home Assistant Core release (if known): N/A
Operating environment (OS/Container/Supervised/Core): N/A
Integration causing this issue: ozw
Link to integration documentation on our website: https://www.home-assistant.io/integrations/ozw/

Problem-relevant `configuration.yaml`

N/A

Traceback/Error logs

N/A

Additional information

A recent commit in open-zwave changed the type of the dim duration value for dimmer switches.

Previously it was a byte value that was encoded by the application into the z-wave values. Now the value is seconds, and open-zwave encodes it to the correct z-wave value.

The value type change affects the factory transition value (255) and any transition values > 127. For example, when light.turn_on is used w/o a brightness, ozw encodes that as 255, which means factory default. With the new API that means 255 seconds.

The factory default value is not well defined. I think there are still bugs in this area of code, so it is unknown if any other changes will follow. In the current implementation, the integration could choose any value > 15240 to indicate factory default.

About this issue

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

Commits related to this issue

Fix ozw dimming duration (#38254) * Dimming duration fix Fixes #38068 - allows dimming duration to 7620 (default of 7621) * Forgot to commit my test updates * Added backwards compatibility w... — committed to home-assistant/core by firstof9 4 years ago

Most upvoted comments

Just FYI - Give me a bit to fix up a few things here, and I’ll post when we have settled on the “factory default” value

Fishwaldo on Jul 23, 2020

What release will this be included in?

PR has been tagged for 0.113.2: https://github.com/home-assistant/core/pull/38254

jef-pearlman on Jul 27, 2020

Since this didn’t make it in to 0.113.2 (#38254 (comment)), is there any chance of rolling back the ozw version in the addon until it’s fixed in HA core? This issue has broken a bunch of my lighting. (Not sure if that means it should be reopened or not.) Thanks!

Just noting that dropping in the dev branch of the ozw component into custom_components seems to be working fine as a workaround for me until the fix is released. (Thanks to the folks on Discord!)

Can you tell med more how to do the workaround?

Just copy the ozw folder from dev branch into yours custom_components folder and restart HA. It will be picked up instead of the system version. Remember to remove it once the commit will be cherry picked (probably in version 0.114).

Michsior14 on Jul 29, 2020

Since this didn’t make it in to 0.113.2 (#38254 (comment)), is there any chance of rolling back the ozw version in the addon until it’s fixed in HA core? This issue has broken a bunch of my lighting. (Not sure if that means it should be reopened or not.) Thanks!

Just noting that dropping in the dev branch of the ozw component into custom_components seems to be working fine as a workaround for me until the fix is released. (Thanks to the folks on Discord!)

jef-pearlman on Jul 28, 2020

These cache invalidation are few and far between. Last time I did it was 1.4 -> 1.6 transition. So 1 1/2 years since then.

But yeah - Need better coordination between upstream and HA addon

Fishwaldo on Jul 24, 2020

Another observation, because of the value change the cache version was updated. Looks like the cache load does not gracefully handle incremental changes and discards the entire cache. This is basically the same as losing the cache file and it needs to be rebuilt. Mains-powered devices will be found automatically. For battery devices this means waking them up manually, or waiting for them to eventually wake up (if they do). Some users rely on the naming feature of OZW, and will notice those names are lost.

[warning]: Warning - Node: 0 WARNING: Driver::ReadCache - /opt/ozw/user/ozwcache_0xc85ce84b.xml is from an older version of OpenZWave and cannot be loaded.

kpine on Jul 24, 2020

Oops, good catch, that will cause a lot of headache.

No choice unfortunately - I’ve had to change the Duration ValueID to a Int (from a byte) and if loading from a cache that has the old encoding, it would crash OZW.

That’s too bad. Some users (including me) have lot’s of battery powered nodes. Most of them do not wake up at all or very sporadic. Going to the trouble of manually refreshing them is a bit of a pain. Let alone the fact that they do not know about the fact this is needed after an update.

These kind of breaking change (if really not unavoidable) should be communicated. We can do that in the add-on release notes for example.

marcelveldt on Jul 24, 2020

Good find, @kpine! This explains why my lights all of a sudden are taking several minutes to respond…

seandop on Jul 23, 2020