aleks

Altså det er ikke noe problem å kjøre HA via docker eller direkte i OS på en mac mini. Skal du ha HASSIO (altså den versjonen som har addons) er det enklere å bruke linux rett og slett fordi det finnes script som gjør dette for deg. På en mac tror jeg ikke du har ting som apparmor etc. Vil du bare ha home assistant, den vanlig python-versjonen tar dette 5 minutter. Installert python, klon home assistant fra github, lag et venv, active venv, kjør setup og start med hass og du er klar. Tenkte å lage en guide på de forskjellige metodene, men hvis du ser på home assistant og sjekket home assistant in venv så står det veldig klart hvordan du går frem Enkleste måte: https://www.home-assistant.io/docs/installation/virtualenv/

Det betyr nok Home Control forsvinner, men for de som vil ha et system tror jeg de har en gylden sjanse til å få deg noe bra utstyr billig

Problemet med SD-kort er de ikke tåler så ekstremt mye I/O. Det første som er viktig hvis du går for RPI-løsningen er et kvalitetsminnekort som er laget for mye IO. Helst ikke sandisk, men minnekort som er laget for f.eks overvåkning, dashcams etc. Koster mer, men vil trolig lønne seg i lengden. Det andre du kan gjøre er å sette opp ting som mysql, influx etc på synologyen og avlaste RPI så mye du kan av logger og historie. La RPI ta seg av kjøring av Home Assistant, men alt av logger kan skje på en annen server. Har du en Mac Mini hadde jeg heller brukt den. Hva med å installere linux på den?

Etter tilbakemeldinger erstatter jeg original tekst med noe enklere, og vil gjøre fremtidige leksjoner noe enklere og litt mindre tekst. Det første som er viktig å understrekene Home Assistant er ikke pr definisjon et produksjonssystem, så oppdateringer er ikke nødvendigvis bakoverkompatibelt. Derfor er det svært viktig å være bevisst på å både lese endringer og ta backup før du prøver en ny oppdatering. Disse begrepene er sett fra Home Assistant-perspekiv. HA = Home Assitant = Selveste navnet på programvaren -> Dette vil på folkemunne bli kalt for "Home Automation". HASS = Home Assistant programvaren = Selveste programvaren som installeres på noen platform på noen måte, men gjort manuelt med python f.eks i venv. Denne støtter ikke "addons". HASSIO = Home Assistant programvaren som er prebygget i docker = Selveste programvaren som installeres automatisk i docker med deres script. Du kan ikke installere denne i docker selv (vel du kan, men den krever andre bindinger, så ikke installer docker og installer hassio), men for enhelthetens skyld sier vi at en ikke kan. Denne støtter addonds ADDONS: Ren programvaren som kjører i en seperat docker container i samme docker-nettverk som Home Assistant. HASSIO inneholder noen få optimaliserte addons. Derfor er det TO grunnmodeller som brukes til Home Assistant, HASS og HASSIO. Når noen refererer til HASSIO refereres det til docker-versjonen som er prebygget, og inneholder addons, samt "hassio"-menyvalg i sidemenyen. HASS kan installeres hvor som helst, inkludert docker. At HASS er installert i docker betyr IKKE det er hassos. Utenom dette finnes det flere grunnsystemer som hassbian, hassos etc, men dette er ikke selvestse programvaren, men laget ovet.

Ser ut som elektroimportøren selger ut Home Control-serien til ekstremt tilbud. For meg SER det ut som dette er POPP-røykvarslere til en gedigen rabatt: Kanskje noen burde bruke sjansen. Worst case hvis de er låst til Home Control så har en jo returrett. Ser resten selges med en ektremt høy rabatt så hvis noen vil ha rebrandet ting tror jeg dagen i dag er rette tid til å kjøpe https://www.elektroimportoren.no/home-control-smart-roeykvarsler-hcsmokedetect/4512619/Product.html?Event=brandlist

