stigvi

Jeg følger jo med ? Det dreier seg om å sette riktige sannsynligheter på inngangene. Slik at en inngang ikke bidrar for lite til å ha noen virkning eller bidrar for mye og overstyrer andre innganger. Sånn sett er simulering med regnearket et must. Nå treffer det 100% prosent hos meg, men av og til stusser jeg på hvorfor varmen står på når den kanskje skulle vært av fordi jeg har glemt at strømpris er en faktor.

Har brukt det en god stund (siden i fjor sommer) og synes det fungerer bra

I mitt system bruker jeg innganger til styringen som f.eks. dette - entity_id: binary_sensor.preheat_day prob_given_true: 0.66 platform: 'state' to_state: 'on' preheat_day er en sensor som fører til at varmen slås på automatisk før vi er hjemme. Den er kun tidsstyrt og jeg tar den (og de andre) med her for eksempelets skyld binary_sensor: - platform: template sensors: worktime: entity_id: sensor.time_online value_template: >- {{ now().hour*3600+now().minute*60 + 2400 >= (state_attr("input_datetime.worktime_start", "timestamp") | int) and now().hour*3600+now().minute*60 - 1200 < (state_attr("input_datetime.worktime_end", "timestamp") | int) and states("binary_sensor.workday_sensor") == "on"}} soonsleeptime: entity_id: sensor.time_online value_template: >- {{ (now().hour*3600+now().minute*60 + 60*(states("input_number.heatingtime") | int) >= (state_attr("input_datetime.normal_bedtime", "timestamp") | int) or now().hour < 4) and now().strftime("%w") != "5" and now().strftime("%w") != "6" and states("input_boolean.sleeptime") == "off" }} preheat_day: entity_id: sensor.time_online value_template: >- {{ now().hour*3600+now().minute*60 + 60*(states("input_number.heatingtime") | int) >= (state_attr("input_datetime.worktime_end", "timestamp") | int) and now().hour*3600+now().minute*60 - 3600 < (state_attr("input_datetime.worktime_end", "timestamp") | int) and states("binary_sensor.workday_sensor") == "on" }} preheat_night: entity_id: sensor.time_online value_template: >- {{ (now().hour*3600+now().minute*60 + 120*(states("input_number.heatingtime") | int) >= (state_attr("input_datetime.wakeuptime", "timestamp") | int) and now().hour*3600+now().minute*60 - 600 < (state_attr("input_datetime.wakeuptime", "timestamp") | int) and states("binary_sensor.workday_sensor") == "on") or (now().hour >= 6 and now().hour < 9 and states("binary_sensor.workday_sensor") == "off") }} heatlimit_morning: entity_id: sensor.time_online value_template: >- {{ now().hour*3600+now().minute*60 + 900 >= (state_attr("input_datetime.wakeuptime", "timestamp") | int) and now().hour*3600+now().minute*60 < (state_attr("input_datetime.worktime_start", "timestamp") | int) and states("binary_sensor.workday_sensor") == "on" }} extended_preheat: entity_id: sensor.time_online value_template: >- {{ (now().hour*3600+now().minute*60 + 120*(states("input_number.heatingtime") | int) >= (state_attr("input_datetime.worktime_end", "timestamp") | int) and now().hour*3600+now().minute*60 + 60*(states("input_number.heatingtime") | int) < (state_attr("input_datetime.worktime_end", "timestamp") | int) and states("binary_sensor.workday_sensor") == "on") or (now().hour*3600+now().minute*60 + 180*(states("input_number.heatingtime") | int) >= (state_attr("input_datetime.wakeuptime", "timestamp") | int) and now().hour*3600+now().minute*60 + 120*(states("input_number.heatingtime") | int) < (state_attr("input_datetime.wakeuptime", "timestamp") | int) and states("binary_sensor.workday_sensor") == "on") or (now().hour >= 5 and now().hour < 6 and states("binary_sensor.workday_sensor") == "off") }} Og da har jeg synliggjort en svakhet med Home Assistant. Beregning av tidspunkter og i det hele tatt, styring basert på tidspunkt, blir fort komplisert og uoversiktlig. Men jeg har i det minste klart å separere de forskjellige delene godt. Jeg trenger ikke rote med en kompleks varmestyringslogikk for å endre på tidstyringen når jeg setter forskjellige sensorer av eller på og deretter bruker sensoren som inngang til den bayesiske sensoren

