this one is mine:
Logger: frontend.js.latest.202007160
Source: components/system_log/__init__.py:209
First occurred: 0:13:56 (4 occurrences)
Last logged: 0:13:59
http://192.168.1.2:8123/frontend_latest/chunk.cf565e41b8a8dce0642a.js:133:238 Uncaught TypeError: Cannot read property 'header' of null
No, it will go off when the door closes.
Youâre right.
I also didnât realise those were two separate automations , which is what Iâm trying to avoid by using the new choose functionality.
Thanks. I had same issue with yeelight discovery for 11 yeelights and manually configuring them fixed it.
Finally figured it out with bdraco and RobCâs help. For me it was speedtest.net integration https://www.home-assistant.io/integrations/speedtestdotnet/
Having two simpler automations is often a better solution that one complex automation. Not sure why you would want the more complex solution.
But, if you really want just one automation, and you really want to use choose, then how about this:
- trigger:
# Trigger when door opens or closes
- platform: state
entity_id: binary_sensor.laundry_door_sensor
to:
- 'on'
- 'off'
# Trigger when door has been open for 5 minutes
- platform: state
entity_id: binary_sensor.laundry_door_sensor
to: 'on'
for: '00:05'
action:
- choose:
# Did door close or has it been open for 5 min?
- conditions:
- condition: template
value_template: >
{{ trigger.to_state.state == 'off' or
trigger.for is not none }}
# Yes, turn off lights
sequence:
- service: light.turn_off
entity_id: light.laundry_lights
# No, door opened, turn on lights
default:
- service: light.turn_on
entity_id: light.laundry_lights
Yes have seen that a couple of times. Couldnât work out why. Now you mention developer tools I just tested it. I get the error every time I visit the dev tools and select a tab.
EDIT: Opened an issue,
Close, and there are always two messages that come together:
2020-07-24 15:36:54 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=system_log, service=write, service_data=logger=frontend.js.latest.202007160, message=https://<domain>:<port>/frontend_latest/chunk.cf565e41b8a8dce0642a.js:133:238 Uncaught TypeError: Cannot read property 'header' of null>
2020-07-24 15:36:54 ERROR (MainThread) [frontend.js.latest.202007160] https://<domain>:<port>/frontend_latest/chunk.cf565e41b8a8dce0642a.js:133:238 Uncaught TypeError: Cannot read property 'header' of null
Roll Back Issues!
So, I am on 112.3 HA_OS/RPi3+(SSD)
Since yesterday, have tried upgrading at least 4 times but the upgrade always rolls backâŚthe urgade goes through first byt HA keep display ânot fully startedâ and finally rolls back.
20-07-26 02:44:32 INFO (MainThread) [supervisor.homeassistant] Update Home Assistant to version 0.113.1
20-07-26 02:44:32 INFO (SyncWorker_0) [supervisor.docker.interface] Update image homeassistant/raspberrypi3-homeassistant:0.112.3 to homeassistant/raspberrypi3-homeassistant:0.113.1
20-07-26 02:44:32 INFO (SyncWorker_0) [supervisor.docker.interface] Pull image homeassistant/raspberrypi3-homeassistant tag 0.113.1.
20-07-26 02:49:00 INFO (SyncWorker_0) [supervisor.docker.interface] Stop homeassistant application
20-07-26 02:49:01 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API error: Received message 8:1000 is not str
20-07-26 02:49:01 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API connection is closed
20-07-26 02:50:02 INFO (SyncWorker_0) [supervisor.docker.interface] Clean homeassistant application
20-07-26 02:50:02 INFO (MainThread) [supervisor.homeassistant] Update pulse/client.config: /data/tmp/homeassistant_pulse
20-07-26 02:50:03 INFO (SyncWorker_4) [supervisor.docker.homeassistant] Start homeassistant homeassistant/raspberrypi3-homeassistant with version 0.113.1
20-07-26 02:50:32 INFO (MainThread) [supervisor.homeassistant] Updated Home Assistant API token
20-07-26 02:50:33 INFO (MainThread) [supervisor.homeassistant] Home Assistant pip installation in progress
20-07-26 02:55:15 INFO (MainThread) [supervisor.homeassistant] Home Assistant pip installation done
20-07-26 03:05:19 WARNING (MainThread) [supervisor.homeassistant] Don't wait anymore of Home Assistant startup!
20-07-26 03:05:19 CRITICAL (MainThread) [supervisor.homeassistant] HomeAssistant update fails -> rollback!
I do not have many add-ons or custom settings; just a few. I would appreciate some help with which direction to proceed. My add-ons are:
HACS (DarkTheme, Nodered, Alexa Media Player)
Tasmota IRHvac
sensor.mitemp_bt
Button Card
Mini Media Player
PS: Did a fresh install to lates image and restored but that did not help.
HACS is a custom component, not an add-on.
Figured out - hope this is of use to someone else.
The problem was with the sensor.mitemp_bt (I was runnuing the beta version). Upgraded that to full and was able to move to 113.1
My bad, Nick - any thing not out of the standard install was perhaps what I was referring to. Thanks for pointing out - terminology is important.
Glad you got it all going 
Hello @pnbruckner and everyone,
is it just me or the new automations & scripts running modes doesnât work at all?
Iâm using the following setup to test them:
# Example configuration.yaml entry
input_boolean:
lightbulb:
name: dummy light bulb
icon: mdi:lightbulb
# scripts.yaml entry
turn_the_light_for_5_sec:
alias: Turn the light for 5 sec
icon: mdi:toggle-switch
mode: restart
sequence:
- data: {}
entity_id: input_boolean.lightbulb
service: input_boolean.turn_on
- delay: 00:00:5
- data: {}
entity_id: input_boolean.lightbulb
service: input_boolean.turn_off
so when I execute the script once, it works as expected, but when I execute it twice within the 5 sec delay the dummy light bulb stays on and never turns off.
if I execute the script for the third time the dummy bulb gets turned off after 5 more seconds
It doesnât matter what running mode is chosen (single, queued, parallel) the results are the same.
Tested on 0.113.1 running on docker.
p.s. I also test this against real switch over MQTT and the results are the same
Was it just me, or it seems this update broke the can_cancel attribute that you can use to customize scripts, for it to appear as a switch-like in the UI, rather than âEXECUTEâ/âCANCELâ?
Can anyone confirm?
Thanks in advance.
Correct, it no longer shows as a switch on the frontend, but the wording changes for an active script from âEXECUTEâ to âCANCELâ and still works the same way.
@pnbruckner Is this an expected change (not documented, as far as I can tell), or a regression from the recent script additions?
same here, everything seems to start fine with 0.113.1 but than automatic rollback after 10 mins, no clue why
The can_cancel attribute was only present in scripts that contained delays or waits, because those were the only ones that could âsuspend.â This is no longer the case. All scripts can now be canceled. Hence there was no longer a need for the attribute. I believe there are other, more meaningful attributes now, but I didnât do that. The can_cancel attribute, and now the new ones, have more to do with how the frontend works, and I didnât implement that part, so Iâm not as familiar with it.
The script works, and calling the script a second time does indeed cause it to restart. The script is working as it should.
How are you causing the script to execute? If you do it via the frontend, you may not have noticed that after you click the EXECUTE button it changes to CANCEL. So when you click again youâre not starting the script again, youâre stopping it. (See @ppluckyâs post just after yours.)
This is a frontend thing. If you think it should work differently, then you should create a feature request topic. I donât work on the frontend so thereâs nothing I can do about it.
And to convince yourself that the script is actually doing what it should, first make sure the input_boolean is off, then go to the SERVICES page, select the script from the Service drop down list, and click CALL SERVICE. Wait a couple of seconds, then click CALL SERVICE again. Now go look at the history of the input_boolean. It would have been on about 7 or 8 seconds depending on exactly when you clicked CALL SERVICE the second time.