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)
hi folks,
sorry to spoil the party. need some help but first… great work on speed improvement and new features on automation such as loops and choose… amazing!!!
now problem i am facing with this latest upgrade (0.113 and 0.113.1) that after upgrade my google home minis are not discovered and i cant access them for any tts or other functions.
all become unavailable…
i tried going back to previous version from my snapshot and all are back and working fine…
Im using hassio docker on Synology and GH main or mini (3) along with other cast devices have been working fine for long now…never had issue like this except for occasionally being disconnected etc.
i have not made any change in router (Google WIFI) recently or individually on GM devices… everything starts working again soon i restore the backup (0.112).
any idea???
sorry if i missed anything from breaking change but dont remember seeing anything on this topic.
The problem is that you’re using a newer style device type trigger and not the more traditional MQTT trigger. If you use the latter then the corresponding trigger variable is documented. If you use the former, to my knowledge, it isn’t.
I would suggest changing to the more traditional trigger. Then you can put both triggers into one automation, and then in the action section you can use the trigger variable to determine which trigger fired.
Any suggestions how? This was the only way I could get the Zigbee button going was using that style of trigger.
I haven’t tried this myself, but I believe it should do what you want:
input_boolean:
recent_click:
initial: off
automation:
- trigger:
- # Trigger that detects click goes here...
mode: restart
action:
- choose:
# Was there a click within the last 300 msec?
- conditions:
- condition: template
value_template: "{{ is_state('input_boolean.recent_click', 'off') }}"
sequence:
# NO: Record that one click has happened...
- service: input_boolean.turn_on
entity_id: input_boolean.recent_click
# ... and wait for another...
- delay:
milliseconds: 300
# ... another click did not happen.
- service: input_boolean.turn_off
entity_id: input_boolean.recent_click
- # Do single-click actions here...
default:
# YES
- service: input_boolean.turn_off
entity_id: input_boolean.recent_click
- # Do double-click actions here...
Note that I’m working on a new script action, namely wait_for_trigger, that is designed for just this sort of thing. It would look like this:
- trigger:
- # Trigger that detects click goes here...
mode: single
action:
- wait_for_trigger:
- # Trigger that detects click goes here...
timeout:
milliseconds: 300
continue_on_timeout: true
- choose:
- conditions:
- condition: template
value_template: "{{ wait_trigger is none }}"
sequence:
- # Do single-click actions here...
default:
- # Do double-click actions here...
1 Like
I don’t use MQTT, so I’m not as familiar with it. But, at least in theory, all events that can be detected using a new style device type trigger should be able to be done with the more traditional type of trigger, too. Once you figure out how to substitute you current trigger with the one I referenced, then you can use the trigger variable I also referenced in my last reply. Something like:
- choose:
- conditions:
- condition: template
value_template: "{{ trigger.payload... }}"
For the same zigbee button :
my manual automation :
- id: '1567689190101'
alias: bedlicht aan
trigger:
- platform: mqtt
topic: zigbee2mqtt/ikea_button1/click
payload: 'on'
action:
- data:
entity_id: light.light_ikea1_light
service: light.turn_on
Created with the automation editor :
- id: '1595945774178'
alias: test1
description: ''
trigger:
- device_id: 245279fcc1a241e78c427431c325d8a3
discovery_id: 0x000d6ffffeac1f8a click_on
domain: mqtt
platform: device
subtype: 'on'
type: click
condition: []
action:
- data: {}
entity_id: light.light_ikea1_light
service: light.turn_on
mode: single
1 Like
Thanks!
@callifo, in that case, then maybe this:
- trigger:
- platform: mqtt
topic: zigbee2mqtt/ikea_button1/click
- choose:
- conditions:
- condition: template
value_template: "{{ trigger.payload == 'single' }}"
sequence:
- service: switch.toggle
data:
entity_id: switch.coffee_machine
- conditions:
- condition: template
value_template: "{{ trigger.payload == 'hold' }}"
sequence:
- service: switch.toggle
data:
entity_id: switch.dishwasher
1 Like
Same here v0.113.1
http://192.168.200.210:8123/frontend_latest/chunk.cf565e41b8a8dce0642a.js:133:238 Uncaught TypeError: Cannot read property 'header' of null
Great, looking forward to the new action. Have waited a good while for the sub-second delays, so I can wait a bit longer for that 
1 Like
after updating to 113.2 just now, the first thing I hear is quite disheartening. the template that has been working for ages all of a sudden makes the tts speak %20 on each space in:
- service: script.intercom_message
data_template:
message_en: >
Good {{states('sensor.part_of_day')}}, Home-assistant Rpi4 is back up and running since
{{as_timestamp(now())|timestamp_custom('%d %b %X')}} and it is
{{states('sensor.temp_current')}} degrees.
has anything changed that might have caused this? Ive tried it in various languages, but the result is the same.
the template is parsed as it should:
4 Likes
I have the same issue, using TTS for door sensors, automation using Node-red.
Same here with all my TTS alerts (door, weather, alarm).