Dynamic Memory for Voice Assistant

Configuration Voice Assistant
1

There is a great blue print and post [here] that gives your voice assistant a dynamic memory that loads itself in context each conversation.
This works great until a reboot happens and the var looses its data.

There may be an easier way to do this, but here is what I have come up with to give your voice assistant a dynamic memory that loads itself into context and survives across reboots.

I created a template sensor and included some templating to help prevent overwriting the template sensor with “None” when the system reboots and the var dumps, duplicating data when appending data, and other undesired effects… The finished product looks like this:

    - trigger:
      - platform: state
        entity_id: var.voice_assistant_memory
    sensor:
      - name: Persistent Voice Assistant Memory
        state: >
          {% set new_memory = state_attr(trigger.entity_id, 'full_memory') %}
          {% set old_state = this.state %}
          {% if new_memory is not none and new_memory != '' and new_memory != old_state %}
            {% if old_state is not none and old_state != '' %}
            {% set old_state = '' %}
              {{ old_state }} {{ new_memory }}
            {% else %}
              {{ new_memory }}
            {% endif %}
          {% else %}
            {{ old_state }}
          {% endif %}

This will effectively set the value of the template sensor to match the value of the full_memory attribute of the dynamic memory variable. There is now an automatically updating backup of the dynamic memory stored in a template sensor! Cool!

But… The variable still dumps on reboots and its the variable that is used by the script so we are still loosing our memory on reboots even though we are making a backup of it.

We need an automation to bring our backup back into the variable upon reboots. I came up with this:

alias: Restore Voice Assistant Memory from Persistent Memory
description: >-
  Restores the Dynamic Voice Assistant Memory Variable by setting the value of
  var.voice_assistant_memory, full_memory to the value of
  sensor.persistent_voice_assistant_memory, memory
triggers:
  - trigger: homeassistant
    event: start
conditions: []
actions:
  - data:
      entity_id: var.voice_assistant_memory
      attributes:
        full_memory: "{{ states('sensor.persistent_voice_assistant_memory') }}"
    action: var.set

This automation will copy the “back up” into the empty dynamic memory upon reboot. The memories will then be available to the script and injected back into the LLM context.

I’m no expert and this is a very “felt my way through” attempt at this, but hopefully it helps other people or… someone knows an easier way to accomplish this and points it out!

–Happy Home Assistant Hacking

2

Not sure what you’re saying about clearing out or why your entity is named var.* If you use a Fes pattern trigger text sensor you don’t have to copy anything and it’s permanent.

Fes-style trigger text sensors are the entire basis for the library in Fridays setup… Link halfway through this post. How they’re used see the rest of the thread. Specifically anything related to the cabinet system.

2 Likes
3

Hey, thanks for the reply!
The link I shared specifies using Snarky Snarks Home Assistant Variable. That is why I was working with a .var entity.
I love your posts and try to follow along. I usually have to read them, get confused, go invent a long hard way to do something, then reread it and go
“ooooohhh…”
I’m going to get these cabinets set up. I have good solid indexing set up to your specs using your tools and I had an “it all clicked together” moment when I reread the “red phone” example.
You’re awesome and keep the good stuff coming man.

2 Likes
4
3 Likes