Bjørn Mork

ikke begge deler samtidig kanskje, men en av dem er nyttig hvis du f.eks skal bruke gpio 14/15 som konsoll. Uten dette uart0 koblet til både blåtann og 14/15. Med enable_uart=1 slår du på uart1 ("miniuart" - /dev/ttyS0) og kobler den til 14/15 i stedet. Da har du både blåtann og konsoll. Jeg foretrekker også å slå på uart_2ndstage=1 for litt mer info ved boot. Og så skulle jeg til å si at dtparam=krnbt=on burde vært default for blåtann. Men når jeg ser på dokumentasjonen, så ser det ut til at den er det 🙂 Alle overlays med parametre er greit dokumentert her: https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README Resten av config.txt er dokumentert her, men dette om enable_uart er direkte misvisende mener jeg: https://www.raspberrypi.com/documentation/computers/config_txt.html#enable_uart Tok meg lang tid å innse at det faktisk enabler uart1 og kobler den til gpio 14/15. Mye forvirrende info der ute, og det hjelper jo ikke når den offisielle dokumentasjonen blander inn kommandolinja til kjernen.

Vet ikke om du har lagt merke til samme problem, men hos meg virket ikke en del av de binære sensorene i home assistant. Verdiene på Alarm active, Charging, Derated og EV Connected stod fast som "unknown". Fant ut at årsaken var at z2m lagde en binary_sensor config med "payload_off": "false", "payload_on": "true", som skulle vært "payload_off": false, "payload_on": true, Mitt forslag til fiks: https://github.com/Koenkk/zigbee-herdsman-converters/pull/8440 Virker for meg ihvertfall...

Øy, det er jo et kjempetips. Takk. Ser ut til å være ment som et tilbud til kunder. Men det er jeg jo forsåvidt hvis vi snakker om banktjenester. Og står ingenting her om hvilken type kunde de snakker om, så da må det være greit: https://www.sparebank1.no/nb/smn/privat/forsikring/husforsikring/roykvarsler.html Kjøpte 8 stk jeg

Den eneste måten jeg kan se for meg at du får til dette er hvis releet er konstant lukket. Ta fram et multimeter og sjekk. Og se over programmeringen av fibaroen.

Jeg ser den med elektriker-kostnad ved å ta ting mer gradvis. Men det blir enda dyrere å bytte ut store deler av installasjonen fordi tingene ikke falt helt i smak likevel. Og mange av spørsmålene dine grenser til smak og behag. Det kan ikke noen andre enn du bestemme. Derfor blir fort det unisone svaret her: Prøv deg frem. Men noen deler er enklere enn andre. Hvis du er fornøyd med funksjonalitet og plassering av dagens vridimmere så er det bare å bytte dem ut med tilsvarende smarte varianter. Du får samme funksjonalitet som i dag med smart styring i tillegg. Evt bytte til push-dimmer blir selvsagt en smakssak, men jeg er 100% med @christbj her: Prøv det først. Ellers er jeg usikker på om du tenker litt for komplisert med bytte ut alt. Trenger du/bruker du alle de eksisterende bryterne f.eks? Ofte er jo slikt strødd "vilkårlig" rundt og man blir gående fra vegg til vegg for enkle ting som å slå av eller på lyset i større soner. Med smart styring kan du forenkle det betraktelig, og bare ha smarte fjernkontroller der du faktisk ønsker slikt. Mange her er også på kjøret med automatisering basert på andre typer sensorer enn brytere. Litt usikker på om jeg misforstår hva du mener eller om du har mistforstått hva en Hue Wall Switch modul gjør. Men det er altså bare en zigbee fjernkontroll. Den har ingen bryter- eller dimme-funksjon. Fin til å bygge om eksisterende brytere til fjernkontroller for å beholde "look and feel". Men også litt upraktisk på flere måter siden bryterfunksjonen faller bort og du får en enhet med batteri montert nokså utilgjengelig. Ikke at det må byttes så ofte, men når du snakker om mange slike så er det en ting å tenke på. De krever forresten ikke at du bygger om til impuls-brytere. Wall Switch modulene kan også konfigureres til å sende impuls når du endrer bryterposisjonen. Da kan du av naturlige årsaker ikke bruke bryteren som push-dimmer. Og den får samme funksjon og ulempe som en trappebryter: Hva som er av og på varierer med posisjonen til de andre bryterne i systemet. Jeg synes de er veldig praktiske for utebelysning. Ihvertfall der du har en eksisterende installasjon med armaturer som tar pærer, og gjerne med en dullion brytere rundt hele huset. Vi har f.eks. 4 topolte brytere for utelys i huset og 1 i garasjen. Smarte pærer i alle lampene gir den nødvendige(?) felles styringen uten ombygging av noe som helst. Og utelys er jo uansett noe som alle(?) eller de fleste ønsker automatisert. Bonusfordelen er at du bygger god dekning på zigbee-nettet. For min del var det nok til å koble garasjen sammen med huset, til tross for at jeg var skeptisk på forhånd. Sannelig. Lot meg også lure. Jaja. Usikker på det er riktig spørsmål. Med 22 35W halogen-pærer bør du seriøst tenke over om/når hele røkla skal byttes ut med LED downlights. Har ikke sett noen smarte vridimmere som takler den type last hvis alt dette henger på 1 dimmer. Du kan antageligvis dele det opp vha f.eks dimmepucker hvis det er flere trafoer, men jeg kan ikke se at det gir mening økonomisk i et 10-års perspektiv.

