Bjørn Mork

Det er vanskelig å få kjøpt USB pinne-modem som funker, uavhengig av PI eller OS De aller fleste har nå ruter-funksjonaltet med NAT og web-gui i firmware. Det kan nok fikles til og scriptes, men det er og blir en jalla løsning. Der har du MF823, og dessverre det meste annet som er til salgs nå. Har aldri prøvd, så ingen garantier. Men jeg tror kanskje denne kan funke: https://www.kjell.com//no/produkter/mobilt/mobilt-bredband/modem-mobilt-bredband/4g-modem/d-link-dwm-222-4g-modem-p61613 Ut fra https://osmocom.org/projects/quectel-modems/wiki/D-Link_DWM-222_stick/10 så skal firmware eksponere 4 ttyUSBx serieporter og en QMI/RMNET funksjon. Det betyr at det burde virke flott med f.eks. ModemManager på Pien. Det er jo også et godt tegn at D-Link dokumenterer Linux-bruk, selv om de fokuserer unødig mye på ppp: https://eu.dlink.com/uk/en/support/faq/routers/mobile-routers/how-to-install-my-dwm-222-on-ubuntu Et STORT forbehold: Det er ikke uvanlig at 4G modemer kommer med forskjellig firmware med vidt forskjellig oppførsel og grensesnitt. Det er helt umulig å vite hva du får ut av Kjell uten å prøve...

Anbefaler en USB minnepinne i mikro-variant i stedet for minnekort. Null kabel-salat og ytelse oppimot det du får fra en SSD via USB. Enklere å skrive til fra de fleste PCer også

Huh? Hvor da? Link? Jeg finner bare 8GB varianten til 990. Det er vel OK, men ikke super, pris. Hovedproblemet er at den ikke er på lager - samme som overalt ellers. Ellers har jeg ha på en RPi4 med 4GB RAM og ser ikke noe reellt behov for mer. Kjører 64bits Debian på den, med z2m, mosquitto, nginx, rtl_433, conserver, noe hjemmesnekra python, og ikke minst motion med et par kameraer tilkoblet. Det eneste som drar ressurser av betydning er jo som forventet transkodingen av video-strømmene og bevegelsesdeteksjonen. Samme boks fungerer også som router i nettverket, med dhcp, nat, lokal dns-cache og all annen herlighet som følger med. Det er bortimot uendelig med ressurser i en slik liten dings. Kan lett sammenlignes med det vi kalte server for 10 år siden.

Om de ikke er egnet kommer jo an på hvor strenge krav du stiller. Siden jeg allerede hadde kjøpt modulene så endte jeg også opp med å bruke dem. Og erfaringen i normal bruk, der home assistant er oppegående og funker, er så langt veldig bra. Tror ikke husets høyest teknisk sertifiserte har merket endringen ennå 🙂 Får bare akseptere at disse bryterne vil feile hvis home assistant går ned. Det holder jo forsvåvidt at én bryter virker i den situasjonen. Og jeg har noen IKEA dimmebrytere bundet til de samme lysene

Helt enig. Og der må jeg advare mot Hue wall switch modulene. De ser ikke ut til å støtte slik binding. Ihvertfall har ikke jeg fått det til. Kan selvsagt være bare jeg som kløner... Men jeg får det til både den vanlige Hue dimmeknappen og IKEAs dimmeknapp. Bare ikke med disse wall switch greiene. Ikke støtter de OTA heller visst, i motsetning til det meste annet av Hue. Dermed er det ikke så mye håp om at situasjonen skal bedre seg (eller forverre seg - slik vi har sett med IKEAs knapp. Men det er enn annen historie) Bruker zigbee2mqtt til å sette opp bindinger og slikt, og til å laste ny firmware. Så begge problemer kan jo selvsagt skyldes manglende implemetasjon der.

Dette skal nå være ganske så robust og stabilt med nyere firmware i RPien. Ser ikke helt problemet med å droppe minnekortet. Uansett hvordan du snur på dette så vil jo kortet være en unødvendig komponent som kan gå fløyten. Du kan like gjerne boote fra SSDen hvis alt av applikasjoner er avhengige av den.

