stigvi

Har du erfaring med at et 256GB SD kort er mer utsatt enn en 256GB SSD? Når det gjelder å boote fra SSD, så er ikke dette en anbefalt løsning. Skal en lage noe robust for fremtiden så er det greit å bruke andre sine erfaringer og ikke ramle ned i gamle hull. Anbefalt løsning er å boote fra et SD kort og sette opp SSD som en data partisjon. SD kortet vil monteres som "kun lese" i HA OS'et og vil ikke slites. (PS. Gjelder altså Raspberry Pi) Og så er heller ikke Sonoff Dongle-E anbefalt, som nevnt tidligere ...........

Vil bare føye til at IKEA selger såkalte zigbee "repeatere". Disse er zigbee routere som er på strøm hele tiden og den eneste oppgaven de har er å forlenge rekkevidde på zigbee nettet. De gjør samme jobben som en zigbee lyspære, men uten å lyse 🙂

Før kom office pakken som en "pakke" med CD'er eller disketter. Da kunne en knytte det opp mot en faktisk leveranse. I dag har bedrifter større utgifter til skytjenester. Jeg jobber selv i en bedrift som betaler millionbeløp i skytjeneste-utgifter. Selvsagt må vi skyve slike kostnader over på kundene. I tillegg kommer oppgradering av programvaren oftere og ikke med årlig eller flerårlig intervall. Tidene har endret seg, rett og slett. Og kundene forventer hyppige oppdateringer slik de er vant med på telefon. Da kan ikke vi slippe en "pakke" og ta betalt for oppgraderingen som inneholder peanuts i forhold til hva det var i forrige uke eller måned. For Homeseer sin del er det langt mer gunstig å ha faste og trygge inntekter hver måned. Så jeg vil tro det blir mer og mer abonnement. Og som du sier, litt surt når en i utgangspunktet har betalt en fullpris. Dette er et dilemma som Homeseer bør løse på en grei måte med feks å gi rabatt til eksisterende kunder.

Det skal de og å betale abonnement er for meg helt naturlig. Men jeg jobber i IT bransjen og har vel nettopp en forståelse for at noen skal ha lønn. Ser derimot både her på forumet og i andre forum at det er noen som er prinsipielle motstandere på å betale. For meg er det en merkelig holdning, men folk må jo få ha sine prinsipper selv om de ikke fører til noe positivt. Prinsipper gjør sjelden det.......

Jeg har hatt det på Android en god stund, men har ennå ikke kommet på noe å bruke det til. Garasjeport er nok det nærmeste, men jeg har allerede en løsning som fungerer bedre. Jeg har en NFC brikke skjult under dashbord og bare "tæpper" telefonen der for å åpne eller lukke. Mulig jeg hadde brukt Android Auto hvis bilen hadde støttet trådløs tilkobling. Det er stort sett på lengre turer jeg tar meg bryet å koble til ledning. Ellers ser jeg at en kan opprette sensorer for å lese status på bilen som feks km-teller. Men disse virker ikke på min bil, dessverre.

Når en bruker service kall climate.set_temperature så må en sette både høy og lav. Er usikker på hvor denne begrensingen er, men det skaper ikke store utfordringer. Climate'en har target_temp_high og target_temp_low som attributter så hvis en vil endre kun den ene så setter en den andre til det attributten er. Jeg har brukt mange forskjellige kort opp gjennom årene og har aldri hatt problem med å sette temperatur og kun en av de. Det er kun service kallet som for meg krever at en oppgir begge temperaturene. Siste årene har jeg landet på climate-mode-entity-row der jeg bare setter presets, men klikker jeg på teksten, kan jeg sette temperaturene.

Jeg kjenner ikke til heat-it. Jeg bruker HA sin Nobø integrasjon. Den har støtte for presets.