Høres kjent ut. Utrolig irriterende måte å feile. I noen tilfeller kan det ta lang tid før du merker at filene aldri havnet på kortet likevel. Sluttet med å lagre bilder direkte til minnekortet fra telefonkamera etter en tilsvarende episode for noen år siden...

samma her. Kjøpte en Amina S i mai, men fikk ikke elbil før i oktober. Og siden laderen står på hytta så har det så langt bare blitt én ladeøkt. Litt begrenset erfaring, altså. Men jeg liker alt jeg har sett så langt. Amina har kommet med en del nye firmware-versjoner, der de også har lagt til og forbedret funksjonalitet. Både firmware og dokumentasjon av denne gjøres tilgjengelig på Internett. zigbee2mqtt-støtten har fungert greit fra dag 1, også mens den var under utvikling. Den er nå med i z2m fom versjon 1.41.0 så det er ikke nødvendig å bruke ekstern konverter lenger. Dette er selvsagt smak og behag, men boksen faller i smak fysisk også. Diskret og praktisk design, der du f.eks. kan bruke selve ladeboksen som opphengskrok for ladekabelen. Og fast ladekabel passer meg utmerket. Det gjør at den alltid er der og ikke stikker mer ut fra boksen i noen retning enn nødvendig. Det eneste ønsket jeg har på lista er støtte for zigbee OTA. Dvs, firmwaren deres støtter det jo. Men foreløpig distribuerer de ikke firmware i en form som er forberedt for dette så jeg aner ikke om det funker. Den dokumenterte metoden for firmware-oppdatering benytter blåtann per idag. Det virker forsåvit helt greit, men krever at du er i nærheten med en telefon og app.

"hva skal vi med all informasjonen?" toget gikk nok på 90-tallet engang. Eller kanskje før? Mulig det kan tidfestes til at "folk flest" fikk et barometer på veggen?

ser veldig rar ut herfra iaffal. Svarer konsekvent med HTTP/1.1 med en Upgrade: h2 header selv om jeg tvinger på den HTTP/2 request: bjorn@miraculix:~$ curl --http2-prior-knowledge -D - https://www.tronika.no HTTP/1.1 301 Moved Date: Mon, 25 Nov 2024 12:34:59 GMT Server: Apache/2.4.57 (Ubuntu) Cache-Control: no-cache Strict-Transport-Security: max-age=63072000; includeSubdomains; preload Upgrade: h2,h2c Connection: Upgrade Location: https://www.tronika.no/no/ Content-Length: 0 Content-Type: text/html; charset=utf-8 Og når jeg følger den redirecten så får jeg bare 404: bjorn@miraculix:~$ curl --http2-prior-knowledge -D - https://www.tronika.no/no/ HTTP/1.1 404 Not Found Date: Mon, 25 Nov 2024 12:36:32 GMT Server: Apache/2.4.57 (Ubuntu) Set-Cookie: PrestaShop-29ecf8f7503b4bd780ac4d1bb0b03dfa=def502002823f94c1c4ce34ec8f965fb41fb1e0fbdddf8ae12792cc975e3147f31f0c3450514bdc762a9ece2e8f4d4452551acc645e86b576861a07f04938ad9a51e4aa90d80b91425b1e03e937a87af766ea9ff9db7a7b433b947a9f70a4245a264495f93538b572d7c4b1f6c08c1c3ad9f3e1f49f74d7cb9f7a15fa7b0116e2afa2366e9a30f0a097d7771ff9466528ceb0bf669e5622058cc409c85044dd5242aff75ffbfbccae9a980ab0f75e801793687b20e4a0f360c7865066e84a65672395c3f5f0906736a869be6801c06a9b5a14e4537f1a8c0beef39df42a914f1bd1adf6b279acdef5eb1844414360b0c81206ee27125db7183ffc92d8f98c33a70bbbac84bc712e9fb9a5fc2af95c638; expires=Sun, 15-Dec-2024 12:36:32 GMT; Max-Age=1728000; path=/; domain=www.tronika.no; HttpOnly; SameSite=Lax Set-Cookie: PrestaShop-29ecf8f7503b4bd780ac4d1bb0b03dfa=def502002105ce04cc64a12240dd163208a920948998fc42111189d913258a9ff815deb86eafdd6f78f801e0850931681c0a5fdb50694e10ab1b36c8677c7ec9cb150a4cec6e6ff879eea7c641c601e64ea6a74c93cd355eeceb67dac4521fee85414f5c3d074a634d796e123eae7e1c9b44bd23abfb06a5b9ab7a68ff1cf2c88b10a6680cbbb6c21584a731e0161dc51394516fbd3f2cfc2ab9c539d3cc9d603a8f9d4eec9c4f66f5173af0f0929e2d46c2ec49190a3ec8bbc84ad8336329f2b6555b2e46569ab76138341233dcb366a4d035a18a1cb4882a5a8ed28054dec8e6c125850f1f365b6bccaf739fe505eb3e23812a3e2acc29ed95121b56ba3d36d16bcafcf13eb7660b0bc6e76a434b112092cc89f5b748e3b10e92e0ea5ed66cd6ac7dc913e1279baa05e74d26b687da4c36; expires=Sun, 15-Dec-2024 12:36:32 GMT; Max-Age=1728000; path=/; domain=www.tronika.no; HttpOnly; SameSite=Lax Set-Cookie: PrestaShop-6c4bd792258ec4c57a768be2afe766ba=def50200c9340412ea15bb931899f6d14719e8b981529e4defbe9ef1b0a17b82a1f2aed9a4080aa87f7bfc6db8a8e80f09a43352bbbe9e24e7c6f90c11b61f14743c29304ebe9b249eceaa1cf38065fdefcf7c86a15205d47dc2e61a321b6e2fb27d4193f78ebdbb5c80870089f3ee639c59a01cfc2472373191987339f9a3bdffe609861a959b3ccf5a6b89630c04d333336bb607285d3dcffbf28e5295abfa8faf7478eb368e69ed4efba86603102837bd038a08344cd97449013b54de3ab04bf42d086a48ac8556b26dc3969ef37b8100f0baf5143e1f7cc2931baa1b5919a9814e6b3de297e91c6e; expires=Sun, 15-Dec-2024 12:36:32 GMT; Max-Age=1728000; path=/; domain=www.tronika.no; secure; HttpOnly; SameSite=Lax Strict-Transport-Security: max-age=63072000; includeSubdomains; preload Upgrade: h2,h2c Connection: Upgrade Content-Length: 0 Content-Type: text/html; charset=utf-8 enda mer pussig er det at de tydeligvis skulle hadde en annen 404, for om jeg prøver noe som slutter på html så får jeg denne redirecten: bjorn@miraculix:~$ curl --http2-prior-knowledge -D - https://www.tronika.no/no/foo.html HTTP/1.1 302 Found Date: Mon, 25 Nov 2024 12:37:15 GMT Server: Apache/2.4.57 (Ubuntu) Set-Cookie: PrestaShop-6c4bd792258ec4c57a768be2afe766ba=def50200e0666148968f3b8cf76618ae88c2c1aeb0765ee5c9c8affdbf8bb10721d068d5f84820ee7ed007e49224f6609deccb86285a0bef12601fd504ad53c4004dc76909ed69ced0a7859753cbbb3f7cbcef6d8a239427da8f8780188c565dd67200dea52c573f9a17103ea7426f3d20b11d55be8149e612530547e5db697167ffc5c97ef5b94bd20ebf7e1b89ad994e40d7a644eafa9cad97e66bc79b6aa91267424db82aa095d04ade18408596d0311a5aaff253f6dc24d67b94813b94b375abfad16092; expires=Sun, 15-Dec-2024 12:37:15 GMT; Max-Age=1728000; path=/; domain=www.tronika.no; secure; HttpOnly; SameSite=Lax Strict-Transport-Security: max-age=63072000; includeSubdomains; preload Upgrade: h2,h2c Connection: Upgrade Location: https://www.tronika.no/no/fant-ikke-siden Content-Length: 0 Content-Type: text/html; charset=utf-8 som igjen gir en 404. Herlig. Lenger en det gidder normalt ikke jeg før jeg finner meg en annen butikk. Sorry. Enten får de klare å sette opp en fungerende web-tjeneste eller så får de kjøpe det av noen som kan slikt

Kan ikke stort om dette. Men jdolven har jo dokumentert den vanskelige biten som er protokollen. Å reimplementere det som en climate komponent i esphome synes rimelig overkommelig så lenge du har hardware å teste på. En "external" component er bare en veldig praktisk måte å teste/bruke kode som ennå ikke er merget. Du skriver koden som enhver annen komponent i esphome og kan derfor bruke det du finner der som eksempler. Foreslår at du kikker litt på andre eksisterende komponenter som implementerer climate. Burde komme unna dette med 93% klipp og lim 😉

Jeg brukte en Shelly Uni Plus til formålet tidligere i sommer. Spilte ikke så stor rolle for meg med Wifi vs Zigbee. Tanken min bak å bruke en slik modul var at den kunne få strømforsyning fra motorstyringen. Det måtte jeg til slutt gi opp. Uansett hvordan jeg plasserte dingsen så påvirket den radio-fjernkontrollene merkbart. De fungerte, men rekkevidden ble redusert. Aner ikke om det er fordi støyen følger strømkabelen, eller om jeg rett og slett trekker så mye at mottakeren lider (den drives jo av samme strømforsyning). Virker rart. Men etter noen forsøk kastet jeg kortene og gikk for separat strømforsyning. Sannsynligvis ikke spesielt relevant for din portåpner, men ville nevne det at det er en detalj å følge med på. Jeg merket ikke problemet før samboer klaget. Vi har bakke opp til garasjen hele veien fra absolutt maks rekkevidde for fjernkontrollene, så det var ikke så populært at rekkevidden gikk ned. Og jeg kan bare glemme å selge inn at fjernkontrollen kan erstattes med en browser på en touchskjerm og uendelig rekkevidde. Blir ikke det samme.

Prøvde hardt å unngå å være vanskelig, men klarer ikke la være 😉 Hvorfor? Klart du kan lage noe slikt, f.eks ved å koble en slaktet radio-fjernkontroll til en zigbee-modul. Men det synes meningsløst når port-motoren mest sannsynlig har en inngang for kablet trykknapp som gjør akkurat samme nytten. Et relé er enklere, billigere og mye mer robust mot støy, avlytting, bugs og utilsiktet sletting av minnet i motorstyringen.

Et annet alternativ er å bruke smartpærer og/eller plassere dimmepucker andre steder enn der det i dag er brytere. F.eks. hvis det er plass til slikt i en takboks eller i en lysarmatur. Da kan bryterne erstattes med fjernkontroller etter egen smak. De bygger jo ikke mer ut fra veggen enn et skjult anlegg ville gjort. Og noe av kablingen kan kanskje fjernes slik at totalen blir enda mer "skjult" Noen eksempler: https://www.elektroimportoren.no/namron-zigbee-4-i-1-vridimmer/4512726/Product.html https://www.elektroimportoren.no/philips-hue-dimmebryter/60342/Product.html https://www.elektroimportoren.no/elko-smartbryter-traadloes-plus-ph/4540054/Product.html

