Bjørn Mork

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?

Kjenner ikke til hvordan Eidsiva gjør ting, men hvis den "eidsiva konverteren" er en mediakonverter med 1000baseT ut så er det vel så enkelt som å koble den direkte til wan-porten på ruteren din, og konfigurere wan-interfacet med vlan 102 tagging. Altibox bruker vlan 102 for internett, 101 for multicast IP-TV og 100 for CPE managet (pluss kanskje telefon?). Skal du bare ha Internett så trenger du bare vlan 102.

Hvorfor det? Det synes jo på papiret som en langt bedre klipper enn alternativet du vurderer.

veldig interessant! Er vel egentlig litt sjokkerende at de ikke i det minste har lagt sky-koblingene over TLS. Forventer både kryptering og toveis autentisering av slikt som dette og det hadde vært banalt å få til med både xmpp og http vha TLS yalehomesystem.co.uk er heller ikke beskyttet av DNSSEC. Så det er altså null beskyttelse mot MITM her. Håper alle med en slik dings stoler på ISPen sin.

6e funker, men er ganske krøkkete å konfigurere. Jeg har lett etter en oppskrift uten å finne en. Du må sette country til NO. Og du må bruke WPA3 på 6GHz radioen. I tillegg må SSIDen også være definert på minst en av de andre radioene. Mest sannsynlig med WPA3 der også, for blanding går neppe bra. Tror også det er et begrenset utvalg av kanaler som kan brukes med større kanalbredder, men her har jeg store hull i kunnskapene.

23.05.4 mangler fiksen for kræsj ved disconnect fra 5GHz. Vet ikke om det forklarer alle problemene dine, men det gjør den ihvertfall ubrukelig. Enn så lenge så er det snapshot eller egen-kompilert som gjelder. Med de ulempene det medfører dessverre.

For de av oss som kjører HA på en Debian vert, og ønsker minst mulig hassle, så er dette rimelig gode nyheter: https://wiki.debian.org/Python/HomeAssistant Blir selvsagt nødt til å akseptere vesentlig tregere oppdateringer. Med en ny Debian stable ca annethvert år så ligger applikasjoner typisk ett til tre år bak bleeding edge. Men for min del så er det egentlig bare fint. Jeg oppdaterer HA forholdsvis ofte nå fordi jeg er redd for hva som brekker ved neste oppgradering hvis jeg faller for langt bak. Men jeg trenger absolutt ikke den spenningen i hverdagen.

Gir lite mening. Verdiene er uavhengige av hverandre. Hvis du vil komprimere visningen så er kanskje ekstremverdier mer interessante enn snitt?

Jeg sendte avgårde en fix, og Felix har allerede commitet den til OpenWrt-kopien av mt76 og dratt den inn i OpenWrt master: https://github.com/openwrt/mt76/commit/3b47d9df427c4833605a172f2a8f0e0012b04c80 https://github.com/openwrt/openwrt/commit/7f44f8d8d63d73807c4765386208b36acea01881 Så da blir dette i orden etter hvert. Regner med at han vil ta den med i 23.05 også, men vet ikke om han rekker det før 23.05.4. Som vel var planlagt denne uken, tror jeg

