Bjørn Mork

Har dessverre ikke helt funnet ut av hvordan vi gjør PD på mobilnettet. Skulle gjerne delt ut en /48 på FWA slik at det ble likt med GPON og HFC. Men sliter med å finne oppskrifter som virker. Utfordringen er at et mobilmodem typisk er en ruter som later som den er bridge. Det er ikke trivielt å sende link local pakker gjennom en slik. Er avhengig av at firmwaren faktisk sender DHCPv6 pakkene videre til PGWen. Evt fungerer som et lag 2 DHCPv6 relay. Evt gjør DHCPv6 solicit selv og kjører en separat DHCPv6 server. Men alt dette blir i så fall avhengig av den spesifikke implementasjonen, og det vet jeg ikke om jeg er så happy med. Tar gjerne imot noen tips og triks hvis noen vet hvordan dette gjøres. Men det ligger foreløpig på is til vi har nye PGWer å leke med. Inntil da er /64 det beste vi får til på FWA.

Jeg forstår heller ikke hva du mener når du tegner flere streker til separate "off" og "on" tilstander. Tilstandende henger åpenbart sammen. Bryteren kan ikke være både "off" og "on" samtidig. Og det er uklart hvordan input-strekene kombineres. Er det med "eller" - dvs at hvs en av dem er "sann" så er resultatet "sant"? Eller er det med "og" - dvs at alle må være "sann" for at resultatet skal bli "sant". Jeg prøver å si at det er enklere å forstå sin egen logikk, inkludert eventuelle brister, hvis du tegner disse sammenhengene.

Lag deg en output til bryteren og tegn opp med og/eller mellom de forskjellige input-variablene. Da blir det litt enklere å få oversikt over logikken

Helt enig i at ethernet backhaul for wifi er lurt når man har muligheten. Poenget var at gulvlist blir feil sted for slikt. En takboks er nok mer riktig hvis du går for synlig montering. Ellers er jeg tilbøyelig til å akseptere noe suboptimal plassering av aksesspunkt dersom de kan gjemmes helt bort. Skap, kott, over himling osv. EDIT: Kan jo ta med min subjektive erfaring etter å ha gått amok med kabling i eksisterende rør når vi flyttet for et par år siden. Kablet da til stue, tv-stue og alle soverom, i tillegg til aksesspunkter under trapp og i kleskott. Garasjen hadde en cat5e fra før og null mulighet for utvidelse så den lot jeg være i fred. Har hittil ikke brukt uttakene i stue og de fleste av soverommene til annet enn testing. Unntaket er tenåringsrommet, der et dobbelt uttak var litt i minste laget 😉 Er ingen her som gidder kabel til laptopen noe mer enn de gidder kabel til telefonen. Garasjen kunne nok hatt en kabel til. Men det er jo ikke verre enn at jeg har satt en egen switch der (til aksesspunkt inne og en 5G-ruter ute)

Ikke enig. Dvs, enklere er det kanskje. Men dårligere total-løsning hvis det ferdigtrukne røret bare er 16mm. 20mm rør høres mye bedre ut. Min erfaring med nettverk er at du alltid skulle hatt gjennom en kabel til. Eller kanskje fiber med plugger (for de av oss som ikke skjøter slikt selv). Ellers er det begrenset behov for tradisjonelle nettverksuttak ved gulv. Det er vel bare gaming-PC og stereo/TV som har nytte av slikt nå til dags. Du vil heller ha nettverkskablene der du skal ha wifi aksesspunkter, dørklokke, kameraer er allerede nevnt, og evt andre iot-dingser med PoE mulighet.