Komme her og gi oss dårlig samvittighet på den måten, da! Samvittighet er no dritt 🙂 Jeg gjemmer meg bak unnskyldningen at det er handelen som er problemet. Produktene kommer fra Kina uansett om jeg handler på Ali eller Kjell. Så får jeg heller prøve å kjøpe andre ting så kortreist som mulig. Biler produseres f.eks i denne verdensdelen fremdeles, selv om batteriene sikkert kommer fra Kina uansett. Men det viktigste er selvsagt å kjøpe mindre nytt. Loppemarked-sesong, er det ikke? Dessverre ikke stedet for batterikjøp...

Jeg er i grunnen enig i alt du sier. Har også de samme gode erfaringene når det gjelder penger tilbake ved feil eller mangler. Mange selgere både på ebay og ali expess vil heller refundere enn å diskutere. Selv i tilfeller der de har retten på sin side. Jeg har opplevd å få tilsendt ny vare når jeg har etterlyst en sending, bare for å sitte der med dobbelt opp noen uker senere når det viste seg at pakken bare satt fast et eller annet sted. Og skulle du treffe en vanskelig selger så har jo markedsplassene systemer som sikrer deg likevel. Økonomisk er det altså nokså risikofritt. Men jeg står ved påstanden om at det meste er fake. For mange produkter spiller det ingen rolle. Ekte Tuya? Vet ikke om det gir mening. Samme med alle andre duppeditter der funksjon betyr mer enn merke. Men det er ikke stedet du kjøper en Rolex. Og batterier og minnekort er i særklasse når det gjelder forfalskninger ved at mange selger produkter med dårligere kapasitet enn lovet. Dette er drit-frustrerende. Det er ikke helt det samme å få pengene tilbake hvis det du ville ha faktisk var et batteri med god kapasitet. Men hvis du tar det med i beregningen så er det greit nok. Jeg har også kjøpt batterier der, fordi det var billig uansett og dessuten enkelt selv for de særeste ting. Av og til er det jo også gøy å se hvilke ressurser disse leverandørene kan sette inn på forfalskninger. Jeg kjøpte en batch med FTDI FT232R baserte USB-moduler for en tid siden. Eller det var det de utga seg for. De så helt riktige ut og de virket helt fint. Bare med et par pussigheter: Alle hadde samme serienummer. Og selv om de tilsynelatende lot seg programmere til noe annet enn bare UART-funksjonen, så hadde ikke programmeringen noen effekt. Googling av serienummeret ga f.eks https://www.sevarg.net/2017/03/04/fixing-fake-ftdi-ft232rl-adapters-ssop/ og en drøss andre linker om denne kopien. Noen har altså tatt bryet med å skrive mikrokontrollerkode som emulerer en FT232R godt nok til at det fungerer for de fleste praktiske formål. Og så produsert moduler med slike mikrokontrollere i stedet for ekte FTDI chiper. Som så selges for under en dollar stykket inkludert frakt. Go figure. Greit nok så lenge du bare trenger en slik modul for bruk som UART med "normale" hastigheter. Men ekstremt frustrerende hvis du faktisk trenger ekte vare av en eller annen grunn. Dersom det fremdeles finnes på disse markedsplassene så er det så blandet med alle forfalskningene at det er umulig å skille dem ut. Har også fått lignende trøbbel med enkle PoE-splittere. Har en helt grei noname gigabit 802.3af PoE-splitter jeg kjøpte på ebay for mange år siden. Så jeg innbilte meg at jeg kunne kjøpe et par til av samme type. Studerte annonser lenge og vel før jeg bestemte meg for en som ikke etterlot noen tvil om hverken gigabit eller standard PoE. Stor var skuffelsen når jeg mottok to splittere med kun 2 par synlig koblet i RJ45-pluggen. Helt åpenbart ikke det annonsen beskrev. Men muligens det som var avbildet. For ved nærmere studier av bildene så la jeg merke til at de nøye unngikk å avsløre akkurat denne detaljen. Og på alle andre måter var de helt like den splitteren jeg hadde fra før. Fikk tilbake pengene uten noen diskusjon. Men det hjelper jo ikke stort på problemet. Selv med slke gjennomførte kinaprodukter er det tilsyntelatende umulig å sortere de "ekte" fra de falske. Jeg aner ikke hvordan jeg skal få tak i en splitter av den typen jeg vil ha, selv om jeg vet at den finnes der ute. Selv om omtale og omsetning er gode indikasjoner for en del produktkategorier så hjelper det etter min erfaring lite mot denne typen forfalskninger. Det er billige produkter med høyt volum. Og så lenge alle som klager får pengene tilbake, så er det jo ingen misfornøyde kjøpere igjen til å gi negative kommentarer. Selgerne har derfor typisk grei score fra et enormt antall handler.

