Conversation
| """Return device specific state attributes.""" | ||
| attributes = {} | ||
| if self._sound_mode_raw is not None and self._sound_mode_support\ | ||
| and self._power == 'ON': |
There was a problem hiding this comment.
continuation line over-indented for visual indent
| attributes = {} | ||
| if (self._sound_mode_raw is not None and self._sound_mode_support and | ||
| self._power == 'ON'): | ||
| attributes[ATTR_SOUND_MODE_RAW] = self._sound_mode_raw |
There was a problem hiding this comment.
indentation is not a multiple of four
| """Return device specific state attributes.""" | ||
| attributes = {} | ||
| if (self._sound_mode_raw is not None and self._sound_mode_support and | ||
| self._power == 'ON'): |
There was a problem hiding this comment.
visually indented line with same indent as next logical line
|
@balloob Can you merge this PR for the denonAVR implementation of sound mode support? |
| if sound_mode_support: | ||
| self._sound_mode = self._receiver.sound_mode | ||
| self._sound_mode_raw = self._receiver.sound_mode_raw | ||
| if sound_mode_dict is None: |
There was a problem hiding this comment.
If we can fetch it from the device, we should not allow it to be configured. Integrations should only represent the raw information that we receive from the device.
There was a problem hiding this comment.
@balloob the sound_mode_dict can not be fetched from the device (receiver) itself, the denonavr library contains an default sound_mode_dict that is hard coded in the denonavr library. However that dictionary is based upon the data of about 10 diffrent models of denon receivers (from which the information xml files are available in the denonavr git repositry, but their could potentially be other values available for newer or very old receivers.
This allows for flexibility for these older or newer receivers.
There was a problem hiding this comment.
I think that we should not include this config option because it will not motivate people to update the dictionary upstream for old and new receivers, resulting in all users having to collect the same information.
|
see lines 38 to 49 in the denonavr.py file in the scarface-4711 github denonavr library for the default sound mode dict: |
|
@balloob I removed the option to configure the sound_mode_dict. |
|
@balloob can this now be merged? |
| return self._sound_mode | ||
|
|
||
| @property | ||
| def sound_mode_raw(self): |
- removed the sound_mode_raw propertie because it was not used, (still available through self._sound_mode_raw (as device attribute for automations and diagnostics)
|
@MartinHjelmare Just removed the un-used sound_mode_raw propertie. |
| PLATFORM_SCHEMA = PLATFORM_SCHEMA.extend({ | ||
| vol.Optional(CONF_HOST): cv.string, | ||
| vol.Optional(CONF_NAME): cv.string, | ||
| vol.Optional(CONF_SOUND_MODE, default=DEFAULT_SOUND_MODE): cv.boolean, |
There was a problem hiding this comment.
Why is sound mode configurable? Can it not be detected from the device?
There was a problem hiding this comment.
This is the option to disable sound_mode_support for old types receivers that do not have sound modes. As far as I know this can not be detected from the receiver itself. At least their is no direct bolean if sound mode is supported. It might be possible to see it from the absense of the current sound mode if you request it from the receiver.
However I always like to have the option to disable components in case they give problems for certain types/models. Of course I only have my own receiver to test with and that one does support sound_mode. So I cann't really test with a receiver that doesn't support sound mode.
There was a problem hiding this comment.
However I always like to have the option to disable components in case they give problems for certain types/models.
In Home Assistant we aim to represent devices as-is. If we go down the route to disable sound modes, we can start adding config options for everything…
Please remove the config option and base it on detecting support.
There was a problem hiding this comment.
I am working on it in the denonAVR library of @scarface-4711.
There was a problem hiding this comment.
Okay. This PR can be merged when the config option has been removed and the lib has been updated.
|
@balloob can this denonavr sound mode support be merged? |
|
The library update and the removal of the option is not done as mentioned here. |
Removed the config option to indicate if sound mode is supported. Added detection if sound mode is supported from the receiver itself. Pushed denonavr library to V.0.7.4
|
@balloob Thank you for all your help througout this PR! |
* Add sound mode support * continuation line indent * indentation * indentation * Remove option to configure sound_mode_dict * Sound mode support - removed the sound_mode_raw propertie because it was not used, (still available through self._sound_mode_raw (as device attribute for automations and diagnostics) * Detect sound mode support from device Removed the config option to indicate if sound mode is supported. Added detection if sound mode is supported from the receiver itself. Pushed denonavr library to V.0.7.4 * Pushed denonavr to v.0.7.4
|
After update to 0.74 the log is beeing spammed with the following items: the device is turned off |
|
Please open an issue. |
Description:
Add sound mode support for the DenonAVR platform.
Using the just merged general sound mode support.
Added backend support for selecting the sound mode and updating the sound mode status.
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.io#5521
Example entry for
configuration.yaml(if applicable):Checklist:
tox. Your PR cannot be merged unless tests passIf user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
REQUIREMENTSvariable (example).requirements_all.txtby runningscript/gen_requirements_all.py..coveragerc.If the code does not interact with devices: