All aktivitet

Tja, hvilke fordeler ville det gitt meg? Jeg har ikke satt meg inn i matter. Min plan er å lage noe som fungerer og kommer med lav kostnad. Prøve å unngå alle lisenser og lage mest mulig selv, inkludert hardware.

Hei, det jeg spør er om Heatit har en Edge driver for Smartthings. Det er ikke nok å har en zwave hub i min erfaring, må også har en driver. Smart things er ganske lett å bruker i den tilfelle men uten driver det vil ikke funker.

Dersom huben støtter Z-Wave standarden skal det vel fungere?

Hvorfor ikke lage Matter devices når du først er i gang med slikt?

Har tenkt at NEO6 GPSen har vært litt dårlig siden den hopper og spretter rundtom ganske mye når klipperen står i ro men har de siste ukene jobbet en del med GPS i forskjellige telefoner og ser at de hopper og spretter like mye så da er for så vidt NEO6 GPSen friskmeldt. Bil-GPSer jukser jo en del ved å tvinge posisjonen inn på nærmeste vei og da ser de jo ut til å være veldig nøyaktige men jeg må nok finne på et eller annet lurere... Når jeg tar et kjapt søk på nett så finner jeg at GPS normalt skal ha en nøyaktighet på 3-5 meter men jeg opplever jo at når klipperen står i ladestasjonen så beveger den seg jo vanligvis 10-15 meter men også unntaksvis opptil over 30 meter unna ladestasjonen... Så vidt jeg minnes fra et par ti-år tilbake så var det sagt at nøyaktigheten skulle være 2-5 meter i 95% av tiden og i de siste 5% var det ganske uspesifisert... I praksis ser jeg at der er enkelte dager der den er SVÆRT nøyaktig (1-2 meter) men for det meste virrer den rundt opptil 10-15 meter fra ladestasjonen. Når jeg ser tilbake på de første sporingene i tråden her så fikk jeg langt hyppigere og mer nøyaktige posisjoner da så har jeg nok rotet til et eller annet i programmet mitt... Men det får være greit nok inntil videre. Nå har jeg OTA update av programmet så endringer implementeres raskt og slik det er nå gjør det jobben greit nok. Kommer til å prioritere å få gang på en annen "ny" klipper: Ambrogio L85 DeLuxe. Denne trenger et par nye MOSFETs til knivmotoren og de er ikke dukket opp i posten enda...

Jeg har fått det til tider. Homely sier det er yale låsen som ikke har kontakt med homely sentralen. Så at yale hadde kontakt via sirene som sitter rett ved døra og som tydeligvis ikke har så god dekning til basen. Men nå har det fikset seg selv uten at jeg har flyttet noe utstyr. Må ha vært noe annet utstyr (jeg har en rekke wifi baser og annet zigbee nett)

Har hatt en RPI gående med HomeAssistant utelukkende for å ha kontroll på Yale låsene slik at jeg styrer de fra Node-RED via MQTT. For noen dager siden sluttet låsene å respondere og webgrensesnittet i HA var dødt... PIen responderer på ping og Observer på port 4357 har en masse info men som ikke fortalte meg noe stort. Søk på nett gir meg info om at MANGE opplever det samme men jeg klarte ikke å finne noen løsninger som funket for meg og det virket som om der var veldig mange forskjellige løsninger der en løsning funket for en, en annen funket for en annen osv... Lette etter alternative løsninger og fant at HUE Bridge hadde Yale integrasjon men etter en del mer forskning viste det seg at den KUN kunne aktivere HUE lys når en lås ble aktivisert fra Yale systemet så det var jo totalt ubrukelig siden jeg må kunne styre låsene fra andre steder enn Yale. Endte opp med å gå i gang med en NUC fra rotekassen og installere ProxMox 9 og installere haos16.0. Installasjonen av hele greiene tok ikke mange minutt og jeg fant tak i en fersk HA backup på SD kortet men jeg hadde rotet bort krypteringsnøkkelen... Lastet inn automations.yaml fra SD kortet, installerte Yale og MQTT så var det bare en beskjeden redigering i 27 automasjoner siden alle låsene fikk ny id. Backup og restore av hele HA maskinen til Synology NAS er jo en lek i ProxMox (men nå har jeg lagret krypteringsnøkkelen på en mer logisk plass så den trengs vel ikke lengre)... Edit: Fant krypteringsnøkkelen da jeg lette etter noe helt annet men nå trenger jeg den jo ikke lengre...