Nei, du må nok lage driveren. Ikke helt umulig, men litt risikabelt å fikle med siden det er udokumentert blind fikling inn i det aller helligste der minst en av funksjonene etter all sannsynlighet starter selvdestruksjonsekvensen. seriøst. Nyttige verktøy: Intels ASL+ kompilator. iasl. Inkludert i Debian-pakken acpica-tools https://github.com/mkottman/acpi_call. Pakket som acpi-call-dkms i Debian Eksempel på hvordan dekompilere DSDT for å se på hva som er tilgjengelig og kalle funksjoner der. Utøves med stor forsiktighet - firmware i en laptop gjør veldig mye rart og er vanligvis skrevet av idioter på crack: apt install acpi-call-dkms modprobe acpi-call cp /sys/firmware/acpi/tables/DSDT /tmp/ iasl -d /tmp/DSDT less /tmp/DSDT.dsl Her ser jeg f.eks denn blokken, som jeg er så heldig å allerede vite har noe med batteri/lading å gjøre Scope (\_SB.PCI0.LPC.EC.HKEY) { Method (PSSG, 1, NotSerialized) { Return (\PSIF (0x00, 0x00)) } Method (PSSS, 1, NotSerialized) { Return (\PSIF (0x01, Arg0)) } Method (PSBS, 1, NotSerialized) { Return (\PSIF (0x02, Arg0)) } Method (BICG, 1, NotSerialized) { Return (\PSIF (0x03, Arg0)) } Method (BICS, 1, NotSerialized) { Return (\PSIF (0x04, Arg0)) } Method (BCTG, 1, NotSerialized) { Return (\PSIF (0x05, Arg0)) } Method (BCCS, 1, NotSerialized) { Return (\PSIF (0x06, Arg0)) } Method (BCSG, 1, NotSerialized) { Return (\PSIF (0x07, Arg0)) } Method (BCSS, 1, NotSerialized) { Return (\PSIF (0x08, Arg0)) } Method (BDSG, 1, NotSerialized) { Return (\PSIF (0x09, Arg0)) } Method (BDSS, 1, NotSerialized) { Return (\PSIF (0x0A, Arg0)) } } Funksjonsnavnene er kryptiske, men det er et visst mønster. Slutter på G => get , Slutter på S => set. Interessant nok ser vi at alle samme kaller den samme funksjonen \PSIF med en id og et argument. Hvis vi av nysgjerrighet kikker litt lenger ned så ser vi hva den er Method (PSIF, 2, NotSerialized) { Return (SMI (0x14, 0x05, Arg0, Arg1, 0x00)) } SMI = System Management Interface. Så der har du magien. Men vi kan prøve et par av get-kallene ihvertfall. Må gjette argumentet, men her jeg så heldig at jeg vet at det er batteri 1 eller 2. Og jeg har bare 1. Så dermed (med echo "" for lesbarheten bare) root@miraculix:/home/bjorn# echo '\_SB.PCI0.LPC.EC.HKEY.BCTG 1' >/proc/acpi/call; cat /proc/acpi/call; echo "" 0x350 root@miraculix:/home/bjorn# echo '\_SB.PCI0.LPC.EC.HKEY.BCSG 1' >/proc/acpi/call; cat /proc/acpi/call; echo "" 0x35a Og så er jeg også så heldig at jeg vet at det bare er den laveste byten jeg er interessert i der, så dermed er svarene 0x50 og 0x5a. Eller 80 og 90 som var det jeg hadde som start og end threshold i prosent. Og jeg kan endre f.eks. stop til 85% med (ettersom alle disse fuksjonene bare tar ett argument så forsvinner magisk nok batterinummeret her): root@miraculix:/home/bjorn# echo '\_SB.PCI0.LPC.EC.HKEY.BCSS 0x55' >/proc/acpi/call; cat /proc/acpi/call; echo "" 0x0 Endringen kan jeg se igjen i driverens grensesnitt: root@miraculix:/home/bjorn# grep . /sys/class/power_supply/BAT0/charge_control_* /sys/class/power_supply/BAT0/charge_control_end_threshold:85 /sys/class/power_supply/BAT0/charge_control_start_threshold:80 Vel, der har du mer enn nok info til å skrive en ACPI-driver for Linux. Og vi har kanskje sporet av nok for i dag. Men håper det er underholdning i det minste

