Bjørn Mork

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?

Mye nyttig lesestoff her: https://powerforum.co.za/topic/14238-extracting-axpert-firmware-using-jtag/ Ikke minst ville jeg tenkt litt over det der med mulig passord-beskyttet flash. Ikke sikkert dette er så rett fram som det kunne virke som?

Vel, jeg kan ingenting om dette men er en kløpper på synsing unasett. Er CN7 normalt i bruk til noe? Ellers ser det veldig ut som en TI JTAG-kobling ala https://www.segger.com/products/debug-probes/j-link/accessories/adapters/14-pin-ti-adapter/ Og i følge datasheet for CPUen så befinner JTAG-pinnene seg i hjørnet nærmest denne kontakten, så det er en sannsynlig plassering. Burde være mulig å få tilgang til flash via denne. For noen som vet hva de gjør ihvertfall. Ikke meg....

Usikkerhet mht hvor ofte/raskt strømmen kan endres er litt av grunnen til at jeg valgte å starte med 5-minutters intervaller og 2A trinn. Det forholdsvis få endringer. Og i praksis er det altså godt nok, selv om det åpenbart betyr at maks strøm er "feil" i kortere perioder. Jeg kjører omtrentlig samme script mot Amina S med 5k tariff på hytta. Det har også funket greit det lille jeg har fått testet.

Der har du meg også. Tid/ork/vilje - mangelvare alt sammen. Vet at mange har langt mer fornuftige strategier, bla med ubegrenset forbruk i starten av timen osv. Men min erfaring så langt er at det ikke er så veldig nøye hvis du aksepterer litt slakk. Det funker faktisk helt greit med en primitiv sjekk av øyeblikkseffekten hvert femte minutt. Jeg sikter på 10k-grensen og runder av ladestrømmen nedover i 2A-intervaller. Og treffer gjerne på rundt 9,5k helt uten å vurdere snittforbruket. Ikke viktig for meg å komme særlig nærmere. Har ikke ryddet i dette (ref tid/ork/vilje), men det er kanskje til inspirasjon likevel.... '1732307480710': alias: Elbil-lader sequence: - alias: Verify car is connected condition: not conditions: - condition: state enabled: true entity_id: sensor.hjemmelader_charger_mode state: Disconnected - alias: Calculate available current variables: tariff_limit: 10000 available_a: '{{ (tariff_limit - states(''sensor.ams_be44_p'') | int + states(''sensor.hjemmelader_charge_power'') | int ) / 240 }}' - alias: Turn off if less than 6A is available if: - condition: or conditions: - condition: state entity_id: input_boolean.elbil_lader_enable state: 'off' - condition: template value_template: '{{ available_a < 6 }}' then: - if: - condition: state entity_id: switch.hjemmelader_charging state: 'on' then: - target: entity_id: switch.hjemmelader_charging data: {} action: switch.turn_off - stop: Not enough power available - alias: Convert current to 2A steps and 32A max variables: available_a: '{{ min(32, (available_a / 2) | int * 2) }}' - alias: Turn on if necessary if: - condition: state entity_id: switch.hjemmelader_charging state: 'off' then: - target: entity_id: switch.hjemmelader_charging data: {} action: switch.turn_on - delay: hours: 0 minutes: 1 seconds: 10 milliseconds: 0 - alias: Check if max current should be changed condition: not conditions: - condition: template value_template: '{{ available_a == states(''number.hjemmelader_charger_max_current'') | int(0) }}' - condition: state entity_id: sensor.hjemmelader_charger_mode state: Charge done - alias: Update max current entity_id: number.hjemmelader_charger_max_current data: value: '{{ available_a }}' action: number.set_value icon: mdi:car-electric mode: single "sensor.ams_be44_p" er øyblikkseffekt fra et amsleser.no HAN-adapter. "*.hjemmelader_*" er sensorer/switch/input fra zaptec custom_component mot en eldre Zaptec Home. "input_boolean.elbil_lader_enable" er bare en input jeg bruker for å styre når ladingen skal skjer (manuell, eller evt basert på pris). Grunnen til forsinkelsen i tilfelle jeg må slå på ladingen er at det tar ganske lang tid før "charger_mode" oppdateres etter dette. Og jeg har den sjekken av "charger_mode" for å unngå unødvendige endringer av charger_max_current. Lite vits i å oppdatere når bilen er ferdigladet Trigger scriptet med time_pattern eller ved endring av enable-inputen ala: trigger: - platform: time_pattern minutes: /5 - platform: state entity_id: - input_boolean.elbil_lader_enable Langt fra noen perfekt løsning, men den har vist seg å være god nok for meg.

Det der minner ikke rent lite om

Meater antar jeg. Kan også brukes uten app/sky med f.eks. en esphome BLE proxy i nærheten av komfyren. Se https://community.home-assistant.io/t/support-for-meater-true-wireless-cooking-thermometer/513156/28 Det er vel funksjonalitet du får i mange induksjonstopper? Se f.eks Litt mer usikker på den. Pizzaen skal vel helst stekes på høyere temp enn de fleste stekeovner takler. Og det sier seg selv at det blr en kortvarig seanse der du helst bør følge med uansett. Synes ikke som et optimalt mål for automatisering. Er nok bedre å la automatikken ringe til nærmeste pizzasjappe 🙂