Gyrosensor på katteluke viser om katten sist gikk inn eller ut. Det finnes katteluker som kobles til nettet og som viser om katten er ute eller inne, vi har en slik på hytta. Veldig kjekt å kunne sette den til å kunne slippe katten inn hvis vi er ute en tur og skal reise hjem om litt, slik at katten ikke er ute når vi skal reise. Men hjemme har vi en eldre katteluke som fungerer godt ift oppgaven med kun å slippe inn vår katt. Derfor har jeg tenkt litt på hvordan denne kan utstyres med sensor for å vise inne/ute status. Nylig leste jeg at ESPHome støtter gyrosensorer og fant både billige utgaver som rene kort og mer robust innpakkede enheter fra M5stack. For katteluken valgte jeg enheten fra M5Stack, da den er svært liten og trolig mer robust til denne typen bruk. Koblet til en M5Stack ATOM Lite blir hele installasjonen svært kompakt og lett å montere med et par biter dobbeltsidig tape. En USB-C vinkel var også fin å ha for å få strømledningen fornuftig plassert. Oppsettet i ESPHome er lagt ved. For å finne adressen oppgitt (her 0x86) fjernes kommentarmerket # fra linjen "scan: True" etter i2c. Jeg testet litt hvilke verdier jeg fikk ved å dytte på luken manuelt. Det ble nødvendig å bruke filter for ikke å jamme ned Home Assistant, det blir mye data med hyppige avlesninger for å kunne registrere bevegelsen på en slik luke godt nok. De reelle verdiene fikk jeg først når katten gitt ut og inn gjennom luken. Utfordringen er at luken svinger tilbake når katten har gått gjennom. Det løste jeg ved å lage en hjelper (type toggle) som settes aktiv i 5 sekunder når luken svinger ut og så bruke denne hjelperen som vilkår i automasjonene som igjen oppdaterer status på katten (enda en hjelper av typen toggle). Det er sikkert mulig å slå disse sammen disse to automasjonene ved hjelp av trigger ID, det sjekker jeg senere. For de som måtte ha lyst til å kopiere dette er det trolig enklere å forstå de to adskilte automasjonene. Det jeg nå kan gjøre, hvis familien ønsker det, er å lage en velkomstmelding som spilles av når vi kommer hjem som også forteller når katten sist gikk ut eller inn gjennom katteluken. For de som lurer på type katteluke er dette to luker. En enkel med børster som gir en viss vindtetting inne, det er den som er koblet til tunnelen gjennom veggen. På utsiden av den sitter en PetSafe med RFID leser som kun slipper inn vår katt. Den er montert i en egen ramme som er skrudd på utsiden av veggen. Hele poenget er å få en form for luftsluse som gir mindre trekk og dermed mindre varmetap enn med kun en luke. Katteluke ESPHome.txt Katteluke inn.txt Katteluke ut.txt

Det du trenger er egentlig en GLC-BX-U-C . I den andre enden står det høyst sannsynlig en GLC-2BX-D-C med Tx1490nm/Rx1310nm. Bare pass på at du har en Bidi sfp (1 fiber) med Tx1310/Rx1490 eller Rx1550. Begge bølgelendene er innenfor toleranse her. Disse to sfp modulene er et par og opererer med 1310nm og 1490nm, men den du vil finne i Altibox hjemmesentralen din (VMG) mottar egentlig på "feil" bølgelengde, men altså innenfor toleranse. Kan bekrefte at den du har i hjemmesentralen allerede vil fungere med UDM Pro i alle fall.

De nye sensorene skle rett inn i appen som "egne" sider, nå begynner ting å bli klart til å skalere opp til ett helt hus med egne rom som egne sider osv 🙂 Dog er det skralt med micro usb kabler i hus så jeg kan bare drifte en om gangen 🤣

Jobbet med software for å gjøre den klar til forskjellige "sider"/rom i går, så da ble det fokus på mer hardware i dag. Så blir det å prøve å få det inn som forskjellige rom i morgen 🙂 Går litt på frem! Hadde en del deler liggende men estimerer at disse sensorene nå koster < 100 kroner da har jeg: -Bevegelse -Lys -Temp -Fuktighet

Jeg har 6 TRM3 thermostater som styrer en zwater for vannbåren varme. Den har gått via en futurehome hub, men nå vurdere en alternativ. Er det mulig å bruker en Aeotec/Samsung hub (der var en driver men ikke sikker om det er fortsatt supported)?

Er det mulig å finne ut hvilken Zigbeekanal Homely bruker ?

