stigvi

Det er en påstand jeg uansett ikke kommer videre med ovenfor rørlegger 🙂 Men vi merket plutselige endringer ganske nylig med lavt vanntrykk, rare lyder og varmt vann når vi tappet det kalde. Så jeg tror selv trebiten er ny. Vi får se hva det blir til. Rørlegger-regningen blir ikke enorm. Mulig hjemmeforsikring dekker det, men er usikker på om egenandel er for høy til at det har noen hensikt. Men det er jo mulig at trebiten har vært der hele tiden, men plutselig råtnet så mye at den kom lenger inn i ventilen.

Så har jeg hatt uventet nytte av temperaturmåling på VVB. Jeg så nemlig at temperaturen sank mye raskere enn forventet og hva det har gjort tidligere. Også når huset stod tomt. Hva skjer, tenkte jeg. Hjemme fra jobb gikk jeg selvfølgelig rett til vaskerom og kunne konstatere at vannrør helt til inntaket var glovarmt. Hvorfor i alle dager kommer det varmtvann helt ut her, var min tanke. Vi har et TEK17 hus med tilbakeslagsventil på vannet og ekspansjonstanker. Min umiddelbare tanke var at her må tilbakeslagsventilen være ødelagt. Huset er så nytt at jeg reklamerte ovenfor Block Watne og allerede dagen etterpå var rørlegger på plass. Etter en del styr med å løsne godt tilskrudde rørdeler, fant han en trebit i inntaket. Denne hadde kilt seg fast i tilbakeslagsventilen og satt den ut av funksjon. Det som da skjedde er at for hver trykkendring i det kommunale nettet ble kaldt vann presset inn i VVB sine ekspansjonstanker og varmt vann kom ut igjen når trykket falt. Selvsagt vil ikke rørlegger eller Block Watne betale for dette. Spørsmålet er om kommunen vil det? Noe jeg ikke tror selv........ Men temperaturovervåkning på VVB var det som gjorde at dette ble oppdaget forholdsvis raskt. I tillegg hadde vi masse rare lyder i vannrør / ekspansjonstanker, men vi klarte ikke å konkretisere hva dette skyldtes.

I Norge er det krav om 2-polt bryter uansett og også i TN-nett. Ingen unntak. Hvorfor det er et krav, det vet vel kun de som har satt det som et krav. Hvis en skal spekulere så kan det være for at reglene skal være uniforme og med minst mulig unntak. En annen grunn kan være at dersom en har feil i anlegget (brudd i jordforbindelse ved transformator) så kan også N-leder bli spenningsførende.

Da kan du regne ut støtten direkte i nordpool integrasjonen. Nedenfor ser du min konfigurasjon for "additional costs". Der blir støtte regnet ut og lagt i variabelen "pb" som blir trukket fra prisen. - platform: nordpool VAT: true currency: "NOK" low_price_cutoff: 0.95 region: "Kr.sand" precision: 6 price_type: kWh friendly_name: "Nordpool" additional_costs: >- {% set s = { "hourly_fixed_cost": 0.0, "night": 0.2926, "day": 0.4176, "cert": 0.02 } %} {% set helligdager = ["0101", "0501", "0517", "1225", "1226", "0328", "0329", "0401", "0509", "0520"] %} {% set pb = max((current_price - 0.875) * 0.9, 0.0) %} {% if now().isoweekday() <= 5 and now().strftime("%m%d") not in helligdager %} {% if now().hour >= 6 and now().hour < 22 %} {{(s.day + s.hourly_fixed_cost + s.cert - pb)|float(0)}} {% else %} {{(s.night + s.hourly_fixed_cost + s.cert - pb)|float(0)}} {% endif %} {% else %} {{(s.night + s.hourly_fixed_cost + s.cert - pb)|float(0)}} {% endif %}

Har du lagt inn Nordpool integrasjonen? Eller noe tilsvarende?

