Persistent object storage and retrieval in automations

With the addition of the conversation agent, I’d like to start storing my recipes in HomeAssistant, since many of them are generated from LLM data anyways.

I crafted a prompt that reliably returns recipes in JSON format so it can be parsed in an automation. I can use the Shopping List integration to display the recipe so I can check ingredients off as I add them.

However, I don’t want to generate a new recipe for banana bread every time I make it. I’d rather retrieve the object from storage if it exists already, and seamlessly generate and store new recipes when requested.

What’s the best way to go about storing JSON persistently, where both storage and retrieval can be accomplished in a script/automation?

The options I’ve considered:

  • The File integration allows you read the content of a file (and even parse JSON, yay!) but it only grabs the last line of a file, so I’d have to strip all newline characters from the file before saving.
  • The Command Line sensor could contain the whole JSON file, and I just parse the string in the automation.
  • I could try using Shell Commands to write the JSON to file, but I’d have to create a text sensor to temporarily store the stringified JSON, which raises two concerns:
    • I’m not sure how to sanitize arbitrary JSON so it can be safely injected into a shell command.
    • Is there a limit to the length of a shell command? The recipes are typically around 1k characters, but they could be upwards of 4k characters, and I’d rather have an even higher upper bound.

There is a limit to state values, 255 characters. Attribute values however have a much larger limit, 65k if I remember correctly.

That’s a great callout! If I can avoid using an entity as an intermediate step I’d rather do that, but if it can’t be avoided I’ll try to store each recipe as a separate attribute.

If I recall correctly, attributes can be objects, right? I could have a sensor.recipes with an attribute “banana bread” with keys like “ingredients” and “instructions”, yes?

Not sure how I’d go about adding new attributes while preserving the existing ones.

You can create one or more custom Jinja2 macros which can be called within a template.

Reusing templates

I’m not sure I follow how that helps store/retrieve recipes. Right now I only use those macros when I have complex Jinja templates that I reuse. For example, I have one for formatting geocoded location for my mushroom chips cards so it’s not so wordy (blank if home, street if in home town, city if in home state, state if in country, etc) but I don’t see the use case here.

Sorry, I glossed over the “store” aspect. You want to programmatically store JSON and that’s not possible with a custom macro.

I believe this may fulfill your requirements. It’s a Trigger-based Template Sensor with custom events for creating/deleting an attribute and its value. In other words, it offers the ability to create “variables”.

WTH can't input helpers be read only in UI - #13 by TheFes

Because it relies on attributes, the value can be up to ~16Kb in length.

2 Likes

That looks like a great solution! Thank you so much!

1 Like

You must have that post bookmarked

1 Like

Yes indeed. I bookmark all the ones that I feel I may need to reference in the future.

FWIW, I have used the technique you employed for all kinds of applications: last 5 music tracks that have been played, last 10 doors that were opened (and when), etc. Thanks for the inspiration.

1 Like