Ja, problemet med Home Assistant, noe som utviklerne ikke skjønner er alle begrepene. HA er ikke HASS, HASSIO er ikke HASS eller HA. HASSOS har ingenting med HASS, HASSIO og HASS å gjøre. HASSIO = docker, men HASS = python / venv, selv om de teknisk sett gjør det samme. En addon er ikke utvidelse av koden, men en dockeraddon, så HASSIO gir ikke noe funksjonalitet utenom HASS For de som måtte lure for å forklare det så enkelt jeg klarer HA = Home Asssitant = Selveste navnet på programvaren HASS = Home Assistant programvaren = Selveste programvaren som installeres på noen platform på noen måte, men gjort manuelt med python f.eks i venv. Denne støtter ikke "addons" HASSIO = Home Assistant programvaren som er prebygget i docker = Selveste programvaren som installeres automatisk i docker med deres script. Du kan ikke installere denne i docker selv (vel du kan, men den krever andre bindinger, så ikke installer docker og installer hassio), men for enhelthetens skyld sier vi at en ikke kan. Denne støtter addonds ADDONS: Ren programvaren som kjører i en seperat docker container i samme docker-nettverk som Home Assistant. HASSIO inneholder noen få optimaliserte addons. Hva skal en velge: Mitt forslag er å gå for HASSIO, rett og slett for enhelthetens skyld. Det er samme base, ser ut som å være hovedfokuset og addons er veldig automatisert. En har en watchdog som passer på Home Assistant kjører og alt blir mer stabilt. Den støtter snapshots og automatiske oppdateringer. Det negative med HASSIO er siden det kjøres i docker så er det begrenset tilgang til koden med mindre en har docker-kunnskaper. Å kjøre HASS på den andre siden krever ikke så ekstremt mye mer jobb, utenom en må sette opp alle addonds selv. Det positive er en har tilgang til kode og setter ting opp selv. For min case for et HA-system synes jeg det er unødvendig å vedlikeholde to lag med programvare. For enhelthetens skyld kjører jeg i dag dette oppsettet: Intel NUC som hovedenhet (enhver PC burde holde). Jeg holder meg borte fra Rasbpberry PI pga større risiko for korrupte SD-kort og problemene dette fører med. På PC-en installerer jeg alltid Proxmox (gratis VM). Det ligger et script på github som kan kjøre som installerer automatisk HASSOS med HASSIO i en container. På den måten kan en 1. Alltid ha full tilgang til hovedOS 2. Alltid ha consoletilgang til Home Assistant 3. Kunne kjøre snapshots av selveste containeren i før f.eks oppgraderinger, evt regelmessig. 4. Kunne kjøre en testklone av Home Assistant før oppgraderinger (skru av HA, klone, boote, oppgradere og sjekke alt er ok) 5. Evt kunne ha en utviklingsklone en kan leke seg med uten å ende opp med en live versjon som irriterer vettet av kone/mann/partner/barn/whatever

VVB styrt av sensibo? Tenker du på pulse?

Velkommen til klubben; 1: Resett ved å holde pil ned og den i midten inne i ca 30 sekunder til det står RES i displayet, og vent på den blir ferdig 2. Skru av sikringen til termostaten og ta deg en tur, la den stå av i noen timer. Kondensatorene må tømmes skikkelig 3. Skru den på igjen og prøv å ekskludere og inkludere den igjen og det KAN fungere

Hvis du ikke har gjort noen endringer manuelt i Zwave config tidligere og du har siste home assistant kan du stoppe ha, så slette Zwave xml filene i config root også restarte. Da vil den bygge Zwave på nytt, men vil ikke miste noe med mindre du tidligere har gjort noe manuelt i xml filen

Sjekk først i Zwave konfigen. Står den som tf56 (navnet på noden) har du korrekt config. Det er mulig assosiasjonene ikke er satt. dessverre vil ikke thermofloor/Heatit snakke med meg mer vedr problemet så vet ikke andre løsninger enn assosiasjoner og oppdatere config (hvis den er detektert som tf33)

@Moskus her er eposten som fikk de til å avslutte saken

Ja, det er jo iofs tanken med hva jeg mente. Tenkte ikke spessiellt på HS, men ser mange bruker wait og delay på ting, som skaper automasjonsproblematikk. Kanskje mer informativt for nybegynnere enn dere mer erfarne hehe.

Usikker på hvor mange har tenkt på dette (kan godt være jeg er unntaket som gjør det slik), men tidligere når jeg har laget automasjoner har jeg tenkt type Når begevelse er detektert, skru på lys, vent 30 sekunder og skru av lys. Dette er en klassisk måte å bygge opp automasjoner på, men hva skjer hvis noe skjer i de 30 sekundene? Jeg vil anbefale folk å tenke motsatt med 1. Skru på lys NÅR deteksjon skjer 2. Skru av lys NÅR statusen har vært på i 30 minutter (med mindre xxxx) Ja, den første metoden er enklere og mer logisk, men også mer åpen for feil. Metode nummer to anser jeg som mer stabil selv om det lager mer enn en automasjon. Mitt råd er derfor å fjern alt som heter wait og delay, og heller reager på en satt status.

