Bjørn Mork

ekomloven gjelder definitivt også privatpersoner. "virksomhet" er nok her å forstå som "aktiviteter". Det er bare å lese videre i § 1-2. Absolutt ikke fritt fram for privatpersoner å bruke alt mulig av radiofrekvenser f.eks, og dette er loven som begrenser det Men som storeulv påpeker så gjelder kapittel 2 bare tilbydere, definert i § 1-5 som Det kan altså også væe en fysisk person. Men normalt tilbyr ikke folk slike tjenester til andre fra sine hjemmenettverk

Litt i gråsonen mellom fullverdig hub og nettverks- eller usb-tilkoblet zigbee/zwave/thread-adapter: https://smlight.tech/global/smhub Jeg ble oppmerksom på den gjennom en diskusjon om Openwrt-støtte (på ingen måte der ennå). Der er det mye nyttig info om hardwaren: https://forum.openwrt.org/t/smlight-smhub-openwrt-support/240533 Vet ikke om dette kommer til å utvikle seg til en hub etterhvert som de får firmware årntli på plass. Potensialet er der. Men for mange av oss er det kanskje tilstrekkelig med alle radioer, z2m og mosquitto i en pakke? Har bare god erfaring med https://smartlight.me/en . Kjøpte en enkel zigbee-pinne basert på en TI CC2652P med CH340 USB UART derfra i hine hårde, før krigen i Ukraina, og har brukt den som coordinator på hytta siden. Litt håndlaget utførelse den gangen, men solid og pålitelig.

Dette er vel bare enda et eksempel på at man ikke trenger å være redd for at leverandøren legger ned så lenge man holder seg til utstyr med standardisert lokalt grensesnitt. Jeg kan ikke si at jeg bekymrer meg mye for mine 10 røykvarslere og ene dimmepuck fra Elko. De har jo aldri vært koblet til noe annet enn z2m og HA uansett. Men wifi-utstyr uten et veldokumentert lokalt API er risky. Det gjelder uansett leverandør. Og at apper og skytjeneste-duppeditter som "huber" er dødt den dagen leverandøren gir seg burde ikke sjokkere noen

For å gjenopplive denne tråden med flere erfaringer av den litt mer positive varianten... I tillegg til de ubrukelige zigbee-sensorene så kjøpte jeg også en blåtann-basert plantesensor. Ofte solgt som "Xiaomi MiFlora" eller "Flower Care" eller tilsvarende. Aner ikke om alle variantene er de samme eller bare kopier. Men den varianten jeg har ser ihvertfall identisk ut som denne: https://www.ebay.com/itm/384169473179 med bla merkingen HHCCJCY01HHCC på den synlige delen av kretskortet som går ned i bakken. Den medfølgende manualen angr "HHCC" som merke. Den ble kjøpt på eBay i april 2022, fra en selger som ikke lenger har noen aktive annonser, så jeg har ikke en direkte kjøpsanbefaling å komme med. Den dukker opp som "HHCCJCY01 by Xiaomi" i "Xiaomi BLE" integrasjonen i Home Assistant Basert på bilder antar jeg at dette er eksakt samme produkt: https://www.multicom.no/xiaomi-smart-plantesensor-med-bluetooth/cat-p/c/p1500010292 Denne har jeg nå hatt stående utendørs i et blomsterbed på hytta et par somre. Jeg tar den inn om vinteren. Hytta ligger slik til at den gjerne dusjes med litt sjøvann når værforholdene tilsier det, og det aktuelle bedet er på ingen måte skjermet mot hverken sjøvann eller horisontalt plaskregn. Men det er fremdeles ingen spor av vanninntrengning i sensoren. Sammenlignet med sensorene nevnt lenger oppe i tråden så er denne sensoren helt vanntett (dvs sprutsikker - jeg tviler på at den tåler neddykking), mindre og mer diskret selv om målepinnene er omtrentlig like lange, veldig mye enklere å åpne for å bytte batteri (eller for å ta det ut for vinteren), utstyrt med illuminans-måling i tillegg til temperatur og konduktivitet (fuktighet) Jeg var opprinnelig skeptisk til at den bare har et CR2032 batteri. Men det varer og varer så det er et ikke-problem. Har faktisk brukt samme batteri i to somre på rad. Var også skeptisk til BLE. Men sensoren støttes som nevnt av Xiaomi BLE integrasjonen i Home Assistant og fungerer stabilit og fint med en esp32c3-basert BLE proxy plassert innendørs noen meter unna ytterveggen (murvegg i kjeller). Så dette har også vist seg å være et ikke-problem. Alt i alt er jeg strålende fornøyd med sensoren etter 3 års bruk. Men jeg har ikke kjøpt flere slike ennå... Selve målingen av jordfuktighet er kanskje noe mindre nyttig enn jeg hadde sett for meg. Den fungerer fint, men forsinkelsen fra regnvær til fuktig blomsterbed blir litt for stor til at det gir noen mening å regulere vanningen etter det. Når det har regnet i lang tid så vil sensoren avsløre det. Men den vil ikke hindre at du vanner i regnvær hvis det var tørt dagen før. Da er faktisk illuminans-målingen nyttigere siden den forteller når det er direkte sol i bedet. Tror en regnsensor ville være en bedre match for intelligent vanning. Denne erfaringen har jeg vel egentlig gjort tidligere også med en gammeldags Gardena-sensor tilkoblet en tidlig variant av deres vanningscomputere (altså ikke min automatisering). Det virker såder, rett og slett fordi det tar tid for vann å trenge ned i jorden fra det har falt på overflaten. Og enda verre: Det hjelper ikke at det kom en byge i går som gjør at sensoren tror det er nok fuktighet i jorden. Du trenger fremdeles å tilføre mer vann jevnlig for at det ikke skal tørke ut, og hvis det ikke regner i dag så må det vannes. EDIT: La til et bilde av begge sensortyper med åpen batteriluke slik at størrelsen kan sammenlignes. Begge batteriluker har tilsynlatende tetning, men den digre zigbee-sensoren har andre åpninger som slipper inn vann både i topp og bunn uten at det dreneres ut igjen