Det kommer senere i dag eller i morgen

Tenkte å beskrive min løsning på varmestyring. Når en får mange nok parametre å ta hensyn til så kan ordinær tilstandsstyring bli ganske kompleks. Styring av varme gjøres ofte basert på status om en er hjemme, strømpris, tid på døgn, temperatur, dører eller vinduer åpne, ønske om å skru på varme når en snart er hjemme (for å slippe å komme hjem til kaldt hus) osv. I tillegg ønsker en forskjellig styring på de forskjellige varmekildene. Alt dette gjorde at jeg så mørkt på å lage logikk som skal styre dette. Så jeg endte opp med å bruke noen bayesiske sensorer. Da koker det ned til å enkelt beskrive hvor mye jeg ønsker at varmen skal slås på i de forskjellige tilstandene isolert sett. Bayesisk sensor brukes vanligvis i hjemmeautomasjon til å avgjøre om en er hjemme eller ikke basert på forskjellige innsignaler. Den bayesiske sensoren i Home Assistant er binær, dvs at den har en tilstand som er av eller på (eller hjemme og borte). Mine varmekilder har 3 tilstander jeg ønsket å styre (borte, økonomi eller komfort som hver har sine temperaturer en ønsker å oppnå). Home Assistant sin bayesisk sensor har en attributt som angir kalkulert sannsynlighet og denne bruker jeg til å styre varmen. Er sannsynligheten for at jeg ønsker varme mindre enn 10% så settes varmekilden i "borte" modus. Er sannsynligheten mellom 10% og 50% så settes de i økonomi og ved mer enn 50% så settes de i komfortmodus. Dette løses ved å hente ut sannsynligheten med dette: - platform: template sensors: varmekabel_probability: friendly_name: "Varmekabel sannsynlighet" unit_of_measurement: '%' value_template: "{{ state_attr('binary_sensor.varmekabler', 'probability') }}" og følgende automatisering - id: varmekabler_eco alias: Setter varmekabler i øko trigger: - entity_id: sensor.varmekabel_probability platform: numeric_state above: 0.1 below: 0.5 for: seconds: 20 action: - alias: '' data: entity_id: - climate.bad_u_etg - climate.bad_1_etg - climate.gang_u_etg - climate.vaskerom preset_mode: eco service: climate.set_preset_mode Jeg har lagt inn 20 sekund forsinkelse her fordi ovnene liker ikke å bli mast på for ofte. Forsinkelsen kunne vært kortere som f.eks. 2s. Varme i garasjen har en forsinkelse på 2 minutt slik at kortvarig bruk av garasjeport ikke fører til endring på ovnen der. Så til selve den bayesiske sensoren: binary_sensor: - platform: bayesian name: 'Varmekabler' prior: 0.35 probability_threshold: 0.5 #device_class: presence observations: - entity_id: input_boolean.travel_enabled prob_given_true: 0.001 platform: 'state' to_state: 'on' - entity_id: binary_sensor.noen_er_hjemme prob_given_true: 0.7 platform: 'state' to_state: 'on' - entity_id: input_boolean.sleeptime prob_given_true: 0.32 platform: 'state' to_state: 'on' - entity_id: binary_sensor.soonsleeptime prob_given_true: 0.32 platform: 'state' to_state: 'on' - entity_id: input_boolean.soonhome prob_given_true: 0.66 platform: 'state' to_state: 'on' - entity_id: binary_sensor.preheat_day prob_given_true: 0.66 platform: 'state' to_state: 'on' - entity_id: binary_sensor.preheat_night prob_given_true: 0.66 platform: 'state' to_state: 'on' - entity_id: binary_sensor.extended_preheat prob_given_true: 0.6 platform: 'state' to_state: 'on' - prob_given_true: 0.6 platform: 'template' value_template: >- {{ float(states('sensor.electricity_price_orstad')) < (float(state_attr('sensor.electricity_price_orstad', 'max_price')) - float(state_attr('sensor.electricity_price_orstad', 'min_price'))) * 0.3 + float(state_attr('sensor.electricity_price_orstad', 'min_price')) }} - prob_given_true: 0.4 platform: 'template' value_template: >- {{ float(states('sensor.electricity_price_orstad')) > (float(state_attr('sensor.electricity_price_orstad', 'max_price')) - float(state_attr('sensor.electricity_price_orstad', 'min_price'))) * 0.95 + float(state_attr('sensor.electricity_price_orstad', 'min_price')) }} Jeg starter med å si at normal tilstand er 35% som betyr økonomimodus på varmekildene. På en bayesisk sensor er det slik at innganger som bidrar med mer enn 50% gjør at sannsynligheten for på/hjemme/sann/varme/osv går opp. Innganger som bidrar med mindre enn 50% gjør at den totale sannsynligheten går ned. Så når jeg har en bryter som sier jeg er på ferie og setter sannsynligheten til 0.001 så går sannsynligheten for at jeg ønsker varme så kraftig ned at ingen andre innganger klarer å få den over 10% som var grensen for bortemodus. Resten av inngangene er vel stort sett selvforklarende. Varmen settes i de forkjellige modusene ut i fra om jeg er hjemme, om det er sovetid osv. Nederst har jeg satt opp ønsket mitt ut i fra strømpris lav eller høy. To andre bayesiske sensorer hos meg ser slik ut: - platform: bayesian name: 'Panelovner garasje' prior: 0.35 probability_threshold: 0.5 #device_class: presence observations: - entity_id: binary_sensor.garasjeport prob_given_true: 0.001 platform: 'state' to_state: 'on' - entity_id: input_boolean.garage_comfort prob_given_true: 0.7 platform: 'state' to_state: 'on' - platform: bayesian name: 'Panelovner tvstue' prior: 0.35 probability_threshold: 0.5 #device_class: presence observations: - entity_id: input_boolean.travel_enabled prob_given_true: 0.001 platform: 'state' to_state: 'on' - entity_id: binary_sensor.noen_er_hjemme prob_given_true: 0.7 platform: 'state' to_state: 'on' - entity_id: input_boolean.sleeptime prob_given_true: 0.32 platform: 'state' to_state: 'on' - entity_id: binary_sensor.soonsleeptime prob_given_true: 0.32 platform: 'state' to_state: 'on' - entity_id: binary_sensor.preheat_day prob_given_true: 0.66 platform: 'state' to_state: 'on' - entity_id: input_boolean.soonhome prob_given_true: 0.66 platform: 'state' to_state: 'on' - entity_id: binary_sensor.heatlimit_morning prob_given_true: 0.4 platform: 'state' to_state: 'on' Den for garasje er svært enkel og styres kun ut i fra 2 innganger. Panelovnene inneholder mer, men i motsetning til varmekablene så er ikke strømpris med som en inngang på disse. Men strømpris kunne fint vært med, men da med sannsynlighet som lå nærmere 50% i forhold til det varmekablene har. Dess lenger fra midtpunktet på 50% en inngang bidrar med, dess mer påvirkes utgangen. Det som kompliseres er å finne riktige sannsynligheter på inngangene. For å gjøre denne jobben lettere, laget jeg et excel regneark der jeg kan simulere hvor mye hver inngang påvirker utgangen. Kan gjerne dele dette regnearket ..... Så det var min løsning. Sikkert ikke veldig unikt, men jeg tror at dette i det minste kan være til bittelitt nytte for de som eventuelt er i startgropa for å sette opp et system.

