So you’re not inclined to report it properly and contribute to fixing it? Very community minded.
The package is a Docker Container.
The maintainer needs to update the Icon we can’t do this.
I’m having issues with the update of the RFXtrx intergration because I can’t get fire_event to work.
I got it working in earlier releases with the button_pressed event but now (0.113.1) it stopped working.
configuration.yaml:
rfxtrx:
device: /dev/ttyUSB0
debug: true
automatic_add: true
devices:
# Deurbel
0b11000501b1a0e60c010f60:
off_delay:
seconds: 1
fire_event: true
Developer Tools state:
It doesn’t show up under State attributes.
My devices and everything is working exept for this.
I also saw that if you restart Home Assistant, binary sensors are set to on. My doorbell automation triggers if the state is going from off to on but if the binary_sensor is already on the automation won’t trigger. I wanted to fix this by setting fire_event to true but that isn’t working anymore. 
I hope someone can help me.
Edit:
Everything works again. 
Thanks to Rob I knew that the binary sensor thing was a bug that had to be fixed.
The fire_event event has changed from button_pressed to rfxtrx_event. This was later added to the documentation.
The fact that binary sensors are set to on when Home Assistant starts is an issue:
The fix is in place and tagged to go in 0.113.2, so hang on a bit.
we’re already on it: https://github.com/thomasloven/hass-browser_mod/issues/120
coudn’t hurt if other people with new/additional information on the subject would join in.
(edited the correct link now)
My Configuration Checker runs blow up with the following error:
Building wheels for collected packages: yarl
Building wheel for yarl (PEP 517): started
Building wheel for yarl (PEP 517): finished with status 'error'
Failed to build yarl
Started this thread with complete details… is that where I should report it? If not, where should I?
Did I get you right?
Old:
action:
- entity_id: script.1536739215145
service: script.turn_off
- entity_id: script.1536739215145
service: script.turn_on
sequence:
- wait_template: "{{ is_state('binary_sensor.secure', 'off') }}"
timeout: '00:40:00'
- entity_id: script.1536739215146
service: script.turn_on
Now can be:
mode: restart
action:
- wait_template: "{{ is_state('binary_sensor.secure', 'off') }}"
timeout: '00:40:00'
- entity_id: script.1536739215146
service: script.turn_on
Am I getting it right?
Yes, assuming the sequence snippet is in script.1536739215145.
So if/when the automation restarts, do you also want to stop & start script.1536739215146? If not, then they way you’re calling it from the automation is ok. If so, then the automation should probably call it like this:
- service: script.1536739215146
If I’ll go with
- service: script.1536739215146
Then Home Assistant would wait until script is done. So, if automation was triggered second time while script was running, would Home Assistant wait till the end of the script and then fire it second time?
No, that would be queued mode. You showed restart mode.
Let’s break it down…
automation:
- trigger:
- SOMETHING
mode: restart
action:
- wait_template: "{{ is_state('binary_sensor.secure', 'off') }}"
timeout: '00:40:00'
- service: script.1536739215146
When the automation calls the script that way it means the automation will wait for the script to finish before the automation is done.
If the automation triggers again before it has finished from the first trigger event, that will cause the automation to restart. Restarting means stopping what it’s doing, and then starting again. If it was in the wait_template, then the wait will be aborted. If, however, it was in the called script, then the called script will also be stopped. Once the wait_template or the called script is stopped, the automation actions will be run again; i.e., the script, which was just potentially stopped, will now start again (that is, after the wait_template, of course.)
Now, with the same automation as above, but changed to queued mode, if the automation is triggered again while it’s still waiting for the wait_template or the script to be done, that will cause the automation to “queue” another run of its actions, which will run once the run from the original trigger event finishes, which won’t finish until the script it called is finished. So, bottom line, in this case the script will be called once for each trigger event, and will be able to complete each time (assuming max_runs, which defaults to 10, is not exceeded.)
BTW, is there a reason for the actions to be in script.1536739215146? If not, then just move them directly into the automation’s action section.
Ok, I got now how queued mode works. I just wanted to understand the difference between:
service: script.1536739215146 # Which will make Home Assistant wait until script is done
and
- entity_id: script.1536739215146 # Which would just be triggered and then next step would run
service: script.turn_on
in a case of “restart”. In the first case script would be stopped too and started again (after wait_template). But in second case, script would not be stopped, would it? It was fired and then will run independent to automation (which could be retriggered and restart the action)?
And you are right there is no need in script.1536739215146 I am moving now sequence to action. I just want to get a good understanding for future changes, so I asked question on this example
UPD.
I just realised I have condition in another automation like:
- condition: state
entity_id: script.1536739215146
state: 'off'
Can I check if automation is running, or should I run script?
No problem.
Correct. That’s a “fire and forget” type of action.
Note, however, then the script’s mode will come into play. If it is still running, and the automation tries to run it again (whether or not the automation waits for it), what the script does at that point depends on its mode. If it’s the default (single) then the second call will be ignored. If it’s restart, then it will be restarted. If it’s parallel, then a second run of the script will be started in parallel with the first. If queued, then it will queue up a run to be executed once the current run completes.
Not if the automation’s mode is single or restart. For parallel and queued modes, you can indirectly by checking its current attribute, which is the number of currently active runs (either running in parallel, or running & queued up to run.)
If you need to know if that sequence of actions is running, then yes, that would be a good reason to keep them in a script.
2 Likes
Now it is clear for me. Thank you man, you rock
1 Like
Hello all,
Can’t go through all posts now, sorry if someone has already mentioned this. I did a quick search and found nothing.
About the MDI icon updates, more specifically about renamed ones. After updating to 0.113.0 my log showed a few lines like the one below, as expected when you use the mentioned icon:
WARNING (MainThread) [frontend.js.latest.202007160] Icon mdi:settings was renamed to mdi:cog, please change your config, it will be removed in version 0.115.
The thing is I hadn’t any reference to this icon in my ui-lovelace.yaml, took me a while to realize they were embedded in an entities card where I have some input_boolean toggles.
Specifying the icon with the new name in each entry inside the entities card did the trick.
Before:
- type: entities
show_header_toggle: false
entities:
- input_boolean.cozinha_forno
- input_boolean.cozinha_lavaroupas
After:
- type: entities
show_header_toggle: false
entities:
- entity: input_boolean.cozinha_forno
icon: mdi:cog
- entity: input_boolean.cozinha_lavaroupas
icon: mdi:cog
Thank you developers for such an amazing system.
Take care.
Tales
1 Like
Any idea if this could be an issue of the 0.113.1 version?
Log Details (ERROR)
Logger: homeassistant.components.websocket_api.http.connection.139813093147120
Source: components/smartthings/switch.py:37
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 7:38:24 AM (1 occurrences)
Last logged: 7:38:24 AM
409, message=‘Conflict’, url='https://api.smartthings.com/v1/devices/444dd3ug-9823-4028-bed8-5c408486241d0/commands
Traceback (most recent call last): File “/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py”, line 125, in handle_call_service await hass.services.async_call( File “/usr/src/homeassistant/homeassistant/core.py”, line 1265, in async_call task.result() File “/usr/src/homeassistant/homeassistant/core.py”, line 1300, in _execute_service await handler.func(service_call) File “/usr/src/homeassistant/homeassistant/helpers/entity_component.py”, line 208, in handle_service await self.hass.helpers.service.entity_service_call( File “/usr/src/homeassistant/homeassistant/helpers/service.py”, line 454, in entity_service_call future.result() # pop exception if have File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 595, in async_request_call await coro File “/usr/src/homeassistant/homeassistant/helpers/service.py”, line 485, in _handle_entity_call await result File “/usr/src/homeassistant/homeassistant/components/smartthings/switch.py”, line 37, in async_turn_off await self._device.switch_off(set_status=True) File “/usr/local/lib/python3.8/site-packages/pysmartthings/device.py”, line 991, in switch_off result = await self.command(component_id, Capability.switch, Command.off) File “/usr/local/lib/python3.8/site-packages/pysmartthings/device.py”, line 803, in command response = await self._api.post_device_command( File “/usr/local/lib/python3.8/site-packages/pysmartthings/api.py”, line 156, in post_device_command return await self.post(API_DEVICE_COMMAND.format(device_id=device_id), data) File “/usr/local/lib/python3.8/site-packages/pysmartthings/api.py”, line 404, in post return await self.request(“post”, self._api_base + resource, data=data) File “/usr/local/lib/python3.8/site-packages/pysmartthings/api.py”, line 385, in request resp.raise_for_status() File “/usr/local/lib/python3.8/site-packages/aiohttp/client_reqrep.py”, line 941, in raise_for_status raise ClientResponseError( aiohttp.client_exceptions.ClientResponseError: 409, message=‘Conflict’, url='https://api.smartthings.com/v1/devices/444dd3ug-9823-4028-bed8-5c408486241d0/commands
Sure I am a very community minded hence I made the people on this thread aware of it, on the other hand I did report it to the guy behind Bowser_Mod before you even replied to me
The very community minded one is the one who does not bully others with silly replies
Cheers
1 Like
Can anyone suggest how to use a chooser when using mqtt (zigbee2mqtt) buttons? Code looks like this:
- id: button_press_kitchen_coffee_single
alias: Button Press Kitchen Coffee Single
mode: queued
trigger:
- platform: device
domain: mqtt
device_id: 5e7862a937294c348177962ef68b5f34
type: click
subtype: single
discovery_id: 0x286d9700010b2f42 click_single
action:
- service: switch.toggle
data:
entity_id: switch.coffee_machine
- id: button_press_kitchen_coffee_hold
alias: Button Press Kitchen Coffee Hold
mode: queued
trigger:
- platform: device
domain: mqtt
device_id: 5e7862a937294c348177962ef68b5f34
type: click
subtype: hold
discovery_id: 0x286d9700010b2f42 click_hold
action:
- service: switch.toggle
data:
entity_id: switch.dishwasher
Each button press just differs with the subtype being single, double or hold. What would I put in the choose condition?
- choose:
- conditions:
- condition: template
value_template: "{{ ?? }}"
sequence:
That is not the impression you gave. But I apologise for not searching your issues to see that you had already posted there. Good work.
No worries and sorry for he misunderstanding
Cheers
Looks like very nice upgrades! Does the sub-second precision mean i can finally implement a double click-function directly as a script? (if button A pressed, wait 300ms, if button pressed again within the 300ms, run function X, of not, run function Y)