Føler dette er en smule overdrevent. De dør, men det gjør minnepinner, SSDer og harddisker også. Hvor lang tid det tar kan virke nokså vilkårlig. Greia med minnekort er at det er lurt å dimensjonere for et solid overskudd av ledig plass. Det øker både ytelse og levetid. Hvis du konsekvent fyller opp kortet så dør det fortere. Gjelder forsåvidt også de andre flash-baserte mediene. Men minnekort er gjerne dårligere utrustet med skjulte reserver og kontrollere som automatisk administrerer disse reservene for deg.

veldig interessant. Greit å vite at de også reagerer på brann 🙂 Jeg har til sammen 10 batteridrevne hjemme og på hytta. Har lagt merke til at batterimålingen på alle sammen følger den samme jevne kurven, helt uavhengig av at de på hytta f.eks har stått store deler av vinteren i bare noen få plussgrader. Faktisk er kurven så jevn på alle sammen at jeg mistenker at den er basert på tid i stedet for kapasitetsmåling. Alle 10 mister ett prosentpoeng batteri hver 44. dag! Som pussig nok gir en batterilevetid på 12 år. Men sensorene er selvsagt bare garantert for 10 uansett så det spiller ingen rolle. Eller så er batteriberegningen basert på en minimumskapasitet på 17% for å drive alarmen i lang nok tid. Det er kanskje ikke urimelig

Jeg tror det er lenge siden folk flest ga opp å forstå strømregningen. Det er heller ikke en øvelse som gir særlig mening. Blir som å tolke matvareprisene. Prøv gjerne å handle billig ved å se på hyllekantene, men ikke studer kassalappen for nøye. Det er bare frustrerende

I det siste har det jo vært helt umulig å gjøre noen fornuftig styring heromkring. I dag "varierte" spotprisen mellom 0,73 og 1,07. I morgen er den enda mer stabil mellom 0,86 og 1,05. Lite å spare på optimalisering av forbruket da. "Vent to dager med dusjen og se om prisen går ned". Tror ikke den går hjem... Hvis bilen kan vente til helgen med påfyll så er det nok noe å hente. Men det er lenge siden femtiøringen var realistisk i snitt. Ihvertfall i den delen av året da forbruket er stort nok til at det faktisk betyr noe

Jeg har bare de batteridrevne, men synes jo ikke det høres så urimelig ut at disse kjører sånn omtrentlig samme firmware. I motsetning til det meste annet av kablet zigbee så er ikke zigbee-nett noen primær funksjon her. Og de har et backupbatteri som de også må ta hensyn til. Finleste dokumentasjonen til ELKO men der står det selvsagt ingenting som tyder på hverken det ene eller andre.

