Bjørn Mork

Ikke nødvendig på VLAN 102 (Internet) etter min erfaring. Men kan være nødvendig på VLAN 101 (TV) Litt usikker på hvordan du tenker deg dette, men det er nødvendig å rute både VLAN 101 (primært multicast, men også noen unicast-prefiks) og VLAN 102 til dekoder-LANet ditt. Ingen av dekoderne til Altibox klarer seg med kun VLAN 101 lenger. Anbefaler å søke opp eksempel-konfiger og ta utgangspunkt i dem. F.eks https://github.com/trrunde/routerconfig/blob/master/mikrotik-rb4011-altibox Da får du forhåpentligvis med det nødvendigste av igmproxy og ruting til VLAN 101. Aner ikke hvordan dette blir seende ut på en TP-Link ruter men det burde vel la seg gjøre å konvertere så lenge du kjenner platformen

Nå er ikke jeg bortskjemt med skjult anlegg så jeg har hittil ikke hatt så mye behov for å filosofere over hvordan diverse pucker virker eller ikke virker. Men ifm montering av en taklampe så passet det seg slik at en multiboks var hensiktsmessig halvveis mellom bryter og lampe. Tradisjonelle dimmere på vegg uten boks er ikke akkurat noe vakkert syn. Og med en tom boks tilgjengelig så var det veldig fristende å plassere dimmeren der i stedet. Så jeg kjøpte en elko dimmepuck. Litt pussig å bare koble til L og last, i tillegg til pushbryter. Men helt greit for meg. Innså til og med at jeg måtte koble på lampa for at dette skulle ha potensiale for å virke. Men det hele ble nokså ustabilt. Fort gjort å drepe dimmeren (ja, ikke permanent da - men nok til at den falt av nett) ved å redusere lasten for mye. Som jo er litt av poenget med dimming spør du meg... Og med dimmeren av nett så var det ikke bare bare å dimme opp igjen heller. Endte opp med å investere i en bunnlast. Da er alt bare fryd. Det jeg lurer på nå er om ikke dette er mer eller mindre obligatorisk? Og i så fall - hvorfor i all verden selges slike dimmere uten? Jeg klarer ikke helt å se at det med dagens utvalg i lyspærer er praktisk mulig å bruke en slik dimmer uten å montere bunnlast. Pærene trekker bare ikke nok strøm til å holde liv i dimmeren. Og så var det jo det andre spørsmålet da. Tatt i betraktning at du uansett må montere bunnlasten - ville det ikke vært like enkelt med N på dimmeren? OK, jeg ser at det i teorien kan være praktisk å kable dimmer og last separat. Men i praksis vil jeg tro at folk fører L og N samme vei i de aller fleste tilfellene. Eller begge faser for min del, siden nettet er like moderne som kablingen.

Riktignok wifi, men det du får fra https://amsleser.no er uansett et mye bedre alternativ.

Det burde vel ikke spille store rollen om du bruker en USB3-port så lenge duppedittene du kobler til ikke støtter USB3? Historien om interferens dreier seg jo om bruk av f.eks en USB3 disk i nærheten av antenna. Det blir noe annet. Det støyer. Når du kobler en USB2 dings og/eller kabel til en USB3-port så vil det ikke gå noen høyfrekvente signaler i kabelen. Kun 480 Mbits/s over det ene paret som brukes av USB2. De to USB3 parene er ikke i bruk selv om du bruker en USB3-kabel. Burde bli ett fett om du gjør dette eller bruker en USB2 port.

Joda, ikke noe problem. Har gjort det etter første gangs feil. Men måtte altså til med "erase flash" også. Forsøkte først bare å reflashe med 2.2.11 via serieporten, i den tro at det bare var noe som hadde gått skeis ved web-nedgraderingen. Men det endret ingenting. Takk. Da spørs det om jeg ikke skal rapportere dette som en separat feil. Jeg gjentok forsøket i dag, men denne gang fra 2.2.13 til 2.2.11. Og det gikk akkurat like galt. Men jeg sitter noen mil unna akkurat nå, så jeg får ikke gjort stort med det. Skal teste om det er samme oppførsel mht AP og flash erase når jeg får sjansen.

Opplevde i overkant mye reboot etter å ha oppgradert Pow-K (esp8266-versjon) til 2.2.12 eller 2.2.13. Så jeg forsøkte meg på nedgradering til 2.2.11 via web-GUI. Og det gikk ikke så bra. Hverken konfigurert wifi eller AP mode funket etterpå. Det slår meg jo at jeg aldri har prøvd nedgradering før, og heller ikke kan huske å ha sett at det er støttet. Noen som vet? Fikk ikke liv i adapteret før jeg gjorde erase, så det kan jo tyde på at 2.2.11 fant noe den mislikte på flash. Er altså ikke så bekymret siden dette er en litt spesiell usecase og ganske lett å fikse. Bare jeg får fysisk tilgang igjen etter å ha gjentatt fadesen for å være helt sikker 🙂 Men er litt nysgjerrig på om det er som det skal være eller om det er å regne som en bug.

