386 925 läst · 4 671 svar
387k läst
4,7k svar
Home Assistant
Han menade tillsammans med HA, i framtiden. Tror jag. Det finns en integration just nu men den är revers engineerad (?) och kan sluta funka av en uppgradering, och tror inte den underhålls officiellt. Därav att man får räkna med att det kan sluta fungera. Även nya funktioner är inte garanterade att följa med. Eller nya för Plejd då.Johan1975z skrev:
I brist på bättre kunnande, har jag gjort en automation för varje sak. Ja, det blir svåröverskådligt, men jag tror att det grafiska användargränssnittet inte klarar att baka ihop flera saker i en automation. Om man blir fena på YAML, kanske man kan handkoda något fiffigare/kompaktare.leby skrev:Hej, har använt Domoticz sen 2014 efter att ha inspirerats av HEK. Började med z-wave enheter och har sedan 2019 lyft in allt fler Shelly.
Nu stöds inte de nya Shelly varianterna av Domoticz och sen har jag dessutom sen några år byggt ut mitt unifi nätt med protect och ett antal kameror.
Både Shelly & Protect har stabila integrationer i HA så nu tänkte jag ge mig på en flytt från Domoticz till HA.
Efter ett antal år med Domoticz och dess scriptlösning dzVents (som är ett tillägg till LUA) så har jag avnt mig vid att få till ganska kod effektiva automationer.
Nu försöker jag sakta bygga upp mina script i HA men hittar inte hur man styr "action" baserat på vad som var "trigger".
Det jag försöker få till är att använda alla kameror och dess "motion" som trigger, dvs 7 olika event som kan skjuta igång automationen. Sen vill jag beroende på vilken kamera som ser rörelse tända lite olika lampor.
Dvs olika action beroende på vilken kamera som var triggerr. Begriper att jag kan göra 7 automationer men det kommer bli svår överskådligt med tiden.
Har ni tips på länkar eller excempel så jag kan ta mig framåt?
Har någon en bättre idé?
/Fumble
leby skrev:Hej, har använt Domoticz sen 2014 efter att ha inspirerats av HEK. Började med z-wave enheter och har sedan 2019 lyft in allt fler Shelly.
Nu stöds inte de nya Shelly varianterna av Domoticz och sen har jag dessutom sen några år byggt ut mitt unifi nätt med protect och ett antal kameror.
Både Shelly & Protect har stabila integrationer i HA så nu tänkte jag ge mig på en flytt från Domoticz till HA.
Efter ett antal år med Domoticz och dess scriptlösning dzVents (som är ett tillägg till LUA) så har jag avnt mig vid att få till ganska kod effektiva automationer.
Nu försöker jag sakta bygga upp mina script i HA men hittar inte hur man styr "action" baserat på vad som var "trigger".
Det jag försöker få till är att använda alla kameror och dess "motion" som trigger, dvs 7 olika event som kan skjuta igång automationen. Sen vill jag beroende på vilken kamera som ser rörelse tända lite olika lampor.
Dvs olika action beroende på vilken kamera som var triggerr. Begriper att jag kan göra 7 automationer men det kommer bli svår överskådligt med tiden.
Har ni tips på länkar eller excempel så jag kan ta mig framåt?
Är det inte trigger id du är ute efter?
https://www.home-assistant.io/docs/automation/trigger/#trigger-id
Det finns en if function nu för tiden som du sen kan använda trigger entity id för att peka på rätt actions.leby skrev:Hej, har använt Domoticz sen 2014 efter att ha inspirerats av HEK. Började med z-wave enheter och har sedan 2019 lyft in allt fler Shelly.
Nu stöds inte de nya Shelly varianterna av Domoticz och sen har jag dessutom sen några år byggt ut mitt unifi nätt med protect och ett antal kameror.
Både Shelly & Protect har stabila integrationer i HA så nu tänkte jag ge mig på en flytt från Domoticz till HA.
Efter ett antal år med Domoticz och dess scriptlösning dzVents (som är ett tillägg till LUA) så har jag avnt mig vid att få till ganska kod effektiva automationer.
Nu försöker jag sakta bygga upp mina script i HA men hittar inte hur man styr "action" baserat på vad som var "trigger".
Det jag försöker få till är att använda alla kameror och dess "motion" som trigger, dvs 7 olika event som kan skjuta igång automationen. Sen vill jag beroende på vilken kamera som ser rörelse tända lite olika lampor.
Dvs olika action beroende på vilken kamera som var triggerr. Begriper att jag kan göra 7 automationer men det kommer bli svår överskådligt med tiden.
Har ni tips på länkar eller excempel så jag kan ta mig framåt?
Trigger: rörelse a, b, c, d
Action: om a utlöste gör ax
Om b utlöste gör bx
https://www.home-assistant.io/docs/automation/templating/#available-trigger-data
https://www.home-assistant.io/docs/scripts/#if-then
Kan du koda så bör du undvika det grafiska gränssnittet. Jag skulle bli tokig om jag behövde använda det... VS code tillägget är guld värt.leby skrev:
Är det det här? https://github.com/hassio-addons/addon-vscodeFn87 skrev:
Vad gör det som man inte får genom att bara slå om till YAML-redigering i automationen?
/Fumble
ja det är den, jag valde för att få bättre överblick att installera den standalone https://code.visualstudio.com/download och installera Samba.F Fumble skrev:
Du får snabb kommandon etc jämfört med "YAML-redigering i automationen"
Sen vet nog Fn87 mer om vad du får (gissar att han är betydligt vassare programerare än jag ;-))
Helt riktigt, syntax highlight och snabb kommandon. Jag kör 10 st automation filer för att separera så jag kan inte använda in line editor på ett vettigt sätt.leby skrev:
Import av data från Nordpool
Ifall det kan vara till hjälp för andra, har jag gjort så här för att importera prisinformation från Nordpool.
Den har en del skönhetsfel, som jag hoppas kunna reda ut. Det röda strecket markerar gränsen för den övre kvartilen och den gröna den undre. De kallas "high price" resp "low price" och används för att styra värmepumpen. Mer om det i nästa inlägg. Grafiken är "Apex-charts", också den tillgänglig i HACS.
Här är uträkningarna för high och low prices i config.yaml:
template:
- sensor:
- name: "cheap_level"
state: >
{{( ( float( state_attr( 'sensor.nordpool_kwh_se3_sek_2_05_0' , 'min' ) ) + float( state_attr( 'sensor.nordpool_kwh_se3_sek_2_05_0' , 'average' ) ) ) / 2 ) }}
- sensor:
- name: "cheap"
state: >
{{float( state_attr( 'sensor.nordpool_kwh_se3_sek_2_05_0' , 'current_price' ) ) < ( float( states('sensor.cheap_level'))) }}
- sensor:
- name: "expensive_level"
state: >
{{( ( float( state_attr( 'sensor.nordpool_kwh_se3_sek_2_05_0' , 'max' ) ) + float( state_attr( 'sensor.nordpool_kwh_se3_sek_2_05_0' , 'average' ) ) ) / 2 ) }}
- sensor:
- name: "expensive"
state: >
{{float( state_attr( 'sensor.nordpool_kwh_se3_sek_2_05_0' , 'current_price' ) ) > ( float( states('sensor.expensive_level'))) }}
Här är definitionen för själva grafiken:
type: custom:apexcharts-card
header:
show: true
title: Nordpool
show_states: true
colorize_states: true
graph_span: 3d
span:
offset: '-1 day'
start: day
now:
show: true
label: now
yaxis:
- id: Nordpool
opposite: true
decimals: 2
min: 0
- id: energy
decimals: 1
min: 0
series:
- entity: sensor.accumulated_consumption_current_hour_xxxxvagen_yy
yaxis_id: energy
show:
legend_value: false
type: column
name: energy consumption
color: blue
group_by:
func: max
duration: 1h
- entity: sensor.nordpool_kwh_se3_sek_2_05_0
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
in_header: false
attribute: today
name: Nordpool
color: orange
extend_to: false
data_generator: |
return entity.attributes.raw_today.map((p) => {
return [new Date(p.start), p.value];
});
- entity: sensor.cheap_level
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
fill_raw: last
name: low price
color: green
extend_to: now
- entity: sensor.expensive_level
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
fill_raw: last
name: high price
color: red
extend_to: now
- entity: sensor.nordpool_kwh_se3_sek_2_05_0
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
in_header: false
attribute: tomorrow
name: Nordpool
color: orange
extend_to: false
data_generator: |
return entity.attributes.raw_tomorrow.map((p) => {
return [new Date(p.start), p.value];
});
- entity: sensor.nordpool_kwh_se3_sek_2_05_0
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
unit: SEK/kWh
fill_raw: zero
name: Nordpool
color: orange
extend_to: false
group_by:
duration: 1h
- entity: sensor.cheap_level
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
in_header: false
fill_raw: last
name: low price
color: green
extend_to: false
group_by:
duration: 1h
- entity: sensor.expensive_level
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
in_header: false
fill_raw: last
name: high price
color: red
extend_to: false
group_by:
duration: 1h
/Fumble
Ifall det kan vara till hjälp för andra, har jag gjort så här för att importera prisinformation från Nordpool.
- Installera HACS (Home Assistant Components Store): https://hacs.xyz/ 1 och SSH om det inte redan finns på plats.
- Följ instruktionerna i Nordpool custom component: https://github.com/custom-components/nordpool#readme 8
Inloggade ser högupplösta bilder
Logga in
Skapa konto
Gratis och tar endast 30 sekunder
Den har en del skönhetsfel, som jag hoppas kunna reda ut. Det röda strecket markerar gränsen för den övre kvartilen och den gröna den undre. De kallas "high price" resp "low price" och används för att styra värmepumpen. Mer om det i nästa inlägg. Grafiken är "Apex-charts", också den tillgänglig i HACS.
Här är uträkningarna för high och low prices i config.yaml:
template:
- sensor:
- name: "cheap_level"
state: >
{{( ( float( state_attr( 'sensor.nordpool_kwh_se3_sek_2_05_0' , 'min' ) ) + float( state_attr( 'sensor.nordpool_kwh_se3_sek_2_05_0' , 'average' ) ) ) / 2 ) }}
- sensor:
- name: "cheap"
state: >
{{float( state_attr( 'sensor.nordpool_kwh_se3_sek_2_05_0' , 'current_price' ) ) < ( float( states('sensor.cheap_level'))) }}
- sensor:
- name: "expensive_level"
state: >
{{( ( float( state_attr( 'sensor.nordpool_kwh_se3_sek_2_05_0' , 'max' ) ) + float( state_attr( 'sensor.nordpool_kwh_se3_sek_2_05_0' , 'average' ) ) ) / 2 ) }}
- sensor:
- name: "expensive"
state: >
{{float( state_attr( 'sensor.nordpool_kwh_se3_sek_2_05_0' , 'current_price' ) ) > ( float( states('sensor.expensive_level'))) }}
Här är definitionen för själva grafiken:
type: custom:apexcharts-card
header:
show: true
title: Nordpool
show_states: true
colorize_states: true
graph_span: 3d
span:
offset: '-1 day'
start: day
now:
show: true
label: now
yaxis:
- id: Nordpool
opposite: true
decimals: 2
min: 0
- id: energy
decimals: 1
min: 0
series:
- entity: sensor.accumulated_consumption_current_hour_xxxxvagen_yy
yaxis_id: energy
show:
legend_value: false
type: column
name: energy consumption
color: blue
group_by:
func: max
duration: 1h
- entity: sensor.nordpool_kwh_se3_sek_2_05_0
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
in_header: false
attribute: today
name: Nordpool
color: orange
extend_to: false
data_generator: |
return entity.attributes.raw_today.map((p) => {
return [new Date(p.start), p.value];
});
- entity: sensor.cheap_level
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
fill_raw: last
name: low price
color: green
extend_to: now
- entity: sensor.expensive_level
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
fill_raw: last
name: high price
color: red
extend_to: now
- entity: sensor.nordpool_kwh_se3_sek_2_05_0
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
in_header: false
attribute: tomorrow
name: Nordpool
color: orange
extend_to: false
data_generator: |
return entity.attributes.raw_tomorrow.map((p) => {
return [new Date(p.start), p.value];
});
- entity: sensor.nordpool_kwh_se3_sek_2_05_0
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
unit: SEK/kWh
fill_raw: zero
name: Nordpool
color: orange
extend_to: false
group_by:
duration: 1h
- entity: sensor.cheap_level
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
in_header: false
fill_raw: last
name: low price
color: green
extend_to: false
group_by:
duration: 1h
- entity: sensor.expensive_level
yaxis_id: Nordpool
float_precision: 2
show:
legend_value: false
in_header: false
fill_raw: last
name: high price
color: red
extend_to: false
group_by:
duration: 1h
/Fumble
Styra varmvattenberedaren med nordpoolpriser
I inlägg #854 beskrivs importen av nordpoolpriserna. Här är automationerna som sätter börvärden för varmvattnet:
- id: '1653943393126'
alias: Varmvatten hög
description: Höj varmvattentemp vid lågt elpris
trigger:
- platform: state
entity_id:
- sensor.cheap
to: 'True'
condition: []
action:
- service: climate.set_temperature
data:
temperature: 55
target:
entity_id: climate.warm_water_stop_temp
mode: single
- id: '1653943498687'
alias: Varmvatten normal
description: Återställ varmvattentemp vid normalt elpris
trigger:
- platform: state
entity_id:
- sensor.expensive
to: 'False'
- platform: state
entity_id:
- sensor.cheap
to: 'False'
condition:
- condition: state
entity_id: sensor.cheap
state: 'False'
- condition: state
entity_id: sensor.expensive
state: 'False'
action:
- service: climate.set_temperature
data:
temperature: 51
target:
entity_id: climate.warm_water_stop_temp
mode: single
- id: '1656622899083'
alias: Varmvatten låg
description: Sänk varmvattentemp vid högt elpris
trigger:
- platform: state
entity_id:
- sensor.expensive
to: 'True'
condition: []
action:
- service: climate.set_temperature
data:
temperature: 45
target:
entity_id: climate.warm_water_stop_temp
mode: single
Jag började med att sätta temperaturen till 60 grader vid lågpris, vilket verkar vara max. Det gör dock att värmepumpen går mer eller mindre hela tiden, vilket nog inte är bra. Vid 55 grader blev det betydligt lugnare. Ni kan prova vad som funkar bäst för er. Min VP är 18 år gammal, så en modernare kanske klarar lite högre temp utan att jobba ihjäl sig?
En annan observation är att jag bara tittar på nordpoolpriset utan påslag och skatter i dagsläget. Det leder till att vissa dygn, när priserna är låga och skillnaderna små, kommer logiken köra i alla fall, även om prisskillnaden bara är ett par öre. Det kostar lite extra energi att flytta sin förbrukning, så detta är inte optimalt. Det är nog bättre att lägga på alla påslag, skatter och överföringsavgift och styra på totalen i stället. Det kan göras i konfigurationen av prisimporten.
Att styra värmen i huset på liknande sätt borde gå, men jag tror det svider mer att ha "förvärmningen" påslagen hela natten/billigperioden än för varmvattnet. I så fall skulle man behöva en logik som räknar ut när "förvärmningen" ska starta. "Förvärmning" av huset kräver också att både värmekurvan ökas och att man gör något med termostaterna också, om man inte har turen att kunna köra med dem helt öppna. Jag har alltså bergvärmepump. Tänket får anpassas för andra värmeslag.
/Fumble
I inlägg #854 beskrivs importen av nordpoolpriserna. Här är automationerna som sätter börvärden för varmvattnet:
- id: '1653943393126'
alias: Varmvatten hög
description: Höj varmvattentemp vid lågt elpris
trigger:
- platform: state
entity_id:
- sensor.cheap
to: 'True'
condition: []
action:
- service: climate.set_temperature
data:
temperature: 55
target:
entity_id: climate.warm_water_stop_temp
mode: single
- id: '1653943498687'
alias: Varmvatten normal
description: Återställ varmvattentemp vid normalt elpris
trigger:
- platform: state
entity_id:
- sensor.expensive
to: 'False'
- platform: state
entity_id:
- sensor.cheap
to: 'False'
condition:
- condition: state
entity_id: sensor.cheap
state: 'False'
- condition: state
entity_id: sensor.expensive
state: 'False'
action:
- service: climate.set_temperature
data:
temperature: 51
target:
entity_id: climate.warm_water_stop_temp
mode: single
- id: '1656622899083'
alias: Varmvatten låg
description: Sänk varmvattentemp vid högt elpris
trigger:
- platform: state
entity_id:
- sensor.expensive
to: 'True'
condition: []
action:
- service: climate.set_temperature
data:
temperature: 45
target:
entity_id: climate.warm_water_stop_temp
mode: single
Jag började med att sätta temperaturen till 60 grader vid lågpris, vilket verkar vara max. Det gör dock att värmepumpen går mer eller mindre hela tiden, vilket nog inte är bra. Vid 55 grader blev det betydligt lugnare. Ni kan prova vad som funkar bäst för er. Min VP är 18 år gammal, så en modernare kanske klarar lite högre temp utan att jobba ihjäl sig?
En annan observation är att jag bara tittar på nordpoolpriset utan påslag och skatter i dagsläget. Det leder till att vissa dygn, när priserna är låga och skillnaderna små, kommer logiken köra i alla fall, även om prisskillnaden bara är ett par öre. Det kostar lite extra energi att flytta sin förbrukning, så detta är inte optimalt. Det är nog bättre att lägga på alla påslag, skatter och överföringsavgift och styra på totalen i stället. Det kan göras i konfigurationen av prisimporten.
Att styra värmen i huset på liknande sätt borde gå, men jag tror det svider mer att ha "förvärmningen" påslagen hela natten/billigperioden än för varmvattnet. I så fall skulle man behöva en logik som räknar ut när "förvärmningen" ska starta. "Förvärmning" av huset kräver också att både värmekurvan ökas och att man gör något med termostaterna också, om man inte har turen att kunna köra med dem helt öppna. Jag har alltså bergvärmepump. Tänket får anpassas för andra värmeslag.
/Fumble