Bjørn Mork

OK, bare å legge seg flat og tilstå at jeg aldri har fundert over hvordan gammeldags lysrørarmaturer funker. Hadde jeg tenkt litt så hadde jeg kanskje innsett at LED ikke endrer den delen av kretsen som skaper rele-trøbbel: Den gedigne spolen som brukes både som konstantstrømkilde og startspenningsgenerator. Det har jo egentlig ingenting med gassrøret å gjøre. Lavere strøm reduserer selvsagt problemet, men når jeg hadde problemer med 2x36W så burde jeg nok regnet ut at 4x15W heller ikke var noen kjempegod ide. Men en fordel med LED i tillegg til lavere strøm er jo at det er problemfritt å legge på et RC ledd. Den slags ville antageligvis ikke gått så bra med lysrør siden det også ville tatt knekken på den ønskede transienten trigget av starteren? Men med LED-rør så er det jo bare å pøse på med kapasitans. Tror jeg.... Så jeg prøver meg enda en gang. Nå med RC ledd på begge releene. Også det som har fungert med 2x15W LED - likevel ingen grunn til å utsette det for unødvendige transienter.

Er litt fristende å pushe den fila til https://github.com/Koenkk/zigbee-OTA men er usikker på om det er lurt så lenge instruksjonene fremdeles tilsier factory reset. Hvad tycks?

Den er veldig nært beslektet så den kan nok helt sikkert brukes med OpenWrt. Men jeg har ikke hatt tid til å se på den, og dermed tror jeg vi trygt kan se bort fra at jeg kommer til å få tid til det. Jobben med å teste ut og finpusse på OpenWrt-konfig gjenstår. Altså ikke en plug-and-play installasjon...

Og der var boksen min oppgradert. La merke til en pussig ting som ikke ahr skjedd før: Den dukket aldri opp igen i nRF Device Manager. Måtte fjerne avkyssingen for "Only devices advertising SMP UUID". Først da dukket den opp igjen, og jeg kunne lese av ny firmware-versjon osv (liker å verifisere den i BLE også etter oppdatering, før jeg gjør en "re-interview" i z2m). I følge f.eks. nrF Connect (forvirrende nok en annen BLE app fra nordic semi) så annonserer bokse fremdeles en "SMP Service". Så jeg forstår ikke helt hva greia er. Ikke noen viktig sak, men det forvirret meg litt først at den forsvant slik fra nRF Device Manager. Hadde jo vært brilliant om Amina snart kunne støtte Zigbee OTA, og da selvsagt uten factory reset siden det ville vært en dårlig kombo. Virker litt sånn "under utvikling" at de baserer seg på nordic semi sine utviklingsverktøy for firmware-oppgradering. Samtidig, hvis det er en forutsetning for det nivået vi har sett på firmware hittil så skal ikke jeg klage

Nå sier manualen eksplisitt "make sure the amp wheel is not at zero" ifm oppdatering. Ikke at jeg tror det gjør noen forskjell så lenge boksen ikke bootes, men...

Takk for tips. Begynte nesten å tro at de så seg fornøyd med 1.8.50 etter såpass lang tid uten oppdateringer. Etter min erfaring så kunne de fint ha gjort det. Kan ikke si at jeg har merket noe til stabilitetsproblemer eller andre problemer. Boksen min har virket dønn stabilt så langt med akkurat den funksjonaliteten jeg trenger (bruker z2m og HA). Men jeg klarer nok ikke å motstå fristelsen til å oppgradere firmware likevel. Må ha siste versjon 🙂 Selv etter IKEAs stunt i fjor. Veldig hyggelig av dem å inkludere release notes med et innhold som faktisk forteller hva som er endret. Men skulle gjerne sett at de droppet factory reset fra instruksjonene. Evt endringer i formater på lagret info mellom versjoner burde de ha kontroll på i firmware. Greit nok at factory reset er en "fiks alt", men jeg synes ikke noe om at det skal være nødvendig ved hver oppgradering. Ganske mye unødvendig hassle at boksen må åpnes og du må løpe et par ganger fram og tilbake til sikringsskapet. Uten at det beviser noe som helst så har jeg tidligere prøvd oppgraderinger både med og uten factory reset uten å registrere noen ulemper ved å droppe det. Men det kan selvsagt tenkes at noe kræsjer på seg. YMMV