Update: Om noen andre gjør samme feil, så klarte jeg å fikse det med å gå inn i .storage/core.entity_registry filen og fjerne alle devices med de gamle identitetene. Jeg gjorde også et søk på samme katalog og fjernet andre treff med device-ID eller Homely i strengen. Husk å restarte både homeassistant og homely-mqtt etter at endringen er gjort.

Hva er alternativet? Husk at HA er laget for små Raspberry Pi enheter, Home Assistant Green, Home Assistant Yellow osv. De lager sin egen maskinvare, hvorfor skal de ikke da bruke ressurser på et OS?

Selvsagt er det slik. Dette er ikke unikt for HA. Det er heller ikke et nytt problem. Løsningen deres - å lage et OS ut av applikasjonen - er arrogant og historieløs. Problemet ble beskrevet av jwz for en hel evighet siden, i det som er kjent som "Zawinski's Law of Software Envelopment". Merk at den ble laget lenge før virtualisering var tilgjengelig for folk flest. Eller noen, egentlig.

Bare for å lage litt balanse, her er Home Assistant sin begrunnelse: The Core and Supervised installation methods are not only complex for users to install and maintain — they’re also challenging for the Home Assistant team to support. In the past, there were compelling reasons, outside Home Assistant development, to run these installation methods, but for most people those reasons are disappearing. Home Assistant OS is very capable with a rich ecosystem of add-ons, while also being easy to run in a virtual machine. Container adoption has become mainstream, now being widely available along with systems having more resources to run them. Steadily, we’ve seen year-on-year reductions in the percentage of Core and Supervised installations (currently standing at 2.5% and 3.3% respectively). As Core and Supervised are more complex to maintain, they generate more issues that are more difficult to solve. This complexity places a disproportionate burden on our community-driven support system, where volunteers generously give their time to help others. It also takes time away from assisting the vast majority of users who are on the simpler to maintain installation methods. Along with this, new users could sometimes be swayed into running Core or Supervised, and have a bad experience that could cause them to give up on the best way to automate their home. By focusing our support and documentation on OS and Container methods, we can greatly improve the onboarding experience and ensure a smoother start for new users. Slik jeg leser det er det ikke utvikling som er krevende, men support for installasjon av disse to.

Har kjørt HA i python virtual environment (aka "Core") på et par Debian-maskiner i noen år. Det er jo sånn passelig nivå av virtualisering for en enkel python-applikasjon. Men nå har de vise menn tydeligvis bestemt seg for å gjøre sin egen hverdag litt enklere på bekostning av brukerne. Og siden jeg ser for meg at jeg vil ha behov for å oppgradere HA også etter 2025.12 så utforsker jeg alternativene. Og jeg blir ikke imponert. Konteiner my ass. De har altså valgt å inkludere en full Alpine-installasjon. For å få kjørt en jævla python-applikasjon på Debian så må jeg ha en koipi av Alpine? Det er bare.... dumt. Og oppgraderinger? Da laster du ganske enkelt ned en ny kopi av Alpine. Må jeg virkelig reinstallere et OS for hver eneste applikasjons-oppgradering? Fordi noen late og inkompetente utviklere ikke vet hvordan de lager programvare som kan kjøres i slightly forskjellige miljøer? Hva er det egentlig som gjøre det umulig å kjøre HA under Debian? Nada. Kan jeg fikle det ti? Selvsagt. Men jeg er jo ikke spesielt interessert i å gjøre det for hver eneste oppgradering framover. Jeg vil bare kjøre denne applikasjonen med minst mulig hassle. Jaja, etter å ha prøvd meg på dette dusteriet noen uker i den misforståtte troen på at konteiner er litt mindre overkill, så innser jeg jo at det nok er ve-em som er svaret. Også komplett idioti når målet er å kjøre en applikasjon på et OS som allerede har absolutt alt applikasjonen har behov for, men det vil ihvertfall gjøre oppgraderingene litt mer hensiktsmessige. Og det er jo på ingen måte mindre overkill slik dette er designet. Jeg er nok bare gammel grinebiter, men dette ser IKKE ut som noe framskritt for meg. Har begynt å frykte for hvor HA er på veg. Hvis det er OS de skal lage så er jeg ikke interessert. Det har jeg allerede