Hva står det på FiberTwist-boksen som du prøver å erstatte? Forstår det slik at Altibox også har noe XGS-PON. Da er det like greit å bare droppe prosjektet og bruke boksen deres i bridge mode. En annen mulighet er at du har ødelagt SFP eller fiberplugg hvis det er slik at du tidligere har tvunget den grønne pluggen inn i den SFPen du har? Det er to tynne glassbiter som er slipt med forskjellig vinkel. De bør ikke presses mot hverandre.

Burde vel være mulig å finne ut av vha https://github.com/DigitalSecurity/btlejuice eller andre tilsvarende løsninger, forutsatt at du har de to dingsene som snakker med hverandre

Klart. Men så spørs det om du skal det da. Selv har jeg veldig sansen for PoE med et utall forskjellige enheter. Alt av APer både hjemme og på hytta, noen 8-ports switcher, RPi4, noen eksperiment-rutere, to NR7101 og en eth01-evo. Ingenting av dette trekker noensinne over 10W, selv om enkelte av enhetene nok er spesifisert som 802.1at. esp32-modulen trekker bare 0,7W etter at jeg fant ut hvordan jeg enabler EEE på den 🙂 Ser muligheten for at dette er en "640 kB er nok" uttalelse, men jeg har problemer med å forstå hva jeg skal bruke 100W PoE til. Joda, kanskje praktisk i et switch-hierarki. Men så var det kraftverket som skal levere 100W på 8-16 porter da.... Jeg liker ikke vifter heller. Da spiser jeg heller i meg en ekstra 230V power-kladd her og der.

Den krever plugger og kontakter som er tilpasset tykkelsen. Jeg har lirket til noen helt standard elko cat6 uttak, men det er ikke noe jeg vil anbefale. Avstanden mellom kontakt-knivene er altfor stor. Du får både plugger og keystone-moduler som er laget for denne kabelen. De er en drøm å jobbe med. Andre plugger kan du bare glemme. Jeg trodde i starten at jeg kunne fikle det til. Men det er helt håpløst. Ellers skal det visst ikke være anbefalt å bruke slik kabel til lange PoE strekk. Selv bruker jeg den til 1 gig med PoE på inntil 25 meter. Har ikke noen høyere hastigheter i bruk, men har så vidt testet 50 meter med 10gig og det funket iaffal i en begrenset test. Som forventet selvsagt, siden spec tilsier at de skal klare cat6a

For et par år siden dro jeg 5 cat6a sammen med en preterminert (SC plugg) single mode simpleks fiber i et 20mm rør, med lengste strekk mellom boksene på ca 13 meter. Det går ikke med vanlig kabel, men null stress med denne eller tilsvarende: https://www.direktronik.no/direktronik/nettverk/kabling/kabel---nettverk/installationskabel-cat.6a-utp-slim-100m/?variationCode=20103384 Ytterdiameteren på kabelen har alt å si. Normalt blir de bare tykkere og tykkere med høyere båndbredde. Typiske verdier her: https://www.fs.com/glossary/cable-outer-diameter-74.html Men det finnes altså unntak. En vanlig cat6a er gjerne 7mm og da tror jeg du sliter big time med 3 stykker i et 20mm rør.

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.

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

Kan jo tenkes at kortet jobber på 5V ettersom denne dingsen har USB-porter, og at det er en liten 3,3V regulator mellom Vcc og ESPen?

Interessant. Slo meg aldri. Det var kanskje grunnen til at jeg ikke lykkes å flashe med Vcc fra TTL-adapteret. Jeg jukset til slutt med å plugge i AC i stedet, men det er jo en småskummel løsning.

Er dette helt korrekt? Fra tidligere diskusjoner og https://github.com/thomasloven/hass-plejd virker det som om Plejd krever sky for nøkkelhåndtering. Selv om du klarer deg uten etter førstegangs oppsett så hjelper jo ikke det hvis du må/vil resette en enhet. Hvorden setter du opp plejd-nettet den dagen skytjenesten ikke lenger eksisterer? Eller har jeg misforstått noe? Som vanlig så er det klin umulig å lese ut av dokumentasjonen om dingsene faktisk kan konfigureres uten app. Det er bare "bruk app" overalt

Vi er enige i det aller meste. Poenget mitt er at det gjelder alle som selger hardware basert på skytjenester. Men lovverk og forbrukermyndigheter har ikke helt kommet seg utpå banen ennå. Derfor er det fremdeles tillatt å selge ting som er helt avhengig av tjenester som krever vesentlig større omsetning i tingens levetid enn hver enkelt forbruker har tenkt å betale. Risikoen er helt uforutsigbar og overføres til forbruker allerede ved kjøpstidspunktet. Vi kan selvsagt kalle det kynisk å utnytte dette, men alternativet er å overlate markedet til konkurrentene. Det er bare myndighetskrav som kan gjøre noe med problemet. Blir litt som å selge avhengighetskapende stoffer som nikotin, tippekuponger eller alkohol. Rimelig kynisk, men det hjelper ingenting om din lokale nærbutikk nekter.