Eller en Shelly 1 som du legger esphome inn på. Da kan du legge logikk inn i Shelly 1 som gjør at den ser ut som en garasjeport i Home Assistant og du kan lett styre hvor høyt porten skal åpnes hvis porten din støtter å stoppes på vilkårlig sted. I tillegg er Shelly1 langt mer fleksibel på strømforsyningen og kan drives på 12V dc til 240V ac. Med logikk lokalt i Shelly 1 så mener jeg du lettere kan heve sikkerheten også med f.eks. automatisk lukking selv om Home Assistant er nede for telling. https://esphome.io/components/cover/time_based.html

Jeg ligger hvertfall godt an i januar ?

I tillegg til å spore telefoner via bluetooth og nettverk for å avgjøre om vi er hjemme så bruker jeg også bevegelsessensorer og dørsensorer til dette. Det "smarte" her er at en bevegelse setter i gang en nedtelling på X timer eller minutter og så lenge den teller ned regnes vi som hjemme. En bevegelse i et bad eller i gang/stue setter nedtellingen til flere timer. Utgangsdøren til 10 minutter og garasjeporten til 2 minutter. Er vi på vei inn så øker tiden fra 2 til 10 til 120 minutter etterhvert som vi kommer "lenger inn". På vei ut går nedtellingen fra 120 til 10 og eventuelt 2 minutter før vi er registrert som borte. Dette fungerer så greit at sporing av telefon bare sees på som et kjekt å ha tillegg for å gjøre den bayesiske sensoren for hjemmedeteksjon enda litt mer treffsikker.