Vet ikke hvordan på en HP, men den riktige måten er å lage en driver som snakker med ECen i laptopen og forteller den hva grensene skal være. Typisk har ECen ACPI og/eller WMI funksjoner for den slags. I Linux er det standardiserte og dokumenterte grensesnittet et par sysfs attributter. Dokumentasjon her: https://www.kernel.org/doc/html/latest/admin-guide/abi-testing.html#abi-sys-class-power-supply-supply-name-charge-control-end-threshold Dersom du har en driver som støtter dette så finner du dem under batteri-objektet i sysfs. Helt sikkert også i diverse GUI-verktøy på toppen, men det er jo mer krøkkete å forholde seg til. På min Stinkpad så har jeg: root@miraculix:/home/bjorn# ls -l /sys/class/power_supply/BAT0/charge_control_* -rw-r--r-- 1 root root 4096 Feb 10 18:14 /sys/class/power_supply/BAT0/charge_control_end_threshold -rw-r--r-- 1 root root 4096 Feb 10 18:14 /sys/class/power_supply/BAT0/charge_control_start_threshold root@miraculix:/home/bjorn# grep . /sys/class/power_supply/BAT0/charge_control_* /sys/class/power_supply/BAT0/charge_control_end_threshold:90 /sys/class/power_supply/BAT0/charge_control_start_threshold:80 Så dermed lader ECen batteriet til 90% og stopper der. Så kjører den maskinen på AC inntil batteriet har droppet til 80% før den begynner å lade igjen. Kan jo ta en del tid når den ikke bruker batteriet. Dette er grenser jeg har valgt og bare lagt inn i de filene der (vha sysfsutils, men det kunne jo like gjerne vært et par echo kommandoer i et boot script). Navnene på driverne som har implementert slikt forteller det meste om hvilke merker du kan forvente at det virker. Dessverre ikke HP ser det ut til: bjorn@miraculix:/usr/local/src/git/linux$ git grep -l charge_control_end_threshold drivers/ drivers/platform/x86/asus-wmi.c drivers/platform/x86/dell/dell-laptop.c drivers/platform/x86/fujitsu-laptop.c drivers/platform/x86/huawei-wmi.c drivers/platform/x86/lg-laptop.c drivers/platform/x86/msi-ec.c drivers/platform/x86/system76_acpi.c drivers/platform/x86/thinkpad_acpi.c drivers/platform/x86/toshiba_acpi.c Noe å tenke på neste gang du handler laptop... Evt er det jo sikkert mulig å implementere på HP også hvis man har tid og ork. Regner med at de har funksjonaliteten i WIndows, så det er jo "bare" å finne ut hva de magiske ACPI eller WMI besvergelsene er

Teknologivalg blir smak og behag. Men du kan ikke basere deg på hva som er mest hensiktsmessig for elektrikeren. For dem er det er fordel at systemet er lukket og begrenset til én leverandør. Det gir færre variable å ta hensyn til. Mye enklere å levere og sannsynligvis mindre support. Evt lock-in er bare en bonus som øker sannsynligheten for at du kommer tilbake og kjøper mer av samme. De trenger heller ikke bekymre seg for evt total utskifting av hele systemet på et senere tidspunkt hvis du finner ut at Plejd ikke var tingen likevel, eller skytjenestene skulle forsvinne. Den risikoen tar du alene. For dem vil det bare være en ny sjanse til å få et stort oppdrag. Jeg forstår det slik at alle tredjeparts-løsninger for Plejd er basert på at det finnes en fungerende Plejd skytjeneste der produktene registrers og man kan hente ut nøkler. Det ville ihvertfall ikke jeg tatt sjansen på for faste installasjoner som skal leve i 10+ år.

Sant. De har også vist at de kan ta tilbakemeldinger om uheldige designvalg i firmware, og faktisk endre dem. Se https://github.com/somlioy/amina_s/issues/7#issuecomment-2358501644 Dette er relativt unikt. De fleste andre duppeditt-produsenter evner vel knapt nok å fikse åpenbare bugs.

Her kan det jo tenkes at Amina C er noe? Vet ikke så mye om den, men i følge produkark har den "local OCPP 1.6j" (hw klar for 2.01) via wifi6 (2,4 og 5 GHz) eller 4G cat1. Har fremdeles BLE og Zigbee også. Fysisk ser den ut som Amina S bortsett fra RFID/NFC-symbolet, så jeg vil tro de har gjenbrukt det meste unntatt kontroller-modulen. Virker særdeles fornuftig i forhold til kostnadskontroll. For min del ville nok en lokal OCPP-installasjon bli litt i overkant komplekst i forhold til behovet. Så jeg foretrekker uansett Zigbee. Men hver sin smak. Vil du ha wifi så er det vel OCPP som gjelder om du sjal ha noe som ligner på standard. Ja, men det blir da et separat Zigbee-nett. Selvsagt ikke et stort problem. Men greit å være klar over.

