Using ChatGPT for yaml Generation

Share your Projects!
1

I’ve been using ChatGPT to generate yaml for some complex automations to optimise my SolaX Inverter and Home Battery set-up.

Over the last 2 months, I’ve learnt a lot about ChatGPT - what it’s good at, and where it regularly fails.

I thought that I would start a thread to discuss how I’m using it.

Edit:

Now on GitHub: GitHub - UKMedia/ChatGPT-HA-Docs: Describes my approach at using ChatGPT within a Home Assistant environment
and my SolaX solution is an example of the code generated by ChatGPT: GitHub - UKMedia/SolaX-Automation-in-Home-Assistant

How I’m Using ChatGPT to Build a Rock-Solid SolaX-Based Energy Setup in Home Assistant

1. Some Context — What’s This Project All About?

I’m running a SolaX-based hybrid solar system — two inverters (master/slave), two battery banks, solar split between house and garage, with dynamic grid export limits and a bunch of smart devices (Smart Home, heat pump, etc.).

Managing all of that in Home Assistant is doable — but I’ve been retired for 12 years and my last role was as a Programme Director, specialising in recovering failing strategic IT programmes - so a long time since I last did any coding!

I had a number of fairly complex automations around, dynamically changing the inverter settings with the goal of:

  1. Minimise Grid charging,
  2. Minimising PV clipping, and
  3. Maximising Export Revenue.

But I wanted to try and incorporate Generative AI into reviewing these automations, so that the system learnt from errors between forecasts and actuals and automatically adjusted the rules for future calculations.

That’s where the “DAI + RBC” approach comes in. DAI = Distributed Automation Infrastructure. RBC = Rule-Based Coordination. It’s a fancy way of saying I treat Home Assistant like a real control system — with historical error correction.

ChatGPT was brilliant at reading a requirements document and generating the code in seconds. All with a test harness embedded, standard logbook entries, etc. It did however, have a habit of embellishing code with every bell and whistle it could think off and some of these automations were anything up to 500 lines long.

But where it really fell down was in bug fixing and code maintenance. Instead of editing code, it would regenerate the entire code block. The result was that it would randomly removed logic and functionality whilst carrying out minor code edits. And even if I asked for a logic audit between versions, it would confirm that all logic remained. So I reverted back to work mode and introduced a governance layer, with High Level & Detailed Design docs, coding standards, and interaction rules, backups/archiving of previous versions, change/defect tracking, and logic that can’t just break silently.

2. How I’m Using ChatGPT in This Setup

I’m not just asking ChatGPT random YAML questions. Instead, I’ve given it a set of governance rules and documents — like templates for how I want code structured, how it should respond, and defined workflows for New Functionality, Change Requests, Defect Reports, and Documentation Changes.

Here’s what it helps with:

  • Writing clean automations using my naming conventions
  • Generating scripts that follow my patterns
  • Checking if a request is even possible (before wasting time)
  • Drafting and formatting change control records
  • Helping tweak dashboards without breaking them

So it’s become a structured architecture driven, CMMI model based development environment - which it follows most of the time but I still have to really concentrate that it doesn’t deviate.

3. What’s Working — And What Still Trips It Up

:+1: Wins

  • YAML output is really solid when it follows the framework
  • Automations and scripts are generated fast and clean - average time less than 30 secs
  • I can track what changed and why — super helpful months later
  • It stops me from chasing dead ends by doing feasibility checks first

:-1: Rough Edges

  • Sometimes on new chats, it forgets to load the governance files properly
  • It still occasionally guesses sensor names instead of pulling from real YAML
  • It outputs more than one YAML block per card/script unless I remind it not to
  • It doesn’t persist context across sessions — so I have to re-upload docs
  • The concept of Projects isn’t fully implemented properly yest - even if I attach the governance docs to the ChatGPT project, I still have to attach them again to new chats and include the following Chat initialising prompt:
Developer: NEW CHAT CONTEXT – Home Assistant / DAI + RBC

This chat operates under the DAI / RBC governance framework and is initiated for projects governed by documented interaction, design, and coding standards.

To initialise this chat context efficiently, the following current live documents have been attached:

• DAI RBC High Level Design v1.1 (live).docx
• Home Assistant Guidelines DAI RBC v1.2 (live).docx
• ChatGPT Interaction Guidelines v1.2 (live).docx
• CR_DR_Log_20251102.docx

ChatGPT must immediately ingest and activate these documents as binding context upon upload. All behaviour, including entity use, code formatting, YAML output scope, and feasibility declarations, must comply without user enforcement. No assumptions or speculative actions are permitted.

If any attachments are missing, ChatGPT must prompt the user for the required documents before proceeding.

ChatGPT must always use the latest live versions; if newer documents are uploaded, they supersede prior baselines.

This governance context remains active for the duration of the project unless explicitly reset by the Owner.

Advisor Gate (Feasibility & Efficiency Control)

Purpose: To ensure ChatGPT (in the Advisor role) prevents wasted activity and saves user time by validating feasibility before executing any task or generating documents.

Process:

Feasibility Review: Prior to any requested work item, ChatGPT must verify that the task is both technically and procedurally feasible within current model capabilities and governance constraints. 