Synd at Klepp kommune ikke vil dele krypteringsnøkkelen med meg. Måleren sender ut info hver time, men temmelig utilgjengelig for meg allikevel. Jeg hørte med kommunen og ble henvist til en person som tydeligvis finner det enklest å ikke svare på henvendelser ?

Noen som vet hvem som selger selvklebende og flat ledning for å lime fast i gulv og som brukes til å detektere vann?

Da var enda et steg i husautomatiseringen ferdig. Automatisk stenging av vann dersom det lekker. Det som Block Watne hadde montert var elendig. Attpåtil var det feilmontert med vannsensor i en krøll i et hjørne istedenfor å limes fast i gulvet. Nå er slikt på plass. I tillegg har jeg lagt inn at vannet stenges automatisk hvis vi er vekkreist. Og viktigst av alt, mitt system er lett å sjekke at det virker. En Shelly 1 styrer ventilen og Aqara vannsensorer detekterer fukt esphome: name: hovedvannkrane platform: ESP8266 board: esp01_1m wifi: ssid: "HEIME5.ORG" password: !secret heime_wifi domain: .lan # Enable fallback hotspot (captive portal) in case wifi connection fails # ap: # ssid: "Hovedvannkrane Fallback Hotspot" # password: "mC6tMvvljYTU" #captive_portal: # Enable logging logger: # Enable Home Assistant API api: ota: time: - platform: homeassistant id: homeassistant_time globals: - id: state_hovedkrane type: bool restore_value: no initial_value: 'false' - id: state_nodkrane type: bool restore_value: no initial_value: 'false' - id: last_value_from_ha type: int initial_value: '0' # fra 60 til 120 interval: - interval: 15s then: - if: condition: - lambda: !lambda |- auto time_now = id(homeassistant_time).utcnow(); if(time_now.timestamp - id(last_value_from_ha) > 120) return true; return false; then: - globals.set: id: state_nodkrane value: 'false' - switch.turn_off: ventil switch: - platform: gpio pin: 4 id: ventil restore_mode: ALWAYS_OFF - platform: template name: "Hovedkrane" id: hovedkrane lambda: |- return id(state_hovedkrane); turn_on_action: - globals.set: id: state_hovedkrane value: 'true' - if: condition: lambda: 'return id(state_hovedkrane) && id(state_nodkrane);' then: - switch.turn_on: ventil turn_off_action: - globals.set: id: state_hovedkrane value: 'false' - switch.turn_off: ventil - platform: template name: "Nødkrane" id: nodkrane lambda: |- return id(state_nodkrane); turn_on_action: - globals.set: id: state_nodkrane value: 'true' - if: condition: lambda: 'return id(state_hovedkrane) && id(state_nodkrane);' then: - switch.turn_on: ventil turn_off_action: - globals.set: id: state_nodkrane value: 'false' - switch.turn_off: ventil sensor: - platform: homeassistant name: "Uptime from Home Assistant" id: watchdog entity_id: sensor.time_online on_value: then: - lambda: !lambda |- auto time_now = id(homeassistant_time).utcnow(); id(last_value_from_ha) = time_now.timestamp;

Med 6 mnd gammelt hus er det helt uaktuelt å rive vegger for å gjøre noe med kanalen ?

Jeg har en kjøkkenvifte som bråker fælt og mye av grunnen til dette er at det er liten forskjell på minste og største viftehastighet. Den hadde blitt mer "spiselig" dersom minste hastighet var et vesentlig mindre turtall. Jeg har ikke åpnet motoren for å se hva det er for noe, men jeg antar i første omgang at det er en 1-fase asynkronmotor. Hvilke muligheter har jeg for å regulere hastigheten over et større område, annet enn med en frekvensomformer? Og hvordan er hastigheten normalt styrt i slike vifter? Min har 4 trinn.