Tviler ikke. Men hvordan skiller det seg egentlig fra en hvilken som helst annen smarthub du får kjøpt?

Ikke bare er det uforståelig, men prismodellen har også motsatt effekt av det som burde være ønsket. Hvis du først er over terskelverdien så har du ingen incentiver for å spare lenger. Da er videre overforbruk "gratis" inntil neste terskel. Og det spiller ingen rolle når du legger dette overforbruket, så du kan like gjerne ta det ut kl 16:00 på en kald dag (jada, strømprisene vil ofte hjelpe, men plutselig en dag sprenger du nettet fordi det er passe mye vind i Tyskland).

Jepp. Beregning og fordeling av lasti et nett med mange noder og mange linker er ikke en rett-fram oppgave. Dette er ikke unikt for strøm. De har det samme for vann, kloakk, Internett, veger osv. Men jeg er ganske sikker på at netteierne har folk og systemer som er gode på den statistikken. Og dette er også et sted der AI kanskje kan gi mer enn bare hype. Her har vi massive datamengder og nokså umiddelbar feedback med fasit. Burde passe perfekt. Den store utfordringen er nok å designe et system som får hver enkelt til å oppføre seg optimalt. Det kan ikke bli for komplekst. Der tror jeg allerede dagens nettleie-system er over grensen for gjennomsnittsforbrukeren. Og det kan heller ikke være basert på fullautomatisering av alle hjem. Det er helt urealistisk. Jeg har ingen fasit. Men jeg innbiller meg at det ville være bedre med flere og større forskjeller gjennom døgnet enn dagens natt- vs dag-priser. En vekting av nettleien basert på døgnstatistikk for et passende område f.eks. Uten den, for folk flest, helt uforutsigbare terskelverdi-straffen. Den bidrar mulgens til at noen få tenker over hvor mange storforbrukere de slår på samtidig. Men jeg tror heller den får flere til å f.eks fordele elbilladingen utover en større del av døgnets timer. Og det er neppe gunstig i et større perspektiv. Da havner bare flere av de timene i de mest belastede periodene.

Usj, nyere version med mer massering av resultatet tydeligvis. Da er det jo umulig å vite om det er en feil i deres parsing eller om du faktisk mangler 5G. Men de har kanskje en support-kanal som kan svare på slikt? Uansett hvordan det henger sammen så må det vel defineres som en feil. Jeg aner ikke hva som er på innsiden av en slik eller hva den normalt vil si. Men det er rimelig å forvente at den skiller mellom 4G og 5G NSA på en slik måte at den kan fortelle deg om du "har 5G"

Har heller ingen erfaring med Teltonika utover at de virker nokså ryddige av seg. Det skjermbildet ditt var mystisk likt eksempelet på https://wiki.teltonika-networks.com/view/RUTX50_Network Er jo kanskje litt rart at de viser fram et 4G skjermbilde når ruteren støtter 5G? Vet ikke om det hjelper noe eller om det bare er den samme informasjonen presentert som tekst, men de dokumenterer også noen CLI-kommandoer du kan bruke: https://wiki.teltonika-networks.com/view/Command_Line_Interfaces https://wiki.teltonika-networks.com/view/Gsmctl_commands gsmctl ser ut til å være en wrapper de har laget rundt en del vanlige modem-kommanoer. "gsmctl -F" og "gsmctl -K" ser spesielt interessante ut. Eksemplene tyder på at de bare er enkel wrapping av Quectel-spesifikke AT-kommandoer. Du finner igjen +QNWINFO og +QENG i Quectels AT kommando-manualer. For eksempel ser dette slik ut på en Zyxel NR7101 (som har et lignende modem) oppkoblet mot 5G NSA: root@NR7101:~# atcmd /dev/ttyUSB3 'AT+QNWINFO' +QNWINFO: "FDD LTE","24201","LTE BAND 7",3150 +QNWINFO: "TDD NR5G","24201","NR5G BAND 78",643296 OK Merk at det er to linjer med NSA. Mulig feilen ligger i hvordan Teltonika parser dette? Men kunne jo være underholdene å se hva "gsmctl -F" sier. Tilsvarende forventer vi noe slikt fra "gsmctl -K": root@NR7101:~# atcmd /dev/ttyUSB3 'AT+QENG="servingcell"' +QENG: "servingcell","NOCONN" +QENG: "LTE","FDD",242,01,319DB05,51,3150,7,5,5,81A2,-89,-12,-58,11,8,-20,- +QENG: "NR5G-NSA",242,01,41,-78,16,-10,643296,78,12,1 OK