Nei, den er foreldet. Nå trenger en ikke estimere strømstøtte lenger. Den er jo gitt direkte time for time ut i fra gjeldende strømpris.

Lag en mal-sensor som gir deg summen av disse to

Sånn bare for å pirke i oss med en pinne?

Takk. Den som venter på noe godt, osv .....

Så attributten heter temperature? Hos mine climate's (som er Nobø ovner) heter de current_temperature og jeg trodde dette var standardisert.

https://github.com/kalkih/mini-graph-card#entities-object Du må lese dokumentasjonen for hvordan du skal lage en kurve ut i fra en attributt. climate.rom har en attributt som heter current_temperature

Jeg skal ikke blande meg inn i diskusjonen om hvor mye denne produsenten er å stole på. Det som derimot lyser opp mine varsellamper er produktet i seg selv. En bør være litt skeptisk til produkter som skal løse "alt" og som det finnes 1 eller svært få produsenter på. Hva om nå går til innkjøp av en rekke av disse, men dessverre trenger en å bytte ut 1 av de om noen år. Da må en krysse fingrer og tær og håpe på at dette produktet fortsatt er i salg. Sånn sett synes jeg det er bedre å bygge opp sin egen løsning med standard vare. Da finnes det alternativer hvis en trenger å bytte ut en komponent.

Ser også at det er en del støy i fra mcp9808 så et filter hjelper en del på det, hvis en vil begrense datamengden som logges i HA - platform: mcp9808 id: varmtvannstank_topp_temperatur name: "${devicename}_topp_temperatur" address: 0x1D filters: - min: window_size: 3 send_every: 1

Bare som en kommentar til formelen double v_t = diff_t + 0.00135 * id(temperatur_varmtvannsbereder).state - 0.03839286; For et par år siden målte jeg varmetapet i fra tanken ved forskjellige temperaturer. Og det er dette som er grunnlaget for formlene. Hvis jeg stiller inn settpunkt på 70 grader så får jeg altså nøyaktig den effekten som skal til for å holde temperaturen der hvis en ikke tapper varmtvann.

Litt usikker på hva som menes med "reclosing". Men hvis det er at de kan fjernstyres til å koble inn så tror jeg nok du sliter med å få dette "godkjent". Når sikringer kobles ut, er det for en god grunn. Å koble de inn igjen "automatisk" er ikke en lur ting å gjøre.

