Bjørn Mork

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.

Ja, absolutt. Men så var det den vanlige misforståtte "forenklingen" i å beholde det man har fra før.... Ville nok vært mye enklere å bytte alt sammen til LED-paneler med zigbee-driver. Hadde jeg bare ikke vært så fordømt sta.