stigvi

RVM skrev (6 minutter siden):

Nå har vi sporet tråden helt av (beklager!), men jeg er glad for at HA er så fleksibelt at det finnes mange ulike måter å gjøre ting på - slik at jeg kan gjøre det på en måte jeg ønsker. Jeg er ikke så opptatt av at alt skal være enklest mulig, men jeg forstår at andre vurderer det annerledes.

Enig at en må selv finne ut av det.

Men automasjoner i HA tror jeg har et ufortjent dårlig rykte fordi en tar utgangspunkt i hva det var og ikke hva det er nå. Jeg selv blir litt matt av de som setter i gang med HA for aller første gang og så installerer node-red uten en gang å ha prøvd automasjoner (jeg peker ikke på noen i denne tråden. Det er mer en oppfattelse jeg sitter igjen med i andre fora). Spesielt i Home Assistant for Norge forumet på FB har det utviklet seg en oppfatning av at det kun er i node-red en kan løse ting.

Det er selvfølgelig masse en kan kritisere i HA, også. Feks må en for ofte ty til yaml-redigering for å utnytte avansert funksjonalitet. Men det blir bedre i små skritt for hvert slipp av ny versjon hver måned.

minim skrev (1 time siden):

Mye ryddigere å ha alt som styrer en utgang på et sted synst jeg

Det er bare at det finnes ikke utganger i HA. Du styrer noe ved hjelp av hendelser. Ta feks et lys. Du slår det på med turn_on og slår det av med turn_off. Dette er to forskjellige operasjoner (eller hendelser som en sender inn i systemet). Lyset skal gjerne slås på ved hjelp av en bevegelsesensor og slås av når det har stått på i noen minutter. Dette er to forskjellige hendelser. Jeg ser på forumet til HA at mange prøver å få dette inn i en enkel automasjon fordi en tenker at dette er et lys en skal styre. Men jeg mener det er langt enklere å løse dette med å splitte det opp. Det er to separate hendelser som utfører to separate operasjoner.

Og det er lett å løse det med to korte automasjoner også. Å lage en enkel automasjon for dette, ville jeg ikke vurdert en gang.
Det som gjenstår er å navngi dette logisk slik at en lett finner det igjen
Det kan være:
bad_1_etg_turn_on
bad_1_etg_turn_off

Men som andre har nevnt og som jeg er enig i, det er smak og behag hvordan en gjør det. Men HA er ikke en PLS og en gjør det vanskelig for seg selv hvis en prøver  å programmere den som om den var det.

Slå på:



Slå av:

minim skrev (36 minutter siden):

Det der er mye ryddigere i mitt hode, men mulig man må snu tankegangen og akseptere rotet siden det virker for å være måten å gjøre det på i HA. Kanskje python er løsningen her i stede for å trekke inn nodered som også lar meg jobbe som jeg ønsker. 

Avfukteren til RVM kan en selvfølgelig lage en enkel automasjon på i HA der en setter opp mange triggere. Det er faktisk veldig lett også.

minim skrev (14 minutter siden):

 

Takker for god forklaring begge to. Dette er no uvaner jeg drar med meg fra jobb i Siemens plser ja. Det er ryddig å ha alt som styrer utgangen samlet synst jeg så en kan se at ikke en lager loops og andre rariteter blant 100 andre automasjoner 😛

Du nevner to forhold som virker mot hverandre. Det er lettest å lage og vedlikeholde automasjoner hvis de er korte. Men det går ut over totaloversikten. Da vil jeg anbefale at du lager de korte og konkret til en enkel oppgave. Å slå av og på er i utgangspunktet to oppgaver 🙂

Etterhvert vil brukergrensesnittet i HA bli oppdatert for å gjøre det lettere å holde oversikt. Selv kan du allerede nå starte med god navngivning.

Her virker det som noen i Radio Haugaland roter fælt. Haugaland Kraft har ingenting med nettleie å gjøre. Dette er det Fagne AS som driver med. Å dra inn et annet selskaps overskudd i omtale av Fagne sin økning av nettleie, er bare helt merkelig.

RVM skrev (14 minutter siden):

Det er ofte jeg må løsrive meg fra tanken om et syklisk kontrollsystem som jeg er vant til fra jobb, f.eks. en PLS. Må tenke litt annerledes for et event-basert kontrollsystem som Home Assistant.

Event basert system er et helt naturlig valg i et overordnet system som HA, ja 🙂 Men når det gjelder vaskemaskinen så ville jeg splittet dette opp i to automasjoner. Det eneste problemet med dette er at det blir fryktelig mange automasjoner av de. Men jeg lærte i går at Home Assistant vil svært sannsynlig få en bedre organisering på dette i 2024. Det er noe de allerede jobber med.

