stigvi
-
Innlegg
2 650 -
Ble med
-
Besøkte siden sist
-
Dager vunnet
141
Innholdstype
Profiler
Forum
Blogger
Nedlastninger
Artikler
Regler
Hendelser
Galleri
Store
Innlegg skrevet av stigvi
-
-
Sandvik skrev (7 minutter siden):
På hvilken måte hjelper det svaret meg?
Sandvik skrev (7 minutter siden):men det kan umulig være årsaken
Hvis det er svarene til de som svarer på ditt spørsmål og deler sine erfaringer så forstår jeg ikke helt hvorfor du spør her.
Lykke til med dine valg ...... -
Hvorfor ikke bruke zigbee2mqtt? Gir det noen ekstra fordeler for deg å bruke noe som kommer direkte fra HomeSeer?
Bruker du zigbee2mqtt så er du sikker på å få det siste nye, og trenger ikke vente på at HomeSeer skal somle seg til å oppdatere den.Sandvik skrev (41 minutter siden):Jeg bruker en Conbee I USB stick for Zigbee
Denne er ikke mye god. Vil sterkt anbefale å skifte til bedre koordinator. Og gjerne en som støtter zigbee 3. -
For å lettere kunne følge med på varmtvannsforbruket har jeg lagt inn temperaturendring pr time. Den bruker Home Assistant sin trend integrasjon så lett å legge inn.
Energi i tank tar utgangspunkt i en temperatur som ikke skal under 50 grader. Så energi i tank viser null hvis temperatur er 50 grader.
-
SveinHa skrev (7 minutter siden):
Godt spørsmål... Jeg ville tro at en slik treflis har havnet i røret under bygging av ditt hus og ligget der siden dag 1... Slurvete rørlegger?
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.SveinHa skrev (13 minutter siden):Godt spørsmål... Jeg ville tro at en slik treflis har havnet i røret under bygging av ditt hus og ligget der siden dag 1... Slurvete rørlegger?
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.
-
SveinHa skrev (På 11.11.2023 den 9.57):
og da er kun den ene lederen spenningsførende og N lederen skal ikke brytes.
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. -
Olep skrev (10 timer siden):
ja, nordpool har jegDa 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 %}-
1
-
-
Olep skrev (4 timer siden):
Kanskje jeg ikke skjønner, men hvordan henter jeg strømprisen med strømstøtte inn i HA?Har du lagt inn Nordpool integrasjonen? Eller noe tilsvarende?
-
Olep skrev (2 timer siden):
Ble litt usikker på om denne guiden er fremdeles "up-to-date" ?
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.
-
MHR skrev (På 28.11.2022 den 12.14):
blant annet kWh per time, akkumulert aktiv import (f.eks 136,763.05 kWh)
Lag en mal-sensor som gir deg summen av disse to
-
OlavT skrev (1 time siden):
Sånn bare for å pirke i oss med en pinne?-
1
-
1
-
-
Tander skrev (1 time siden):
Her er løsningen for å hente ut værmeldingen som en attributt:
- platform: rest
resource: https://api.met.no/weatherapi/textforecast/2.0/?forecast=landoverview
name: textweather text
scan_interval: 180
json_attributes_path: '$.textforecast.time[0].forecasttype.location[?("Øst" in @["\x40name"])]'
value_template: '1'
json_attributes:
- '@id'
- '@name'
- '#text'I eksempelet ovenfor blir værmeldingsteksten lagt til attributt sensor.textweather_text.#text.
Attributten @name angir området og @id id-nummeret. Jeg har valgt å søke på områdenavnet og bruker "Øst" og "\x40name" i json_attributes_path, da dekkes både Østlandet og Østafjells avhengig av hva meteorologen velger å angi. Dersom det er ønskelig å søke på id-nummer i stedet byttes "Øst" ut med id-nummer og "\x40name" med "\x40id".
Deretter legger jeg værmeldingsteksten ut i flere sensorer, en for hver linje:
- platform: template
sensors:
weather_summary1:
value_template: >-
{% set t= (state_attr('sensor.textweather_text','#text') | wordwrap(42, true,"§")).split("§")[0] %}
{{t}}weather_summary2:
value_template: >-
{% set t= (state_attr('sensor.textweather_text','#text') | wordwrap(42, true,"§")).split("§")[1] %}
{{t}}osv..
I eksempelet over er lengden på tekstlinjen angitt i "wordwrap(42, true,"§")" hvor 42 angir antall tegn/lengde på tekstlinjen.
Takk. Den som venter på noe godt, osv .....-
2
-
-
Bjolliot skrev (57 minutter siden):
Løst. Tusen takk stigvi!
Så attributten heter temperature? Hos mine climate's (som er Nobø ovner) heter de current_temperature og jeg trodde dette var standardisert.-
1
-
-
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
-
1
-
-
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.-
3
-
-
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? -
Hårek skrev (8 timer siden):
mens på TN er det 3x 230V
3x400V
-
Hårek skrev (3 timer siden):
Ble nysgjerrig på hva det innebærer at ladeboksen støtter 3-fas IT? Trodde det bare er opp til bilen.
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.hakostra skrev (1 time siden):Hvor viktig er egentlig 3-fas lading på IT? Hvilke biler støtter det? Og gir det egentlig noen vesentlige fordeler over vanlig 1-fas?
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.
-
hellowlol skrev (59 minutter siden):
Hvorfor brukes ikke bare binary_sensor.workday direkte i template? Jeg har ikke testet, men jeg ser ingen grunn til at det ikke skal virke
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. -
Kim123 skrev (54 minutter siden):
Ville anbefalt å heller bruke en workday sensor. Så ser du bare om sensoren er ‘on’. Det arrayet må du huske å vedlikeholde å legge inn datoer. Slikt har en høy sannsynlighet for å glemmes
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.
stigvi skrev (3 minutter siden):Slikt har en høy sannsynlighet for å glemmes
Jeg bruker en todo liste til slikt som ikke skal glemmes. Minner meg på det hvert år.
Finnes det en enkel elbil-lader som kan styres fra Home Assistant i 2022? (skyfritt?)
i Annen Elektronikk
Skrevet
Ja, skulle ønsket meg 2 slike bokser enn disse forbaska easee boksene. Skytjeneste er faktisk så dårlig som vi advarer mot her.