bearer

Endra like godt området til grafen til å kun være 48h og justert mot slutten av neste dag, da vil det det ikkje være behov for å fylle med med gårsdagens pris og kan beholde gjennomsiktigheten. Men om noen finner en måte å kombinere serier på lytter eg gjerne. En av grunnene til eg ville beholde 72h var at eg da fikk ticks på midnatt; tidlighere ignorerte grafen tickAmount for X, som nå plutselig virker. graph_span: 48h span: end: day offset: +24h apex_config: xaxis: tickAmount: 2 edit: .. ved midnatt var det kanskje ikkje en like god ide, null historikk, 24h strømpris og 24h blank graf.

Er det mulig å unngå overlappingen som gjør at gjennomsiktigheten blir litt feil her? Har slått sammen today/tomorrow for å slippe å ha egen serie med I dag og i morgen, som bare heiter strømpris. data_generator: | return [].concat( entity.attributes.raw_today.map((p) => { return [new Date(p.start), p.value];}), entity.attributes.raw_tomorrow.map((p) => {return [new Date(p.start), p.value];})) Men får ikkje heilt til å slå sammen med strømprisene som kommer fra serien uten data_generator, og legger eg til en ekstra serie så overlapper det på dagen i dag. Har nokken inspill her? Eg kan alltids fjerne gjenommsiktigheten, men er det da mulig å skjule navnet på serien som nå heter "(skjul meg?)"

litt klønete wiki ja, men det er flere sider, eller det er det hvertfall nå. - https://github.com/toreamun/amshan-homeassistant/wiki/Lesere-MQTT - https://github.com/toreamun/amshan-homeassistant/wiki/Konfigurering-i-Home-Assistant burde hjelpe andre som kommer siden

Ja, omsider fått satt meg ned og ordna lokal mqtt her også; har tibber nokke ønske eller policy om å motta en "kopi" av datastrømmen? Tviler egentlig på at eg forblir Tibber kunde, men vil tru Tibber er interessert i dataene fra kundene som går fra sky til lokal mqtt?

Ang helligdager funnet noe svar på det? Er vel ei veke sida eg spurte lokal nettselskap om det samme men ikkje noe svar enda. (btw, takk for at du delte apexcharts-card oppsettet)

Hm, nei, har nok missforstått den biten. (Det er tibber sine sensorer, har bare omdøpt dei fjerna adresse og kalla både strøm og spenning l1/l2/l3) Fjerna og venter i spenning på neste gang tanken slår inn. (Litt grønn på dette, men det er vel inn i tiden med grønt skifte så det får gå seg til:)

D'oh. Ja, da får hvertfall 0 ut enn så lenge. Om det kun er om L1 og L2 overstiger 12A så vil det kun fange opp faktisk varmtvann, om eg trenger det mer nøyaktig enn 3kW er det vel bare å bruke spenning og nominell motstand i elementet +/5v er vel rundt regnet +/-100w, så kanskje noe å sjå på om det funker. Får la det snurre en dag eller to og sjå om det ser greit før evt ser på å gjøre W om kWh for statestikk. edit: so far so good

Er det noen som har brukt Tibber sine L1/L2/L3 målinger til å fange opp f.ex. varmtvann? Det er eneste last på både L1 og L2 som trekker 3kW, så det burde være mulig å skille ut, men litt fersk i template gamet. Tenkte noe ala under, men får bare "Unavailable" edit: template: - sensor: - name: varmtvann_effekt unit_of_measurement: "W" state_class: measurement device_class: power state: > {% if states("sensor.current_l1")|float > 12 %} {% if states("sensor.current_l2")|float > 12 %} {{ (((states("sensor.voltage_l1")|float+states("sensor.voltage_l2")|float)/2)*((states("sensor.voltage_l1")|float+states("sensor.voltage_l2")|float)/2)/17.63)|round(0) }} {% endif %} {% else %} 0 {% endif %} sensor: - platform: integration source: sensor.varmtvann_effekt name: "Varmtvann(kWh)" unit_prefix: k round: 1 Ser ut til å virke som tiltenkt all den tid det ikkje andre laster som får l1 og l2 over 12A - noe som ikkje har skjedd siste 14 dagene hvertfall. Opphavet fekk fast installasjon på ny bereder så i påvente av evt Shelly Pro 2PM får dette duge inntil videre.

