frodegill

Jeg poster strømpriser til public MQTT server, FWIW.

Kortet gir ikke strøm - det krever strøm. Du kobler 3.3-5V og GND til f.eks tilsvarende pin på ESP, og TX fra kortet til en eller annen datapin på ESP. I tillegg kobler du en ledning fra HAN inn på en av MB_A, og den andre ledningen fra HAN inn på en av MB_B.

Å hente data maskinelt fra Nordpool er ikke i gråsonen - det er eksplisitt ikke tillatt. Jeg har laget litt kode som henter strømpris fra ENTSO-E og valutakurs fra exchangeratesapi.io , og publiserer dette bl.a. på et MQTT-endepunkt. Topics m.m. er dokumentert på https://gillhub.org/index.php?view=article&id=8&catid=21 .

Jeg har etterhvert testet meg gjennom en god del mesh-systemer, og er vel egentlig særdeles skuffet. Har vært gjennom 4 noder ASUS AIMesh, 3 noder TP-Link Deco M9, 3 noder Freemesh før jeg har endt opp med 3 noder (men behov for flere) D-Link COVR. Alle systemene har vært satt opp med kablet backbone. Det gjennomgående problemet er at mobiltelefoner lett hopper av én node, men klarer så ikke å koble på neste node - og ender da enten opp enten uten fungerende nettverksforbindelse eller at trafikken styres over på datamålt 4G.

Hva sier `lsusb` både med og uten enheten plugget inn, og hva sier `sudo dmesg`?

Vet ikke om det er relevant, men i min ENTSO-E-kode har jeg fått dette i loggen de siste dagene: "Tag mismatch in line 8 column 6". Riktig pris kommer inn etterhvert. Jeg har lagt inn kode som skal logge selve XMLen hvis parsing av den feiler, men inntil feilmeldingen dukker opp igjen kan jeg bare spekulere i at ENTSO-E av og til sender ut invalid XML.

Sett Publish Topic til "meter/import" (uten innledende path separator). Jsonpath i klienten er jo helt avhengig av hva som sendes. Har du en Json som ser noe slik ut: { data: { "P": <verdi> } } vil det være korrekt å bruke data.P som Jsonpath. I Node-Red er jeg da vant til å bruke msg.data.P, men det er godt mulig systemet du benytter da vil ha det på formen $.data.P Merk at meldingen godt kan inneholde mere, f.eks { "foo": "bar", data: { "P": <verdi>, "Q": <annen verdi> } } Jsonpath for P-verdien vil da være $.data.P , og Jsonpath for Q-verdien ikke uventet vil være $.data.Q

Litt usikker på hva det er du trøbler med. Hvis du vil ha litt mere eksempler, kode og kommandoer kan du gjerne leke litt med min MQTT for strømpriser med mere. MQTT topics er dokumentert her , og helt nederst på siden står også en kommando (mosquitto_sub) og eksempel på hvordan du kan bruke denne for å motta MQTT-data. Selve dataene er en JSON, og jsonpath sier bare noe om hvor i json-strukturen du er interessert i data fra. Hvis du er interessert i C++-koden som dytter ut json til MQTT-serveren min finnes den her .

Har du vurdert SVG? Jeg har laget litt kode for SVG, som bl.a inkluderer litt grisete javascript for å finne tidspunktet i norsk tidssone. Du kan sjekke template for SVG, C++-koden og siden der SVG blir lagt inn som object (img-element kjører ikke javascipt).

Målet er å få ting over på en wESP32 (med kablet nett og PoE) (men da må nettverksstack'en byttes ut)

Av og til (tre ganger til nå) har min falt så grundig av nett at kun en reflash har løst problemet. Regner med at et eller annet overskriver enten konfigurasjonen eller wifi-koden. Har tatt en kodegjennomgang uten å finne plausible kandidater, men det er jo også mulig at problemet ligger inne i selve systemet (benytter en NodeMCU)

Tja, hadde det bare stemt. I følge dem virker det som om eksisterende avtale begrenser salg til 1000kr/år, og har bare en diskret "Historiske avtaler vil gjelde ut kalenderåret 2021" i bunnen av teksten. Med min Tibber-avtale har jeg eksportert for over 5000 kr til nå i år.

Jeg skjønner utmerket godt at Tibber gjør dette for fortjenesten sin. Problemet deres er jo at de opererer i et marked det er veldig lett å flytte over til konkurrentene, og nå har de gjort en grei avtale om til en dårlig avtale (og er tydeligvis veldig klar over at plusskundene deres kommer til å flykte. Selv om de tar ekstra betalt for opprinnelsesgaranti og sertifisert kraft, kan de i følge den nye avtalen ikke lengre garantere at strømmen de leverer ikke kommer fra f.eks engelske kullkraftverk). Den gamle avtalen var 1Kr/KWh første 1000KWh, og så spotpris. Det var aldri en problemstilling med spotpris > 1Kr/KWh, men jeg kan ikke tenke meg at de da ville satt pris=1kr og ikke pris=maks(spot,1kr) Uansett: Dette året, frem til senhøsten, var et ganske normalt strømår. Bildet under viser spotpris for de fem norske sonene siste fire måneder, og jeg har lagt gul bakgrunn på det som overstiger 1Kr/KWh. Selv om avisene har brukt krigstyper og folk er desperate, har spotpris faktisk ikke vært langt over 1Kr/KWh ofte. Ser vi på strømproduksjonen fra solcellepanelene mine må jeg faktisk litt ut i mai før de passerte årets 1000KWh overproduksjon (feb:22, mars:261, april:678), og det aller meste av overproduksjonen, som selvfølgelig er på sommeren, har blitt solgt til spotpris på ca 50 øre. Jeg har ikke inne spotprisen for starten av året, men avtalen Tibber hadde var fordelaktig for meg, og endringen deres gjør at jeg selvfølgelig shopper rundt. Det ville jo vært idiotisk å bli værende i en så dårlig avtale når konkurrentene tilbyr noe bedre?

De første 1000KWh. Årlig.

Jeg skjønner virkelig ikke hva du vil frem til med meldingene dine, men jeg kan godt fortelle deg om én enkel måte å spare 3000-4000 kroner (i et 10 års perspektiv). Hvis du har andre enkle måter for dette er det bare å poste dem her eller ta direkte kontakt.