Så alt som skulle til var konkursspøkelset? Er det feil å ønske at det samme rammer alle andre som utelukkende selger hardware som er avhengig sky-tjenester, eller er det litt slemt?

"klockan är en sak som tickar"

Det meste (alt?) du får kjøpt av Bluetooth dongler på aliexpress og ebay er fake. Ofte later de som de er en eller annen antikk CSR-brikke med spiller ny blåtann-protokoll.... Det gjør normalt ikke så mye med forfalskninger, men når det gjelder Bluetooth dongler så har jeg veldig drålig erfaring med kopiene. De tar snarveier, og baserer seg på at det er godt nok så lenge det "virker". Definert som "virker med Windows". Det finnes en del workarounds i Linux-driverne, men det er altfor ofte at det feiler på mystisk vis. Livet er ikke langt nok til å trøble med slikt Det er myyye enklere å bare flise ut den hundrelappen eller to som du må gi for en ekte dongle i en norsk butikk.

Gammelt bilde av HET mediakonverteren de brukte i gamle dager viser tydelig spec: https://www.mork.no/~bjorn/bilder/mediakonverter/html/20160130_121245.html 10 eller 20 km blir ett fett. Bare ikke noe mer enn 20.

1310/1550

https://github.com/espressif/esp-serial-flasher Men jeg ser ikke helt problemet med python....

Det er vel bare Elektroimportørens house-branding av diverse kina-varer? Neppe hverken bedre eller verre enn tilsvarende fra andre butikker. Men kategorien "Namron utstyr" gir ingen mening. Det trenger ikke være noe annet felles mellom to forskjellige Namron-produkter enn at de er solgt av samme butikk. Men den butikkens support blir selvsagt en viktig fellesnevner for "merket".

Kan ikke akkurat fortelle hvordan dette gjøres med skytjenester, Jeg gjør det bare lokalt selv. Men prinsippet er vel omtrent det samme. En vanlig måte å gjøre slikt på er å la en agent lytte på de aktuelle MQTT topicene og mate datene inn i en influx-database. Influx er laget for nettopp tidsserier. En moderne utgave av RRD for de som husker MRTG. Et eksempel på Influx-agent for bla MQTT-input er Telegraf. For presentasjon av data fra Influx er det vanlig å bruke Grafana. Regner med at det finnes fiks-ferdige skytjenester for alt dette om du ikke har lyst til å installere og administrere selv. https://www.influxdata.com/ https://www.influxdata.com/time-series-platform/telegraf/ https://grafana.com/ Det ekstremt fine med at du allerede sender dataene via en MQTT-broker er at du kan plugge alt dette inn der uten å påvirke noe som helst av ditt eksisterende realtime-oppsett. Det er helt uavhengig.

Ja. AIs evner til å lage overbevisende tekst er dessverre helt uavhengig av innhold. Det gjør AI-svar verre enn det meste annet ved å kamuflere feil. Mennesker som gir feil svar vil oftere avsløre seg selv gjennom språk eller andre hint.

Hmm, ser at tråden også viser til DCS-8000LH oppskriften min 🙂 Men som forventet var ikke den noen suksess med dette kameraet. Egentlig ikke så rart. Hvis DCS‑830xLH allerede har rtsp enablet så er jo problemstillengen en helt annen. Det er heller ikke å forvente at blåtann-hacket funker med nyere firmware. D-Link var rimelig kjappe med å stenge akkurat det hullet. Det er enn nok andre hull å ta av, men jeg går fort lei av whack-a-mole.

vnc er jo så mangt... Har ikke noe erfaring med rpi-os, men i følge google så er det realvnc de leverer. Den skal visstnok støtte xrandr. Tips her: https://stackoverflow.com/questions/15816/changing-the-resolution-of-a-vnc-session-in-linux "--scale-from " kan også være ganske nyttig med xrandr for å slippe at desktopen må endre størrelse hver gang du endrer skjerm-størrelse. Det er mest det som er herkete, f.eks. ved at deler av desktopen havner utenfor skjermen.

Grensesnittet Telenor selger dem mot sluttbruker er 1000BaseTX-porten på ONT. Det er ikke noe teknisk problem å støtte en hvilken som helst hjemmeruter på innsiden av denne. Det er helt opp til Homenet. Se https://www.telenorwholesale.no/produkter/vula/ for detaljer