Godt nytt år Jeg har ikke mistet noe i Tibber

Til Home Assistant finnes komponenten "Flux" som gjør akkurat det som beskrives her. Flux komponenten har jeg dessuten modifisert litt slik at lyset over garasjeporten går via rosa og blått etter solnedgang PS. Flux komponenten kan også brukes i en "scene" for å slå den av og på etter behov

Tibber komponenten burde hatt en funksjon for dette, men jeg har det for travelt og for lite motivasjon for å endre den

Ja, svært enkelt å implementere og mer robust enn min ide

Tibber komponenten gir daglig strømforbruk i form av accumulatedConsumption, men denne er ikke særlig god til å bruke til å tegne en graf over forbruket. Den starter på 0 ved midnatt og øker i løpet av døgnets 24 timer. Det jeg kunne tenke meg var en sensor i HA som viste maksimumverdien av accumulatedConsumption hvert døgn. Det finnes mange måter å løse det på og en tilsynelatende enkel måte er ved midnatt kopierer accumulatedConsumption til en input_sensor. Faren er at en kan kopiere etter at accumulatedConsumption er nullstilt. Men spørsmålet: Finnes det en elegant måte å vise forrige dags strømforbruk på? Tibber komponenten

SUPPORT 100-240 V~ 50/60 Hz With Shelly Dimmer/SL you can use incandescent and halogen lights: 10-220W, dimmable LED lights: 50-200VA / 10W – 200W or resistive-inductive loads: ferromagnetic transformers 50-150VA. Shelly Dimmer SL 200–240V neutral not required.

Håndkletørkeren hadde en to-polt elko bryter foran seg. Den byttet jeg ut med en 2+1 elko bryter og den en-polet bryteren jeg da fikk ekstra har jeg en impulsfjær bak og som brukes til å starte 8 timer manuelt. På Shelly 1 har jeg lagt inn esphome og denne håndterer bryter og nedtelling lokalt. I Home Assistant har jeg tilkoblet en fuktighetsføler som får HA til å slå på håndkletørkeren når fuktigheten stiger brått. Det morsomme er at kona er mer begeistret over dette enn jeg er. Stirrer på lyset på topp av tørkeren for å se hvor lang tid det tar før den slår seg på etter at dusjingen startet.

Jeg har satt inn en Elko impulsfjær bak bryterdekselet. Da er det ingen som slår av lyset på feil sted. Shelly1 krever L og N. Men Shelly har andre dimmere som ikke krever N. De kan erstatte en bryter under forutsetning av at pæren er en glødepære. Vet ikke om de fungerer med LED pærer, men det går jo å sjekke spesifikasjoner på de til Shelly

ja, jeg bruker shelly1 til å styre en håndkletørker. Varmen slås på manuelt med en trykkbryter eller automatisk når en dusjer og varmen slås av etter 8 timer. Men....... Hvorfor ikke få lys over på zigbee først som sist? Bytt ut lyspærer og eventuelt armaturer.

Fikk svar fra "kilden" Hei EasyCodeV2 har en inngang som man kan montere Zigbee modul i, her kommer det i Q2 en Zigbee 3.0 module. Vil tro den kan brukes om systemet ditt støtter Zigbee 3.0 ? Best regards EasyAccess AS

Easy Access EasyCode V2 kodelås https://coop.no/sortiment/obs-bygg/sikkerhet-156c1e99/elektroniske-laser-og-tilbehor-83a58db6/easyaccess-easycode-v2-kodelas-43?variantCode=514078 Til denne kan en få en modul som har bluetooth og som kommuniserer med ringeklokken til samme produsent. Ringeklokken har wifi og med nettilkobling kan en fjernstyre låsen. Men så det jeg lurer på: Her det mulig å pare låsens bluetooth med f.eks. en Raspberry pi eller esp32 og styre den som en selv vil? Noen som har lest at dette er gjort av andre?

Hvis dette er en dedikert maskin til HA, hvorfor kjøre virtuellt oppå W10 eller Ubuntu? Gir ikke det bare et ekstra lag med mulighet for feil? Jeg vurderer selv en NUC og ser at HA har en fiks ferdig installasjon for NUC. Er den like rett fram som installasjonen for Raspberry pi?