home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
71.88k stars 30.11k forks source link

Can't Access Frontend - REST sensor #42552

Closed danbayliss closed 3 years ago

danbayliss commented 3 years ago

The problem

I upgraded to 0.117 using the Supervisor update button in the frontend and watched the upgrade on the Supervisor logs but when the 0.117 container started up I couldn't access the frontend. If i delete configuration.yaml and reboot the frontend comes up with default config but it refuses to open with my normal configuration.yaml. Downgrading back to 0.116.4 (via command line) fixes the issue. I ran the upgrade again but the same happened so I've now downgraded back to 0.116.4

Environment

Problem-relevant configuration.yaml

Traceback/Error logs

20-10-29 04:18:42 INFO (MainThread) [supervisor.homeassistant.core] Updating Home Assistant to version 0.117.0
20-10-29 04:18:42 INFO (SyncWorker_2) [supervisor.docker.interface] Updating image homeassistant/qemux86-64-homeassistant:0.116.4 to homeassistant/qemux86-64-homeassistant:0.117.0
20-10-29 04:18:42 INFO (SyncWorker_2) [supervisor.docker.interface] Downloading docker image homeassistant/qemux86-64-homeassistant with tag 0.117.0.
20-10-29 04:19:25 INFO (SyncWorker_2) [supervisor.docker.interface] Stopping homeassistant application
20-10-29 04:19:26 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API error: Received message 8:1000 is not str
20-10-29 04:19:26 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API connection is closed
20-10-29 04:20:11 INFO (SyncWorker_2) [supervisor.docker.interface] Cleaning homeassistant application
20-10-29 04:20:11 INFO (MainThread) [supervisor.homeassistant] Update pulse/client.config: /data/tmp/homeassistant_pulse
20-10-29 04:20:14 INFO (SyncWorker_3) [supervisor.docker.homeassistant] Starting Home Assistant homeassistant/qemux86-64-homeassistant with version 0.117.0
20-10-29 04:20:14 INFO (MainThread) [supervisor.homeassistant.core] Wait until Home Assistant is ready
20-10-29 04:21:39 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
20-10-29 04:21:42 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
20-10-29 04:22:15 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
20-10-29 04:22:18 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
20-10-29 04:22:51 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
20-10-29 04:22:54 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config: 
20-10-29 04:25:18 INFO (MainThread) [supervisor.homeassistant.core] Updating Home Assistant to version 0.116.4
20-10-29 04:25:18 INFO (SyncWorker_0) [supervisor.docker.interface] Updating image homeassistant/qemux86-64-homeassistant:0.117.0 to homeassistant/qemux86-64-homeassistant:0.116.4
20-10-29 04:25:18 INFO (SyncWorker_0) [supervisor.docker.interface] Downloading docker image homeassistant/qemux86-64-homeassistant with tag 0.116.4.
20-10-29 04:26:01 INFO (SyncWorker_0) [supervisor.docker.interface] Stopping homeassistant application
20-10-29 04:26:02 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API error: Received message 8:1000 is not str
20-10-29 04:26:02 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API connection is closed
20-10-29 04:26:16 INFO (SyncWorker_0) [supervisor.docker.interface] Cleaning homeassistant application
20-10-29 04:26:16 INFO (MainThread) [supervisor.homeassistant] Update pulse/client.config: /data/tmp/homeassistant_pulse
20-10-29 04:26:18 INFO (SyncWorker_5) [supervisor.docker.homeassistant] Starting Home Assistant homeassistant/qemux86-64-homeassistant with version 0.116.4
20-10-29 04:26:18 INFO (MainThread) [supervisor.homeassistant.core] Wait until Home Assistant is ready
20-10-29 04:27:22 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API request initialize
20-10-29 04:27:22 INFO (MainThread) [supervisor.api.proxy] WebSocket access from a0d7b954_nodered
20-10-29 04:27:22 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API request running

Additional information