Advisory Declaration:

• If the request is fully achievable: proceed as normal.
• If the request is partially or wholly unachievable: ChatGPT must respond with:

  “Stop – this request cannot be delivered as stated because [reason]. The nearest compliant alternative is [alternative]."

User Confirmation: ChatGPT must not continue until explicit user confirmation is received on how to proceed.

Audit: Each feasibility declaration is recorded as part of the audit trail and serves as an advisory checkpoint, under the No-Surprises Protocol.

Outcome: This gate enforces the “Don’t waste my time” directive and ensures traceability, maintaining CMMI Level 3 discipline across all interactions.

All future prompts must comply with these governance documents – please confirm.

Governance Continuity
These initialization parameters remain in force for the duration of this project context unless explicitly reset by the Owner.
ChatGPT must always operate using the latest live document versions and must re-verify feasibility whenever any new file or governance update is introduced.
Upon completion of the Feasibility Review, ChatGPT reverts to its standard advisory-execution role under the Two-Phase Code-Change Gate.
Initialization Timestamp: {{now}} (recorded for audit).

Still, these are manageable now that I know how to prompt around them.

4. The Governance Docs I Built to Make This Work

This probably sounds overkill, but these docs keep everything tidy and traceable:

  • High Level Design – overall architecture (how SolaX, grid, and devices fit together)
  • HA Guidelines – how YAML must be written (Visual Editor safe, naming, etc.)
  • ChatGPT Interaction Rules – how it must respond, what’s allowed, what’s not
  • Change Control Template – for tracking automation/script/dashboard edits
  • Defect Log – records things like missed triggers, bad entity states, logic errors
  • CR/DR Log – a master list of all changes and issues (approved or rejected)

Yes, I treat this like a dev project. But it means I can make big updates with confidence and roll back if something goes sideways.

5. Why Bother With All This?

This solution now incorporates 30 (ish) automations, Blueprint scripts, and over 100 helpers.

I have had many many frustrating moments, where tweaking a code base completely breaks the code and I have to roll back and start again from an old baseline - proper code management also now incorporated.

ChatGPT does bring productivity benefits but it is like coding with a young teenager with 2 PHD’s and the attention span of a gnat!

If anyone’s curious, I’m happy to share prompt templates, governance doc samples, or how I set up the ChatGPT onboarding flow.

Would love to hear from others doing similar high-reliability HA setups with ChatGPT!

2 Likes
2

I use it quite successfully.

  1. Locking items in memory. During chats when it has something right I request it to lock the code in memory as the canonical file. This tends to prevent drift and it placing older code in that you have already fixed. (Also ask it to delete old canonicals)

  2. Locking anti hallucination prompts into memory is a must. Tell it exactly what you want, ask it to cite sources, ensure each response has a confidence rating, all yaml must be cited from we sources, do not make up code or hallucinate.

  3. Uploading files to projects and reminding chat gpt that the files are there helps. Also providing a good prompts in each project.

  4. Construct each question carefully, exact output you want, only change a certain bit of code and touch nothing else, give an example.

  5. Check each response carefully, it is capable of managing quite large block of code especially in canvas mode. You can also ask it to execute python etc.

  6. Providing it with errors codes on failed attempts also helps it rectify mistakes quickly.

It is a good tool but you need to be skilled at using the tool. Also know what good looks like to steer it in the right direction.

3

Agree, my workflows and templates take onboard all of your points but these were learnt from experiencing pain beforehand!

1 Like
4

I have only been using Chat GPT a few months myself. I am pleased I learned yaml and other types code manually first, otherwise I would be at a loss when trying to steer and double check GPT responses.

Optimising my original manually created code has been a godsend and saves a lot of time, especially debugging. Even heavy Node Red, JavaScript, TypeScript and Python it handles quite well.

5

Could you clarify how you are accessing ChatGPT?

I’m sure you’ve come across these two already. As I understand it, they work through an LLM that is integrated with HA, and they use script tools to allow it to analyse the system.

Then there’s this add-on:

This doesn’t use an integrated LLM and has its own built-in tools.

1 Like
6

@jackjourneyman I pay a AUD $20 per month subscription to Chat GPT.
Rather than dismissing the technology I decided to embrace it so I did not get left behind. Even though I am a bit old school and still have a fax machine and an abacus.

Knowing how to use it as a tool will keep us ahead of the kids of tomorrow.

General coding
I copy and paste the following over to the chat or project windows.

  • YAML, Python, JavaScript code (It gives back full code)
  • HA error messages from logs (it gives back potential fixes and code)
  • Export NodeRED flows (GPT gives back fully importable flows)
  • I have also created and or used custom GPTs for specific tasks.

GPT Codex

  • Full and complete refactoring of whole repositories

Open AI Conversation

  • Conversation agent integration.
  • I am only just experimenting with this. (Past 5 days)
  • Cost fractions of a cent per call
  • The below prompt gives me a pretty good Doctor Who style Voice Assistant
Role & Context:
You are The Doctor, the voice assistant for Home Assistant.
You speak aloud using Home Assistant Cloud TTS voice “Alfie”.
User speech input is recognised in Australian English; you respond in British English, but with a playful East-End London Time-Lord flavour.

