REST integration not working

Configuration
1

I installed core 2025.1.3 today and all my REST sensors have disappeared. I hastily restored from the overnight backup but they are all still missing. If I go to the entities list & filter by integration, REST is missing from the dropdown implying that it hasn’t loaded. I have tried restarting several times including a power off/on cycle. I have tried reloading the YAML by section (ie just the template entities or just the REST entities). This is the only reference to REST in the log:

Logger: homeassistant.setup
Source: setup.py:497
First occurred: 15:53:08 (129 occurrences)
Last logged: 15:53:08
Unable to prepare setup for platform 'rest.sensor': Unable to set up component.

I have checked that the API’s I’m going to with my REST sensor are working by using CURL in the terminal window. I have tested the REST sensors YAML work in the developer tools template tester. I don’t know what else to do. I feel aggrieved that everything worked perfectly well until I tried to install the update and that restore didn’t reverse whatever error the update caused!
Please HELP!

2

You can’t test the rest yaml in developer tools without going through extra hoops. Did you just copy paste the yaml to test it?

3

Well not exactly. I used the supplier API to get the JSON and added {% set value_json = xxx %} above the REST YAML code.

4

Ok, that’s the correct way. Check your logs for errors on startup then. Your raw logs, not what you took a screenshot of above.

5

You mean home-assistant.log? In there I’m clearly getting a ton of errors due to all the REST entities being unavailable, but the messages relating to the integration look like this (many of)

2025-01-21 16:58:29.611 DEBUG (MainThread) [homeassistant.components.rest] Finished fetching rest data data in 1.498 seconds (success: True)

and a zillion copies of this

2025-01-21 16:58:30.422 ERROR (MainThread) [homeassistant.setup] Unable to prepare setup for platform 'rest.sensor': Unable to set up component.
6

You’ll have to find something that stands out. Typically at the front. Also, share your configuration if possible.

7

I’ve spent hours on this and can’t find any errors that aren’t a result of a REST entity being unavailable, so how can I see what comes first?
My configuration is large and includes a lot of rest sensors from quite a few different resources. I’m not quite sure which to share without inundating you! The thing is I haven’t changed anything today - it all went bad when I did the core update.
e.g. The most recent code (being worked on yesterday but working fine when I finished) is this:

rest:
  - resource_template: https://admiraltyapi.azure-api.net/uktidalapi-premium/api/V2/Stations/0536/TidalEventsForDateRange?StartDate={{ (as_datetime(states('input_datetime.tidequery'))-timedelta(hours=15)).strftime("%Y-%m-%d") }}&EndDate={{ (as_datetime(states('input_datetime.tidequery'))+timedelta(hours=15)).strftime("%Y-%m-%d") }}
    scan_interval: 120000
    headers:
      Ocp-Apim-Subscription-Key: XX
      Cache-Control: no-cache
    sensor:
      - name: "TideQueryEventLast"
        unique_id: "tidequeryeventlast"
        value_template: >
          {% set idx = value_json.index(value_json|selectattr("DateTime", ">", states('input_datetime.tidequery')|as_timestamp|timestamp_custom('%Y-%m-%dT%H:%M', local=false))|list|first) -%}
          {% set tqi = idx | default(1) -%}
          {{ as_datetime(value_json[tqi -1]['DateTime']+'+00:00') }}
        device_class: timestamp
      - name: "TideQueryEventLastH"
        unique_id: "tidequeryeventlasth"
        value_template: >
          {% set idx = value_json.index(value_json|selectattr("DateTime", ">", states('input_datetime.tidequery')|as_timestamp|timestamp_custom('%Y-%m-%dT%H:%M', local=false))|list|first) -%}
          {% set tqi = idx | default(1) -%}
          {{ value_json[tqi -1]['Height']|float(0)|round(2) }}
        state_class: measurement
        unit_of_measurement: m
      - name: "TideQueryEventNext"
        unique_id: "tidequeryeventnext"
        value_template: >
          {% set idx = value_json.index(value_json|selectattr("DateTime", ">", states('input_datetime.tidequery')|as_timestamp|timestamp_custom('%Y-%m-%dT%H:%M', local=false))|list|first) -%}
          {% set tqi = idx | default(2) -%}
          {{ as_datetime(value_json[tqi]['DateTime']+'+00:00') }}
        device_class: timestamp
      - name: "TideQueryEventNextH"
        unique_id: "tidequeryeventnexth"
        value_template: >
          {% set idx = value_json.index(value_json|selectattr("DateTime", ">", states('input_datetime.tidequery')|as_timestamp|timestamp_custom('%Y-%m-%dT%H:%M', local=false))|list|first) -%}
          {% set tqi = idx | default(2) -%}
          {{ value_json[tqi]['Height']|float(0)|round(2) }}       
        state_class: measurement
        unit_of_measurement: m
8

HA core? Is that your installation method? Are you running the correct version of python?

9

I’ve got HA OS running “bare metal” on a dedicated mini-pc, the system setup says:

Core
2025.1.2
Supervisor
2024.12.3
Operating System
14.1
Frontend
20250109.0

Everything is setup by HA, as far as I know I don’t have python other than what is inside HA.

10

Whelp, without the bare logs, there’s not much I can point you to do short of re-installing everything.

11

What are bare logs? Can I send them to you?

12

Just your logs, somewhere in your log file is likely a log line explaining why it cannot set up the rest integration. Either through a traceback or hand-tailored error.

13

Thanks. The log file is huge so I won’t send it. I’ll go through it more thoroughly looking for what you describe. Can I get back to you on this thread tomorrow when I’ve done this?
I’m very grateful for your help!

14

Thanks for the guidance. The problem was in how two of the REST resource templates were formed. They both uses an input_datetime and strftime to form the resource and it appears that during a restart this is not resolved before the REST is called and for some reason if the resource_template fails it causes ALL the REST sensors to fail. The reason this didn’t some to light during development was that I had been testing by reloading the YAML rather than restarting.
My solution is to use a trigger sensor which retains its value during a restart. So I’ve replaced this:-

  - resource_template: https://admiraltyapi.azure-api.net/uktidalapi-premium/api/V2/Stations/0536/TidalEventsForDateRange?StartDate={{ (as_datetime(states('input_datetime.tidequery'))-timedelta(hours=15)).strftime('%Y-%m-%d') }}&EndDate={{ (as_datetime(states('input_datetime.tidequery'))+timedelta(hours=15)).strftime('%Y-%m-%d') }}

With this:-

  - resource_template: https://admiraltyapi.azure-api.net/uktidalapi-premium/api/V2/Stations/0536/TidalEventsForDateRange?StartDate={{ state_attr('sensor.tidequerytiming','StartDate') }}&EndDate={{ state_attr('sensor.tidequerytiming','EndDate') }}

with the trigger sensor being:

  - trigger:
    - platform: state
      entity_id: input_datetime.tidequery
      not_to:
        - unknown
        - unavailable    
    sensor:
    - name: tidequerytiming
      unique_id: tidequerytiming
      state: "{{ as_datetime(states('input_datetime.tidequery')).strftime('%Y-%m-%dT%H:%MZ') }}"
      attributes:
        StartDate: "{{ (as_datetime(states('input_datetime.tidequery'))-timedelta(hours=15)).strftime('%Y-%m-%d') }}"
        EndDate: "{{ (as_datetime(states('input_datetime.tidequery'))+timedelta(hours=15)).strftime('%Y-%m-%d') }}"
1 Like