Veldig rart at det adapteret kom uten beskyttelse. Det koster jo ingenting og er normalt med. Se f.eks bilde her: https://www.fs.com/products/76105.html Går sikkert bra uten i en begrenset periode forutsatt at det ikke er veldig mye dritt som pøses inn i hullet. Men jeg ville nå uansett spandert på en slik plastplugg. Vet ikke hvor du kjøper den slags løst, men det følger med alt av SFPer (og etter min erfaring også slike skjøtestykker). Evt hvis dette bare er midlertidig så kan du kanskje bare plugge inn en fibersnor og la den henge der? Med beskyttelseshettene på pluggen i den andre enden, selvsagt.

Og da var fasiten klar. Releet i garasjen med 4 x 15W LED-rør bak hang seg opp igjen i dag. Mulig jeg har for høye forventninger, men jeg synes kanskje det burde kreve litt mer å "drepe" et rele som hevdes å takle 16A. Eller kanskje kontaktene er litt i overkant sticky etter lysrør-testingen tidligere? Releet var selvsagt ikke helt dødt nå heller - det hang fremdeles etter demontering, men et par lette kakk og så funket det igjen. Ihvertfall med de mikroamperene som multimeteret gir. Men jeg aner ikke hva jeg skal bruke det til. Ser at manualen illustrer montering bak stikkontakt. Tenker det hadde gått kjempebra med en støvsugerlast elns. Minner mest om søppel.

Må vel være mulig å lage en trykkdrevet ventilanordning som sørger for at fløytene spiller en passende melodi? Sannsynligvis vanskelig å unngå økende takt, men det kan jo brukes som en feature. Sånn, nå har du noe å bruke påsken på 🙂

Har vel vært nevnt før, men det store aberet med den der er at du fremdeles er avhengig av skytjenestene til Plejd for å få tak i nøklene dine. Ref https://github.com/icanos/hassio-plejd/blob/master/plejd/README.md#configuration-parameters

og etter å ha sett på produktutvalget så tror jeg at jeg forstår hvorfor. Enkle og geniale ting som et modulært design der du kan velge å sette dimmehjul på alle pillevariantene. Eller at de fleste (alle?) pillene har topolet brudd slik at de kan ertstatte en hvilken som helst bryter. Formelt, uten at jeg ser helt nytteverdien. Kunne vel like gjerne spikret opp et skilt ala Og ikke minst at de tilbyr design-ripoff av vanlige brytersystemer, slik at det visuelt sklir rett inn sammen med usmarte komponenter. Også i felles rammer. Skulle gjerne hatt alt dette jeg, forutsatt at det var kombinert med zigbee og/eller thread. Men at denslags er mindre viktig for elektrikeren og 99% av kundene er helt som forventet.

Ser ikke helt hva som skulle være problemet? Som alle andre drivhus så kommer det med det "gulvet" du bygger selv. Jordgulv/platting/støpt såle - du velger. Vil du ha innlagt vann så er det jo bare å legge et rør eller en slange opp gjennom gulvet. Akkurat som andre steder du vil ha en vannkran i hagen

Montert begge rele igjen med billige LED lysrør fra Clas Ohlson. Så langt ser det ut som det går greit. Og det var jo en virkelig lysvinner. Skulle gjort for lenge siden. Blir spennende å se om releene holder over tid

Er fortsatt fornøyd . Men håper jo å unngå å finne ut hvor godt de egentlig virker. Har kjøpt en til siden første batch ettersom det viste seg at jeg hadde glemt et rom. Full oversikt ... Men da fikk jeg prøvd ut hvordan det er å koble til flere . Akkurat så lett som forventet . Bare å la den joine zigbee nettet og så var seriekoblingen på plass. Uten å måtte tenke på hvilken som var master eller slikt

Gammal tråd, men det passer bra. I stedet for å lese den og lære så foretrakk jeg å gjøre samme feil, og så lese. Men nå frisker jeg opp denne i minnet til glede for andre som har tenkt å gjøre det samme. Installerte 2 Namron 16A zigbee releer i garasje og tilhørende bod i går. Foran 2x36W lysrør i boden og 4x36W i garasjen. Stod ikke en dritt om lavere begrensninger for induktive laster i manualen, men jeg er jo ikke dummere (tja..) enn at jeg skjønner det. Antok bare at 16A var overkill nok. Det var det ikke. Fikk banket liv i releene igjen etter demontering. Så nå er spørsmålet: Vil det gå bra om jeg bytter til LED lysrør, som jeg uansett har tenkt å gjøre? Eller er det bare å drite i kombinasjonen smart rele med de armaturene som henger der? Er ikke viktig nok til at jeg gidder bytte dem tror jeg

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.