När en blueprint inte laddas eller ger ett kryptiskt felmeddelande är orsaken ofta en saknad eller felaktig indatavariabel. Problemet är att många system, inte minst Home Assistant, hanterar sådana fel tyst – utan tydliga loggmeddelanden. För att förstå vad som händer måste man veta hur !input egentligen fungerar i YAML och varför det inte går att använda direkt i Jinja2-mallar.
En blueprint är en återanvändbar mall som automatiseringar i till exempel Home Assistant bygger på. Den deklarerar indata via inputs:, och dessa indata läses in med YAML-taggen !input. Om en input-variabel saknas, har fel namn eller används på fel sätt, kan blueprinten sluta fungera – ibland utan att något fel rapporteras.
Den här artikeln går igenom de vanligaste orsakerna till “missing required input variables”-fel, hur man identifierar dem och, framför allt, hur man undviker dem.
Vad innebär felet “missing required input variables” i blueprints?
Felet uppstår när en blueprint förväntar sig en indatavariabel som inte är definierad, inte kan läsas in eller har en ogiltig typ. I Home Assistant kan det visa sig genom att blueprinten inte syns i listan, importen misslyckas utan förklaring eller att ett fel om “unknown tag !input” dyker upp först vid körning.
Variabeln finns inte i
inputs:-blocket.!input används innanför Jinja2-klamrar.Fel indrag eller syntax bryter valideringen.
Blueprinten läses inte alls – inget felmeddelande skrivs ut.
Viktiga insikter från forskningen
- En blueprint kan tyst ignoreras om den refererar till en icke-existerande input – ett känt problem i Home Assistant (GitHub issue #90145).
!inputär en YAML-tag och fungerar inte inuti{{ }}-block i Jinja2.- Istället måste indata först läsas in i en variabel och sedan användas i mallen.
- Vanliga symptom: blueprinten syns inte i listan, import misslyckas, felaktig rendering vid körning.
- Typfel – till exempel att en sträng förväntas men ett heltal skickas – kan ge svårspårade fel.
- Felaktig YAML-syntax (t.ex. fel indrag) är en av de vanligaste grundorsakerna.
- Liknande mönster finns i andra system som Terraform (fel vid input-variabler) och Spacelift (obligatoriska fält).
Vanliga orsaker och symptom – en faktatabell
| Orsak | Symptom | Exempel från källor |
|---|---|---|
| Saknad input-definition | Blueprinten syns inte | GitHub #90145 |
| !input inuti Jinja2 | Mallen renderas inte korrekt | Home Assistant forum #298824 |
| Fel datatyp | Fel vid körning | Spacelift docs |
| YAML-syntaxfel | Valideringsfel vid import | Allmän YAML-dokumentation |
| Input-ID stavas olika | Blueprinten laddas inte | Home Assistant community |
| Template refererar till fel objekt | Fel vid rendering | Forum #323811 |
| Blueprint med ogiltig input ignoreras tyst | Inget fel i loggen | GitHub #90145 |
| Obligatorisk input saknas i Make-scenario | Generiskt “blueprint missing”-fel | Make community |
| Input används där systemet inte förväntar sig den | Fel först vid körning | Terraform-fel, OneUptime |
| Felaktig indentering i YAML | Import misslyckas | Allmän praxis |
Varför fungerar inte !input inuti Jinja2-templates?
En av de vanligaste missuppfattningarna är att man kan skriva {{ !input min_variabel }} direkt i en template. Det fungerar inte eftersom !input bearbetas av YAML-tolkaren, medan Jinja2 bara ser rå text. YAML-taggen måste stå på en egen rad eller som ett YAML-värde, inte inuti klamrar.
Skillnaden mellan YAML-tagg och Jinja2-variabel
I Home Assistant är !input en så kallad YAML-tag som anger att värdet ska hämtas från blueprintens indatadeklaration. Jinja2-mallar däremot använder {{ }} för att evaluera uttryck. När !input placeras innanför klamrarna tolkas det som text, inte som en tagg.
Rätt användning – variabelbindning
För att använda indata i en template måste värdet först läsas in i en variabel via variables:-blocket. Först därefter kan variabeln användas med {{ }}. Ett korrekt mönster ser ut så här:
variables:
mitt_meddelande: !input meddelande
action:
- service: notify.notify
data:
message: "{{ mitt_meddelande }}"Att försöka nästla !input inuti en Jinja2-mall fungerar inte. YAML-taggen måste alltid stå i YAML-kontext, inte i templatetext. Utan variabelbindning blir resultatet antingen en tom sträng eller ett felmeddelande vid körning.
Vilka andra vanliga felkällor finns?
Utöver problem med !input i templates finns flera andra faktorer som kan orsaka att blueprinten inte fungerar som tänkt.
YAML-struktur och datatyper
Blueprintens inputs:-block måste vara korrekt strukturerat. Varje input ska ha ett unikt ID, en typ (t.ex. string, number, boolean) och vid behov ett standardvärde. Om en input förväntas vara en sträng men får ett heltal kan Home Assistant rapportera ett generiskt fel eller ignorera blueprinten.
Blueprints som tyst ignoreras
Enligt GitHub issue #90145 kan Home Assistant sluta läsa en blueprint utan någon varning om den innehåller en referens till en icke-existerande input. Detta gör felsökningen extra svår eftersom användaren inte får någon indikation på vad som är fel. Blueprinten dyker helt enkelt inte upp i listan över tillgängliga automatiseringar.
Exempel på felmeddelanden
- “Unknown tag !input” – uppstår när YAML-taggen inte känns igen, ofta på grund av felaktig användning.
- “Blueprint version is missing” – kan förekomma i Make (tidigare Integromat) när input-kraven inte uppfylls.
- “Invalid value for input variable” – ett typiskt Terraform-fel som även kan uppstå i liknande system.
Kontrollera i ordning: att alla inputs: är definierade, att varje !input pekar på ett existerande ID, att taggen inte ligger inuti {{ }}, att datatypen stämmer, att YAML-syntaxen är korrekt (indrag, inga tabbar), och att eventuella templates använder variabler – inte rå !input.
När upptäcks felet – vid laddning eller körning?
Tidpunkten för felmeddelandet varierar beroende på system och feltyp. I Home Assistant kan en blueprint med ogiltig input ignoreras redan vid laddning, utan logg. I andra fall upptäcks felet först när automationen körs och mallen ska renderas. Denna fördröjning försvårar felsökningen.
- Vid laddning av blueprint – vanligt om YAML-syntaxen är felaktig eller om en obligatorisk input saknas helt. I vissa fall (t.ex. GitHub #90145) sker ingen notifiering.
- Vid import – Home Assistant kan visa “invalid blueprint” om valideringen misslyckas. Ofta utan detaljer.
- Vid sparande – i system som Spacelift kan validering ske vid sparning.
- Vid körning – typfel eller referenser till icke-existerande variabler upptäcks först när automationen aktiveras.
- Vid rendering av template – om
!inputanvänts inuti Jinja2 blir resultatet en tom eller felaktig sträng först vid körning.
Vad är känt respektive oklart om dessa fel?
| Etablerad information | Information som fortfarande är oklar |
|---|---|
!input måste användas som YAML-tagg, inte i Jinja2. |
Exakt varför Home Assistant i vissa fall inte loggar något alls vid ogiltig input. |
| En blueprint med referens till icke-existerande input kan ignoreras tyst. | Om det finns en gräns för hur många felaktiga inputs som kan finnas innan systemet reagerar. |
Variabelbindning i variables: är rätt tillvägagångssätt. |
Om framtida versioner av Home Assistant kommer att förbättra felmeddelandena. |
| Typfel (t.ex. sträng vs. nummer) kan orsaka körningsfel. | Hur vanligt det är att användare av misstag blandar datatyper i praktiken. |
| Liknande beteenden finns i Terraform, Spacelift och Make. | Om det finns en gemensam standard för blueprints som kan minska förvirringen. |
Vad är en blueprint egentligen?
En blueprint är en återanvändbar mall som beskriver en automation eller en infrastrukturresurs. I Home Assistant definierar den indata (inputs:) som användaren kan fylla i vid skapandet av en automatisering. På så sätt kan samma mall användas för flera olika scenarier – till exempel att tända lampor vid solnedgång, med olika tider eller lampor som indata.
I system som Spacelift och Terraform fungerar blueprints på ett liknande sätt: de deklarerar variabler som måste tillhandahållas för att mallen ska kunna användas. När en obligatorisk variabel saknas eller har fel typ, misslyckas valideringen.
Vilka källor bekräftar dessa observationer?
“If a blueprint references a non-existing input via !input, Home Assistant may stop reading the blueprint silently, without any warning or clear log message.”
GitHub issue #90145 – Home Assistant Core
“!input is processed by the YAML parser. Jinja2 only sees raw text if !input is written inside a template.”
Home Assistant Community Forum – Blueprints variables !input not working
“Blueprints can have required fields. Validation may fail when input is missing or incorrect.”
Spacelift Blueprint Documentation
Utöver dessa källor bekräftar flera inlägg på Home Assistant‑forumet samt dokumentation från Terraform, OneUptime och Make att mönstret är återkommande: blueprints som kräver indata ger ofta otillräckliga felmeddelanden när indata saknas eller är felaktig.
Sammanfattning – hur undviker man “missing required input variables”?
Grundregeln är att alltid definiera alla indata i inputs:-blocket, använda !input enbart i YAML-kontext och binda värdet till en variabel innan det används i en Jinja2-mall. Genom att följa en enkel checklista – kontrollera stavning, datatyper, indrag och att !input inte är inuti klamrar – kan de flesta felen undvikas. För den som vill fördjupa sig i strukturerad artikelplanering och SEO-anpassning av tekniskt innehåll rekommenderas SEO Artikelstruktur – Guide för bättre synlighet och ranking och Svensk SEO – Guide till artikelplanering och SERP-analys.
Vanliga frågor och svar
Kan en blueprint med felaktig input skada mitt Home Assistant-system?
Nej, felet påverkar bara den specifika blueprinten. Systemet i övrigt förblir opåverkat.
Hur vet jag om en blueprint har en saknad input?
Kontrollera att varje !input har en motsvarande deklaration i inputs:-blocket. Jämför stavningen noggrant.
Varför ser jag inget fel i loggen när blueprinten inte laddas?
Home Assistant kan, enligt GitHub #90145, ignorera en blueprint utan att skriva något i loggen om input-referensen är ogiltig.
Fungerar !input i andra system än Home Assistant?
Ja, liknande YAML-taggar används i bland annat Docker Compose, Ansible och Spacelift, men syntaxen kan variera.
Kan jag använda samma variabelnamn i flera blueprints?
Ja, varje blueprint har sitt eget scope. Namnkonflikter mellan olika blueprints förekommer inte.
Hur felsöker jag en blueprint som inte syns i listan?
Börja med att validera YAML-strukturen med ett externt verktyg. Kontrollera sedan att alla !input-referenser pekar på existerande ID:n.
Behöver jag alltid ange en datatyp för input?
Det är starkt rekommenderat, men i vissa fall kan Home Assistant gissa typen. Explicit typ minskar risken för körningsfel.
Vad är skillnaden mellan !input och !secret i Home Assistant?
!input hämtar värdet från blueprintens indata; !secret hämtar från hemlighetsfilen. De används i helt olika sammanhang.
Kan jag använda en input-variabel i flera templates?
Ja, efter att du bundit den till en variabel i variables:-blocket kan du referera till variabeln hur många gånger som helst i samma blueprint.
