Yes. The delay in automation A is not influenced by Automation B. The delay time in Automation A does not have anything to do with the fact that Light 2 might be turned off/on/off as many times as you want outside Automation A. If you don’t re-trigger Automation A then after 10 seconds the delay will finish and Lights 1 & 2 will be switched off.
The delay and countdowns are per automation. So it does not care (or know) that several automations are going to turn off (or on) the same light.
So in your example, whatever automation was triggered first will turn off the light #2 after the timeout is reached. The other automation will also try to turn it off, but it will already be off when it comes to that point.
I managed to change a rfxtrx device that was being recognized as a switch to a light by changing the last 6 characters of the devices id from e.g. 010f70 to 020f70. After a restart it will be recognized as a light. You can delete the (unavailable) switch afterwards.
See Rfxtrx lights are recognized as switches in 0.113
It is not really clear from the documentation, I agree. I don’t know a better way right now.
2 Likes
After updating to the latest version, home assistant gets stuck in:
Home Assistant is starting up, not everything will be available until it has completed booting.
I have a NUC so it starts fairly quickly but after waiting half an hour it always remains blocked, the frontend loads but the template sensors and automations do not load, returning to 112.5 everything works correctly.
How can I solve it?
I absolutely LOVE the new automation modes. I’ve missed it, without considering that it may be solved as simple as with such modes, and now that it’s there, I’m thrilled. Previously, I had to keep track of some of my automations to make sure they weren’t triggered twice or more while still running. Now that’s solved for me, and it even opens up new possibilities! EXCELLENT WORK, you guys! 
Max is like entering any other number, it will hit that limit and just not queue or service more than that number (for that particular script / automation )
You could have 1000 automations, each with 100 instances of itself running.
I don’t see why you’d want that or the scenario under which that would happen - but it’s possible (I can’t get my head round some scripts running once 
, so it’s best to be sparing when changing from the safe defaults, depending on your usage case)
1 Like
Awesome release, thanks guys!
I have the opposite. So it must be a case of taste. Me personally am visually oriented. Scripting means reading and documenting. Not my 2 strongest points. Using visual scripting (node-red) gives me an immediate overview of my automations without having to read (and understand) the script/automation prior to adjusting. Thats why I prefer node-red…
Really pleased to see scripts getting an ID, as a UI not yaml user this has made scripts more functionally usable! Thanks
Edit: I did notice and wondered if anyone else has, took a snapshot before the upgrade and one afterward (having tweaking a few automation’s to use scripts, nothing major) and the size of the snapshots have reduced by a third. Didn’t see anything in the release note about it, will try restoring from the latest to check it out…
I have the same issue with tensorflow.
I’m running HA on docker and tensorflow manually installed. I’l try and update tensorflow
My version of tensorflow is 1.14.0, HA 0.113.0 has a requirement of 1.13.2 so it fails…
Here is my log:
2020-07-23 10:40:11 ERROR (SyncWorker_6) [homeassistant.util.package] Unable to install package tensorflow==1.13.2: ERROR: Could not find a version that satisfies the requirement tensorflow==1.13.2 (from versions: none)
ERROR: No matching distribution found for tensorflow==1.13.2
2020-07-23 10:40:11 ERROR (MainThread) [homeassistant.config] Platform error: image_processing - Requirements for tensorflow not found: ['tensorflow==1.13.2'].
Not sure why it’s happening. Works fine in 0.112.4 with the same version
1 Like
I Agree with your procedure. Everyone should take snapshots (before ALL upgrades, at the very least)
I gone through the process of re-creating the YAML for all my rfxtrx devices, but after this I also need to rework the entire naming (which is next to impossible if you only have values like “0b110018006de0360c010f70”. I therefore decided to roll back to 0.112 and stick to that until a solution is ready.
2 Likes
Is it just me or there is something wrong with repeat value:
This script is not working:
xiaomi_alarm_seq:
sequence:
repeat:
while:
- condition: state
entity_id: input_boolean.activate_alarm
state: 'on'
- condition: template
value_template: "{{ repeat.index < 10 }}"
sequence:
- service: light.turn_on
data:
entity_id: light.gateway_light_04cf8c8f8ee4
color_name: 'red'
brightness: 255
- delay: '00:00:01'
- service: light.turn_off
entity_id: light.gateway_light_04cf8c8f8ee4
- delay: '00:00:01'
and this one does:
xiaomi_alarm_seq:
sequence:
repeat:
while:
- condition: state
entity_id: input_boolean.activate_alarm
state: 'on'
sequence:
- service: light.turn_on
data:
entity_id: light.gateway_light_04cf8c8f8ee4
color_name: 'red'
brightness: 255
- delay: '00:00:01'
- service: light.turn_off
entity_id: light.gateway_light_04cf8c8f8ee4
- delay: '00:00:01'
the only difference is use of repeat.index value 
Anyone could help please?
paper-dialog-background-color for the more info pop-up background colour no longer seems to work. Has this been changed as well?
I tried dialog-background-color and ha-dialog-background. Neither of which worked.
Same here. And event button_pressed is NOT working either.
Thanks @crookedview, removed the yaml but forgot the HACS component. Once removed from HACS and I restarted I was able to properly setup the new Bond component.
Hi,
I tried to update my Hassio Raspberry3 installation (it was on 0.111.4) bot it didn’t went well.
I reinstalled everything on the SD card and restored a snapshot, but it’s still not working.
I’m able to ssh in cli, SMB on the SD (via addon), but lovelace is not reachable.
I see this error in the logs, do you have any idea why?
Traceback (most recent call last):
File "/usr/local/lib/python3.8/runpy.py", line 194, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/local/lib/python3.8/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/usr/src/homeassistant/homeassistant/__main__.py", line 320, in <module>
sys.exit(main())
File "/usr/src/homeassistant/homeassistant/__main__.py", line 278, in main
args = get_arguments()
File "/usr/src/homeassistant/homeassistant/__main__.py", line 60, in get_arguments
import homeassistant.config as config_util
File "/usr/src/homeassistant/homeassistant/config.py", line 12, in <module>
from voluptuous.humanize import humanize_error
File "<frozen importlib._bootstrap>", line 991, in _find_and_load
File "<frozen importlib._bootstrap>", line 971, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 914, in _find_spec
File "<frozen importlib._bootstrap_external>", line 1342, in find_spec
File "<frozen importlib._bootstrap_external>", line 1314, in _get_spec
File "<frozen importlib._bootstrap_external>", line 1443, in find_spec
File "<frozen importlib._bootstrap_external>", line 1483, in _fill_cache
OSError: [Errno 74] Bad message: '/usr/local/lib/python3.8/site-packages/voluptuous'
Thanks for another great update: fix for tuya cloud, shiny new stuff and zero issues!
Now I can simplify some automations and even dream up some new use cases.
I’m having problems to update.
After clicking on update button and wait for the normal process, my HA instance restarts and everything seems OK. However, few minutes later it restarts again and auto “downgrade” to the previous version (112.4).