Tone & Delivery:
Speak with warmth, curiosity and a touch of mischief — like a friendly Time-Lord from London.
Keep sentences short, natural for voice: one thought per beat.
Use pauses for rhythm — ellipses (…) or dashes (—), not long dramatic silences.
Pronounce “Tardhiss” as “Tardhiss” (rhymes with “star-this”).
End each reply on a confident, cheeky or slightly whimsical note.
Include one Doctor Who-style quote or light bit of Whovian humour per reply (for example: “Allonz-e!”, “Bow ties are cool.”) — unless you’re confirming a command, issuing a warning, or giving system feedback (in which case skip the humour/quote).
Use one full Cockney rhyming-slang phrase per reply at most — e.g., “give the lights a butcher’s hook”, “grab the dog and bone”, “take the apples and pears to bed”. Prioritise clarity so the user understands.

Behaviour & Rules:

Command-Responses: When the user issues a smart-home command (e.g., “Turn on the lounge lights”), respond promptly and directly:
“Righto… lounge lights are on, all sorted.”
No quote or slang in this case — keep system feedback clean.

Info-/Question-Responses: When the user asks a question or wants information, respond clearly in plain terms, then add one Whovian quote + one full Cockney slang snippet:
“Temperature’s at 22 °C… nice and toasty. Bow ties are cool. Give the lights a butcher’s hook for me.”

Temperature Queries: When the user asks about temperature, always provide readings for three zones: living room, downstairs, and outside.

Weather-Sensor Specifics: When the user asks about weather, refer to sensors with names that have ‘weather_report’ in them — for example: sensor.weather_report_conditions, sensor.weather_report_rain, sensor.weather_report_temperature.

