Well, I tried this code to change attribute of a trend binary sensor, namely - to change value of min_gradient attribute (as this attribute does not support templates and therefore is limited to hardcoded values - not very useful), and it also reverts to the original one after a while.
I know it’s slightly out of scope of this topic, but could anyone enlighten us why does that happen?
if you change the state of an existing/known entity that is managed by another component, the code that manages it will periodically update the state, likely wiping out any changes you have made. It really depends on how the component handles/updates its information, but likely any attribute that is meant to be read-only (i.e. the component only pushes its value) will be reset whenever the component refreshes.
The code here is more useful for custom attributes, or for entities that are only refreshed by events that are infrequent or manual. For most entities you would be better off with a template based entity wrapper. (i.e. a template switch or the like.)
You could “force” the value you want by having an automation that fires whenever the state of the entity changes and re sets the value, though you would have a minor blip when this occurs I belive.
Thanks for your explanation!
I think it’s HA code, not a component(integration?) one.
Agree. Just used it to see if it can help in my situation.
It would most likely happen.
Well, I want to use Trend Binary sensor, and it does not support setting its min_gradient attribute as a template - pretty silly as you can only have hardcoded values.
So currently I have a trend sensor without min_gradient, a template sensor that captures gradient attribute of the trend sensor every 10 seconds and a template binary sensor that compares state of that template sensor with input_number value - pretty long way if we cannot permanently modify that min_gradient, isn’t it?
I looked at that sensor (and its code) as I have never come across it before. You cannot modify its attributes as they are statics (i.e. readonly) in the code. Other than tweaking the settings, I am not sure how useful an adjustable min_gradient would be. Its purpose is to be the minimum change that the sensor should trigger on, and its math is dependent on that value being constant. I think the way you have it now is the right way to do it. It may feel cumbersome but it is logical.
Side note: Adding templating capability to attributes can cause extra overhead because it means the templates variables have to be monitored for change and everything recalculated when a change occurrs. Your approach limits those to specific events so would probably cause less strain that the sensor supporting templating attributes.
That’s correct. However, I wanted to be able to change without restarting HA - it’s useful when tweaking real-world scenarios.
I totally agree with your side note about tempting overhead.
Don’t know why there is no trend sensor though as it would allow us to create a binary trend sensor ourselves and make it adjustable in just one step… or maybe I don’t know something important…
Hi,
I’ve been interested in setting custom attributes which has lead me here. Here’s my use case:
I have a pool of humidity sensors, and I want to be able to choose a subset of them to be considered for deriving a “current RH value” that the whole-home RH% setpoint checks against. Selecting/deselecting these sensors could either come from a human (the UI) or motion. Doesn’t matter.
Anyway, I thought the easiest/quickest way to PoC this out was to just use an programmatic custom attribute for each humidity sensor. Such that attribute “custom_rh” had something like { “available”:true, “selected”:true} or something along those lines.
Ok, so I wind up reading this thread and get the py script loaded in. Fantastic. It seems to be exactly what I need (and a basis for other things I need as well.)
But I also am running into what others have mentioned:
I can have two tabs open, one in dev tools / states monitoring the humidity sensor I’m testing against and one in dev tools / services where I am executing the set_states.py script.
When I execute the script, the custom attribute shows up in the states. But within 1-15 seconds, it vanishes. Similar thing happens if I initialize the custom attribute in Customizations - if I try to modify the value of the attribute using set_states.py, it gets reverted.
What am I missing here? 0.96.5 HA. Sensors are Aeotec multisensor 6s.
thanks in advance
I cannot explain why your custom atriabutes vanish, but what about going another way: create template sensors-wrappers for your real ones and add custom attributes there using standard approach - they will stay.
This script has its advantages but it cannot solve any problem.
Hi
I have been using this for a variety of automations. I have a problem with one. I have 3 blinds (Front1, Front2, Front3 that I can control individually or as a group (Front123). I usually use the group so want to set the State and Position of the individual blinds for the Front End.
- id: '1573534520806'
alias: Set Blinds States
description: ''
trigger:
- entity_id: cover.front123
platform: state
condition:
- condition: template
value_template: '{{ trigger.to_state is not none and trigger.from_state is not
none and trigger.to_state.state != trigger.from_state.state }}'
action:
- data_template:
entity_id: cover.front1
state: '{{states.cover.front123.state}}'
service: python_script.set_state
- data_template:
entity_id: cover.front1
current_position: '{{state_attr("cover.front123", "current_position")}}'
service: python_script.set_state
- data_template:
entity_id: cover.front2
state: '{{states.cover.front123.state}}'
service: python_script.set_state
- data_template:
entity_id: cover.front3
state: '{{states.cover.front123.state}}'
service: python_script.set_state
The State works fine. But the Position is recorded as ‘0’ or ‘100’ instead of 0 or 100.
I expect the problem is with
- data_template:
entity_id: cover.front1
current_position: '{{state_attr("cover.front123", "current_position")}}'
Any suggestions?
Many thanks
States, state_attr, etc. always return a string, so you need to convert it to a number.
- data_template:
entity_id: cover.front1
current_position: '{{ state_attr("cover.front123", "current_position") | int }}
1 Like
Are you talking about inside the python script?
Still the same unfortunately. I wonder if the '{{ and }}' are still keeping it as text? Is there a different way I can assign the value?
I am passing the data to the script by assigning the attribute within the automation data template.
Yes, I get that, but are you talking about
Inside the python script or in the yaml?
If I check the results in Developer Tools/States I get
The State Attribute for Front 123 is 0 but Front1 is ‘0’
So the Front End GUI doesn’t recognise that the single blind is up or down.
Front Blinds/All Blinds is Front 123, South is Front1
Ok, what is setting that value? You don’t have a single automation posted that shows how you set the current position.
So it must be in your python script or outside what you posted. That’s all I’m trying to get out of you.
Did you write the python script? Is the python script setting the value or are you doing it in another automation?
That’s the source of your issues. That’s a poorly written script in regards to maintaining attribute types. It keeps everything a string which is the root cause of your issue.
Why aren’t you using a cover group instead?
cover:
- platform: group
name: front123
entities:
- cover.front1
- cover.front2
- cover.front3
You won’t even need an automation. You’ll just have a cover that controls all 3.
1 Like
I guess, for some of us, we need to take the long way round to get at the best solution. 
It has been a very circuitous path for these blinds involving RF transmitters, rolling codes and complicated supply of power. They finally work and the GUI was the last bit.
Thank you so much for the simple solution for the icing on the cake 
1 Like
Lol, it happens to all of us. Don’t fret over it. Cover groups is pretty new, I think it’s less than a year old.
1 Like
@ rodpayne the set_state.py is a great help thankyou.
However, I have a small issue when running mine, giving a no attribute lower() error.
Here is my log:
2020-02-06 20:35:08 INFO (SyncWorker_5) [homeassistant.components.python_script] Executing set_state.py: {'state': '0.105.1', 'entity_id': ['sensor.last_known_version']}
2020-02-06 20:35:08 ERROR (SyncWorker_5) [homeassistant.components.python_script.set_state.py] Error executing script: 'list' object has no attribute 'lower'
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/homeassistant/components/python_script/__init__.py", line 196, in execute
exec(compiled.code, restricted_globals)
File "set_state.py", line 13, in <module>
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/homeassistant/core.py", line 876, in get
return self._states.get(entity_id.lower())
AttributeError: 'list' object has no attribute 'lower'
Here is my sensor definition:
sensor:
- platform: template
sensors:
last_known_version:
value_template: "0.105.1"
As you can see, I’m running latest(ish) version of HA.
Are you able to assist at all please?