Description of problem:
There are cases that reading config parameter is valuable especially when validating a prior set_config_parameter on a z-wave node had succeeded. This approach can be used to implement a retry logic in AppDaemon. The showcase for such a service would be HomeSeer dimmers. Sometimes zwave/set_config_parameter would fail to transmit the setting (possibly due to congestion in the network). The current workaround is to call zwave/print_config_parameter to HASS log and then parse it to read the value in AppDaemon which causes unnecessary processing and I/O. If zwave/get_config_parameter is not possible (since i didn't see a way to return a value from service), maybe a service can be created that would raise an event with the current configuration value and then this can be listened for in AppDaemon.
Home Assistant release with the issue: All
Last working Home Assistant release (if known): None
Operating environment (Hass.io/Docker/Windows/etc.): Doesn't matter
Component/platform: https://www.home-assistant.io/components/zwave
Description of problem: There are cases that reading config parameter is valuable especially when validating a prior set_config_parameter on a z-wave node had succeeded. This approach can be used to implement a retry logic in AppDaemon. The showcase for such a service would be HomeSeer dimmers. Sometimes zwave/set_config_parameter would fail to transmit the setting (possibly due to congestion in the network). The current workaround is to call zwave/print_config_parameter to HASS log and then parse it to read the value in AppDaemon which causes unnecessary processing and I/O. If zwave/get_config_parameter is not possible (since i didn't see a way to return a value from service), maybe a service can be created that would raise an event with the current configuration value and then this can be listened for in AppDaemon.