Nesten alt på ali express er fake. Batterier forfalskes lett ved å bytte label. Minnekort og ssder får kanskje ny firmware i tillegg slik at den også forteller samme kapasitet. Det er bare å gi opp. Det er sikkert en ærlig selger der et eller annet sted, men du finner ham ikke

eller kanskje https://www.shelly.com/en/products/shop/shelly-plus-0-10-v-dimmer ?

Noen kuldegrader er ikke noe problem på utstyr som er i drift. Det er kondens som er den største trusselen og det unngår du som oftest pga varmeutviklingen fra utstyret. Tviler på at du får en rpi med strøm kald nok til at det blir et problem Det er feks drøssevis av fwa "antenner" installert utendørs i Norge. Det er helt normalt med kuldegrader inne i modemet på dem når det er kaldt nok, selv om de står på og er i bruk

Rart at dette skulle være så vanskelig å google seg fram til. Det ser ut til å være "ESP Touch" protokollen fra espressif. Med manual på https://www.espressif.com.cn/sites/default/files/documentation/esp-touch_user_guide_en.pdf og eksempel-kode på https://github.com/EspressifApp Så da burde det være overkommelig å sette samme hele greia fra factory reset til lokal MQTT broker. Forutsetter riktignok et system for å redirigere https://agent.devicedrive.com/api/agent til en lokal webserver. Men det funker nok både med DNS og forskjelige varianter av IP redirect. Ikkeno DNSSEC i veien her heller.

Fant meg https://github.com/nikitastupin/mitmproxy-mqtt-script og dette synes ganske så rett fram ut: info: Loading script /usr/local/src/git/mitmproxy-mqtt-script/mqtt_message.py info: Proxy server listening at *:9192 info: 192.168.15.136:21645: client connect info: 192.168.15.136:21645: server connect 13.74.108.192:8883 info: [CONNECT] Client Id: <mac> Will Topic: None Will Message: None User Name: BehaIotHubProd.azure-devices.net/<mac> Password: <innholdet fra auth_token_receive ovenfor> info: [SUBSCRIBE] sent topic filters: 'devices/<mac>/messages/devicebound/#' info: [PUBLISH] '<json blob med device data ala den jeg postet ovenfor>' to topic 'devices/<mac>/messages/events/DeviceDrive%2DHeader=%7B%22mac%22 <osv med hele "DeviceDriver-Header fra første HTTPS POST url-kodet>' Deretter kommer det en del kommandoer til topic 'devices/<mac>/messages/devicebound/%24.mid=<en eller annen uuid>&%24.to=%2Fdevices%2F<mac>%2Fmessages%2Fdevicebound'. Som f.eks info: [PUBLISH] '{"com.beha.heater": {"enable_notify": ["300"]}}' info: [PUBLISH] '{"com.devicedrive.heater": {"target_temperature": "22.0"}}' info: [PUBLISH] '{"com.beha.heater": {"heater_mode": "0"}}' info: [PUBLISH] '{"com.beha.heater": {"heater_mode": "3"}}' Selvsagt med stadige rapporter tilbake fra ovnen.