Enda, kan du ikke bare skru den av og sette egen automasjon på låsing etter noe lengre tid? Ser ingen grunn til du MÅ bruke autolåsingen uansett grunn. Autolåsing fikser du jo med en automasjon. For min del foretrekker jeg reverserte automasjoner (isteden for hvis du åpner døren, vent 2 minutter, så lås), men isteden for sjekk (etter x minutter etter du åpnet låsen, lås den). På den måten minimerer du sjansen for en automasjon feiler da den bare bryr seg om hvor lenge siden noe skjedde

Siste av avsluttende svar fra dem:

Ja, men kjøpte mine på finn, så blir komplisert. Hadde jeg sittet med faktura etc hadde jeg hatt noe med håndfast. Ønsker egentlig de bare fikser firmwaren enn å reklamere da det ikke er mange alternativer ute

Jeg bruker HA til å låse opp når jeg går inn i en sone, sjekker om mobilen kommer nærmere og låser når jeg har kommet inn. Slipper å styre med kode etc de første 5 minuttene fra jeg parkerer bilen

Ja. Burde gå fint å skru av verisure autolock og lage et event i homey som låser døren. Døren skal være eksponert fra verisureplugin (mener jeg huske det var plugin for homey også?)

Ja, meld fra! Det er en del av oss som ikke kan returnere og er ute av garanti. Men det er jo åpenbart noe feil på produktet deres. Siden løsningen for zwave er 90% av gangene skru av sikringen, vent til full utladning av termostaten så er det nok en eller annen cache som har gått løpsk, kanskje den tar livet av seg selv av overrapportering og fyller opp minnet?

Flott du rapporterer, flere må gjøre det. De nekter å innrømme noe er feil, så du får nok svar de aldri har hørt om problemet før, så push dem. Dette må fikses, men regner med de har hatt en stor utgift med de måtte skifte de gamle termostatene de ikke har kapital til å gjøre noe. Regner med firmaet ikke eksisterer om noen mnd.

Det er dette som irriterer meg; I andre land kan en ha eksterne temperaturmålere, men i norge ser det ikke ut til å være tilfelle. Jeg vil tro Kumo og Melcloud er akkuratt det samme - de bruker jo eksakt samme wifi-moduler. Men i USA har de faktisk utviklet klienten (selv om den er elendig) til å ha mulighet for IFFFT / Alexa, endre delta og bruke ekstern temperturmåler. Å målte temperaturen ved VP er jo aldri en god ide. Det er ikke umulig det er noe som kommer gjennom hullet her også, den må jeg nesten sjekke. Men ser ut som mange har "problemer" med disse VP og det skulle jo være "top of the line", så hvorfor det ikke går ann å få noe bedre er for meg forbløffende rart

Oppfordrer i hvert fall alle med problemer å sende dem epost igjen, fordi de sier de aldri har hørt om problemene før. Typisk svar fra slike leverandører, men får de nok press så kan det være det innrømmer det. Den 2fx-versjonen burde jo ha vært bugtestet nok til at barnesykdommene fra v2 forsvant, men det virker som de absolutt ikke bryr seg om integrasjonen. Med mindre de har avtale med en leverandørhub hvor de er 100% custom støttet, og resten er under klassifikasjonen usupportert DIY

Interessant. Følg godt med på hva han gjør slik jeg kan replikere det hvis han finner ut noe feil. Hvis det er servicemeny finn ut hvordan han gjør det

Er det flere som er i kontakt med dem? Altså; dette var svaret jeg fikk som et endelig svar. Det ser ut som de mener det ikke finnes problemer med zwave på termostatene; selv om det fungerer for mange er det jo påvist det er problemer som enten ligger i protokoll, software eller hardware. Det er et fryktelig arrogant svar synes jeg

Prøv også å sette sticken i en PC og last opp den offisielle progravaren til silicon labs "zwave pc-controller" og oppdater nodene der. Jeg har opplevd HA og andre ikke drar opp all informasjon om assosiasjoner etc. Særlig på heatit dro den inn nye informasjon som ikke ble hentet. Dog fikk jeg endelig svar fra heatit i dag: "vi er zwave pluss serifisert" og thats it