er fremdeles der i master ja. Gjelder "bare" 5GHz tror jeg. Får ikke sjekket 6GHz, men 2 GHz er ihvertfall ikke noe problem. Siden feilen tilsynelatende ikke gjelder veldig mange andre bokser så lurer jeg litt på om det er relatert til et eller annet som manlger ifm definisjonen av ex5700. Vi har jo også den mystiske 6dBm effekten på 5GHz kanalene, som jeg aldri helt har kommet til bunns i. Skyldes helt sikkert en eller annen mangelfull eller feil initialisering, og da er det lett å msitenke at det også kan trigge andre bugs. ex5700 er fremdeles veldig unik hardware, med en PCIe-tilkoblet DBDC radio som server 2 og 6 GHz mens 5GHz er servet av MT7986 SoCen. Det gjør dessverre at det er dårlig med andre eksempler å kopiere. Jeg har bare fiklet det til på et vis. OK, jeg la inn en dev_warn() og en if (!phy) return i mt76_wcid_cleanup, slik: void mt76_wcid_cleanup(struct mt76_dev *dev, struct mt76_wcid *wcid) { struct mt76_phy *phy = dev->phys[wcid->phy_idx]; struct ieee80211_hw *hw; struct sk_buff_head list; struct sk_buff *skb; dev_warn(dev->dev, "phy=%p, offsetof(tx_lock)=%zu, offsetof(pktid)=%zu\n", phy, offsetof(struct mt76_phy, tx_lock), offsetof(struct mt76_wcid, pktid)); mt76_tx_status_lock(dev, &list); mt76_tx_status_skb_get(dev, wcid, -1, &list); mt76_tx_status_unlock(dev, &list); idr_destroy(&wcid->pktid); if (!phy) return; spin_lock_bh(&phy->tx_lock); Grunnen var at jeg mistenkte at problemet var relatert til derefereringen av &phy->tx_lock, som var nytt i https://github.com/openwrt/mt76/commit/f1e1e67d97d1e9a8bb01b59ab20c45ebc985a958 Og det er bekreftet. Når jeg kobler fra 2GHz ser det slik ut: [ 62.116403] mt7915e 0000:01:00.0: phy=000000004f4a303d, offsetof(tx_lock)=36, offsetof(pktid)=360 mens på 5GHz ser det slik ut: [ 89.220004] mt798x-wmac 18000000.wifi: phy=0000000000000000, offsetof(tx_lock)=36, offsetof(pktid)=360 Så phy er ganske riktig NULL. Og offset til tx_lock er 36. Eller altså 0x24. Derav Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Eneste problemet nå er at jeg ikke aner hvorfor phy er NULL i dette tilfellet. Jeg unngår forsåvidt kræsj med den ekstra testen, men det er vel å feie problemet under teppet

sannelig. Prøvde nå med v23.05.3 på ex5700 og ser det samme. Kræsjer med (her med funsjonsnavn i stack trace - gjør det litt enklere å grave rundt i mt76): root@OpenWrt:/# [ 203.065843] Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 [ 203.074880] Mem abort info: [ 203.077667] ESR = 0x0000000096000005 [ 203.081399] EC = 0x25: DABT (current EL), IL = 32 bits [ 203.086696] SET = 0, FnV = 0 [ 203.089734] EA = 0, S1PTW = 0 [ 203.092858] FSC = 0x05: level 1 translation fault [ 203.097721] Data abort info: [ 203.100585] ISV = 0, ISS = 0x00000005 [ 203.104402] CM = 0, WnR = 0 [ 203.107358] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [ 203.113777] [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 203.122459] Internal error: Oops: 0000000096000005 [#1] SMP [ 203.128011] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_counter nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7915e mt76_connac_lib mt76 mac80211 cfg80211 slhc nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mdio_netlink libcrc32c compat crypto_safexcel sha1_generic seqiv md5 des_generic libdes authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd gpio_button_hotplug usbcore usb_common aquantia crc_ccitt [ 203.194677] CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 [ 203.200838] Hardware name: ZyXEL EX5700 (Telenor) (DT) [ 203.205956] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 203.212897] pc : mt76_wcid_cleanup+0x84/0x22c [mt76] [ 203.217856] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] [ 203.222806] sp : ffffffc00a803700 [ 203.226104] x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 [ 203.233220] x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 [ 203.240335] x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 [ 203.247450] x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 [ 203.254565] x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 [ 203.261679] x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 [ 203.268794] x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 [ 203.275909] x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 [ 203.283025] x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 [ 203.290140] x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 [ 203.297255] Call trace: [ 203.299686] mt76_wcid_cleanup+0x84/0x22c [mt76] [ 203.304290] __mt76_sta_remove+0x70/0xbc [mt76] [ 203.308806] mt76_sta_state+0x8c/0x1a4 [mt76] [ 203.313148] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] [ 203.319313] drv_sta_state+0x144/0x274 [mac80211] [ 203.324028] sta_info_move_state+0x1cc/0x2a4 [mac80211] [ 203.329249] sta_set_sinfo+0xaf8/0xc24 [mac80211] [ 203.333952] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] [ 203.339520] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] [ 203.345782] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] [ 203.352042] genl_family_rcv_msg_doit+0xb4/0x110 [ 203.356647] genl_rcv_msg+0xd0/0x1bc [ 203.360208] netlink_rcv_skb+0x58/0x120 [ 203.364027] genl_rcv+0x34/0x50 [ 203.367154] netlink_unicast+0x1f0/0x2ec [ 203.371061] netlink_sendmsg+0x198/0x3d0 [ 203.374967] ____sys_sendmsg+0x1b0/0x210 [ 203.378876] ___sys_sendmsg+0x80/0xf0 [ 203.382522] __sys_sendmsg+0x44/0xa0 [ 203.386081] __arm64_sys_sendmsg+0x20/0x30 [ 203.390161] invoke_syscall.constprop.0+0x4c/0xe0 [ 203.394849] do_el0_svc+0x40/0xd0 [ 203.398149] el0_svc+0x14/0x4c [ 203.401189] el0t_64_sync_handler+0x100/0x110 [ 203.405529] el0t_64_sync+0x15c/0x160 [ 203.409179] Code: d2800002 910092c0 52800023 f9800011 (885f7c01) [ 203.415252] ---[ end trace 7e42dd9a39ed2281 ]--- [ 203.426754] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 203.433610] SMP: stopping secondary CPUs [ 203.437517] Kernel Offset: disabled [ 203.440988] CPU features: 0x0,00000000,20000802 [ 203.445501] Memory Limit: none [ 203.455362] Rebooting in 3 seconds.. Må da være mulig å finne ut hvorfor dette skjer. I første omgang får jeg se om problemet er der i master branchen også.

Kanskje det funker med en ikea smartlås for skap/skuff og et rfidkort tapet på fronten av roboten? Og ikke tape kort på hunden https://www.ikea.com/no/no/p/rothult-smartlas-hvit-00359739/ Edit: hmm, nei. Innså at det var en dårlig ide. De låsene smekker vel ikke? Da funker det dårlig. Lage noe tilsvarende med smekk selv, da

interessant! Har en Conbee II liggende uten noe mål og mening fordi, som det står, " there are far better and more capable alternatives out there". Her var jo en mulighet til å gi den litt mening igjen.

Samtidig er det kanskje mulig med tilsvarende ordninger som man har hatt for USB-duppeditter? Der har det i mange tilfeller vært mulig å få sin egen product ID fra produsenten av hardwaren du bruker, med deres vendor ID og tilhørende medlemsskap i USB-IF. Gjerne kostnadsfritt. Jeg fikk f.eks en ID fra Microchip i sin tid basert på en håndfull PIC18LF2550 som jeg labbet litt med. Det gikk jo selvsagt ingen steder. Prosjektet ble til slutt stjålet. Men det var nok mest pga motorsykkelen det satt i.

Hm. Er det noe jeg ikke har fått meg meg her? På https://www.home-assistant.io/docs/authentication/ står det Det kan se ut som de skiller mellom forskjellige grupper som "Owner, Administrator, Read-Only User" under /config/users men i Add User dialogen er det bare mulig å velge Administrator on/off, med kommentaren Dette dekker ikke noen som helst praktisk use case som jeg kan se. Noen eksempler: slomsete samboer som helst ikke skal ha tilgang til å trykke på for mange knapper barn skal kunne styre lys her og der, men får kanskje ikke leke med garasjeporten eller vannkokeren leieboer skal ha full tilgang til alt som dekker hybelen, inkludert lys i fellesområder som gang den som låner hytta skal få midlertidig tilgang til all automagi der, selv om HA-instansen dekker både hus og hytte

Jatakk! Litt usikker på hva jeg synes om at den er satt opp som en "Later priority". Jeg fatter egentlig ikke hva de tenkte på når de designet systemet uteni første omgang.

@Fermate har kommet med løsningen for lenge siden. Du kan jo bare droppe PC-vifta:

Vet at mange har vært entusiastiske lenge når det gjelder esphome. Jeg må innrømme at jeg ikke helt har sett poenget. Men nylig testet jeg ut Blåtann (egentlig BLE) proxy-funksjonen, og den er jo konge! Kjører greit på knøttsmå og billige ESP32C3 moduler. Delt Wifi og Blåtann skal riktignok ikke være så lurt. Har ikke hatt kjempeproblemer utover at det var greit å vente med BLE scanning til nettet var ferdig konfigurert. Men jeg liker kablet nett og jeg liker PoE. Spesielt hvis vi ser for oss en BLE proxy plassert på steder der det ikke er strøm fra før. En slik virket perfekt (men pass på å velge "Color: ETH01-EVO with POE"): https://www.aliexpress.com/item/1005006528549724.html ...bortsett fra at ethernet-modulen ikke var støttet i esphome, da. Optimist som jeg er så bestilte jeg likevel. Det ligger en driver i esp32-idf, som er mer eller mindre obligatorisk uansett med ESP32C3 om jeg har forstått det riktig. Så hvor vanskelig kan det være å legg til i esphome? Ikke vanskelig i det hele tatt, viste det seg. Det var dagens prosjekt: https://github.com/esphome/esphome/pull/6861 Så da gjelder det bare å finne et sted den kan gjøre nytte for seg.

Et par nyttige linker... Zigbee dokumentasjon (ser ikke ut til å være helt stabilisert ennå, så det kan vel være greit å følge med på om det kommer nye versjoner av dette dokumentet). Linken er bla fra https://help.aminacharging.com/en/faq: https://doc.clickup.com/9004130215/p/h/8cb07x7-18308/c750786359b035a Firmware versjon 1.5.3 og oppgraderingsinstruksjoner, fra https://github.com/somlioy/amina_s/issues/7#issuecomment-2142017779 https://doc.clickup.com/9004130215/p/h/8cb07x7-30795/12688a97b1dfa55 Min lader kom med versjon 1.4.10, og der manglet en del av de dokumenterte Zigbee attributtene. Oppgradering over BLE vha Android-appen det refereres i dokumentasjonen til virket fint. Men jeg håper jo virkelig de har tenkt å støtte Zigbee OTA etter hvert.