Vet ikke hvorfor jeg ikke har lagt merke til det før, men ser at en av panelovene på hytta er en Beha "PV6 Wi-Fi". Før jeg kaster bort mer tid på å prøve å finne ut av hvilket språk den snakker: Er det noen som kjenner til at dette er gjort før? Jeg gjorde noen eksperimenter med Behas app, mitmproxy og litt snooping, og det ser overkommelig ut å få denne til å styres lokalt. Mangler detaljer om hvordan appen konfigurerer WiFi. Den bruker åpenbart multicast på en særdeles kreativ måte med pakker til en drøss multicast-adresser. Innholdet er mystisk nok stort sett et antall "1". Det ser nesten ut som om de koder data inn som varierende antall/pakkestørrelse. Elns. Må forskes mer på. Men når oven først har passordet så klarer den seg ganske bra. Kjører DHCP og NTP og poster deretter en json-blob og en DeviceDrive-Header med litt personlige til https://agent.devicedrive.com/api/agent Glad og fornøyd selv om det sitter en proxy der, slik at sertifikater ikke kan valideres i noen retning.... Men det den får tilbake er det som er mest interessant. Body er bare "{"response":"OK"}" så den er ikke nyttig. Men i headerne finner vi auth_token_receive: SharedAccessSignature sr=BehaIotHubProd.azure-devices.net%2Fdevices%2F<mac>&sig=<sig>%3D&se=<sn> auth_token_send: SharedAccessSignature sr=BehaIotHubProd.azure-devices.net%2Fdevices%2F<mac>&sig=<sig>%3D&se=<sn> url_format_receive: https://BehaIotHubProd.azure-devices.net/devices/<mac>/messages/devicebound/%s?api-version=2021-04-12 url_format_send: https://BehaIotHubProd.azure-devices.net/devices/<mac>/messages/devicebound/%s?api-version=2021-04-12 med <mac> som 12 lc hex siffer uten skilletegn, og sn som 10 desimale siffer Nå står det https der. Men det kom aldri noen GET eller POST i den retningen. Skjønte ikke bæret før jeg la merke til at det gikk pakker i retning av tcp port 8883 på BehaIotHubProd.azure-devices.net Så det der konfigurerer rett og slett ovnen til å bruke MQTT over TLS. Og enda bedre: Fremdeles uten å validere sertifkater! Så da er det bare å fyre opp sin egen broker og leke i veg. mitmproxy, som jeg har brukt så langt, er ikke så velegnet til å dekode MQTT. Men jeg ser ihvertfall at det utveksles JSON blober med svært så lesbart innhold. Slik som { "com.beha.heater": { "sw_rev": "1.2", "child_lock": 0, "heater_mode": 2, "alarm_flags": 0, "current_triac_temperature": 60.7, "current_ext_temperature": 0, "current_NTCtemperature": 33.1, "current_model": 25.2, "target_temperature": 30, "current_nrf_temperature": 36.5, "current_TriacDutyCycle": 39, "max_triac_diff": 35.4, "max_triac_delta": 6.07 }, "com.devicedrive.heater": { "target_temperature": 30, "current_temperature": 25.2, "week_program_name": "", "week_program_id": "", "last_programmed": 1726494495 } } Trenger bare å finne en fornuftig måte å samle inn topics og meldings-eksempler Men så var det spørsmålet i starten da. Dette er jo 5(?) år gammel hardware. Noen må vel ha gjort tilsvarende før?

Jøss. Den var ekkel. Litt overraskende at driveren ikke feiler på en sjekksum eller annen sanity sjekk, for det der er jo helt åpenbar galskap. Nå får du kanskje ikke sendestyrken helt opp i 255 dBm uansett 🙂 Men jeg ser ikke bort fra at den forsøker å sende med høyere effekt enn den burde både av regulatoriske og tekniske årsaker. Ser ikke noen annen forklaring enn at driveren leser 0xff fra flash-området som brukes som "eeprom" for denne radioen, og at den ukritisk bruker disse dataene. Du finner de datatene driveren bruker her: root@OpenWrt:/# ls -la /sys/kernel/debug/ieee80211/phy*/mt76/eeprom -r-------- 1 root root 0 Sep 6 06:52 /sys/kernel/debug/ieee80211/phy0/mt76/eeprom -r-------- 1 root root 0 Sep 6 06:52 /sys/kernel/debug/ieee80211/phy1/mt76/eeprom -r-------- 1 root root 0 Sep 6 06:53 /sys/kernel/debug/ieee80211/phy2/mt76/eeprom 6 GHz er phy1. Driveren får dataene fra "Factory" mtd-partisjonen. Dette er /dev/mtd2 i OpenWrt. Jeg lurer på om det som tok knekken på ubi-partisjonen din også har tatt "Factory"? Da er det jo i så fall nesten rart at du fremdeles har en fungerende bootloader. Lurer virkelig på hva som kan ha skjedd. Men i første omgang så kan du jo sjekke hvordan ting ser ut. "eeprom" for mt7916 (phy0 og phy1) er 0x1000 bytes fra 0xa0000 og utover. De skal starte med 0x16 0x79 (altså 0x7916 som LE). Du kan jo f.eks bare se på innholdet med noe ala dd if=/dev/mtd2ro bs=$((0x100)) skip=$((0xa00)) count=$((0x10)) | hexdump -C Dette bør jo normalt være nøyaktig det samme som du finner i /sys/kernel/debug/ieee80211/phy0/mt76/eeprom og /sys/kernel/debug/ieee80211/phy1/mt76/eeprom, men gudene vet hva som skjer her. Best å sjekke.