Den ene endringen har ikke noe med sensoren å gjøre. Jeg bruker en esp8266 og den klarer ikke 400kHz avlesningsfrekvens. Så jeg endte opp med standardverdien på 50kHz. For selve sensoren bruker de andre adresser: Topp er 0x1D Senter er 0x1E Bunn er 0x1F (Dette er altså for min 200l OSO sensor) Jeg har laget mitt system slik at jeg setter temperaturen til 50 grader i de periodene jeg vil spare strøm, men samtidig ikke ha lavere temperatur enn at det går å dusje. Så setter jeg temperaturen til 67 eller 80 grader når strømmen er billig og avhengig av om det er hverdag eller helg. Den nedre sensoren har lav prioritet så hvis den kommer under settpunkt, så varmes vannet med lav effekt. Den midterste sensoren har høyere prioritet og vannet varmes med litt høyere effekt. Og til sist, den øverste sensoren har så høy prioritet at effekten er 2kW dersom temperaturen har falt 1 grad under settpunkt. substitutions: devicename: Varmtvannstank esphome: compile_process_limit: 1 name: varmtvannstank on_boot: - priority: -100 then: - delay: 30s - homeassistant.event: event: esphome.boot data: message: "${devicename} Started" esp8266: board: esp01_1m restore_from_flash: false wifi: ssid: "HEIME5.ORG" password: !secret heime_wifi domain: .lan #captive_portal: # Enable logging logger: # Enable Home Assistant API api: reboot_timeout: 24h ota: script: - id: set_output mode: single then: - output.set_level: id: pwm_output level: !lambda |- double diff_t = id(temperatur_varmtvannsbereder).state - id(varmtvannstank_topp_temperatur).state; double diff_c = id(temperatur_varmtvannsbereder).state - id(varmtvannstank_senter_temperatur).state; double diff_b = id(temperatur_varmtvannsbereder).state - id(varmtvannstank_bunn_temperatur).state; double v_t = diff_t + 0.00135 * id(temperatur_varmtvannsbereder).state - 0.03839286; double v_c = diff_c / 20 + 0.00135 * id(temperatur_varmtvannsbereder).state - 0.03839286; double v_b = diff_b / 200 + 0.00135 * id(temperatur_varmtvannsbereder).state - 0.03839286; double v = min((id(effekt)/100.0), max(max(v_t, 0.0), max(v_c, v_b))); id(power).publish_state(v * 2.0); return v; globals: - id: last_value_from_ha type: int initial_value: '0' - id: effekt type: float restore_value: no initial_value: '100.0' number: - platform: template max_value: 100.0 min_value: 0.0 step: 0.1 id: effekt_varmtvannsbereder name: effekt_varmtvannsbereder unit_of_measurement: '%' initial_value: 100 optimistic: true set_action: then: - lambda: |- id(effekt) = x; - script.execute: set_output - platform: template max_value: 80.0 min_value: 5.0 step: 5 id: temperatur_varmtvannsbereder name: temperatur_varmtvannsbereder unit_of_measurement: '°C' initial_value: 60 optimistic: true i2c: sda: GPIO14 scl: GPIO4 scan: true status_led: pin: number: GPIO13 inverted: yes output: - platform: sigma_delta_output pin: 12 update_interval: 2.5s id: pwm_output state_change_action: - lambda: |- id(internalpower).publish_state(state ? 2.0 : 0.0); id(internalcost).publish_state(state ? 2.0 * id(current_energy_price).state : 0.0); sensor: - platform: homeassistant id: current_energy_price entity_id: sensor.nordpool - platform: wifi_signal name: "${devicename} WiFi Signal" update_interval: 300s - platform: mcp9808 id: varmtvannstank_topp_temperatur name: "${devicename}_topp_temperatur" address: 0x1D on_value: then: - script.execute: set_output - platform: mcp9808 id: varmtvannstank_senter_temperatur name: "${devicename}_senter_temperatur" address: 0x1E on_value: then: - script.execute: set_output - platform: mcp9808 id: varmtvannstank_bunn_temperatur name: "${devicename}_bunn_temperatur" address: 0x1F on_value: then: - script.execute: set_output - platform: total_daily_energy name: "VVB Total Daily Energy" power_id: power restore: false method: left accuracy_decimals: 2 filters: - throttle: 60s - platform: integration name: "VVB Total Daily Cost" id: vvb_total_daily_cost sensor: internalcost state_class: "total_increasing" time_unit: h unit_of_measurement: "NOK" restore: false integration_method: left accuracy_decimals: 2 filters: - throttle: 60s - platform: template id: power name: "Effekt varmtvann" unit_of_measurement: "kW" icon: "mdi:power-plug" accuracy_decimals: 3 - platform: template id: internalpower unit_of_measurement: "kW" update_interval: 1s accuracy_decimals: 3 internal: true - platform: template id: internalcost unit_of_measurement: "NOK" update_interval: 1s accuracy_decimals: 6 internal: true interval: - interval: 4h then: - if: condition: - lambda: !lambda |- auto time_now = id(homeassistant_time).utcnow(); if(time_now.timestamp - id(last_value_from_ha) > 600) return true; return false; then: - number.set: id: temperatur_varmtvannsbereder value: 60 time: - platform: homeassistant id: homeassistant_time timezone: "Europe/Oslo" on_time: - seconds: 0 minutes: 0 hours: 0 then: - sensor.integration.reset: vvb_total_daily_cost text_sensor: - platform: homeassistant id: watchdog entity_id: sensor.time on_value: then: - lambda: !lambda |- auto time_now = id(homeassistant_time).utcnow(); id(last_value_from_ha) = time_now.timestamp; binary_sensor: - platform: status name: "${devicename} Esp Status"