Det gjelder ikke eldre Karmstrup målere, heller

haraldov skrev (2 timer siden):

Du kan også sende en mail til strømselskapet å be de rekonfigurere strømmåler til å bruke DLMS data

Det du linket til, gjelder Karmstrup målere. Jeg har  en Aidon og jeg kikket litt i dokumentasjonen på de. Det ser ikke ut som om de kan konfigureres til å sende noe annet enn det de allerede gjør. Med forbehold om at dokumentet jeg kikket i er foreldet, da.

minim skrev (9 timer siden):

Muligens et dumt spørsmål, men slike eksempler som du har der ligger det mye av på nett, men det er jo bare 50% av automasjonen

Forstår ikke helt hva du mener her. Jeg ønsker å slå på radio når jeg kommer hjem. Hverken mer eller mindre.

Jo, jeg har automasjoner som slår av sonos når jeg legger meg eller forlater huset, men de har helt andre triggere. Det blir rot å blande ting som skal skje på forskjellige triggere. Å dele automasjonene opp i små snutter som gjør en helt enkel konkret ting, tror jeg er lurt. Jeg blander ikke styring av alarm inn i samme automasjon som styring av radio, selv om disse kan ha helt like triggere.

SveinHa skrev (15 minutter siden):

Nøyaktig samme grunn til at jeg ga opp HomeSeer selv om HS har en for så vidt grei gruppering.

Når det gjelder Home Assistant så er det neppe snakk om "hvis", men "når" de får en bedre måte å organisere dette på så kommer jeg selv til å gjøre om mange av mine python skript til Home Assistant automasjon.

Dette er typisk å slå på radio via Sonos når noen kommer hjem etter at huset har stått tomt. Det er en python funksjon på 4 linjer

 

@state_trigger("binary_sensor.noen_er_hjemme == 'on' and binary_sensor.noen_er_hjemme.old == 'off'")
def somebodygothome():
    media_player.stue.select_source(source = "NRK P1 Rogaland")
    media_player.volume_set(volume_level = 0.3, entity_id = "all")

og lages like enkelt i HA sin automasjon. Grunnen til at jeg ikke har gjort det er altså at det blir for mange slik små snutter. I pyscript kan jeg organisere det i mapper.

Venin skrev (6 minutter siden):

Hvilken oversikt er det du trenger egentlig? Jeg har inndelt alle mine med prefiks for rommet hvor automasjonen utføres (så langt det lar seg gjøre). Og søkefunksjonen finner jo alt så lenge man har gode navn på automasjonene.

Ja, navneprefiks vil sannsynligvis løse det for meg også. Men jeg har tid til å vente enda litt til for å se om det kommer en grei måte å organisere det på.

Det finnes en mellomløsning hvis en synes HA sine automasjoner er "dårlige" og heller ikke har lyst til å bruke node-red.

Jeg selv er der. HA automasjoner er forsåvidt greie nok, men når en har hundrevis så mister en oversikten i HA sin flate automasjonsliste. Det går ikke å kategorisere dem eller plassere de i mapper. Men jeg synes allikevel en får til det meste. For meg er det oversikten det skorter på.

Jeg jobber med programmering så for meg var det helt naturlig å ta i bruk pyscript, https://github.com/custom-components/pyscript
Denne er langt mer lettvekt enn å gå for node-red, men programmering er lite brukervennlig hvis en ikke har erfaring fra før med det.

Einar skrev (1 time siden):

Hva som er enkelt for deg og meg kan være ganske forskjellig.

Det er sant. Men et automasjonssystem er alltid enklere enn to som skal kommunisere med hverandre.

KISS er noe jeg streber etter når det gjelder hjemmeautomasjon.

https://en.wikipedia.org/wiki/KISS_principle
 

Jeg fikk vel egentlig svar på det jeg lurte på. Jeg sliter med at amsleser ikke alltid får med seg kwh-teller oppdatering som sendes hver time. Jeg har nettopp byttet til en PowU fra en egenlagd og det samme problemet skjer på begge.

Det som skjedde var at den kontinuerlige telleren for dagsforbruk gikk ned ca 4kWh kl 10:00 og så spratt den opp ca 4kWh klokken 11:00. En ser hoppet mellom melding 49 og 50 nedenfor. Da tyder det på at dagsforbruket er basert på en integrasjon siste time og at resten av døgnets timer er på grunnlag av målerstand.

Det gjør det uansett svært vanskelig å bruke Energy Dashboard i HA. Jeg må egentlig mekke i hop et eller annet selv som tar høyde for at data mangler.

@gskjold