Dokumenter gjerne og legg ved et ark med info om hva slags utstyr du etterlater. En oppegående kjøper vil nok bli veldig glad for å slippe å forske det fram selv. Samboern kjøpte hytte i fjor. Har ikke funnet spor av noen brytere, smarte dimmere eller pucker. Men oppdaget ved en ren tilfeldighet til sammen 9 Trådfri pærer. Ikke store greia men selgeren kunne nå gjerne ha nevnt det, spør du meg. Bare flaks at jeg oppdaget dem ved at et par av dem joinet en åpen zigbee2mqttl. Kunne like gjerne ha endt opp med feilsøking etter et mislykket forsøk på å sette en dimmer foran.... Håper at jeg ikke har gått glipp av noe mer skjult. Sitter det en puck, som ikke er factory resatt, i en boks et sted så er det jo bortimot puck umulig å gjette det. Går liksom ikke rundt og skrur ut alle pærer for å se på dem heller. Burde kanskje det i nyinnkjøpt brukt-bolig?

Måtte kikke på den der med lupe, men jeg mener det mangler data her. 19 (25 desimalt) nest sist på linje 2 er antall elementer vi forventer. Dvs listenavn og 12 par med obis-kode + verdi. Hvis vi formatterer slik så blir det tydeligere: 7E A0BA 2B 21 13 EDAA E6E700 0F 00000000 0C07E60205060D000AFF800000 0219 0A0E 4B616D73747275705F5630303031 0906 0101000005FF 0A10 35373036353637323731353333323037 0906 0101600101FF 0A12 36383631313131424E323432313031303430 0906 0101010700FF 0600000268 0906 0101020700FF 0600000000 0906 0101030700FF 0600000053 0906 0101040700FF 0600000000 0906 01011F0700FF 0600000122 00 00 00 00 0906 0101200700FF 1200E2 00 00 00 00 05D8 7E Her er det noe rart etter 0600000122. Det kan godt tenks dette er gyldig for en-fase(?) måler. Men jegsavner OBIS-kodene 0101330700FF 0101470700FF 0101340700FF 0101480700FF der det bare er 00 00. Dette er strøm og spenning for L2 og L3. Selv om disse pakkene kanskje er gyldige, så er det mulig at de forvirrer programvaren?

Jeg fikk en forsåvidt fornuftig begrunnelse til slutt: Den typen måler som vi har (AXIOMA QALCOSONIC F1) benytter felles nøkkel. Ikke akkurat et design jeg ville akseptert om jeg skulle kjøpe inn utstyr. Men gitt at det er slik, så er jo kommunens tilbakeholdenhet fullt forståelig.

Du kan like gjerne kjøre den på samme RPi som resten. Krever ikke stort. Og så blir du uavhengig av nettverkstrøbbel mellom RPiene.

Jeg tenkte ikke på batteri-enheter. De hjelper selvsagt ingenting som du sier. Men 5 zigbee-pærer gir 5 ganger så mange repeatere i nettverket som 1 zigbee-bryter med 5 dumme pærer bak. Nå vil nok pærer (som kunne vært) bak samme bryter stå relativt nær hverandre så jeg vet ikke hvor stor gevinsten egentlig er. Kommer nok litt an på hvor mye annen redundans du har. Men man bør ihvertfall tenke litt over dette før man bygger ned nettverket til en enkelt zigbee-bryter per etasje elns

Skjønner ikke helt den. Det går jo like bra å binde (de fleste?) zigbee knapper direkte til smartpærer? Hvilken fordel skal bryteren gi deg? Færre radio-dingser å holde styr på? Slippe å binde på nytt om 5 år når du må bytte ut pæra? Det siste kan jeg være med på. Men færre radioer er jo ikke nødvendigvis en fordel i et mesh-nettverk.