Jeg styrer de via "climate" som har borte, øko og komfort modus. Så bruker jeg bayesian sensor i HA til å avgjøre hvilken modus de skal være i. Bayesian sensor for stue har inngang for effektregulator som passer på at jeg ikke havner i feil pristrinn på nettleie, om vi er på ferie, om vi snart er reist på ferie, om vi snart kommer hjem fra ferie, om vinduer er åpne, om noen er hjemme, om det er sovetid, om det snart er sovetid, om vi snart er hjemme, om vi snart står opp, om vi har besøk, om strømmen er så dyr at jeg heller vil fyre i vedovnen, prisnivå på strøm, om jeg har hjemmekontor neste dag. Varmekabler er styrt på samme måte, men der har jeg færre innganger på bayesisk sensor. På bad er det inngang for effektregulator / nettleie, om vi er på ferie, snart på ferie eller snart hjemme fra ferie, om vi har besøk og om strømmen snart blir billigere.

Jeg har i mange år nå hatt en lyslist over garasjeport der jeg endrer farge ut i fra solhøyde. Den er i utgangspunktet hvit, men når sol kommer like under horisont så endres den til mørk rosa med en overgangstid på en time og videre mot blått med en overgangstid på enda en time. Men forandring fryder og jeg så etter muligheten for å endre til en tilfeldig farge. Jeg kunne ikke fortsette med en scene fordi disse er statiske. Men i Home Assistant kan en definere dynamiske scener i skript og bruke scene.apply. Neste utfordring var at jeg ikke ville ha fargene grønt og gult med alle nyanser mellom disse to. Jeg ville heller ikke ha rødt og jeg ville kun ha sterke farger. Hvordan løser en det med RGB koder? Ikke så lett, fant jeg ut. Men Philips Hue smartpærer kan også styres farge på med X og Y koordinater eller med Hue og Saturation (HS). Det siste er løsningen. Jeg ville ha sterke farger så metningen er alltid 100%. Fargene styres med antall grader fra 0 til 360 så da er det bare å velge tilfeldig tall innenfor områder som utelater rødt, grønt og gult. Jeg har to skript. Et for å sette en tilfeldig farge i den røde/rosa enden og et for å sette i den blå enden. Så det er vel det en kaller semi-tilfeldig. Transition settes som en parameter til skriptet. Her kunne en selvsagt tatt med lysstyrke også, men jeg trenger ikke det i denne omgang. Det er ment som et eksempel på hvordan en setter en scene dynamisk....... tilfeldig_farge1_ute_1_etg: alias: Tilfeldig farge1 Ute 1. etg sequence: - variables: hue: '{{ (range(15, 45)|list+range(275,330)|list)|random }}' - service: scene.apply data: entities: light.ute_1_etg_a: state: true color_temp: 451 brightness: 180 light.ute_1_etg_b: state: true color_temp: 451 brightness: 180 light.ute_1_etg_c: state: true color_temp: 451 brightness: 180 light.garasjeport_lys: state: true hs_color: '[{{ hue }}, 100]' brightness: 150 transition: '{{transition}}' mode: single icon: mdi:palette tilfeldig_farge2_ute_1_etg: alias: Tilfeldig farge2 Ute 1. etg sequence: - variables: hue: '{{ (range(180,275)|list)|random }}' - service: scene.apply data: entities: light.ute_1_etg_a: state: true color_temp: 451 brightness: 120 light.ute_1_etg_b: state: true color_temp: 451 brightness: 120 light.ute_1_etg_c: state: true color_temp: 451 brightness: 120 light.garasjeport_lys: state: true hs_color: '[{{ hue }}, 100]' brightness: 140 transition: '{{transition}}' mode: single icon: mdi:palette

Topic navn for mqtt skiller mellom store og små bokstaver. Samtidig er Home Assistant veldig glad i bare små bokstaver, men om det er tilfelle når det gjelder topic, det vet jeg ikke. Men for å ikke friste skjebnen kan det være greit å holde seg til små bokstaver. @ArnieO Edit: Store bokstaver i name tag er verre. Her bør amsleser endre koden og kun tillate små bokstaver. Entity navn i HA kan _ikke_ inneholde store bokstaver. Det er noen andre begrensinger også som å ikke bruke mellomrom og helst unngå å starte med et tall.