For meg er det et lite problem at jeg ikke vet hvordan amsleser kommer fram til dagsforbruket. Jeg ser av timeforbruket at de integrerer opp ved å bruke Riemann summering med "right" som innverdi. Jeg har testet litt med Riemann summering direkte i HA og ser at resultatet av integreringen blir mer nøyaktig med "middle" (eller trapezoidal) innverdi. Har planer om å skrive en feature request og spørre om de kan endre fra "right" til "middle" for å bedre nøyaktigheten.

Når det gjelder dagsforbruket som oppdateres "kontinuerlig", er det da en integrering i 24 timer eller er det integrering i 1 time pluss rapporterte målerverdier fra måleren i de foregående timene. Jeg har kikket bittelitt i koden, men fant det ikke. Hvis de integrerer i 24 timer, ser jeg for meg at dette tallet avviker en del fra det reelle når det nærmer seg slutt på døgnet.

kodax skrev (10 timer siden):

noe som virker som en merkelig begrensning

Det er vel ment som en frostsikring og i så fall ikke merkelig i det hele tatt. Jeg innbiller meg at det er ganske vanlig å begrense til 5-7 grader.

Info om esphome sin støtte for BK7231N prosessoren er her: https://esphome.io/components/libretiny

Esphome har støtte for CB2S. Mon tro hva som skiller den i fra CB3S.

Jeg fant ut jeg ville gjøre noe med dette selv og her er min løsning:

Jeg har laget en mal-sensor som dette
 

template:
  - trigger:
      - platform: time_pattern
        minutes: 59
        seconds: 55
    sensor:
      - unique_id: d0edb519-03b2-4848-9b86-ac39bb4d5a90
        name: klepp_energi_total_energi_denne_time
        state_class: total_increasing
        unit_of_measurement: kWh
        device_class: energy
        state: "{{ (float(states('sensor.klepp_energi_total_energi')) + float(states('sensor.energy')))|round(3) }}"

Så har jeg satt opp energy dashboard til å bruke denne nye sensoren.
 

Det som skjer er at 5 sekund før hver hele time blir denne sensoren satt til forrige times kWh teller som rapportert i fra måleren pluss timesforbruk som min HAN leser genererer ut i fra effekt som den integrerer opp. Jeg bruker amsleser. Jeg mener Tibber Pulse også har denne, men er ikke helt sikker. Uansett kan du bruke Home Assistant sin "Integration - Riemann sum integral" til å beregne den.

Løsningen har en svakhet. Det blir ikke helt nøyaktig. Litt skyldes at jeg mangler 5 sekund og litt skyldes at amsleser ikke er helt nøyaktig. Men avviket er stort sett innenfor 10-20Wh. Det er ikke mye og for meg en bedre løsning enn å ha en graf som er forskjøvet. Det positive er at integreringen starter på null hver time så en eventuell feil blir ikke summert opp gjennom hele døgnet.

Dette skrev jeg 12:40 og siste time i grafen er for 11:00 til 12:00

Jeg vil gjerne be om at dere gir en stemme på denne: https://community.home-assistant.io/t/energy-dashboard-is-shifted-one-hour/685596

minim skrev (10 timer siden):

Trodde dette fungerte slik at de automatisk fant router tilgjengelig egentlig.

Det gjør de. Men ikke nødvendigvis når du selv ønsker det. De finner nye ruter når de selv detekterer at det finnes noe bedre eller at den gamle ikke er god nok. Som oftest er de gamle rutene gode nok. I tillegg bruker de tid på det. Noen enheter bruker timer, andre enheter opp til en uke som feks enkelte Aqara sensorer.

Garasjeport er populært å automatisere. Her er min løsning og kanskje kan noen bruke det videre.

Min åpner er av den enkle typen. Den har to innganger, en for nødstopp og en for å veksle opp eller ned. 

Til denne har jeg koblet til et esp32 kort som jeg kjører esphome på.

I esphome har jeg definert en "cover" som er tidsbasert og med endebrytere.

 

cover:
  - platform: feedback
    name: "${devicename}"
    id: garasjeport
    has_built_in_endstop: true
    assumed_state: false
    direction_change_wait_time: 5s
    close_endstop: status_lukket
    open_endstop: status_aapen
    open_duration: 15s
    close_duration: 18s

Endebrytere trenger en strengt tatt ikke, men uten de så er det vanskelig for Home Assistant å vite om port er åpen eller lukket. Jeg hadde i land tid en zigbee dørsensor som viste om port var lukket og status på den ble sendt til esp32 slik at jeg kunne sette status på "cover" at porten var igjen. Etterhvert har jeg byttet ut zigbee sensor med brytere koblet til esp32 direkte. Ikke fordi det virker bedre, men fordi jeg hadde lyst.