Det er ingenting som prinsipelt skiller FutureHome's forretningspraksis fra alle andre som selger sky-avhengig hardware. Det er helt irrelevant om abonnementskostnaden var 0, 10, 100 eller 1000 kroner måneden den dagen det viser seg at det er for lite til å opprettholde skytjenesten. Det er komplett urealistisk å tro at noen klarer å selge slike tjenester til høy nok pris til å garantere evig drift. Derfor vil du som kunde på et eller annet tidspunkt oppleve at prisen øker drastisk og/eller at tjenesten faller bort. Alternativet er helt åpenbart. Ikke kjøp hardware som er avhengig av skytjenster. Skal FutureHome kritiseres så er det mer interessant å se på markedsføringen av de komponenter som evt viser seg å ikke fungere uten sky. Dersom de var annonsert som åpne, eller på en måte som må forstås som åpne ("zigbee" f.eks), så er jo markedsføringen misvisende. Men det er uansett nokså poengløst å angripe det etter at konkursen er et faktum... Se heller på hva de andre som ennå ikke er konkurs holder på med.

Og mer enn et år senere så har jeg litt mer erfaring med håndtering av PR i esphome. DM9051-støtten ble endelig merget i dag. Uten at det var mer enn noe småpirk som ble endret i løpet av dette året. Review av de delene av esphome som ikke har dedikerte "code owners" er sirupstregt. Det går måneder mellom hver gang noen ser på en PR. Dette skyldes selvsagt bare det utbredte problemet at det er for få folk til å gjøre jobben. Men for en med min tålmodighet er prosessen såpass frustrerende at det spørs om jeg prøver flere ganger. Nå er jeg spent på hvordan prosessen hos espressif funker i forhold. Oppdaget underveis at DM9051 faktisk støtter "Energy Efficient Ethernet". Men driveren i esp-idf implementerer det ikke. Testet som kjappest og fant ut at dette faktisk sparer ca 200 mW på en dongle som bare fungerer som BLE proxy. Total-forbruket med PoE-modul, esp32c3 og DM9051 (på 100 Mbit/s) ligger på ca 700 mW med EEE og 900 mW uten. I følge PoE-switchen min, så tallene er neppe helt presise. Men uansett en ganske vesentlig forskjell spør du meg. Derfor prøver jeg å lure dette inn som default i esp-idf: https://github.com/espressif/esp-idf/pull/16138 Så får vi se hvordan det går. Fant ingen andre drivere med EEE der. Vet heller ikke om det er noen andre moduler som har muligheten. Så det er dårlig med eksempler på hvordan de ønsker slike features implementert.

Her var det litt mer IO-kjøtt, inkludert den magiske "transfer" AES-nøkkelen som trengs for å pare en fjernkontroll: https://github.com/Velocet/iown-homecontrol/ Ikke helt fiks ferdige greier, men det er nå håp

Kjipt. IO har jo utgangspunktet en stor fordel ved toveis kommunikasjon, men det hjelper jo ikke stort hvis det bare virker gjennom en sky. Hvemfaen trenger skyer når de har solskjerming? Har ikke lest dette ennå, men det ser da halvveis lovende ut: https://deralchemist.wordpress.com/2021/05/10/reverse-engineering-remote-controlled-somfy-blinds-part-1/ Ellers er jeg ytterst imponert over hvor bra ESPSomfy-RTS funker når jeg først har fått mappet sensorer og fjernkontroller riktig i forhold til hva motorene er programmert med. Eliminerer langt på veg behovet for toveis kommunikasjon. Var litt forvirret i starten fordi det var så veldig mange sensorer som rapporterte data hele tiden. Slik er det når alle naboene har samme system. Kanskje like greit at jeg gikk for den lille antennen 🙂

Takk for tipset om ESPSomfy-RTS. Har også somlet meg til å kjøpe et par C1101 moduler, med den litt kjipere 4cm antennen. Brukte en ESP32-C3 "Super Mini" modul. Funket finfint. Har nok dårligere signal enn nødvendig med den lille antennen, men fremdeles mer enn godt nok.