All aktivitet

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)...

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 😛

Testet fort her og dette ser ut til å fungere utmerket med et AHU-700BH anlegg og! 😊 Det eneste jeg ser er at det ser ikke ut til at den viser oppdatert viftehastighet når jeg endrer det fra et annet sted.

Driver å tester selv her: https://homey.app/en-no/app/com.rein.ensy/Ensy-Ventilation/test/ Grunnleggende ting som å sette viftehastighet, away mode etc.. funker men synes selv at UI er litt clunky enda, så det kan fortsatt komme noe breaking endringer (må slette og legge til device på nytt) Har kun testet med InoVent AHU-200 KH, men antar det vil funke med de fleste InoVent anlegg siden hovedlogikken er skamløst stjelt fra HA integrasjonen over 😅

@servercookie Har du noe oppdatert info om status på HA-integrasjon? Jeg har to ovner og har lagt dem til både som cloud og local i integrasjonen https://www.home-assistant.io/integrations/mill/ . Jeg bruker cloud for å få kWh inn i HA, ellers kunne local vært godt nok. Men det hadde vært fint med en offisiell integrasjon som dere har testet selv. Slik oppsettet mitt er nå så blir jeg tvunget til å logge inn på nytt i Mill-appen hver dag. Dersom jeg deaktiverer integrasjonen så blir jeg ikke logget ut av Mill-appen.

@servercookie Har du noe info om når dere vil støtte strømmåling (watt) i Matter firmware? Vil dere også gjøre det mulig å sette effektbegrensning?

Stiller gjerne som betatester for en Homey app!

Kjøpte vår leilighet i November i fjor som hadde ventilasjon fra Ensy, har googlet siden den gang og følgt med på denne tråden av og til, men slo meg ikke før nå at det Bitzner kontrollpanelet som jeg styrte alt med hadde WIFI innebygget. Bitzner opplegget funket ikke særlig og Ensy gadd jeg ikke prøve en gang etter å ha sett bilder i denne tråden, men takket være @AlexB sin HA integrasjon så er jeg godt i gang med å portere denne over til å funke i Homey. Funker rimelig greit til nå! Skal se på å få releaset den offentlig og en gang. Hadde gitt opp håpet så takk for denne livbøyen!