When visiting the frontend it would give a NGINX 504 Gateway Time Out error message I don't have the NGINX logs but it would say upstream timed out Home Assistant observer said Supervisor was connected

frenck commented 3 years ago

It is hard to say what is going on with the currently provided information. Anything in the home-assistant.log file?

Have you tried disabling all custom components?

jazzmonger commented 3 years ago

I'm having the same issue on my iPad in Chrome. Totally blank screen after ug. Ug completed ok but blank screen after 2nd restart.

Chrome version 86.0.4240.93

Safari works fine. Interestingly Chrome Private window works fine after logging in. But regular Chrome window is completely s blank. Changing themes has no effect.

F2046B24-A5B7-4EB1-8E11-BF0B4752F879

jazzmonger commented 3 years ago

Clearing cookies and site data In Chrome/history (not just cache) resolved it for me.

Working ok now. This is the first time I've had to do this as far back as I can recall, and I've caught pretty much every upgrade since 0.95.

danbayliss commented 3 years ago

I tried upgrading with HACS and all custom_components removed and the same happened. I've now gone through my configuration.yaml file and found that my rest sensors are causing this issue. I've just entered one and it makes the issue appear but when I remove it and reboot it resolves it.

The code is

  - platform: rest
    name: Electricity Raw Data - Yesterday
    resource_template: >
      {% set starttime = (as_timestamp(now()) - (86400*2)) | timestamp_custom('%Y-%m-%d', True) + 'T00:00:00' %}
      {% set endtime = (as_timestamp(now()) - (86400*2)) | timestamp_custom('%Y-%m-%d', True) + 'T23:59:59' %}
      https://api.octopus.energy/v1/electricity-meter-**removed**period_from={{starttime}}&period_to={{endtime}}
    headers:
      Authorization: Basic **removed**
    value_template: "{{ value_json.count }}"
    scan_interval: 7200
    json_attributes:
      - results

When the above code is in configuration.yaml the frontend does come up for a few seconds as I see Home Assistant is starting, not everything will be available until it is finished. however after a few seconds the frontend stops responding and I see the following in my Supervisor logs 20-10-29 10:52:16 ERROR (MainThread) [supervisor.homeassistant.api] Error on call http://172.30.32.1:8123/api/config:

I don't see anything in my home-assistant.log file. I'm not sure what's wrong with the above code as it used to work previously on 0.116.4

gopheridze commented 3 years ago

I confirm. After removing REST sensors and commands from config no issue appears and frontend starts normally. Enabling any of the REST components in config stops frontend to respond.

here're my components:

rest_command:
  reboot_shelly1_kitchen_fan:
    url: 'http://shelly1-kitchen-fan.local/reboot'
    username: !secret shelly_user
    password: !secret shelly_password

---

- platform: rest
  name: "Neptun Cold Water"
  resource: SOME_URL_HERE
  headers: 
    Authorization: !secret neptun_token
    Accept: application/json
  json_attributes:
    - value
  value_template: '{{ value_json.value / 1000 }}'
  scan_interval: 600
  unit_of_measurement: "м³"
  timeout: 20

- platform: rest
  name: "Neptun Hot Water"
  resource: SOME_URL_HERE
  headers: 
    Authorization: !secret neptun_token
    Accept: application/json
  json_attributes:
    - value
  value_template: '{{ value_json.value / 1000 }}'
  scan_interval: 600
  unit_of_measurement: "м³"
  timeout: 20

- platform: rest
  name: "Neptun Cold Water Daily"
  resource_template: "SOME_URL_HERE/?date_from={{ now().strftime('%Y-%m-%d') }}&date_to={{ now().strftime('%Y-%m-%d') }}&interval=day"
  headers: 
    Authorization: !secret neptun_token
    Accept: application/json
  json_attributes:
    - cold
  value_template: '{{ value_json[0].cold }}'
  scan_interval: 600
  unit_of_measurement: "л"
  timeout: 20