Skjønner ikke hvordan dette kan ha skjedd, men du mangler tydeligvis ganske mye av innholdet i ubi partisjonen. Ikke bra hvis sysupgrade gjorde det der. Men frykt ei, det kan reddes helt fint. tftpboot er nok det enkleste. Men som du har oppdaget så har de lagt inn en irriterende bug i boot-loaderen: Den insisterer på å lese starten av "rootfs" volumet fra flash selv når du booter fra RAM. For å fikse dette så må du derfor først lage et "rootfs" volum i bootloaderen. Det trenger ikke inneholde noe data, men jeg tror det var slik at det må ha en korrekt squasfs magic. Selv om det er overkill i størrelse så er det enkleste bare å ta et filsystem fra en sysupgrade fil. Det spiller egentlig ikke noen rolle hvilken, men f.eks wget https://downloads.openwrt.org/snapshots/targets/mediatek/filogic/openwrt-mediatek-filogic-zyxel_ex5700-telenor-squashfs-sysupgrade.bin tar xvf openwrt-mediatek-filogic-zyxel_ex5700-telenor-squashfs-sysupgrade.bin mv sysupgrade-zyxel_ex5700-telenor/root /hvor/du/nå/har/tftpfilene Du legger altså en "root" fil med et squashfs image samme sted som "C0A80101.img". Denne filen laster du deretter opp med tftp og skriver til et nytt "rootfs" volum før du booter fra "C0A80101.img". tftpboot $loadaddr root ubi create rootfs $filesize ubi write $loadaddr rootfs $filesize Etter dette skal ram boot virke. Kjør samme som du gjorde tidligere. Med sysupgrade for å fikse opp resten etter at systemet har bootet. I teorien. Ettersom jeg ikke aner hva som kan ha skjedd så må vi vel ta noen forbehold om at det kan være flere uventede ting her.... Mulig du har lyst til å kjøre "ubi info l" når du først er i bootloaderen, før du gjør noe som helst. Kan være greit å vite hva som er der. Om det er noe i det hele tatt. Normalt er det en rekke volum. F.eks kernel, rootfs, kernel-rescue, rootfs-rescue, user, perm, ext, RIP. Du kan alltids installere og boote OpenWrt uten noe av dette, men hvis du skal tilbake til Telenor så må du ha RIP. Der ligger bla nøkkel og sertifikat for din ruter. Dersom det volumet er gone, og du ikke har en backup, så er du nok låst til OpenWrt for alltid. Kanskje ikke så galt 🙂 EDIT: Bare sånn for å være helt sikker på at det ikke er noe graverende galt så testet jeg nettopp sysupgrade -v https://downloads.openwrt.org/snapshots/targets/mediatek/filogic/openwrt-mediatek-filogic-zyxel_ex5700-telenor-squashfs-sysupgrade.bin og det gikk helt fint hos meg. Like blank mht hva som har skjedd hos deg, men det er ihvertfall ikke et generelt problem.

billge, robuste og kompakte kontakter. Hvem kan motstå slikt? Bare vent til noen oppdager at en vanlig usb-c kontakt helt fint kan brukes tll 240V AC. Gjerne flere faser også. Den neste elbil-laderen din kan bli mye billigere og veldig kompakt da

Rart. Antar denne kan settes opp med forskjellige søkemetoder og at du da har prøvd alle? Kan den bli forvirret av at du bytter guide-kabel? Nei, det er klart. Men jeg er nå fremdeles skeptisk til mindre kjente utfordrere. For meg ser det ut til at Husqvarna har lagt ganske mye omtanke i nettopp ting som framkommelighet, både i hardware og software. Interessant erfaring at den blir dårligere over tid. Hva kan det skyldes? Slark? Læring? Eller nye software-bugs?