Got a working code, but still a few errors to iron out.
I’ve got an input_select for source select TV, which I then sync.
But every once and awhile i get the following error;
Invalid option: (possible options: PC, TV, Wii)
How can i get around this?
Feel like i’m missing something obvious.
Template sensors will often have a state of ‘unknown’ for a short time when HA starts. Try adding a condition to your automation that checks if the value of the sensor is valid for the input_select.
I can see a few things in your latest code that you might want to consider changing.
First, is_state returns true or false. I don’t think you were looking to have sensor.tv_source evaluate to either true or false. (Although, if you did, you should probably make it a binary_sensor instead of a sensor.) Assuming the source attribute of media_player.tv is indeed one of PC, TV or Wii, then I think the way you had sensor.tv_source in the first place makes more sense. Although I would use the state_attr function:
No, normally they will result in exactly the same value. However, the former will not cause an error if the entity doesn’t exist yet; it will just return ‘unknown’ in that case. The latter will cause an error in the same situation. The former is slightly shorter and less to type as well.
Maybe you could / want to help me with similar error.
Besides source select, i’ve got volume control for the TV and spotify.
It works 2-way. Can change volume on TV and HA, and it get’s synced.
But both of them give the same error.
Error executing service <ServiceCall media_player.volume_set: entity_id=[‘media_player.tv’], volume_level=0.0>
Error executing service <ServiceCall media_player.volume_set: entity_id=[‘media_player.spotify’], volume_level=0.0>
It errors out on the ‘volume.set’ attribute.
Could it be that when tv is off, ‘0 / 100’ would return an error?
Is it correct to resolve this, by adding this condition to the automation:
condition:
condition: state
entity_id: media_player.tv
state: ‘playing’
making it:
################################################################################
## VOLUME SET
################################################################################
- alias: 'TV Volume (Set)'
trigger:
platform: state
entity_id: input_number.tv_volume
condition:
- condition: state
entity_id: media_player.tv
state: 'playing'
action:
service: media_player.volume_set
data_template:
entity_id: media_player.tv
volume_level: '{{ states.input_number.tv_volume.state | int / 100 }}'
Error executing service <ServiceCall media_player.volume_set: entity_id=[‘media_player.tv’], volume_level=0.0>
Traceback (most recent call last):
File “/usr/local/lib/python3.6/site-packages/homeassistant/core.py”, line 1038, in _event_to_service_call
await service_handler.func(service_call)
File “/usr/local/lib/python3.6/site-packages/homeassistant/components/media_player/init.py”, line 441, in async_service_handler
await getattr(player, method[‘method’])(**params)
File “/usr/local/lib/python3.6/concurrent/futures/thread.py”, line 56, in run
result = self.fn(*self.args, **self.kwargs)
File “/usr/local/lib/python3.6/site-packages/homeassistant/components/media_player/webostv.py”, line 317, in set_volume_level
self._client.set_volume(tv_volume)
File “/usr/local/lib/python3.6/site-packages/pylgtv/webos_client.py”, line 312, in set_volume
‘volume’: volume
File “/usr/local/lib/python3.6/site-packages/pylgtv/webos_client.py”, line 199, in request
self.command(‘request’, uri, payload)
File “/usr/local/lib/python3.6/site-packages/pylgtv/webos_client.py”, line 193, in command
loop.run_until_complete(asyncio.wait_for(self._command(message), self.timeout_connect, loop=loop))
File “uvloop/loop.pyx”, line 1448, in uvloop.loop.Loop.run_until_complete
File “/usr/local/lib/python3.6/asyncio/tasks.py”, line 362, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
I deliberately did that.
TV Volume goes to 100, but 40 is already really loud, so i maxed the setting at 40
Well, the error certainly is a timeout error which appears to happen when trying to send the command to the TV. So, yes, I’d say you shouldn’t try setting the volume when the TV won’t respond (i.e., when it’s off I guess.) Since this is specific to a media_player platform I don’t use (webostv), you’ll just have to figure out under what conditions the media_player.volume_set service will work, and come up with an appropriate condition for your automation.
I suppose that prevents someone from changing the input_number to a value above 40 via the HA interface, but what if the volume is turned up beyond that at the TV itself - i.e., when your automation will try to set the input_number accordingly?
Got a point.
But, I have this TV 2 years and not once set the volume higher than 30.
So the convenience of not being able to give the slider a yank / accidentally (read:the wife) putting it to 100. That outweighs the possible error i could get when manually setting volume to 45, and HA not being able to sync it’s value.
Understood. But you could let the input_number go all the way to 100, then in your automation that sets the TV volume, cap the value that is actually sent to 0.4. It could even immediately set the input_number back to 40, too.
One thing you have to be careful about with these automations is feedback. I.e., the input_number gets changed, so it changes the TV volume. The TV volume changes accordingly, then that causes the input_number to get updated, too. But if there’s any difference, this could go on forever. (E.g., input_number goes to 27, which changes TV to 0.27, but TV actually changes to 0.26, which causes input_number to get changed to 26, which causes TV to be set to 0.26, but…) I think you’ve already considered this, especially given the delay you’ve included. But I just thought I’d point it out in case.