Holder på å implementere OSO sin sensor for 200l tank og ser det er noen forskjeller i forhold til det som er oppgitt her. Kommer tilbake til det i løpet av uken. Men det jeg lurer på: Er det noen som vet hvor på denne sensorstaven de 3 sensorene er plassert. Jeg vil tro den ene er plassert lengst mulig ned i sensorstaven, men hvor er de 2 andre?

3x400V

Lading av biler er normalt konstruert for TN nett for det er dette resten av europa bruker. Norsk IT nett er en "hack". Det er riktig at bilen må støtte dette og laderen må også ha støtte for det. Slik jeg har forstått det så får en ikke ekte 3-fase lading fra et IT nett. Ladeboksens nøytral må kobles til den ene fasen og så må boksens to av tre fase-innganger kobles til nettets to andre faser. En lurer da boksen til å tro den er på et TN nett der den ene fasen er borte. En har 230V mellom boksens nøytral og de to fasene. Mellom de to fasene er det også 230V. I et TN nett har en 230V mellom nøytral og fasene og mellom fasene er det 400V. Jeg kjenner ikke alle biler, men min, en e-Golf 2018 modell, har to ladere ombord og ved 3-fase kan den altså lade med dobbel effekt i forhold til 1-fase.

Det kan sikkert fint virke. Jeg bruker en sensor for kurs for euro til kroner i Entso som har samme system for mal. Men som nevnt ovenfor. Du må ha to workday sensorer, en for i dag og en for i morgen. Og så må du lage logikk for å teste på den ene eller den andre ut i fra tidspunkt som now() returnerer. Enn så lenge klarer jeg meg med en liste som jeg endrer en gang i året.

En workday sensor virker ikke til dette. I Nordpool integrasjonen er now() overstyrt og returnerer tidspunktene for denne og neste dag. Så da vil min kode gi riktig pris for neste dag. Riktignok kan en også lage en workday sensor for neste dag, men det blir uansett krøkkete å få dette inn i malen til nordpool og lage en pris for hver av 48 timer. Jeg bruker en todo liste til slikt som ikke skal glemmes. Minner meg på det hvert år.

Jeg vil anbefale Home Assistant. Men har ikke tid til mer skriving nå for å utdype........

Det ser ut til å virke greit når en tester det i mal-verktøyet

Hvorfor i all verden skulle de gjøre det???

Slik kan det bli med offentlige helligdager. Her mangler de bevegelige så det må en eventuelt legge inn. Obs!! Jeg har ikke testet dette så ta gjerne en kvalitetssjekk - platform: nordpool VAT: true currency: "NOK" low_price_cutoff: 0.95 region: "Kr.sand" precision: 6 price_type: kWh friendly_name: "Nordpool" additional_costs: >- {% set s = { "hourly_fixed_cost": 0.0, "night": 0.2926, "day": 0.4176, "cert": 0.02 } %} {% set helligdager = ["0101", "0501", "0517", "1225", "1226", "0328", "0329", "0401", "0509", "0520"] %} {% set pb = max((current_price - 0.875) * 0.9, 0.0) %} {% if now().isoweekday() <= 5 and now().strftime("%m%d") not in helligdager %} {% if now().hour >= 6 and now().hour < 22 %} {{(s.day + s.hourly_fixed_cost + s.cert - pb)|float(0)}} {% else %} {{(s.night + s.hourly_fixed_cost + s.cert - pb)|float(0)}} {% endif %} {% else %} {{(s.night + s.hourly_fixed_cost + s.cert - pb)|float(0)}} {% endif %}