For å spore det tilbake. Tråden starter med dette Men trenger det å være smarte strømleverandører? Hva med smarte netteiere? Elvia har et api som tilbyr ganske mye. Jeg har forstått det slik at de også tilbyr priser (Nordpool pris) og de nevner spesifikt at api er åpent for alle, også de som ikke er Elvia kunder. Da har en tilgang til pris. Selv bor jeg i en kommune som har funnet ut de vil ha et eget lite selskap for å drifte strømnettet. Alle nabokommunene har havnet under Lyse sitt nett. Klepp er forsåvidt greie nok. De har satset 100% på 400V TN nett og stort sett samtlige husstander i kommunen har dette. Det gjør elbil-lading litt mer fleksibelt i og med at utvalget bokser for AC lading blir litt større. De har også vært rimelige på nettleie, men det endret seg i 2024, dessverre. Det skorter stort på smarte løsninger. Her er det null api for deling av pris og forbruk. Egentlig er det rart at vi i Norge har endt opp der at vi har en spotpris som endrer seg time for time, men ingen felles api for å hente ut denne prisen. Og vi har en nettleie som varierer både i løpet av døgnet, basert på forbruk og basert på maks forbruk i løpet av en måned. Men heller ikke her en standardisert måte for kunder å vite hvordan en ligger an og hva en skal betale. Istedenfor har vi en drøss halv- og heldårlige løsninger lagd av selskaper som driver med fakturering og netteiere. Og det er mange av dem. En standard løsning på dette ville gjort det enkelt å utvikle løsninger og apper for å presentere dataene, men det nytter ikke slik det er nå. Jeg kan ikke engang få det jeg betaler for strømmen på en enkelt faktura. Jeg anser meg som rimelig oppegående på Home Assistant, men det er helt umulig slik det er nå å presentere tall for forbruk og hva jeg skal betale for dette. Jeg kan samle inn data selv og få det veldig likt det jeg til slutt skal betale, men helt nøyaktig blir det ikke.

Enn så lenge trenger du ikke tenke på å bytte vekk fra Vibb. Men det virker som om misnøyen med strømfaktureringsselskaper er økende. Og flere og flere lurer på hvorfor vi ikke bare kan få strømmen til Nordpool pris, fakturert av netteier som sitter inne med all info om forbruk. Det er jo egentlig helt molbo at forbruket skal sendes til et annet firma som gjør en fakturering av en av postene som den totale strømprisen består av. Mulig at politikere skjønner det etterhvert, selv om det muligens er å håpe på for mye. Alternativet er strømfaktureringsselskaper som kjøper inn kraft på langtidskontrakt og selger denne videre til en pris som er lavere enn spot. Men dette tror jeg sitter lenger inne.

Prisen for straffetakst er regulert av NVE kun i de 6 første ukene. Fra og med 7. uke kan Lnett sette opp prisen til hva de selv vil. Fint hvis det er 6,25 øre, men det er ikke slik i Klepp hos KE Nett.

Det er det. Men jeg har lagd knapper for de spesielle anledningene. Det kan være en knapp for leselys. Eller en nedtrekksliste for "dagsbesøk", "overnattingsbesøk" eller "ingen på besøk". Ringer noen på så kommer det opp et spørsmål på mobil 5 min etterpå. Så settes lys og varme ut i fra dette.

Jeg har delt det opp i funksjonalitet/tema. Alt lys på et kort. Alt for varme på et annet. I tillegg har jeg delt det opp i enkle kort som kun gjør det viktigste og mer tekniske "nerde" kort hvis en vil studere detaljer. Og så kan du også styre hvilke kort som skal være tilgjengelig for hvilke brukere så du kan unngå å presentere for mye dilldall til de som ikke har interesse av det. Men min filosofi er egentlig at det meste skal gå automatisk. En skal slippe å trykke på knapper på veggene og slippe å åpne appen på telefon. Men det er vanskelig å gjennomføre dette 100%

Kanskje ikke så mye hjemmeautomasjon, men jeg har en kalender i Home Assistant der jeg setter opp ferien. Dette brukes til å styre varme og lys mens vi er på reise. Så da tenkte jeg at veien er kort til en ferieplanlegger der vi legger inn antall feriedager og avspasering som er overført fra forrige år og som teller opp antall arbeidsdager som går i ferie dette år. Denne tar hensyn til helgedager og andre røde dager som uansett er fri. Jeg fant ingen god måte å automatisk få en hendelse når noe i kalenderen er endret, så da la jeg inn en trykknapp for å oppdatere antall feriedager. Men jeg skal se om jeg ikke kan sjekke på om ICS filen har blitt endret og oppdatere tallene automatisk.