BTDT. Trodde heller ikke det var mulig. Det viste seg å være et mye mindre problem enn antatt. Zigbee-pærer (IKEA Trådfri) i utelysene på både hus og garasje, og vips så hadde jeg sammenhengende zigbee-nett. Dette til tross for at garasjen er en "betongbunker" som er sprengt ned og inn i fjellet nedenfor huset og utelysene står på veggen som vender bort fra huset. Skulle det fremdeles ikke være nok så er nok avstanden antageligvis så lang at du kan tenke deg noen lys-stolper eller -pullerter mellom hus og garasje uansett. God unnskyldning for å kjøre det prosjektet 🙂

Se Link til dok og firmware er også nevnt i Av/på og dynamisk styring av strøm fungerer helt greit. Forutsatt at bilen ikke protesterer antar jeg - bare testet med en 2024 Enyaq. Du får måling av effekt og forbruk. Alt over zigbee. Har ikke testet 3-faselading og -innstillinger siden jeg har IT-nett Firmware-oppdatering skjer foreløpig bare over BLE. Krysser fingrene for Zigbee etter hvert. Men det er jo ikke kritisk nødvendig. Oppdateringer er nokså sjeldne, og vi må vel regne med at de bare blir sjeldnere. Hele greia er en veldig enkel dings. Noe som er en ubetinget fordel, spør du meg. Amina S er nesten latterlig enkel sammenlignet med Zaptec Home laderen jeg har hjemme. Zaptec-laderen inneholder jo en hel Freescale i.MX6 datamaskin med alle slags duppeditter, men bruker opp all intelligensen og alle nettverksinterface på å snakke med en skytjeneste. Totalt sett så blir brukeropplevelsen bedre med Zigbee mot Aminas enkle Nordic Semi mikrokontroller. Ihvertfall etter min mening. Og løsningen blir selvsagt mye billigere å utvikle, produsere og drifte. Det er vinn-vinn-vinn.

Det er spekulanter som sitter igjen med forskjellen mellom produksjonskostnad og det forbruker + staten betaler. Du kan vri rundt på regnestykket så mye du vil med virtuelle "markedspriser", men dette er kun røyk og speil. Markedet eksisterer ikke. Det er et lovpålagt system, som tydeligvis også trenger direkte subsidier i tillegg for å ikke bryte sammen. En helt vanvittig idé.

OK, jeg innrømmer alt om at jeg ikke har giddet å ofre dette en tanke før. Har så vidt fått med meg at forrige strømstøtteordning ga pussige utslag ifm fastprisavtaler, der det kunne lønne seg å svi av mest mulig strøm enkelte måneder. Og selv med spotpris var det vel sånn at de av oss med mulighet til å flytte forbruk til billige timer også kunne gå med "overskudd". Men nå snublet jeg inn i dette kaoset av strøm-avtaler og begynte å fundere på effekten av den nye strømstøtten, der støtten beregnes i forhold til prisen når strømmen brukes. Gir ikke det bare en enda verre effekt i kombinasjon med fastpriser? Dersom du har fastprisavtale, bør du ikke da prøve å bruke mest mulig strøm i de dyreste timene? Eller misser jeg noe nå? Er ikke det i så fall et jævla teit system? Ikke for det... Hele greia med å la spekulanter få milliardoverføringer er jo uansett dritteit. Påstanden om at dette er penger til husholdninger er bullshit. Det er hverken produsenter eller konsumenter av kraft som får pengene. Det er bare kreativ regnskapsføring der man opererer med en kunstig høy liksompris på konsumentsiden. Det gjelder å holde tunga rett i munnen og følge pengestrømmen. Altså ikke de virtuelle pengene, men de ekte pengene som går ut fra statskassa og inn til strømspekulantene. Dvs fra fellesskapet til enkelt-selskaper/-personer uten noen reell nytteverdi/funksjon i samfunnet. Marked my ass.

¿que?