#setting a sensor attribute via python

1 messages · Page 1 of 1 (latest)

snow grail
#

Hi everyone,

I’m trying to clarify the correct / supported way to store a dynamic text response coming from an automation, and I’d like to confirm whether my understanding is correct.

Context:

Home Assistant OS (latest stable)

An automation calls an external REST API (works, response received and visible in automation traces).

The automation then calls a python_script and passes the response text as a variable (reply).

The python script runs without errors and logs confirm it receives the full text correctly.

What I tried:

Updating a sensor defined via template: (state or attributes) from the python script (using hass.states.set()).

The script executes, but the sensor never updates and no error is logged.

My understanding so far:

python_script is not allowed to create or modify sensor entities, even if no explicit error is raised.

Template sensors are read-only and derived from templates, not meant to store arbitrary data.

Follow-up question:

Is the officially recommended approach to use a helper entity such as input_text to store this kind of dynamic text?

If so, how should longer texts be handled, since input_text has a character limit (255 by default, configurable but still limited)?

In my use case, the text can easily exceed 500–1000 characters (LLM-generated advice), so I want to make sure I’m using a supported pattern and not fighting the system.

Thanks a lot for your guidance!

round lintel
#

My idea would be the file integration. A file notification can store the data (if it is formatted as JSON) in a file. Every notification appends the data to the end of the file. To prevent it getting too big, you can delete the file with a shell command beforehand.
The file.read_data action can extract the JSON (or YAML) from the created file.

amber roostBOT
snow grail
#

i found a post sayning that i should use rest instead of python : I'll try this an tell you the resuklt :
rest:

  • resource: http://192.168.1.46:8000/chat
    method: POST
    headers:
    Content-Type: application/json
    payload_template: >
    {
    "user_id": "jacques",
    "message": "Contexte santé du jour : Poids {{ states('sensor.withings_poids') }} kg ; Moyenne 7j {{ states('sensor.poids_moyenne_7_jours') }} kg."
    }
    sensor:
    • name: "Nestor coaching santé"
      value_template: "OK"
      json_attributes:
      • reply
      • memory_count
        to set thesensor

and this script to actualise it
alias: Nestor – Coaching santé (auto)
trigger:

  • platform: state
    entity_id: sensor.withings_poids
  • platform: time
    at: "07:00:00"
    action:
  • service: homeassistant.update_entity
    target:
    entity_id: sensor.nestor_coaching_sante
    mode: single
    il i still have a length issue i'll try file 🙂
#

of course i dont want to send health data to a cloud LLM so i made mine locally, with stored context

snow grail
#

nope it doesnt work effinciently the rest instruction call automaticaly every 30 seconds.... my local llm dont appreciate that 🙂
changing to :

rest_command:
nestor_chat:
url: "http://192.168.1.46:8000/chat"
method: POST
headers:
Content-Type: application/json
payload: >
{
"user_id": "jacques",
"message": "Contexte santé du jour : Poids {{ states('sensor.withings_poids') }} kg ; Moyenne 7j {{ states('sensor.poids_moyenne_7_jours') }} kg."
}
keep you posted... (i'll try to get the lll message via notification after... (no text limit to notification)

snow grail
#

✅ Displaying a long AI-generated message in Home Assistant (final setup)

After many failed attempts, here is a stable, native Home Assistant solution
to display a long AI-generated message (>255 chars) coming from a local FastAPI API,
directly inside a dashboard card, without polling loops.

🎯 Goal

  • Event-based trigger (e.g. Withings weight update)
  • Single HTTP POST (rest_command)
  • Long text response
  • Displayed in a dashboard card
  • ❌ No REST sensor / no polling

🚫 What didn’t work well

  • REST sensors (polling & loops)
  • Reading persistent notifications in native cards (not supported)
  • Custom HACS notification cards (unmaintained / removed)
  • Filesystem tricks (fragile)

✅ Final architecture

sensor update
→ automation (mode: single)
→ POST to local FastAPI
→ long text reply
→ split into multiple input_text (255 chars)
→ native Markdown card

Yes, this stores the text, but it is:

  • 100% native
  • Stable across HA updates
  • No polling
  • No frontend hacks

Sometimes the clean solution is the one that respects Home Assistant’s real constraints.

#

🧩 Code examples (simplified)

1️⃣ rest_command (HTTP POST to local FastAPI)

rest_command: nestor_chat: url: "http://192.168.1.46:8000/chat" method: POST headers: Content-Type: application/json payload: > { "user_id": "jacques", "message": "Health context: weight {{ states('sensor.withings_poids') }} kg" }
2️⃣ Automation (event-based, no polling)
Triggered when the weight sensor changes.

`alias: Nestor – Health coaching after weigh-in
mode: single
trigger:

  • platform: state
    entity_id: sensor.withings_poids
    condition:
  • condition: template
    value_template: >
    {{ trigger.from_state.state != trigger.to_state.state }}
    action:
  • action: rest_command.nestor_chat
    response_variable: nestor_response

Clear previous content

  • service: input_text.set_value
    data:
    entity_id:
    - input_text.nestor_coaching_poids_sante_1
    - input_text.nestor_coaching_poids_sante_2
    - input_text.nestor_coaching_poids_sante_3
    - input_text.nestor_coaching_poids_sante_4
    value: ""

Split long reply into 255-char chunks

  • service: input_text.set_value
    data:
    entity_id: input_text.nestor_coaching_poids_sante_1
    value: "{{ nestor_response.content.reply[0:255] }}"
  • service: input_text.set_value
    data:
    entity_id: input_text.nestor_coaching_poids_sante_2
    value: "{{ nestor_response.content.reply[255:510] }}"
  • service: input_text.set_value
    data:
    entity_id: input_text.nestor_coaching_poids_sante_3
    value: "{{ nestor_response.content.reply[510:765] }}"
  • service: input_text.set_value
    data:
    entity_id: input_text.nestor_coaching_poids_sante_4
    value: "{{ nestor_response.content.reply[765:1020] }}"`
#

3️⃣ input_text helpers
input_text: nestor_coaching_poids_sante_1: max: 255 nestor_coaching_poids_sante_2: max: 255 nestor_coaching_poids_sante_3: max: 255 nestor_coaching_poids_sante_4: max: 255
4️⃣ Native Markdown dashboard card

type: markdown title: Health coaching content: > {{ states('input_text.nestor_coaching_poids_sante_1') }} {{ states('input_text.nestor_coaching_poids_sante_2') }} {{ states('input_text.nestor_coaching_poids_sante_3') }} {{ states('input_text.nestor_coaching_poids_sante_4') }}

This is fully native Home Assistant:

no REST sensor
no polling
no custom frontend
predictable and stable

#

💡 Missing Home Assistant building block (feedback)

While building this integration, one limitation became very clear.

What would greatly simplify external API / AI integrations is a native long-text state variable:

Desired characteristics

  • Permanent (survives restarts)
  • Not historized
  • No length limit (or very high)
  • Readable directly from dashboard cards
  • Event-driven (trigger on change / duration)
  • Writable from automations
  • Modifiable from Python scripts / external APIs

In short:

A permanent, non-historized, long-text state, designed for communication
with external services (AI, diagnostics, summaries).

This would fully respect Home Assistant’s philosophy:

  • no polling
  • no database bloat
  • no filesystem hacks

It would make AI and external API integrations much cleaner and safer
than current workarounds.

Just sharing feedback from a real-world use case.