Jeg bruker amsleser så jeg får sanntidsdata derifra. Historikk kan jeg hente hos Elhub og netteier. Dette har jeg også importert i Home Assistant så det er lett tilgjengelig. Så da er det fryktelig lite jeg brukte av Tibber sine tjenester som jeg betalte 39 pr mnd for og som nå øker til 49. Jeg kunne fortsatt med Tibber hvis de hadde noe som ga meg en merverdi, men det virker som om de satser på de som vil ha det aller enkleste og synes det er greit at noen andre styrer lading av bil og varme i hus. Med de nye prisene ender jeg opp med å betale 1200 i året for noe jeg ikke bruker. Så jeg skiftet til Vibb og så får vi se etter tre år.

I motsetning til deg så presenterer jeg realistiske tall. En avtaletid fra 3 til 10 år er sannsynligvis innenfor det normale for de fleste. 100 år eller 1 mnd er bare nevnt for å se vekk hva kostnaden faktisk er. Men som du skriver, en velger selv hva en betaler for. Hvis du har forståelse for at Tibber må tjene mer enn Vibb eller at Tibber driver forretningen sin med større utgifter, så er det helt greit for meg. Men du trenger ikke latterliggjøre at det koster 3600,- mer for meg å fortsette med Tibber de neste 3 år.

Det er bare måten en presenterer tall på. 28,- kroner ekstra i forhold til Tibber sin gamle pris er lite. I forhold til Vibb så koster Tibber 12000,- mer i løpet av ti år for meg. Eller 3600,- i den perioden Vibb garanterer prisen.

Så kom det epost fra Tibber om at de setter opp prisen på påslag med 50% og månedsprisen øker med 25% Jeg vurderer Vibb. Jeg mister tilgang til noe som jeg får hos Tibber, men det er ikke viktig og heller ingenting jeg ikke kan regne ut selv.

Og en smule ufine kommentarer i den github tråden. En svarer ikke folk som ønsker noe bedre at "du kan fikse det selv". Dette er hva jeg kaller en form for hersketeknikk. Det er ikke alle gitt å endre på kode og lage en PR. Dette vet Jan Iversen veldig godt og han viser tydelig at han har null interesse av å forbedre dette. Og som han skriver i siste innlegg, det er slik open source fungerer. Dessverre gjør det det. Open source gir en mulighet til å slenge ut at en "kan fikse det selv".

Bare å notere det ned bak øret i tilfellet du planlegger å fikse noe som allerede virker. Mens vi er inne på problemer. Mosquitto 2.0.16, 2.0.17 og 2.0.18 har bugs som gjør at det ikke helt spiller på lag med zigbee2mqtt hvis en har et stort zigbee nett med nærmere 200 "dingser". Hvor grensen går, er uklart. https://github.com/eclipse/mosquitto/issues/2887 Hvis en bruker mosquitto add-on i Home Assistant, så er add-on versjon 6.2.1 trygg.

Det er firmware problemer der. Zigbee2mqtt virker ikke "fint" med conbee ii hvis den er oppgradert til noen av de nyeste firmwares. Det er i utgangspunktet ikke noe problem om du bruker flere zigbee nett og wifi, bluetooth osv på samme frekvens. De støtter alle sammen feilhåndtering og sender data på nytt hvis det er kollisjon. Mulig det blir et problem hvis poden strømmer video på wifi og det er lite ledig tid på frekvensbåndet.

En kan hente ut hos Elhub, ja. Men kun for en måned om gangen. Så jeg fant ut det var lettere med en enkel eksport hos netteier istedenfor 5*12 eksporter hos Elhub.

Jeg bruker zigbee2mqtt selv og opplever den som stabil, rask og lite ressurskrevende. Men den er også lagd av datanerder for bruk av datanerder. Dette med firmware krever nedlasting av programvare fra feks Texas Instruments og for min del, et verktøy for å gjøre om på filformat for den siste firmware versjonen som kom sommeren 2023. Hvis en ikke er forberedt på å fikle, finn noe annet. Jeg _tror_ og innbiller meg at Home Assistant sin egen koordinator med Home Assistant sin programvare, ZHA, er mer strømlinjeformet.