search

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

Re-work discovery process #26

Closed cgarwood closed 4 years ago

cgarwood commented 4 years ago

The discovery (mapping node values/CCs to HA entities) process was mostly copied from the existing zwave component as I was trying to re-use as much code as possible. However, its difficult to follow and I'm hitting issues now with devices that have multiple values/CCs per entity (RGB lights, etc).

Currently the zwave_mqtt component receives a value_added notification for every value for every node. These values then get run through a discovery process and matched against a schema to see what kind of entity (if any) should be created. If there's a schema match it gets shipped off to a ZWaveDeviceEntityValues class for processing and actually creating the entity. ZWaveDeviceEntityValues is supposed to then update an entity if it gets additional values after its created. For example, we create a light entity based off of COMMAND_CLASS_SWITCH_MULTILEVEL, if the ZWaveDeviceEntityValues object for that class then receives a COMMAND_CLASS_COLOR, it should update the capabilities of the light entity to support RGB mixing.

The problem I'm seeing is, we create the light based off COMMAND_CLASS_SWITCH_MULTILEVEL, and we see the value_added notification for a COMMAND_CLASS_COLOR value in the time between dispatching the entity creation but before the entity has actually been created.

I think we may be better off re-writing the entire process. My hope is that it can be simplified to make it easier to follow and easier to maintain.

balloob commented 4 years ago

Wouldn't it be better to not drop value changed messages while creating objects? That would avoid a rewrite ! Just make sure you don't await anything before creating that object. Maybe all values are initially sent to a ZWaveDeviceEntityValuesManager class ?