Da er alt ordna, men tar sikkert litt tid før det er main-steam. Bruke "bleeding edge" fikser pulse counter/hlw8012 til effektmåling og og legge config under fikser ble tracker under esp-idf. esp32: board: esp32-c3-devkitm-1 framework: type: esp-idf sdkconfig_options: CONFIG_BT_BLE_42_FEATURES_SUPPORTED: y Husk å flashe c3 modul før den loddes inn siden rele1 har pull-down der en trenger pull-up for å få til flashing.

Okay, ett steg nærmare. Det om var IO15 heter nå IO08 og denne må være 1 ikkje 0 for å få flasha. IO0 har blitt til IO9 og denne skal fremdeles være 0. Det som nå er IO8 har intern pull-up, men iiglo kortet har en mindre pull-down på kortet så den vinner. Modulen starter uavhenig av IO8 så lenge IO9 er høy så det burde funke gitt den er flasha før den blir installert. Relè og USB virker, men hlw8012 skaper utfordringer med kompileringsfeil. Bluetooth ser ut til å virke dog! Samme gjør OTA etter den er tilbake på iiglo kortet (med Arduino framework som siste config over) Usikker om eg er villig til å offre effektmåling for bluetooth enn så lenge blir det nok bare den ene på benken.

D'oh .. skulle kanskje sjekka litt nøyare ... ESP32-C3 er ikkje heilt samme sak som ESP32. Ser ut som tasmota har binærfiler men trur det får ligge på hylla til esphome er litt meir klar. Men den passa nå på footprint i det minste Edit: Hm, får bygga denne hvertfall - får prøve flashing en annen dag. esphome: name: powerstrip-c3 esp32: board: esp32-c3-devkitm-1 framework: type: esp-idf version: recommended variant: esp32c3 wifi: ssid: !secret iot_ssid password: !secret iot_password domain: !secret iot_domain logger: api: ota: Dammit, legger til ble så svikter det. Dette må nok modnes litt ja https://github.com/esphome/issues/issues/2648 Ser også ut som at en må flashe over uart om en legger til ble, så ikkje noe poeng i å få det opp med kun wifi i første omgang. edit2: denne lar seg bygge med ble, men må grave litt i hva som gjorde at eg ikkje fikk flasha c3 etter den var lodda på iiglo kortet. esphome: name: testing platformio_options: platform_packages: - framework-arduinoespressif32 @ https://github.com/espressif/arduino-esp32.git#2.0.1 platform: - https://github.com/platformio/platform-espressif32.git#feature/arduino-upstream esp32: board: esp32-c3-devkitm-1 framework: type: arduino variant: esp32c3 esp32_ble_tracker:

Eg har bestillt denne https://www.aliexpress.com/item/1005002760799398.html (4M-12F) til test, men reel mulighet for at det tar bokstavlig talt både vinter og vår! (Kilde som omtaler kompatibilitet https://www.cnx-software.com/2021/04/24/ai-thinker-esp32-c3-modules-compatible-esp8266-esp32/ Eg har ikkje finlest om det funker siden ikkje har noe skjema til iiglo allikevel blir det bare å ta en test) Lodde sammen var greit, alle krevde at eg tvinnet sammen kordelane igjen for å få jordleder av - men med Weller WMRT micro tweezers var det greit skuring; men eg hadde nok slitt uten den. Tinnsuger til å gjøre hull rent og tang til å kaldforme ledere kan kanskje hjelpe med å få dei tilbake på plass om en ikkje har slik luksus som WMRT. Men ja, eg bestiller neppe flere. Edit: lekte litt med tanken om å legge frem en 4pins kontakt for fremditig recovery om OTA svikter; lodde kontroll for uttak nr 2 til en annen pinne burde være overkommelig. Får ta og teste det i samme slengen som ESP32. Edit2: ESP32-C3 dukka opp i dag, størrelsen passer, får sjå om eg får bytta og flasha i romjula:)

Stor takk til thoj som beskriver flashing og demontering her. Eg flasha ein "liten stabel" nylig, den første var kjempe enkel å lodde av jordleder på, men resten var svært varierende. Veldig greit å slippe å være avhenig av skyløsningen! Noen som har prøvd å bytte hele esp8266 modulen med en ESP32-C3 som er tilgjengelig i moduler som muligens er pin-kompatible med esp8266? Å få til BLE gateway i tillegg til forgrener og usb lader ville heva produktet noen hakk.