- platform: rest
  name: "Neptun Hot Water Daily"
  resource_template: "SOME_URL_HERE/?date_from={{ now().strftime('%Y-%m-%d') }}&date_to={{ now().strftime('%Y-%m-%d') }}&interval=day"
  headers: 
    Authorization: !secret neptun_token
    Accept: application/json
  json_attributes:
    - hot
  value_template: '{{ value_json[0].hot }}'
  scan_interval: 600
  unit_of_measurement: "л"
  timeout: 20
ghost commented 3 years ago

Thanks I removed the rest and it works now

zvldz commented 3 years ago

Not using rest does not solve the problem, it needs fixing.

probot-home-assistant[bot] commented 3 years ago

rest documentation rest source (message by IssueLinks)

mkanet commented 3 years ago

@gopheridze If your issue is like mine, I have a feeling you can further narrow down the issue by commenting out ONLY your REST sensors that include code like below:

value_template: '{{ value_json[0].xxxxx }}'

It seems 0.117.0 REST sensors aren't able to properly parse JSON responses that have more than one key (at least for my issue). You should be able to keep your REST sensors in your configuration like below that only expect a single key:

value_template: '{{ value_json.value / 1000 }}'
dale3h commented 3 years ago

I attempted to help debug this issue with another affected user on Discord, but was unable to come to a working solution: https://discord.com/channels/330944238910963714/330990055533576204/771591995797274656

LukeSkywalker92 commented 3 years ago

Same for me...had to disable rest sensors to access the frontend in 0.117

mindsocket commented 3 years ago

I ran into this issue today also after upgrading from 116.4 to 117.0, with no obvious mention in the log of the rest sensor.

I commented out 1 of 2 rest sensors, and that got things back up and running.

This one works - it has a regular resource and a value_template...

- platform: rest
  name: redacted
  resource: https://redacted/v1/redacted?status=redacted
  headers:
    Authorization: !secret redacted
  value_template: "{{ value_json[0].name }} #{{ value_json[0].redacted }} - {{ value_json[0].redacted.name }}"
  scan_interval: 86400
  json_attributes_path: "$.[0]"
  json_attributes:
    - _id
    - redacted

This one breaks, the difference appears to be the use of a resource_template. It might be worth noting that the resource_template here frequently resolves to an invalid (404) url...

#- platform: rest
#  name: redacted
#  resource_template: https://redacted/v1/redacted/{{ state_attr('sensor.redacted','_id')}}/redacted
#  headers:
#    Authorization: !secret redacted
#  value_template: "{{ value_json.stages[value_json.stage].steps[value_json.stages[value_json.stage].step].description }}"
#  scan_interval: 86400
#  json_attributes:
#    - stage
#    - init
#    - enabled
#    - stages
#    - active
sr-as2 commented 3 years ago

I'm having the same problem (#42589) but i don't use resource_template

  - platform: rest
    resource: http://192.168.0.39/JQ=8830
    name: ecs_temperature
    unit_of_measurement: "°C"
    timeout: 30
    scan_interval: 60
    value_template: "{{ value_json['8830']['value'] }}"
Cougar commented 3 years ago

The problem is already in 0.117.0b0. In my setup such sensor blocks the whole HA:

  - platform: rest
    scan_interval: 10
    resource_template: 'https://www.xn--jtsiabi-5wa.ee/json.data.php?action=data&draw_route=false&region_id=1&car[6]={{ states.sensor.date_time_iso.state|replace("T", " ") }}&car[7]={{ states.sensor.date_time_iso.state|replace("T", " ") }}'
    name: jatsiabi_car_location
    value_template: 'Available'
    json_attributes:
      - '6'
      - '7'

I added some logging for rendering calls and this template was always the last one that was called.

I made profile graphs with working 0.116.4 and broken 0.117.0b0. Here it is visible how 0.117.0b0 doesn't do much and just blocks everything.