Bjørn Mork

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.