Om du benytter RJ45 på ESP kortet ditt så står du jo fritt til å definere hvilke pinner du bruker til hva. Ser ikkje helt hvordan du skal kunne benytte pinnene i måler enden til noe som helst utover å lese m-bus.

mkay, bare stussa på at det skulle være nødvendig med software serial, men om problemet låg andre plasser er det en annen sak. logger: hardware_uart: UART1 uart: id: uart_bus tx_pin: GPIO15 rx_pin: GPIO13 baud_rate: 2400 Burde fjerne behovet for software serial, med log output på GPIO02, bootloader og flashing på vanlig tx/rx og når esp har bootet bytte til å kjøre uart på GPIO15/GPIO13 mot mbus. har ikkje mottatt mbus-ttl adapter enda, men tenker skal teste ved anledning. esphome godtar hvertfall config

nice! Hva som gjorde at du måtte ty til software serial på esp8266? Er det ikkje mulig å enten be esphome logge til UART1 eller bruke Serial.swap() for å komme bort fra pinnene som er knyttet mot usb-ttl og bootloader?

Derfor eg heller mot en buck konverter som er styrt av en microkontroller som også kan ta seg av jobben å være buffer for seriedata og vekke opp radio eller esp når det er nok data og energi tilgjengelig. Men stopper litt opp i påvente av bedre måleustyr.

Undres om wifi rekkevidden påvirkes av å ha baner og eller jordplan foran?

Vil fortsatt trenge tilstrekkelig kondensator som til føre til ganske store oppstartsstrømmer, og potensielt trøbbel med brownout ved oppstart; og man må bruke kode for å justere intervall til å holde seg innenfor budsjett for aktuelle måleren. Litt mer jobb, men buck converter styrt av en attiny med softstart som måler bus spenning og justerer lasten der etter for å aktivere en vanlig linær ldo regulator når man har akkumulert nok energi. Kommer til å pusle litt med det når eg får bestillt meg en micro current gold type måler

Hehe, samme konklusjon her - stoppa opp i påvente av bedre måleutstyr til små strømmer

Det vil funke med stor nok kondensator bare man holder gjennomsnittlig forbruk under tilførselen. Eg forstod det sånn at Tibber slet på enkelte målere og skulle løse det med å øke intervallet på rapporteringen for å slippe ekstern power ja, men data må tas i mot uansett. TSS721A vil kunne gi max 650uA om eg leser datablad rett, side 7. ICC Supply current (VSTC = 6.5 V, IMC = 0 mA, VBAT = 3.8 V, RRIDD = 13 kΩ) 650 µA

Eg tenkte å bruke samme TSS721 chip til å enten lade supercap direkte, eller bruke 3.3v fra TSS721 til å drifte en attiny som kun har til jobb å lade supercap ut i fra en MPPT algoritme eller noe, og prøve å holde track på hvor mye energi som kommer inn og starte opp en ESP i jevne intervaller ut i fra det. Slow progess.

Mye bra lesing her, og veldig trist å lese om bortgang av ildsjelen. Eg er i samme båt som alle som etterspør å få til noe som kan drives rett fra HAN porten, og heller mot å prøve meg på en TSS721 som forsyner en mikrokontroller som styrer en switch mode supply som bruker en eller annen voodoo til å spare opp nok energi for å skru på en litt mer effektslukende radio modul (antagelig arduino kompatibel atmel + ESP8266 for å gjøre det enkelt for andre å jobbe videre med). Ville helst unngå to mikrokontrollere men ser rett og slett ut til at TSS721 ikkje kan spare opp i nærheten av så mye energi som målerene vil gi ut og som vil trenges til hyppige sendinger; selv om eg er helt klart for å ofre oppdateringfrekvens for å slippe ekstern strøm. Har selv fått en av de mer generøse målerene som leverer rundt 500mW så det er jo 'masse', men hadde vært morro å få til en løsning som var mulig å tilpasse til tilgjengelig energi. Tenker eg forker git prosjektet og lager en ny tråd her for å fortsette diskusjonen etter eg har vært litt mer i tenkeboksen.