i tilfelle noe lurer: Jeg bet i det sure eplet og gambler på at rpien med ha, z2m og mosquitto er stabil nok. Har jo forsåvidt en backup i form av Trådfri dimmere bundet til de samme pærene. Men jeg kjenner noen som kommer til å bli vanvittig frustrerte om bryteren på veggen skulle slutte å virke en dag... En annen lite gjennomtenkt detalj med disse er at de ikke forteller hvilken stilling bryteren har. I "rocker" modus sender de både "press" og "press_release" events hver gang bryteren slås av eller på. Det gir jo en grei trappefunksjon sammen med mapping til "toggle" av lyset, men jeg skjønner ikke hvorfor de ikke samtidig kunne forelle om bryteren er lukket eller åpen. Det burde jo vært en smal sak. Og det er nyttig info i en del sammehenger. Siste klage for i dag: De er kanskje ikke så store, men de kunne nå gjerne vært enda litt mindre. Ville lure en inn i en "76 PH" koblingsboks ( https://proff.elko.no/koblingsboks-76/koblingsboks-76-ph-article1537-716.html ), men selv uten en av klemmene var det akkurat ikke plass. Det gikk til slutt etter å ha filt et spor for koblingsboksskruen i Wall Switch modulen. Men det er et unødvendig stort kretskort med veldig mye plast rundt. OK, jeg kan akseptere at den plasten skal isolere denne fra omgivelsene. Men noe mindre kunne den nå ha vært.

Som du påpeker så er jo dette irrelevant i forhold til reklamasjonsretten, men bare for å pirke: Det er fremdeles tillatt å utføre arbeid i egen bolig uten å tilhøre noen registrert virksomhet, forutsatt at du oppfyller kvalifikasjonskravene i § 7, første ledd. Og det betyr ikke nødvendigvis faglært. Det er tilstrekkelig med en "relevant master". Jeg foretrekker å ikke sjekke for grundig hva som regnes som relevant 🙂 FWIW, så var det iaffal ikke noe problem for el-tilsynet at jeg tilstod "det der har jeg kablet selv" der det var tilfelle

Jeg klarte å bytte om 5V og jord når jeg loddet en USB B-kontakt på et kort en gang i tiden. Det ble grei lunk i kabelen av det. Men porten på PCen stengte ganske raskt ned, så noen brannfare var det jo aldri. Godt var det, for treg som jeg er så tok det meg litt tid å skjønne sammenhengen. Og enda litt mer tid før jeg skjønte hvorfor forrige utgave av kortet feilet ved å bli detektert som Low Speed i stedet for den forventede Full Speed... Hint: FS skal ha pull-up på D+ mens LS har pull-up på D- Har i grunnen aldri vært spesielt stødig på lodding, selv før hendene begynte å skjelve

Hmpf. Alle andre har visst mye greiere kommuner å forholde seg til. Hvilken kommune var dette?

Det er jo en viss framgang her, men ikke helt i boks ennå: https://github.com/Koenkk/zigbee2mqtt/issues/7975

Doh! Takk. Det burde jeg kanskje gjettet.

wtf er en ssr? (norsk) Wikipedia gir meg ingen åpenbart riktige svar, selv om jeg kan ha sansen for det første alternativet: https://no.wikipedia.org/wiki/SSR

Du må vel strengt tatt ikke erstatte Tibber pulse for å bruke Pow-U? Det burde funke greit å bruke begge samtidig vha en splitter-kabel. Må nok sikkert strømforsyne en eller begge via ekstern USB-power.

Kan melde meg på i klubben. Kjøpte samme adapter via den eBay-annonsen det vises til lenger opp. Bestilte 6. august og mottok 18. august. Null trøbbel. Virker helt som forventet. Har den koblet på en RPi4 med en halvmeter kabel. Om jeg skulle pirket på noe jeg kunne tenkt meg å endre, så hadde det vært praktisk å med software-styrt trigging av bootloader. Litt unødvendig krøkkete å måtte fjerne plastdekselet for å fysisk trykke på en knapp hver gang du skal oppgraderte firmware. Men det problemet er jo ikke denne pinnen alene om. Og noe stort problem er det ikke. Har bare oppgradert en gang så langt.

Eksempel på en sesjon fra en RPi4 (men en hvilken som helst Linux-boks med nyere blåtann burde funke): Finn BLE-dingser i nabolaget: root@idefix:/tmp# hcitool lescan LE Scan ... F3:BA:84:AA:5A:48 Netti_01452ec784 F3:BA:84:AA:5A:48 (unknown) 58:93:D8:8C:7C:72 (unknown) 58:93:D8:8C:7C:72 (unknown) 80:6F:B0:A9:EA:0F (unknown) 80:6F:B0:A9:EA:0F (unknown) ^C Koble deg til en av de interessante. Her en Airthings Wave Mini: root@idefix:/tmp# gatttool -I [ ][LE]> connect 80:6F:B0:A9:EA:0F Attempting to connect to 80:6F:B0:A9:EA:0F Connection successful Finn ut hvilke variable du kan lese/skrive ("characteristics" i BLE lingo): [80:6F:B0:A9:EA:0F][LE]> characteristics handle: 0x0002, char properties: 0x02, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb handle: 0x0009, char properties: 0x20, char value handle: 0x000a, uuid: 00002a05-0000-1000-8000-00805f9b34fb handle: 0x000d, char properties: 0x02, char value handle: 0x000e, uuid: b42e3b98-ade7-11e4-89d3-123b93f75cba handle: 0x0011, char properties: 0x2c, char value handle: 0x0012, uuid: b42e3ef4-ade7-11e4-89d3-123b93f75cba handle: 0x0015, char properties: 0x10, char value handle: 0x0016, uuid: b42e41c4-ade7-11e4-89d3-123b93f75cba handle: 0x001a, char properties: 0x1c, char value handle: 0x001b, uuid: f000ffc1-0451-4000-b000-000000000000 handle: 0x001e, char properties: 0x1c, char value handle: 0x001f, uuid: f000ffc2-0451-4000-b000-000000000000 handle: 0x0022, char properties: 0x14, char value handle: 0x0023, uuid: f000ffc5-0451-4000-b000-000000000000 handle: 0x0027, char properties: 0x02, char value handle: 0x0028, uuid: 00002a23-0000-1000-8000-00805f9b34fb handle: 0x0029, char properties: 0x02, char value handle: 0x002a, uuid: 00002a24-0000-1000-8000-00805f9b34fb handle: 0x002b, char properties: 0x02, char value handle: 0x002c, uuid: 00002a25-0000-1000-8000-00805f9b34fb handle: 0x002d, char properties: 0x02, char value handle: 0x002e, uuid: 00002a26-0000-1000-8000-00805f9b34fb handle: 0x002f, char properties: 0x02, char value handle: 0x0030, uuid: 00002a27-0000-1000-8000-00805f9b34fb handle: 0x0031, char properties: 0x02, char value handle: 0x0032, uuid: 00002a29-0000-1000-8000-00805f9b34fb properties forteller hva som er read/write/notify. 0x02 er read. Blir fort ekstra nysgjerring på UUIDer som ikke startert med 0000. Listen overnfor to handles for hver characteristic. Vi er naturlig nok mest interessert i "value". Så f.eks: [80:6F:B0:A9:EA:0F][LE]> char-read-hnd 0x000e Characteristic value/descriptor: 00 00 14 6e 84 c7 57 0f 58 00 00 00 96 57 13 00 ff ff ff ff Nå skal du jo jobbe litt for å få meningen ut av det der om ikke Airthings hadde publisert koden for å parse deler av det. Dette er 6 * le16 og 2 * le32 integer der vi har: 00 00 - ukjent 14 6e - temperaturen i centi-Kelvin (0x6e14/100 - 273,15 = 8,65 °C) 84 c7 - ukjent 57 0f - relativ luftfuktighet i % * 100 (0x0f57 / 100 = 39 %rH) 58 00 - VOC i ppm. (0x0058 = 88 ppm) 00 00 - ukjent 96 57 13 00 - ukjent ff ff ff ff - ukjent Ikke helt rett fram... Men om man tar en del samples sammen med dekodede verdier fra app eller display så er det ofte mulig å gjette ganske mye. Vet ikke hvor lang tid jeg hadde brukt på å innse at temperaturen var gitt i Kelvin, dog 🙂 Mange av de andre verdiene er bare ren ascii og dermed nokså lett å få noe fornuftig ut av. Som f.eks. [80:6F:B0:A9:EA:0F][LE]> char-read-hnd 0x0032 Characteristic value/descriptor: 41 69 72 74 68 69 6e 67 73 20 41 53 Altså "Airthings AS". Når du er ferdig: [80:6F:B0:A9:EA:0F][LE]> disconnect (gatttool:979948): GLib-WARNING **: 16:32:19.458: Invalid file descriptor. [80:6F:B0:A9:EA:0F][LE]> exit

Er ikke spesielt lovkyndig, men akkurat denne regelen er vanskelig å feiltolke tror jeg: https://lovdata.no/forskrift/1999-03-11-301/§4-4 sier Hverken mer eller mindre. Sluttbruker er definert som "kjøper av elektrisk energi som ikke selger denne videre."

morsom greie. Antar du har forøkt de vanlige BLE triksene vha gattool? Skulle jo nesten tro at datane her ble publisert relativt rett fram og at det bare var å matche bytes i en characteristic mot tallene du ser på displayet.

Kan jo det, men du blir nok skuffet. Den er bare en switch og den eneste funksjonen den har ifm Altibox i mitt nett er som "mediakonverter". Routingen gjør jeg på en PC med Debian. Men her er uansett config med de mest private tingenen fjernet. Altibox linken er på port Gi1/0/16. PCen som router mellom alle VLANene er på Te1/0/1. Merk at Ciscos bruk av hastighet i portnavn gir noen pussige effekter. Gi1/0/15 er samme port som Te1/0/1 og Gi1/0/16 er samme port som Te1/0/2. Hvilket navn som er gyldig er avhengig av om det står en SFP eller SFP+ i porten. ! config-register 0xF ! version 15.2 no service pad service timestamps debug datetime msec service timestamps log datetime msec service password-encryption service unsupported-transceiver ! hostname c3560cx ! boot-start-marker boot-end-marker ! !enable password <removed> ! !username <removed> aaa new-model ! aaa authentication login default group radius local aaa authentication enable default group radius enable aaa authorization exec default group radius none ! aaa session-id common switch 1 provision ws-c3560cx-12pd-s system mtu routing 1500 ! ip domain-name <removed> ip name-server 192.168.99.1 ! !crypto pki <removed> ! !crypto pki <removed> ! spanning-tree mode pvst spanning-tree extend system-id no spanning-tree vlan 42,77 ! vlan internal allocation policy ascending ! lldp run ! interface Bluetooth0 no ip address downshift disable ! interface GigabitEthernet1/0/1 description gs108tv3 switchport trunk allowed vlan 37,100 switchport trunk native vlan 37 switchport mode trunk spanning-tree portfast edge ! interface GigabitEthernet1/0/2 description wrt1900ac switchport trunk allowed vlan 1,7-9,13,90,203 switchport mode trunk ! interface GigabitEthernet1/0/3 description Stue switchport trunk allowed vlan 1,7-9,22,101,103,203 switchport mode trunk flowcontrol receive desired ! interface GigabitEthernet1/0/4 description Loft switchport trunk allowed vlan 1,7-9,22,101,203 switchport mode trunk flowcontrol receive desired ! interface GigabitEthernet1/0/5 description Soverom switchport trunk allowed vlan 1,7-9,13,203 switchport mode trunk ! interface GigabitEthernet1/0/6 description "oob canardo" switchport access vlan 203 switchport mode access ! interface GigabitEthernet1/0/7 description 'Telenor uplink' switchport access vlan 90 switchport mode access ! interface GigabitEthernet1/0/8 description 'apc7920' switchport access vlan 203 switchport mode access ! interface GigabitEthernet1/0/9 description "Kjellerstue left" switchport access vlan 7 switchport mode access spanning-tree portfast edge ! interface GigabitEthernet1/0/10 description "Kjellerstue right" switchport access vlan 7 switchport mode access spanning-tree portfast edge ! interface GigabitEthernet1/0/11 description finn switchport access vlan 234 switchport mode access ! interface GigabitEthernet1/0/12 description lte5398 switchport access vlan 235 switchport mode access ! interface GigabitEthernet1/0/13 description Spisestue switchport access vlan 7 switchport mode access ! interface GigabitEthernet1/0/14 description mirrorport switchport access vlan 15 switchport mode access ! interface GigabitEthernet1/0/15 ! interface GigabitEthernet1/0/16 description 'Altibox uplink' switchport trunk allowed vlan 100-102 switchport trunk native vlan 77 switchport mode trunk no cdp enable no lldp transmit spanning-tree bpdufilter enable ! interface TenGigabitEthernet1/0/1 description 'canardo' switchport trunk native vlan 10 switchport mode trunk flowcontrol receive desired ! interface TenGigabitEthernet1/0/2 ! interface Vlan1 no ip address ! interface Vlan203 description Management ip address 192.168.99.59 255.255.255.0 ! ip forward-protocol nd ! no ip http server no ip http secure-server ip scp server enable ! logging trap debugging logging host 192.168.99.1 access-list 60 permit 10.4.0.2 access-list 60 permit 148.122.252.1 access-list 60 permit 192.168.3.1 access-list 60 permit 192.168.99.0 0.0.0.255 access-list 60 deny any log ! !snmp-server community <removed> !snmp-server community <removed> snmp-server trap-source Vlan203 snmp-server location Kjellerboden !snmp-server contact <removed> snmp mib flash cache ! radius server canardo address ipv4 192.168.99.1 auth-port 1812 acct-port 1813 ! key <removed> ! line con 0 line vty 0 4 transport input ssh line vty 5 15 transport input ssh ! ntp source Vlan203 ntp server 192.168.99.1 netconf ssh netconf-yang ! end