Hei. Jeg frisker opp denne tråden. Burde kanskje laget en ny. jeg ser etter en videoringeklokke som kan integreres i Home Assistant på en grei måte. Men synes det er overraskende vanskelig å finne. Det er fordeler/ulemper med alle jeg har sett. I utgangspunktet ønsker jeg ikke en ny hub. Har hatt intnrykk av at Reolink sin videoringeklokke er anbefalt, men fant en utfordring med den også. Ser etter ringeklokke i prisklassen 1500 kr. Disse har jeg sett på: Reolink Doorbell battery - Trodde denne kunne integreres i Home Assistant, men batteriproduktene kan ikke integreres i Home Assistant. Da må man ha en hub, noe jeg ikke ønsker ettersom jeg ikke vil låse meg til en produsent (selv om de sikkert er bra). Jeg har ikke behov for flere overvåkningskameraer og huben koster jo en del i tillegg. Tapo 235D - Denne ser ut til å kunne integreres, men de kan vel "dra ut pluggen" når de vil med en software-oppdatering. Minuset her er at et trykk på ringeklokken ikke blir registrert i Home Assistant. Man kan lage workarounds, men det er irriterende. Enten via Tasker, eller at man har et Tapo-lys som skrur seg på når noen trykker på ringeklokka. De er automatiskert i Tapo-appen. Da kan man lage en automasjon basert på at Tapo-lyset skrur seg på. Eufy E340 + homebase mini - Denne er også veldig kronglete å legge inn i Home Assistant, men akkurat nå virker denne mest fristende ettersom den ikke har behov for hub. Hjemmesnekrede software-løsninger er man jo vant til i Home Assistant, men man er avhengig av at utvikler fortsetter å støtte integrasjonen. Er det andre som kan virke bedre, eller må jeg bare velge en av disse? Amcrest selges kanskje ikke i Norge? Så også ut som Unifi sin også krever en hub?

Min Homely Gateway sluttet å fungere for litt siden, og jeg valgte da å få tak i en ny med batteri-backup etc. Det tok litt tid å få alle sensorer resatt og inkludert i ny Gateway, men fikk det til etter litt plunder (NB: husk å slå av dine andre zigbee GW, de stjeler devices før du vet ordet av det). I forbindelse med å få sensorer inn i Homeassistant, så tenkte jeg det var lurt å bare fjerne de gamle sensorene med gamle navn, men det var kanskje en dårlig ide? De nye (resatte) sensorene dukker iallefall ikke opp, såvidt jeg kan se i MQTT Explorer så sendes data. Er det noen som har noen triks for å få dette gjort, er det noen DB jeg må slette eller finnes det en kommando jeg kan kjøre? Sekundært (eller, det er kanskje løsningen), finnes det mulighet for å få homely-mqtt docker løsningen til å rapportere navnet til sensoren istedet for den lange IDen (GUID?) den sender idag?

Jeg vil dele litt informasjon om å gjøre den gamle Fermax ADS/VDS porttelefon smart. Den enkleste måten er å legge til Fermax Wi-Box enhet og kunne overvåke og kommunisere med besøkende fra mobiltelefonen din. Hvis man patch firmware på Wi-Box, vil det være mulig å integrere den med Home Assistant eller andre systemer via MQTT eller bare REST-forespørsel (som jeg gjorde). Å legge til et USB-komposittvideoopptak med ansiktsgjenkjenningsskript på f.eks. Raspberry Pi vil tillate å åpne dører for gjenkjente personer og annonsere dem via TTS (tekst til tale) på høyttalere (f.eks. Google Home Mini). Det finnes litt informasjon på GitHub https://github.com/kuzmin-no/Fermax_Wi-Box_to_ADS Jeg hadde hatt en slik løsning som fungerte en stund inntil porttelefonsystemet ble erstattet av en annen leverandør. Hvis noen er interessert i å automatisere sin egen Fermax-intercom, kan du søke etter "Fermax Wi-Box" på finn.no

Hvilken integrasjon bruker du?

Hmm jeg testet akkurat med å endre på panelet mitt og det blir oppdatert etter noen sekunder i Homey 🤔

Er det andre som bruker Yale med Homely ? I den siste tiden får jeg meldinger fra låsen, 'Dialling failed, alarm might still be activated' Rebooter jeg låsen, går det bra, men bare for en dag. Så begynner det igjen. Batteriene er ok, meldingen er uansett inkorrekt, alarmen blir slått av. Merkelig nok begynte det etter den siste Homely-oppdateringen.

Går ikke så fort i svingene her, venter fortsatt på å flytte inn i huset så regner med det blir litt mer action når jeg kommer meg inn 🙂 Men enn så lenge har jeg lagt til bevegelsessensor til esp32 sensoren min samt byttet fra DHT11 til 22 for bedre oppløsning: Edit: Ser jeg har lagt til en shelly switch også, trodde den var med i sist innlegg 😛