I tillegg har jeg definert noen binære sensorer i esphome som forteller om status på port. Det er lukket, åpen og i bevegelse. I tillegg noen trykknapper for å starte en sekvens og å avbryte denne sekvensen. Til slutt noen innverdier for å sette antall sekunder til port åpnes og lukkes.

I og med at denne er synlig i Home Assistant som en "cover", har jeg full kontroll på port. Jeg kan dra i en skyvekontroll og settte porten til en vilkårlig posisjon. Ikke så mye brukt til annet enn å sette i luftestilling eller åpne en halvmeter for å ta i mot en pakkelevering når jeg selv er på jobb. Jeg har et kamera inne i garasjen så jeg kan følge med på at pakken er kommet innenfor.


Til porten fulgte det med to fjernkontroller og disse var årsaken til at jeg lagde min egen styring. Fjernkontrollene har tydeligvis dagshumør og noen dager må en helt inntil garasjeportåpnerens antenne før de reagerer. Det var veldig frustrerende. 
Det første jeg lagde, var en NFC brikke på en lur og usynlig plass i bilen. Når jeg holder telefon over denne, så åpnes port.
Etterhvert er det kommet zigbee-brytere inne i hus ved utgangsdør og inne i garasje ved port. Med disse kan jeg åpne og lukke, samt slå på nødstopp. Jeg har også lagd det slik at hvis bakluke på bil er åpen så slås nødstopp på. Da kan ikke port betjenes fra annet enn innside av garasje ved å slå av nødstopp først.
Og så har jeg en trykknapp i garasje som setter i gang en sekvens med å vente-åpne-vente-lukke. Da får en tid til å sette seg inn i bil og port går ned automatisk etter å ha kjørt ut. Sekvensen avbrytes hvis en trykker på knapp en gang til eller åpner garasjedør. Kona har en egen evne til å finne ut at hun ikke har bilnøkkel med seg og da må hun inn igjen i huset. Da er det dumt at port går opp og ned i mellomtiden.

Sensorer som esphome sender til Home Assistant, brukes til alarm og å trigge lys i garasje. Jeg setter også farge på en lyslist over port som viser om den er i bevegelse eller helt oppe.

Einar skrev (1 time siden):

Jeg har bestilt en Sonoff Zigbee dongle for å se om det er deCONZ

Jeg byttet ut deconz og conbee ii med sonoff zbdongle-p og zigbee2mqtt. Det hele har gått fra smått irriterende til dønn stabilt. Ingenting har falt ut. Zigbee2mqtt har hatt en krasj på 1 år. Jeg har laget en automasjon som fanger opp dette og starter den på nytt hvis det skulle skje flere ganger.

Februar utgaven av Home Assistant får støtte for å lese inn forbruksdata fra Elvia.

https://rc.home-assistant.io/integrations/elvia


Edit: Tenk hvis vi kunne fått en universell løsning for å lese data fra elhub, men neida. Elhub har selvfølgelig ikke noe api for slikt. Hvorfor skulle et offentlig eid selskap som har som oppgave å lagre og distribuere målepunktdata, ha et api som privatpersoner kan bruke?

Jeg er, som sikkert flere andre, avhengig av en daglig dose medisiner. Sånn er det når en er arvelig belastet med høyt blodtrykk. For å huske å ta medisin og for å ha kontroll på beholdning, har jeg brukt en app. Men har egentlig alltid tenkt at de som lager denne app'en får mye informasjon om meg. Så for et par dager siden fant jeg ut at jeg ville la Home Assistant styre dette.

Så det jeg har nå er en side i HA som viser min tablettbruk. I HA kan en sette visning og tilgang til sider ut i fra innlogget bruker så når kona tar dette fram på hennes mobil så ser hun sitt og ikke mitt. HA holder kontroll på beholdning og skifter farge på ikon når det nærmer seg tur til apotek. Har jeg ikke trykket på "Medisin tatt" knappen, får jeg et varsel på tlf som jeg svarer ja eller nei på (actionable notification som HA appen har). Her kan jeg sette "kanal" slik at jeg kan bruke egen varsellyd. Etter en time med litt fikling har jeg noe som fungerer bedre enn medisin-appen. Og herfra er det mange muligheter. Jeg kan feks varsle med et lys hjemme. Jeg kan la være å varsle på tlf hvis jeg ikke er hjemme. Det er jo ingen vits i det når tablettene ligger hjemme. Og jeg kan ha en trykknapp i skuffen på badet som teller ned beholdning.

PS. Jeg tar noen tabletter om morgen og noen om kveld. Selvsagt måtte jeg da lage det slik at det telles ned på de tablettene som gjelder for aktuelt tidsrom. Og det vises når de ble sist tatt.