Du kan ha høy strømpris pga spekulasjon eller produksjonsutfordringer uten at det er kapasitetsproblemer i nettet. Og motsatt kan det godt tenkes at ditt lokale nett blir overbelastet når alle skal lade elbilen sin på negativ strømpris midt på natta. For oss som bor i et vannkraftland gir det mye mer mening med variabel nettleie enn variabel strømpris. De ekstreme prisforskjellene som skapes av det mislykkede markedseksperimentet skaper nok mer trøbbel for netteierne enn de vil ut med.

Helt sikker på at den ikke er på 5G? Husk at NSA betyr at du primært er koblet opp mot 4G og bare bruker 5G-bånd i tillegg når båndbreddebehovet tilsier det. Telefoner er svært så aggressive med å kalle dette 5G i displayet, av markedsføringshensyn. Er ikke sikkert Teltonikaen er like ivrig. Hva sier egentlig Teltonikaen? Og hvordan har du konfigurert den? Er ikke sikkert alle bånd er tilgjengelige. Hvis du har valgt å låse til f.eks. n78 på 5G så kan du fort ende opp med 4G i stedet selv om lavere 5G-frekvenser er tilgjengelige

Jeg skulle gjerne visst hva som var poenget med det. Det er svært få kurser jeg kunne tenke meg å slå av og på automatisk. Selv om jeg virkelig legger godviljen til, så er det bare elbillader, varmtvannsbereder og platetopp jeg ser at det har noen som helst nytteverdi. Men for elbiillader er det helt åpenbart mye bedre å ha en smart lader der du også kan styre ladestrømmen. Skal du først bruke noen tusenlapper på å gjøre elbillading smartere så bytter du ut ladeboksen. For platetopp ville den eneste praktiske funksjonen (for min del ihvertfall) vært som en sentralisert komfyrvakt. Det er forsåvidt nyttig nok. Men da må løsningen inneholde direkte sensor-tilkobling og logikk for utkobling uten at noen smarthub er involvert. Uten det må du jo ha en ordinært komfyrvakt i tillegg, og da kan du like gjerne gjøre den smart. Så slapp du dobbelt opp med releer og måler på den kursen også. Ønsker uansett ikke automatisk utkobling basert på annet enn sikkerhet. Da hadde vi VVB igjen. Der er et rele i sikringskapet like bra som de andre av dagens ettermonterte puck-løsninger. Men for nye installasjoner vil jo en smart VVB åpenbart være mye bedre. Jeg har utelatt oppvarming. Med panelovner og elektrisk gulvvarme er det bedre med styring og måling på hver varmekilde separat. Vannbåren varme med elektrisk fyring har nok egen kurs, men er ikke noe jeg ville styrt med utkobling av strømmen. Du har gjerne varmepumpe(r) og en god del sensorer koblet direkte til det systemet, med sin egen halvsmarte styring Tar gjerne mye bedre smarthus-integrasjon av målinger og og styring enn jeg har i dag. Men å slå hele sulamitten av og på med en ekstern strømbryter er uaktuelt. Det hadde nok vært gøy med målinger per kurs med Elkos smarttag eller tilsvarende. Men jeg er usikker på nytteverdien ifm automatisering. Det er nyttig å vite hvor mye elbil og VVB trekker, og relatere dette til totalforbruk. Men hvis du allerede har elbillader og VVB-puck med målinger så blir det jo smør på flesk med måling i sikringsskapet. Så hva skal jeg egentlig med noe i sikringsskapet?

Det er som sagt en ukjent protokoll på 868 MHz, så det er ikke hverken enklere eller vanskeligere enn med alle andre trådløse røykvarslere. Zigbee varslingen utløser neppe noen lyd. Den er bare for apper og automatisering

Humor: Noen har byttet ut MASTER med PRIMARY i både papirmanualen og de små klistrelappene som følger med (og som du ikke trenger når du bruker zigbee). Er vel samme sykdom som gjør at alle mysql-slavene har blitt replikanter elns. Jeg føler for å få inn en bladerunner.

Var ganske sikker på at det virket ettersom seriekoblingen er tradisjonell RF-seriekobling på 868 MHz, som for de aller fleste andre trådløse røykvarslere. Zigbee brukes til automatisk konfigurasjon av sammenkoblingen, men er ikke en del av kommunikasjonen mellom varslerne. Tror kanskje ikke de kommuniserer noe som helst seg i mellom. Sannsynligvis setter de bare opp en felles nøkkel basert på de konfigurerte "iasCieAddr" og "zoneId" verdiene. Men det er jo en god idé å teste at dette virker. Gjort nå. Funker som antatt helt fint. Jeg stoppet z2m og plugget for sikkerhets skyld ut koordinator-donglen. Alle varslerne ga fremdeles lyd når jeg trykket test-knappen på en av dem. Leenge - dokumentasjonen sier 10 sekunder. Det tar ikke nødvendigvis fullt så lang tid, men det er en merkbar forskjell i forsinkelse mellom de 4 varslerne jeg har montert. Gjetter på at varslerne sover ganske tungt og bare våkner opp en gang i blant for å lytte etter alarmer.