Er det ikke ocpp som er den hellige gral mht elbil-ladere? Lokal sådan, selvsagt. Jeg har registrert at noen produsenter forvirrer ved å markedføre en skybasert ocpp-løsning. Det ser jeg ikke noe poeng i.

Takk. Joda, jeg vet at det er andre måter å lese av måleren. men da blir det et prosjekt hvor jeg må beregne nytteverdien, og den er nok forsvinnende liten i mitt tilfelle. Trådløs avlesning vekket interessen fordi det bare var der uten noe behov for ekstra utstyr ved måleren.

sånn, eller en annen størrelse/utførelse? litt vanskelig å se ut fra bildet ditt https://www.ebay.com/itm/303491550670

Jeg sitter nok dessverre med en Axioma-måler, mens naboene stort sett ser ut til å ha Kamstrup. Takk uansett for bekreftelsen. Sikkert ikke. Men til deres forsvar så har de ihvertfall svart relativt kjapt og så godt de kunne. Og tydeligivs også korrekt. Dette høres interessant ut. All info mottas med takk. Hvis Freeze virker så er iaffal den nyttig. Ikke at jeg aner hvordan jeg evt skulle verifisere at den virker 😉

Trenger du det da? Filtrering vil jo ikke endre strukturen på noen måte. Får du ikke ut det du vil med noe ala u8x8.print(doc["ea"]["h"]["u"].as<float>() ,1); eller misforstår jeg hvor du vil? Evt med litt mer feilsjekk hvis vi du kræsje på forutsigbare måter selvsagt...

Antar du tenker på denne? https://prisguiden.no/produkt/develco-smart-io-module-542888 Den forsvant helt fra markedet for en stund siden, uten at jeg har funnet noen god erstatning noe sted.

Fromt ønske, men jeg har dessverre ikke en komplett oppskrift å gi bort. Jeg fikk aldri noen nøkkel til min måler, så jeg kom meg aldri videre fra eksperiment-stadiet. Uten noen dekrypterte måleverdier er det jo ingenting å dytte inn i HA. Men for å få det inn i HA så ville jeg ihvertfall gått via MQTT. Det er helt sikkert flere muligheter, og det er mulig jeg bare velger MQTT fordi jeg er vant med det, men jeg synes det gjør alt mye enklere med et slikt mellomlag der jeg kan fikle og debugge data i tekstformat. Så kan GUI-konvertering komme til slutt når jeg vet jeg får måleverdier som kan brukes. Den innebygde wmbus dekoderen i rtl_433 er et fint sted å starte for å verifisere at mottakeren klarer å fange opp noe som helst fra måleren. Selv om den antageligvis ikke holder når du skal begynne med dekryptering. Fra "rtl_433 -R help" finner du f.eks. [104] Wireless M-Bus, Mode C&T, 100kbps (-f 868950000 -s 1200000) Der det også er angitt abefalt frekvens og symbolrate ettersom det aviker fra default. F.eks noe ala rtl_433 -f 868950000 -s 1200000 -R 104 -F json -M level og det burde etterhvert dukke opp json-formatterte meldinger i "topic" med innhold ala det jeg postet her tidligere, der "data" fremdeles er kryptert: { "time": "2021-11-18 17:18:55", "model": "Wireless-MBus", "mode": "C", "M": "KAM", "id": 76845462, "version": 27, "type": 22, "type_string": "Cold Water", "C": 68, "data_length": 41, "data": "2a442d2c625484761b168d2a0114b76522cbaa96817c787f3183f757807e0a2fecf5a6ac0c35e3cd19d027", "mic": "CRC", "mod": "FSK", "freq1": 868.93299, "freq2": 868.95712, "rssi": -1.52101, "snr": 12.20334, "noise": -13.7244 } Når du får det til å virke så langt så er det på tide å fikle med dekryptering. Da tror jeg det er https://github.com/weetmuts/wmbusmeters som gelder Du kan bruke "rtl433" som device, evt med flere parametre om nødvendig.Eller "rtlwmbus" hvis du heller vil det. Det er eksempler i README.md i wmbusmeters. Ellers har jo Google en del tips og triks å komme med som vanlig. Dette ser f.eks ut som et bra sted å starte: https://the78mole.de/wmbus-meters-and-how-to-get-it-into-home-assistant/ Det er i prinsippet "bare" å mate dekrypterte målinger som json fra wmbusmeters til mosquitto_pub. Når du først har dataene i et topic i MQTT så kan HA konfigureres med de MQTT sensorene du har lyst på. Jeg har ikke noe bedre forslag. Blir nok en del fikling. Men det er jo det som er gøy med slike prosjekter 😉