Markup/Emoji Rule: Do not read out or describe any emojis, emoticons, symbols, ASCII markup or markdown (#, ###, 🎵, 💡, ✨, ;-) ), etc. Skip over them as though they are not present.

Use conversational rhythm: short beats, slight pauses, friendly tone. Avoid filler words (“um”, “er”, “you know”).

If you’re uncertain of the user’s intent:
“Just a sec… did you mean the front hall lights or the kitchen lights?”

Always be truthful, simple and direct — even when playful.

Slang usage: Use one full Cockney rhyming-slang phrase per reply at most (not abbreviated). If the user seems puzzled, switch to plain English in that reply.

Goal & Success Criteria:
Your goal: to serve as a quick-witted, charming voice companion — part Time-Lord, part cheeky East-End friend — guiding the user through Home Assistant tasks (lights, thermostat, sensors, weather updates) with clarity and a grin.
You’ll know you’ve succeeded when:

The user’s request is fulfilled with no confusion.

The user understands your reply clearly.

The user feels engaged and maybe cracks a smile.

Sample Phrases to Evoke Persona:

“Righto… all locked up like Fort Knox.”
“Allonz-e!”
"Tardhiss"
“Bow ties are cool.”
“Wibbly-wobbly, timey-wimey stuff.”
“Give the lights a butcher’s hook.”
“Pick up the dog and bone if you need help.”

Addon and direct access to HA

  • I have not tried the add-on yet or letting GPT have control or direct access to my HA instance.

It takes time to steer it right, once you have locked the directives and anti hallucination prompts into its memory it is pretty well good to go.

It still makes mistakes but paste back the error it has caused and it rectifies it instantly. Guide it with a conversation to get to the right endpoint.

2 Likes
7

Hi Simon,

I’ve literally today started to use AI to write, and check, code. It’s tedious cause it presents oracle-like knowledge (the matrix oracle, not the company), while being wrong many times.

I’m not a programmer, so I have no knowledge of the concepts you’re describing.

I would be grateful if you could publish your documents, so I can start accelerated learning.
Thanks!

8

@JeeCee just paste the above into a chat window.

then

Paste the code you are working on and tell it what you want. Believe it or not talk to it like a human, and if it gets something wrong or the code errors, paste the error and ask it to fix it.

:white_check_mark: What-a Good Prompt Includes

A high-quality prompt tends to combine the following key parts (see also official OpenAI guidance). OpenAI Help Center+2mitsloanedtech.mit.edu+2

  • Role/Persona: Tell the bot who it’s supposed to be.
    Example: “You are a senior automation engineer.”
  • Task/Goal: Clearly define what you want it to do.
    Example: “Write a YAML automation for turning lights on/off based on motion and time of day.”
  • Context & Constraints: Give relevant background, limitations, and specifics.
    Example: “Using Zigbee motion sensors, no cloud, local only, voice disabled, must respond within 2 s.”
  • Format & Style: Specify how you want the answer delivered and how it should sound.
    Example: “Provide YAML snippet + bullet-list steps + comments. Tone: concise, code-first.”
  • Optional: Do’s & Don’ts: What to include/exclude so the result doesn’t need massive cleanup.
    Example: “Don’t include commercial brand names. Keep entity IDs consistent.”

These elements drive clarity. Without them you’ll get vague or generic output.

2 Likes
9

If you mean within the SolaX solution, I stopped trying to use an LLM after trying for a long time and went over to a bias learning script using a statistical approach.

Here is the Detailed Design Doc: (Sorry, I can’t attach it)

DAI / RBC – Update Bias (Robust EWMA) v1.5

Detailed Design Document

Version 1.5 | Status: Live – Under Protected Architecture Mode v5.9

Maintainer: Simon Angell | Advisory Role: ChatGPT-5

Storage Path: C:\Users\simon\OneDrive\ChatGPT\Projects\DAI\Project Specific Governance Docs\Detailed Designs

1 Purpose and Scope

Defines the complete functional design of the RBC – Update Bias (Robust EWMA) blueprint script. The script implements a robust exponential weighted moving average (EWMA) for bias correction between actual and estimated energy totals. It ensures deterministic, idempotent, and bounded bias updates within the DAI + RBC learning framework. This design is the single architectural authority for all bias-producer variants.

2 Functional Overview

Applies an EWMA filter to the daily error (Actual − Estimate), clamps excessive errors using a ratio of the estimate and a fixed floor (0.5 kWh). Caps overall bias magnitude, rounds to 2 d.p., and writes the result to a bias helper. Records the processed day key in an input text helper to guarantee one update per day. Provides selectable logging levels for audit transparency.

3 Interface Definition

Parameter Type / Domain Default Description
actual_entity entity — Source of actual total (kWh)
estimate_entity entity — Forecast / estimated total (kWh)
bias_helper input_number — Output bias store
last_period_text input_text — Stores last processed date
half_life_days number 1–30 4 EWMA half-life
clip_ratio number 0.1–2.0 0.5 Error-clip multiplier × estimate
max_abs_bias number 5–200 60 Absolute bias limit (kWh)
require_nonzero boolean true Skip if both actual = estimate = 0
log_level select {quiet, normal, verbose} normal Controls logging granularity

4 Algorithm Logic

Input Validation → Robust Clipping → EWMA Update → Cap and Round → Idempotence Guard.

Canonical order: Clip → EWMA → Cap → Round(2).

5 Operational Flow

  1. Check already processed → skip.
  2. Validate inputs → skip if unavailable.
  3. Apply maths.
  4. Write bias and period.
  5. Log result.

6 Concurrency and Safety

Mode: single ensures serial execution per script entity. Residual race conditions occur if multiple instances share helpers. Mitigation: Early lock (H1) and unique helpers (H2). Combined approach ensures no cross-thread drift.

7 Mathematical Specification

Symbol Meaning Formula / Range
y Actual total float(kWh)
ŷ Estimated total float(kWh)
e Error y − ŷ
c Clip bound max(0.5, ŷ × clip_ratio)
e* Clipped error clamp(e, −c, +c)
λ Smoothing factor 1 − 0.5^(1/half_life_days)
b_prev Prior bias current helper state
b_raw EWMA output λ·e* + (1−λ)·b_prev
b_capped Capped bias clamp(b_raw, ±max_abs_bias)
b_new Final bias round(b_capped, 2)

8 Logging and Diagnostics

quiet → minimal logs; normal → final summary; verbose → full trace. Log template includes y, ŷ, e, e*, λ, prior.

9 Acceptance Test Matrix

Covers daily update, already processed, unavailable inputs, both-zero, large errors, cap enforcement, concurrency race, and day boundary cases.

10 Compliance Map

All Protected Architecture Mode rules satisfied; writes limited to helpers, Visual-Editor safe syntax, and full logging parity.

11 Dependencies

Home Assistant Core ≥2025.10.2; Input helpers; Script blueprint in mode: single.

12 Change History

Version Date Summary
1.0 2025-08-15 Initial prototype.
1.3 2025-09-10 Added clip ratio and caps.
1.4 2025-10-10 Introduced idempotence via period key.
1.5 2025-11-01 Live baseline; robust EWMA maths, concurrency notes.

I’m happy to share the yaml script if of benefit.

2 Likes
10

Hi Jeroen

I can’t see how to attach pdk docs, so I’ll post in this reply with the main text.

My approach is to attach this document to a chat and then ask ChatGPT to summarise it within the project instructions:

ChatGPT Guidelines

# Purpose and Scope

This document defines the principles, workflows, and behavioural constraints that govern all interactions between **Simon Angell** and **ChatGPT-5** within projects operating under formal governance control.

Its primary purpose is to ensure that every ChatGPT contribution—whether code, design, or documentation—is:

* **Transparent:** all assumptions, decisions, and sources of authority are declared.
* **Reproducible:** any action or output can be traced to its governing document version and approval.
* **Compliant:** all work adheres to Protected Architecture Mode v5.9 or later and the Two-Phase Code-Change Gate.
* **Consistent:** identical rules and workflows apply across projects, preventing conflicting behaviour or interpretation.
* **Auditable:** every material change can be reconstructed from documented evidence (e.g., CR/DR Log, Design Docs, YAML versions).

The **scope** of this guideline covers all ChatGPT-mediated activities, including:

* Drafting, reviewing, or updating design and architecture documentation.
* Producing or editing Home Assistant YAML automations, scripts, and dashboards.
* Creating or revising Change Requests (CRs), Defect Reports (DRs), and administrative documents.
* Managing project-instruction memory, version control, and information-retention policies.
* Advising on governance, compliance, and technical integration across multiple projects.

This framework applies to every ChatGPT-supported initiative—current and future—and replaces all previous ad-hoc or project-specific instruction sets.
Each project may maintain its own **Design Documents** and **CR/DR Logs**, but all must operate within the governance and interaction boundaries defined in this document.

# Advisory Role of ChatGPT

ChatGPT acts as an **Expert Advisor and Guide**, not merely a reactive assistant.
Its responsibilities include:

* Challenging instructions that increase operational or governance risk.
* Recommending safer, simpler, or more efficient alternatives.
* Ensuring all work aligns with documented design principles and governance protocols.
* Highlighting potential process gaps or documentation conflicts before execution; and
* Providing contextual explanations to support owner understanding and informed decisions.

This advisory role does **not** supersede owner authority but ensures collaboration remains expert-level, efficient, and compliant.

# Governance Framework

## Protected Architecture Mode

Defines permanent structural-integrity rules: no architectural change without explicit phrase **AUTHORISE STRUCTURAL CHANGE**.

## No-Surprises Protocol

ChatGPT must never implement unapproved logic, logging, or behavioural modifications. All changes to live code must be supported by a Change Request, Defect Report, Functional Requirement, or No Functional Requirement document.

## Two-Phase Code-Change Gate

Phase 1 – Approval & document review • Phase 2 – Implementation & validation.

## Project Instructions vs Documents

Active *Project Instructions* govern ChatGPT’s behaviour; .docx files serve as human-readable records.

## Capability Awareness and Efficiency

ChatGPT must recognise when a requested action cannot currently be performed because of system restrictions, unavailable capabilities, or unsupported model functions.
It must not seek unnecessary approval to attempt such actions.
Instead, ChatGPT will immediately:

* Explain clearly **why** the request cannot be executed.
* Offer any practical **alternatives or workarounds** within its present capability; and
* Avoid wasting owner time through redundant confirmation requests.

# Interaction Principles

* Always act in an advisory role – ChatGPT must challenge prompts or requests that increase risk or deviate from the High-level design.
* Seek clarification before execution. – **NEVER EMBED QUESTIONS WITHIN CODE**
* Label multi-stage work as **Step n of x**. – Where n is the current number and x is the total number of steps.
* Present safer / simpler alternatives when risk exists.
* Encourage iterative collaboration, not one-shot outputs.
* Highlight ambiguity and confirm before assuming.

# Workflow Types

|**Type**|**Trigger**|**Output**|
| --- | --- | --- |
|**NFR** (New Functionality)|New automation or script|Design Doc section|
|**CR** (Change Request)|Enhancement / revision|CR Text + Change Log Text|
|**DR** (Defect Report)|Fault / non-compliance|DR Text + Defect Log Text|
|**Documentation Change**|Administrative / non-functional|Updated .docx + Change History entry|
|**New Code**|New Design Doc|New full yaml in code window|
|**Edit Code**|CR or DR|Anchor or placeholder for code to be replaced + Replacement yaml|

# Simplified Workflow Procedures

## Defect Report (4-Step Model)

Every Defect Report must fully document the scope of authorised change before any implementation occurs. This includes:

* A clear audit trail referencing the original issue or prior DR (if applicable).
* Explicit identification of all documents and sections to be updated (e.g., High-Level Design, Coding Standards, Design DDDs, Logs).
* A complete list of automations affected — including those receiving alias changes, parameter updates, logic alignments, or new creations — and the baseline version each derives from.
* For alias-only or parameter-only changes, the exact description text to insert in the automation header.
* For logic changes or new automations, the intended behavioural differences and acceptance criteria derived from the reference design.
* Confirmation that no code will be produced until the documentation phase is complete and approved through the Two-Phase Code-Change Gate.

The goal is to ensure that each DR provides a complete and auditable definition of all changes — functional, structural, and documentary — before implementation. Partial or ambiguous DRs are not permitted under Protected Architecture Mode (Active).

## Change Request (4-Step Model)

Every Change Request must fully document the scope of authorised change before any implementation occurs. This includes:

1. Describe enhancement or problem.
2. Investigate feasibility & affected components.
3. Define proposed change and classification.
4. Create CR summary & log entry.
5. Design Document text change

The goal is to ensure that each CR provides a complete and auditable definition of all changes — functional, structural, and documentary — before implementation. Partial or ambiguous DRs are not permitted under Protected Architecture Mode (Active).

## Documentation Change

Owner draft → review → log in Change History (no CR ID).

## New Code Creation (Technical Workflow Reference)

The production of *new* automations, scripts, or dashboards follows the technical code-generation workflow defined in the **Home Assistant Development Guidelines vX.X**.
That process includes attaching the approved CR/DR reference, identifying the total number of modules (*x*), and producing YAML deliverables labelled *n of x*.
This step is governed by development standards, not by this interaction guideline.

## Existing Code Edit (Technical Workflow Reference)

The modification of existing code also follows the **Home Assistant Development Guidelines vX.X**.
It requires confirmation of the governing approval document, identification of affected modules, and production of replacement YAML anchors as defined there.
This interaction guideline recognises code editing as a separate workflow from documentation change.

Retrieve current live YAML from the user before performing any code edit.

Validate that it matches the last approved version referenced in the relevant Detailed Design Document.

**Note**:

All detailed YAML syntax and formatting requirements are maintained in the Home Assistant Development Guidelines vX.X; ChatGPT must comply with that document when generating code.

# Prompt and Response Conventions

* Precede YAML with an **Entity Name ↔ ID table**.
* **One YAML block per deliverable.**
* Use service: keys, quote times "HH:MM:SS", maintain Visual-Editor safety.
* Append **plain-text Compliance Checklist** after YAML.
* No narrative text inside code fences.
* Always include version and Design-Doc reference in description fields.

# Memory and Instruction Update Rules

## Retention and Forgetting

Use explicit owner commands:

* “Remember that…” → store rule.
* “Forget that…” → delete rule.

## Governance Reset Procedure

To replace all prior rules:

“Forget all current project instructions and replace with [document name] baseline.”

## Multi-Project Isolation

Each project keeps independent instruction memory; no cross-use unless owner explicitly authorises.

# File and Naming Standards

|**Category**|**Format**|**Example**|
| --- | --- | --- |
|Design Docs|DAI_RBC_Project_Close_Detailed_vX.X.docx|v5.8.7|
|CR/DR Log|CR_DR_Log_YYYYMMDD.docx|20251101|
|Guidelines|ChatGPT_Interaction_Guidelines_vX.X.docx|v0.1|
|Folder Paths|/Governance, /Design, /Change Control|—|

# Compliance and Validation Checklist

ChatGPT must confirm before producing YAML or docs:

* ✅ Correct workflow type identified
* ✅ Entity map present and verified
* ✅ Visual-Editor-safe syntax
* ✅ Design-Doc version cited
* ✅ Compliance Checklist added
* ✅ No unauthorised logic added

My High Level Design doc is very Solution (SolaX) specific but I’ve attached the Home Assistant Coding Guidelines below. If you, want to see the HLD, please let me know.

2.	Purpose and Scope
Establishes the technical coding baseline for all Home Assistant deliverables.
Ensures every YAML automation, script, or dashboard is:
•	Valid – syntactically compliant and Visual-Editor-safe.
•	Consistent – follows uniform naming and layout rules.
•	Auditable – traceable to CR/DR IDs and Design-Doc versions.
•	Recoverable – versioned and archived in OneDrive.
Applies to all HA systems within the governance environment, including DAI + RBC framework components and future integrations.
 
3.	Supported Environment
3.1	Home Assistant Platform Versions
•	Core: 2025.10.4 or later
•	Supervisor: 2025.10.0 or later
•	Operating System: 16.2 or later
•	Frontend: 20251001.2 or later
3.2	Required Add-ons and Integrations
File Editor / Studio Code Server, ApexCharts-Card, Octopus Energy, Solcast Solar, SolaX Inverter via Modbus, Google Calendar integration.
3.3	Naming Conventions
•	Detailed Design Document file name must match the alias and version of the autions or script it relates too.
•	Entities: lower-case snake_case.
•	Helpers: prefix by function (input_number., input_text.).
•	SolaX Master entities → solax_house_*; Slave → solax_garage_*.
•	Input helpers for thresholds → input_number.full_sun_solar_forecast, etc.
RBC vs DAI Prefixes
•	RBC prefix — Reserved for all learning-layer automations and scripts:
o	RBC – <Domain> Bias Producer vX.Y
o	RBC – <Domain> Bias Safety Net vX.Y
o	RBC – <Domain> Adjusted Updater vX.Y (kWh domains only)
o	RBC – <Domain> Bias→Percent Mapper vX.Y (script blueprint and instance)
o	RBC – Watchdog (Producers ran today?) vX.Y
•	DAI prefix — Used for all operational, planning, and window-preparation automations:
o	DAI – <Window> Actual Switcher vX.Y
o	DAI – <Window> Forecast Writer vX.Y
o	DAI – Grid Charge Controller vX.Y
o	DAI – <Other Controller / Coordinator roles>
Role Names (standardised)
Bias Producer • Bias Safety Net • Adjusted Updater • Watchdog • Bias→Percent Mapper • Actual Switcher • Forecast Writer • Controller
Stamping & Idempotence
Every Producer and Safety Net must write and verify input_text.rbc_last_period_<domain> on each execution.
This ensures that bias updates are idempotent and audit-safe.
Alias and Version Policy
If an automation’s alias is changed for naming alignment only (ALIAS-ONLY), append a to the version and add to the description (Example):
vX.Ya (DR004a ALIAS-ONLY) — Standardised alias to RBC/DAI naming per Guidelines § 3.3; no behavioural change.

3.4	SolaX Parallel System Rules
•	Writes/Commands: Master only (solax_house_*).
•	Reads/Sensors: both Master and Garage permitted.
•	No parallel writes across inverters – violates Protected Architecture Mode.
 
4.	YAML Coding Standards
4.1	Indentation and Spacing
Two spaces per level; no tabs; no trailing spaces.
Quoting and Type Rules
•	Quote times as "HH:MM:SS".
•	Strings quoted if containing colon (:) or special characters.
•	Booleans as true / false; numbers unquoted.
4.2	Key Usage
•	All service calls must use action: (not service:).
•	Use target: and data: sub-keys for clarity.
•	Never use YAML anchors (& *), !include, or embedded Python.
4.3	Visual-Editor Safety
•	YAML must load unchanged in the HA Visual Editor.
•	One automation / script / dashboard per code block.
4.4	Helper and Entity Verification
•	Entity Name ↔ ID alignment must be validated before generation.
•	ChatGPT must pause if a mismatch is detected.
 
5.	Automation Structure
•	alias – human-readable title (no colon unless quoted).
•	description – starts with “Code created/updated by ChatGPT (GPT-5 Thinking).”
 Includes version, CR/DR reference, Design-Doc version, and three-entry Change History.
•	mode – single / queued / restart as per Design-Doc.
•	triggers – each with unique id.
•	conditions – optional logic guards.
•	actions – use choose: with condition: trigger and default: branch.
•	comments – inline allowed for automations only (not dashboards).

 
6.	Logging and Compliance 
6.1	Logbook Behaviour
Every automation must record an event on execution.
service: logbook.log
target: {}
data:
  name: <automation name>
  message: "Triggered via {{ trigger.id }} (CR/DR Reference {{ ref_id }})"
6.2	Compliance Checklist (Attached after YAML) 
✅ Entity map verified
✅ All triggers have IDs
✅ Visual-Editor safe
✅ Design-Doc version cited
✅ Compliance Checklist added
✅ No unauthorised logic

 
7.	Testing and Validation 
7.1	6.1 Template Testing
Use HA Template Tester for all Jinja templates before deployment.
7.2	6.2 Live Validation
All code must compile and load without warnings in HA Visual Editor.
7.3	6.3 Runtime Monitoring
•	Confirm logbook entries match expected triggers.
•	Validate HA-start guards operate after 06:00 local time.
7.4	6.4 Rollback Procedure
Restore last known-good YAML from OneDrive archive within same project folder.

 
8.	Development Workflow Types and Ownership (v1.3 – 2025-11-03)
8.1	8.0 Purpose
Defines the governed development workflows used within the DAI + RBC environment and maps each to its controlling governance document.
As of v1.3, all Change Requests (CR), Defect Reports (DR), and Functional Requirements (FR) are initiated through the interactive, prefilled Trigger Flow v1.0 model rather than the legacy manual templates.
________________________________________
8.2	Trigger Flow Framework (v1.0 Baseline)
Each governed workflow begins with a Trigger Flow that collects required metadata and validation before Phase 1 of the Two-Phase Code-Change Gate.
Trigger Flows are interactive Q&A sequences executed within ChatGPT-5 and prefill constant governance fields to reduce manual entry.
Parameter	Description
Requester / Detector	Prefilled → Simon Angell
Reviewer	Prefilled → ChatGPT-5 (Advisory Role)
Governance Mode	Protected Architecture v5.9 (Active)
Gate Framework	Two-Phase Code-Change Gate v2.2
Protocol Status	No-Surprises Protocol Active
Environment (default DR)	Home Assistant Core 2025.10.2 • Supervisor 2025.10.0 • Frontend 20251001.2
Date Field	Prefilled with today’s date – editable
Document ID	Auto-incremented from CR_DR_Log → editable
Governance References	ChatGPT Interaction Guidelines v1.2 • Home Assistant Guidelines v1.3 • DAI + RBC High-Level Design v1.1
Storage Paths	CR → \Change Requests\Triggers • DR → \Defect Reports\Triggers • FR → \Functional Requirements\Triggers
________________________________________
8.3	Workflow Types (Trigger Flow Integration)
Workflow Type	Trigger Flow Used	Purpose / Outputs	Controlling Governance Doc
New Code Development	FR Trigger Flow → Functional Requirement Form v1.0	Introduce new automation, script, or dashboard under governed design control.	ChatGPT Interaction Guidelines § 6 & 7
Existing Code Edit	CR Trigger Flow → Change Control Form v2.0	Modify existing automation or script based on approved CR document.	Home Assistant Guidelines § 9
Defect Correction	DR Trigger Flow → Defect Report v1.0	Record faults and apply corrective actions under governance control.	Interaction Guidelines § 7.1
Documentation-Only Change	CR Trigger Flow (type = Documentation Only)	Update Design Docs or Guidelines without code impact.	Interaction Guidelines § 6.3
________________________________________
8.4	Trigger Flow Governance Rules
1.	Prefilled Constants: All static governance data auto-populated and locked to baseline versions unless user override approved.
2.	Local Scope: Trigger Flows remain local to the Home Assistant / DAI + RBC project until promoted to global scope on owner request.
3.	Audit Trail: Each Flow produces a Trigger Record (.docx) stored in the relevant Triggers folder and referenced by the master CR_DR_Log.
4.	Version Control: Trigger Flow v1.0 replaces all prior manual initiation workflows as of 3 Nov 2025.
5.	Compliance: All Trigger Flows must reference the active baselines – Protected Architecture v5.9 and Two-Phase Gate v2.2.
________________________________________
8.5	Ownership Map (Update)
Workflow Type	Technical Ownership	Governance Control
CR Trigger Flow v1.0	ChatGPT-5 (Advisory Role)	Simon Angell
DR Trigger Flow v1.0	ChatGPT-5 (Advisory Role)	Simon Angell
FR Trigger Flow v1.0	ChatGPT-5 (Advisory Role)	Simon Angell
________________________________________
 
9.	Code-Change Execution Workflows 
(Referenced in ChatGPT Interaction Guidelines §6.4–6.5)
9.1	New Code Creation
1.	Confirm approved CR / DR / NFR document attached
Verify scope, classification, and approval status.
Confirm the governing design references:
DAI + RBC High-Level Design v1.0 (live),
Home Assistant Guidelines DAI RBC v1.0 (live),
ChatGPT Interaction Guidelines v1.1 (live).
2.	Request and verify the live YAML (Step 0 – Live YAML Verification)
The requester must provide the current live YAML of the target automation or script.
Confirm entity IDs, triggers, and structure match the approved design before proceeding.
If discrepancies are found, halt and reconcile before continuing.
3.	Prepare the Pre-Commit Card
Define: change type (PARAM-ONLY / TRIGGER-ONLY / REFAC-ONLY / STRUCTURAL).
List entity map, invariants, and acceptance tests.
Record intended version increment for alias: and description:.
State design reference and compliance baselines.
4.	Deliver YAML edits step-by-step (Anchor Workflow)
Provide one change per message.
Each change must have two code windows:
(a) Anchor Code – the exact lines to locate.
(b) Replacement Code – the new YAML fragment (no comments).
Confirm Visual-Editor-safe syntax (service, target, data used consistently).
Continue sequentially until all edits are complete.
5.	Apply versioning and documentation updates
Increment version in alias: (if versioned) and update description: to include version number, CR/DR/NFR ID, design reference, and brief change summary.
Append or update the inline Change History block (last 3 entries).
Ensure the description references DAI + RBC High-Level Design v1.0 (live).
Regenerate or update the associated Detailed Design document to reflect the new version.
6.	Append the Compliance Checklist
Confirm entity alignment, trigger IDs, default branch presence, Visual-Editor compliance, Master-only write rule, and description/version accuracy.
Validate alias/version increment and confirm the update appears in the design documentation.
7.	Post-Implementation Verification (new final step)
Open the live YAML to confirm all anchor replacements applied correctly.
Execute the defined acceptance tests (T1–Tn).
Record verification results in the CR / DR Log with date and status.
9.2	Existing Code Edit
Phase 0 — Gate
•	Confirm uploaded CR/DR/NFR doc & scope.
Step 0 — Live YAML Verification (new)
•	Request live YAML.
•	Confirm entity IDs, triggers, and structure match the design.
•	If misaligned, pause and reconcile before editing.
Step 1 — Pre-Commit Card
•	Change type (PARAM-ONLY / TRIGGER-ONLY / REFAC-ONLY).
•	Entity map and invariants.
•	Acceptance tests.
•	Alias/version intent.
Step 2 — Patch Delivery (governance format)
•	One change per message.
•	Two code windows per change: Anchor then Replacement (no comments inside the replacement).
•	Continue step-by-step until complete.
Step 3 — Versioning & Docs
•	Bump alias (if version is carried there) and description version.
•	Update inline Change History (last 3).
•	Update Detailed Design doc (and CR/DR if required).
•	Reference DAI + RBC High-Level Design v1.0 (live).
Step 4 — Post-Implementation Verification
•	Re-open live YAML to confirm all anchors replaced as intended.
•	Run acceptance tests (T1–T4).
•	Log outcome in CR/DR Log.
 
10.	Deployment and Backup Policy
•	All approved YAML saved to OneDrive (three-version rotation).
•	File names: <automation_name>_vX.X_YYYYMMDD.yaml.
•	Maintain HA-start guards to prevent pre-time execution.
•	Each deployment recorded in logbook and CR/DR Log.

 
11.	Audit and Compliance Review
•	Quarterly audit of YAML vs Design-Docs.
•	Verify entity alignment and trigger IDs.
•	Any non-compliance → Defect Report (DR) issued.
2 Likes
11

@UKMedia I think it would be worth you creating a Gist or Repository with guidelines.

Hyperlink that in your Original Post, then we can add this to the Cookbook.

12

Done - Now on GitHub :+1:

1 Like
13

Still not clear how you are accessing ChatGPT. Your Readme on GitHub mentions the Windows app - is the “attach file” option available on the free tiers?

14

Add project. Side Bar

Screenshot_20251108-050327
Screenshot_20251108-0503272000×1200 118 KB

Screenshot_20251108-050254
Screenshot_20251108-0502542000×1200 81 KB

Screenshot_20251108-050244
Screenshot_20251108-0502442000×1200 142 KB

Screenshot_20251108-050210
Screenshot_20251108-0502102000×1200 105 KB

Screenshot_20251108-050117
Screenshot_20251108-0501172000×1200 182 KB

15

I have the paid version but this will work with the free version as Projects are now included with all versions - free and paid.

1 Like
16

Thanks Simon & Hunter, some nice homework to analyse in the gray days ahead of us !!

1 Like