HomeAssistant - Yleinen support topic
- Keskustelun aloittaja -ww-
- Aloitettu
-
- Avainsanat
- hassio homeassistant zigbee
Tuli pari halpista Tuya-zigbee kosteusanturia, alle 6€/kpl. Helposti asentu ja tuntuvat toimivan, heti kun näkee vettä, niin antaa märkää ilmotuksen. Patterin pitäs kestää ainakin vuosi ja on helppo 2032 litiumnappi. Jos noi jotain havaintoa aikastaa, niin ei ainakaan oo menny sijoitus hukkaan.
Toinen on nyt tiskipöydän alla ja toinen pesukoneen vieressä.
Toinen on nyt tiskipöydän alla ja toinen pesukoneen vieressä.
Itse itselleni vastaten:
Tolla Xtend Tuyalla sai kumuloituvan sähkönkulutuksen näkyville.
Sitten jos haluaa täysin reaaliaikaisen virrankulutuksen mikä Tuya appissa näkyy niin LocalTuyan asentamalla saa sen. Se vaati enemmän säätöä tuya developer portaalin kanssa, mutta kun sai tehtyä niin nyt päivittyy vaikka sekunnin välein kaikki tieto! Ai että kun olisi joku LocalOnecta tms...
Onhan sellainen. Faikin.
No joo mutta Faikin ja ESPAltherma molemmat vaatii erillistä rautaa, toi LocalTuya ei vaatinut muuta kuin konffaamista
heebo1974
Aktiivinen jäsen
Daikin AC, joka tosin ei toimi liian uusilla Daikinin wifi palikoilla.
Homeassistant ja Ouman EH-800 ongelma. Kaikki anturit toimii ja näkyy hyvin Ha:ssa mutta en saa millään toimimaan lämpötilan hienosäätöä. Selaimella tutkittaessa rekisteri on S_102_85 mutta en saa millään tuota arvoa muutettua. Koodina esim tämä mutta arvo ei muutu, mikä tässä nyt mättää?
shell_command:
ouman_set_ouman_l1_hienosaato_0_5: 'curl "http://192.168.1.4/update?S_102_85=0.5;"'
Koittanut tuolta opiskella mutta en vain keksi ratkaisua
community.home-assistant.io
shell_command:
ouman_set_ouman_l1_hienosaato_0_5: 'curl "http://192.168.1.4/update?S_102_85=0.5;"'
Koittanut tuolta opiskella mutta en vain keksi ratkaisua
HOW-TO: Control your Ouman EH-800 heating controller using Home Assistant
INTRODUCTION This how-to is all about using Ouman EH-800 heating controller with Home Assistant. Ouman EH-800 is versatile and very popular heating controller in Finland for heating systems using water as transfer medium, both for the radiators and floor heating. Prerequisites: Ouman EH-800...
community.home-assistant.io
Ville-Veikko
Aktiivinen jäsen
Mä tappelin tuon kanssa myös pitkään. En koskaan saanut pelaamaan suoraan niin että olisi koko url ollut tuossa shell komennossa vaan piti laittaa automaation kautta url kommenon parametriksi. Oliko sitten session autentikointi vai joku muu mikä blokkasi komennon läpimenon, mene ja tiedä. Alkoi toimimaan kun saman automaation sisällä kirjautuu ensin Oumanniin, venaa hetken ja sitten lykkää arvon hienosäätöön ja hetken perästä päivittää Oumannin arvot. Mulla on shell komennoissa outputtina tekstitiedostot, saattaisi toimia ilmankin? Jätin noin kun oli helpompi debugata eikä ne ole menoa haitannut...Homeassistant ja Ouman EH-800 ongelma. Kaikki anturit toimii ja näkyy hyvin Ha:ssa mutta en saa millään toimimaan lämpötilan hienosäätöä. Selaimella tutkittaessa rekisteri on S_102_85 mutta en saa millään tuota arvoa muutettua. Koodina esim tämä mutta arvo ei muutu, mikä tässä nyt mättää?
shell_command:
ouman_set_ouman_l1_hienosaato_0_5: 'curl "http://192.168.1.4/update?S_102_85=0.5;"'
Koittanut tuolta opiskella mutta en vain keksi ratkaisua
HOW-TO: Control your Ouman EH-800 heating controller using Home Assistant
INTRODUCTION This how-to is all about using Ouman EH-800 heating controller with Home Assistant. Ouman EH-800 is versatile and very popular heating controller in Finland for heating systems using water as transfer medium, both for the radiators and floor heating. Prerequisites: Ouman EH-800...
HOX! Mulla on näköjään eri rekisterit kun sulla, olisikohan L2 piiri ja laajennussarja syynä?
Sisälämpömittarina mulla on Shelly Plus H&T joka on pelannut luotettavasti jo pari vuotta erilaisissa termostaattihommissa kasvihuoneesta sisätiloihin. Nyt taisi jäädä olohuoneen piirongin päälle pysyvästi kun viritin sen tähän sisäanturiksi
Tein käyttöliittymän:
- input_boolean.l1_huonelampotilan_korjaus
- input_number.l1_huonelampo_asetus = tuo lämpötilatavoite
- sensor.l1_huonelammmon_korjaustarve
- 4. kenttä on Oumannista luettu arvo, tuon jätin näkyville ihan vaan seurannan vuoksi.
Korjaustarve on Template sensori
YAML:
{{ (states('input_number.l1_huonelampo_asetus') | float - states('sensor.lampomittari_temperature') | float(22.6)) | round(1) }}Laitoin shell komennot näin
Koodi:
shell_command:
ouman_logon: 'curl "http://192.168.10.200/login?uid=xxx;pwd=xxx ;" > /dev/null'
ouman_data: 'curl "http://192.168.10.200/request?S_135_85;S_259_85;S_275_85;S_227_85;S_362_85;S_293_85;S_310_85;S_240_85;S_272_85;S_306_85;S_283_85;S_235_85;S_134_85;" --output /config/ouman_data.txt'
# Kyseltävät kentät tässä järjestyksessä
# 1 S_135_85 K/P -tila
# 2 S_259_85 L1 meno
# 3 S_275_85 L1 pyynti
# 4 S_227_85 Ulkolämpötila
# 5 S_362_85 Releohjauksen tila
# 6 S_293_85 L2 meno
# 7 S_310_85 L2 pyynti
# 8 S_240_85 Poltinhälytys
# 9 S_272_85 L1 venttiili
# 10 S_306_85 L2 venttiili
# 11 S_283_85 L1 paluuvesi
# 12 S_235_85 L2 paluuvesi
# 13 S_134_85 L1 huonelämpötilan hienosäätö
ouman_update: 'curl {{ url }} --output /config/oumanl1tune.txt'Ja automaation näin:
YAML:
alias: L1 huonelämmön Hienosäätäjä
description: Päivittää L1 piirin huonelämpötilan hienosäätöä.
mode: single
triggers:
- entity_id:
- sensor.l1_huonelammmon_korjaustarve
for:
hours: 0
minutes: 15
seconds: 0
trigger: state
conditions:
- condition: state
entity_id: input_boolean.l1_huonelampotilan_korjaus
state: "on"
actions:
- metadata: {}
data: {}
action: shell_command.ouman_logon
- delay:
hours: 0
minutes: 0
seconds: 1
milliseconds: 0
- data:
url: >-
http://192.168.10.200/update?S_134_85={{states('sensor.l1_huonelammmon_korjaustarve')}};
action: shell_command.ouman_update
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- metadata: {}
data: {}
action: shell_command.ouman_dataHA:lla on nordpoolin hinnat tiedossa ja esitettynäkin ApexChartin avulla. Samaten HA:lla on tieto Homewizard P1-portinlukijan avulla hetkellisestä ja päivän sähkönkulutuksista. Miten saisi HA:lle näkyviin paljon kuluvan päivän sekä edellisen päivän, tai päivien, kustannusarvion on?
Kiitos @haraldh avusta. En muistanut, että olin HA sivupalkista piilottanut Energy välilehden pois näkyvistä… Mutta kuitenkaan en saa tätä toimimaan. Kulutus kyllä näkyy oikein, mutta jos sensor.nordpool on sähköhinnan lähteenä, ei kustannus kerry oikein. Jostain syystä kustannuksena näkyy 9.79 EUR, tein mitä tahansa tai kului sähköä tai ei.
Päivitystä. Kustannus kertyy nyt, ehkä eilen oli käyttäjän virhettä, mutta summan yksikkönä pitäisi olla sentti, kuten spot hinta, HA esittää sen euroina eli siis kustannus on satakertainen. Kokeilin helperiä voisiko sillä jakaa sensorin datan sadalla, mutta ei sekään onnistu. HA on kaikkine helpereineen, templateineen, yamleineen yms. liian monimutkainen ja vaikeasti opittava. Vaikka pythonia periaatteessa osaankin tuottaa, ei siitä ole apua tämän kanssa.
Päivitystä. Kustannus kertyy nyt, ehkä eilen oli käyttäjän virhettä, mutta summan yksikkönä pitäisi olla sentti, kuten spot hinta, HA esittää sen euroina eli siis kustannus on satakertainen. Kokeilin helperiä voisiko sillä jakaa sensorin datan sadalla, mutta ei sekään onnistu. HA on kaikkine helpereineen, templateineen, yamleineen yms. liian monimutkainen ja vaikeasti opittava. Vaikka pythonia periaatteessa osaankin tuottaa, ei siitä ole apua tämän kanssa.
Viimeksi muokattu:
Tee toinen nordpool integraatio missä yksikkö oikein.
Itselläni kaks nordpool integraatiota, toisessa eurot ja toisessa sentit.
Viimeksi muokattu:
jkoljo
Aktiivinen jäsen
Configuration.yaml lisäys toimisi tähän tyyliin. Siirtotariffin ja veron voi jättää halutessaan pois. Siirtotariffia välpätään automaatiolla yö ja päiväsähkölle.
Koodi:
template:
- sensor:
- name: "Electricity total import cost Nordpool price"
unique_id: "electricity_total_import_cost_nordpool_price"
unit_of_measurement: "€/kWh"
state: >
{% set cost = states('sensor.nordpool_kwh_fi_eur_3_10_0255') | float %}
{% set tariff = states('input_number.electricity_current_transfer_tariff') | float %}
{% set tax = 2.79372 | float %}
{{ (tariff + cost + tax) / 100.0 }}
- name: "Electricity total export price"
unique_id: "electricity_total_export_price"
unit_of_measurement: "€/kWh"
state: >
{% set cost = states('sensor.nordpool_kwh_fi_eur_3_10_0255') | float %}
{{ (cost) / 100.0 }}Noniin ensimmäistä kertaa tuli tilanne vastaan, että pistin vaan luottavaisena että update kun tarjosi uutta corea ja kaikkea. No, sitten huomasin että oli mennyt wifi-pistorasioiden integraatio jotenkin rikki enkä saanut sitä mitenkään korjattua, joten ensimmäistä kertaa sitten testaan että miten backupista palauttaminen toimi. No eipä ollut sekään hauskaa! Muutama integraatio meni rikki ja vaati "uudelleen authorisointia". Joku meni parilla klikkauksella ja joku meni sitten vähän vaikeamman kautta. Netatmon joutui kokonaan tuhoamaan ja asentaan alusta lähtien uudelleennimeämisineen jne.
Nyt näyttäis ehkä/toivottavasti kaikki olevan siinä tilassa missä ne eilen illalla oli ja nyt sitten en varmaan uskalla päivittää enää ikinä yhtään mitään.. Olis toi backupin palauttaminen voinut vähän sujuvammin toimia, en tajua miten se noin vaikea homma oli.
Nyt näyttäis ehkä/toivottavasti kaikki olevan siinä tilassa missä ne eilen illalla oli ja nyt sitten en varmaan uskalla päivittää enää ikinä yhtään mitään
.. Olis toi backupin palauttaminen voinut vähän sujuvammin toimia, en tajua miten se noin vaikea homma oli.
Luukku
Vakionaama
Kiitos. Jätämpä sitten tekemättä. Piti viikonloppuna päivitellä. Muutaman kerran on itselle käynyt noin ja nuo päivitykset onkin HA:ssa se paskin ominaisuus. Yleensä tottunut, että päivitykset pitää tehdä. HA:ssa niitä pitää valikoida, että mitä uskaltaa päivittää.
Joo kun vaan etukäteen tietäisi että mikä päivitys on ok ja mikä ei. Tähän asti meinaan kaikki mennyt ihan sujuvasti ilman mitään rikkoutumisia. Mutta nyt tosiaan jos on Nedis/Tuya wifi-pluginnia niin sen Tuya/xtended tuya meni rikki eikä enää osannut päivittää, joten siinä meni sitten VILPin / sulatuskaapelin sulatusautomaatiot.
Ilmeisesti myös shellyjen integraatio on tuossa hajonnut, kun katsoin tämän ekan 2024.12 version kommentteja - liittyisikö samaan asiaan? itse odottelen aina muutamna viikon että tulee vähintään pari korjausversiota ennen kuin uskallan päivittää.
Joo kantapään kautta opittiin tääkin
.. Muutenhan ei niin olisi haitannut palauttaa backupista, mutta yllättävän tuskainen operaatio sekin oli jostain syystä! En ymmärrä miten noi autohorisoinnit noin moneen paikkaan hajosi backupin palautuksen yhteydessä, luulisi että niillä ei olis mitään vaikutusta asiaan mutta eei.Ville-Veikko
Aktiivinen jäsen
Aika hyvin Copilot koodaa suomenkielisellä ohjeella! Ihan hämmästyin et näinkö helpoksi hommat on menneet. Onneksi en enää ole nörttihommissa, alkaisi hirvittää työpaikan tulevaisuus
YAML:
sensor:
- platform: template
sensors:
custom_formula:
friendly_name: "Custom Formula"
value_template: >
{% set A3 = states('sensor.your_input_sensor') | float %}
{{ (0.0917 * (A3 ** 2)) + (5.0993 * A3) + 66.575 }}
unit_of_measurement: "units"Itse päivitän HA vasta viikonloppuna ennen kuukauden ekaa keskiviikkoa, eli just pari päivää ennen uuden version julkaisua.
Oletin että HACS integraatioita tulee hajoamaan 2024.12 julkaisun yhteydessä, koska change logissa on Pythonin versiopäivitys 3.12 -> 3.13 Edellisen päivityksen yhteydessä keväällä (oisko ollu 2024.4) meni kans useampi HACS komponentti rikki.
Ne HACS kun on tekijän vastuulla päivittää ja kaikki ei reagoi rc/beta versioon ja testaa omaa jakeluaan sen testiviikon aikana ennen varsinaista julkaisua
Oletin että HACS integraatioita tulee hajoamaan 2024.12 julkaisun yhteydessä, koska change logissa on Pythonin versiopäivitys 3.12 -> 3.13 Edellisen päivityksen yhteydessä keväällä (oisko ollu 2024.4) meni kans useampi HACS komponentti rikki.
Ne HACS kun on tekijän vastuulla päivittää ja kaikki ei reagoi rc/beta versioon ja testaa omaa jakeluaan sen testiviikon aikana ennen varsinaista julkaisua
jussipa
Aktiivinen jäsen
Ei ainakaan minulla hajonnut Shelly-integraatio eikä tällä kertaa mikään muukaan, vaikka useampi HACS-integraatio käytössä.
Näyttää varsinkin nuo vanhemmat z-wave laitteet olevan sellasia, jotka ei tykkää noista päivityksistä. Muutokset on sellasia, ettei niitä edes heti huomaa.
Laiteasetukset menee sekoiluksi, ei saa muutettua. Arvot eivät päivity, tulee täysin olemattomia entiteettejä automaatilla pyytämättä, asetuksista ei pysty muuttamaan pois oletuksesta ym. häikkää.
Nyt viimesen vuoden aikana liki kaikki vanhemmat z-wavet on jotenkin muuttuneet puolivammaisiksi. Osan pystyy kiertämään automaatiolla, joka pyytää päivittämään vehkeen mittarit. Kun esm. Aeon kytkimet ei suostu raportoimaan jännite ja virta-arvoaan ilman eri pyyntöä. Asetuksissa arvo palaa aina "disabled" arvoon. Samaten Qubinon kytkimet sekoilee lähes kaikessa.
Ja kaikki on pelannut ihan oikein sillon kun ne on liitetty HA:n settiin. Melko ärsyttävää. En jaksa uskoa, että yhenäkisti monta laitetta ja vielä eri firman tuotteita hajoaa osin tomimattomaksi.
Laiteasetukset menee sekoiluksi, ei saa muutettua. Arvot eivät päivity, tulee täysin olemattomia entiteettejä automaatilla pyytämättä, asetuksista ei pysty muuttamaan pois oletuksesta ym. häikkää.
Nyt viimesen vuoden aikana liki kaikki vanhemmat z-wavet on jotenkin muuttuneet puolivammaisiksi. Osan pystyy kiertämään automaatiolla, joka pyytää päivittämään vehkeen mittarit. Kun esm. Aeon kytkimet ei suostu raportoimaan jännite ja virta-arvoaan ilman eri pyyntöä. Asetuksissa arvo palaa aina "disabled" arvoon. Samaten Qubinon kytkimet sekoilee lähes kaikessa.
Ja kaikki on pelannut ihan oikein sillon kun ne on liitetty HA:n settiin. Melko ärsyttävää. En jaksa uskoa, että yhenäkisti monta laitetta ja vielä eri firman tuotteita hajoaa osin tomimattomaksi.
Ninnannunna
Jäsen
Olettekos rakennelleet sensoria "tyhmän" LVV:n sähkönkulutuksen seurantaan? Tämä on ollut ikuisuusprojekti, joka alkoi taas mietityttämään.
Jos talossa olisi muuten tasainen kulutus niin olisi helppo homma suodattaa 3kW piikin avulla, mutta kun saattaa olla lattialämpöjä ties mitä päällä, niin varsinaista pohja-arvoa ei oikein voi asettaa. Varaajaa ohjataan kyllä HA:lla, joten tieto onko kytkin päällä tai pois on, mutta varaaja ei kuitenkaan välttämättä lämmitä silloin. Samoin tieto useimmista muista kulutuksista paitsi tuosta varaajasta. Kaikkia laitteita ei kuitenkaan viitsisi alkaa sensoriin laittamaan. Olisiko joku fiksumpi on tämän jo ratkaissut? Tai jotain ideaa mistä päin tätä pitäisi lähteä lähestymään?
Jos talossa olisi muuten tasainen kulutus niin olisi helppo homma suodattaa 3kW piikin avulla, mutta kun saattaa olla lattialämpöjä ties mitä päällä, niin varsinaista pohja-arvoa ei oikein voi asettaa. Varaajaa ohjataan kyllä HA:lla, joten tieto onko kytkin päällä tai pois on, mutta varaaja ei kuitenkaan välttämättä lämmitä silloin. Samoin tieto useimmista muista kulutuksista paitsi tuosta varaajasta. Kaikkia laitteita ei kuitenkaan viitsisi alkaa sensoriin laittamaan. Olisiko joku fiksumpi on tämän jo ratkaissut? Tai jotain ideaa mistä päin tätä pitäisi lähteä lähestymään?
Ninnannunna
Jäsen
Yhtenä ajatuksena oli siis että kokonaiskulutuksesta voisi jättää pois tiedetyt kuormat, esim nuo lattialämmitykset ja muut enemmän kuluttavat ja tehdä sen jälkeen tämänsuuntainen foorumeilta löytynyt hässäkkä:
YAML:
template:
- binary_sensor:
- name: "Pompe puisard"
state: >
{% set power = states('sensor.smart_meter_electric_consumption_w')|float(0) %}
{{ (200 <= power <= 300) or (900 <= power <= 1100) }}
# Example configuration.yaml entry
sensor:
- platform: history_stats
name: Pompe puisard Count
entity_id: binary_sensor.pompe_puisard
state: "on"
type: count
start: "{{ now().replace(minute=0, second=0) }}"
end: "{{ now() }}"Tästä saisi sitten helposti Powercalcilla tai muuten kulutuksen helposti.
haraldh
Vakionaama
Minulla on tuollainen Template sensor Helper "sensor.synthetic_lvv_power" joka aiheuttaa synteettisen 3 kW kulutuksen kun LVV on HA:n ohjaamana pääällä;
Tuo tosin vain aiheuttaa 3 kW kulutuksen kun kytkin on päällä, eikä tietenkään huomaa sitä että termari sammuttaa.
Väärintilauksesta johtunen minulla on muutama ylimääräinen Shelly PM Mini (kykenee vain mittaamiseen), ja ajatus olisi laittaa sellainen yhteen karvaan/vaiheeseen ja sitten vain kylmästi kerrata tuo kolmella em. helperissä sen sijaan että vain katsoo kytkimen tilaa.
YAML:
{% if is_state('switch.lvv', 'on') %}
{{ 3000 | int }}
{% else %}
{{ 0.0 | int }}
{% endif %}Tuo tosin vain aiheuttaa 3 kW kulutuksen kun kytkin on päällä, eikä tietenkään huomaa sitä että termari sammuttaa.
Väärintilauksesta johtunen minulla on muutama ylimääräinen Shelly PM Mini (kykenee vain mittaamiseen), ja ajatus olisi laittaa sellainen yhteen karvaan/vaiheeseen ja sitten vain kylmästi kerrata tuo kolmella em. helperissä sen sijaan että vain katsoo kytkimen tilaa.
Mulla on kanssa kattilassa mittaus yhdessä vaiheessa. Kun siirsin kiertopumput ja säätimen tulemaan eri kautta, niin nyt 3x toimii hyvin.
Ninnannunna
Jäsen
Powercalcilla on helppo tehdä noita kanssa, mutta ongelmana on juurikin tuo termostaatin omapäinen toiminta. Minulla on ylimääräinen varatunti varaajan lämmityksessä, mutta kiinnostaisi tietää vähän tarkemmin sen toiminta erilaisissa tilanteissa. Millään en tuota varten enää viitsisi lisärautaa laitella, kun varmasti ohjelmallisestikin onnistuu nykyisellä kokoonpanolla. Toki lämpöjen seuranta on varmaankin jossain kohtaa tulossa jotta pääsee tuonkin optimoimaan fiksummaksi.
Itse olen ratkaissut asennuttamalla Shelly 3EM kulutusmittarin LVV kulutusta seuraamaan.
Lisäksi jokainen termari on erillismitattu, samoin liesi+uuni, mikroaaltouuni, airfryer, kiuas, tv, av vahvari, subbari, työpisteet, verkkolaitteet, ILP, IV, JK, pakastin, APK, PK, kuivuri, valoja... jne yli 40 kohdetta erillismittauksessa
Lisäksi jokainen termari on erillismitattu, samoin liesi+uuni, mikroaaltouuni, airfryer, kiuas, tv, av vahvari, subbari, työpisteet, verkkolaitteet, ILP, IV, JK, pakastin, APK, PK, kuivuri, valoja... jne yli 40 kohdetta erillismittauksessa
Luukku
Vakionaama
On tota dataa sit kumminkin
Ninnannunna
Jäsen
No eipä tuo nyt loppujen lopuksi olekaan kummoinen homma poistella noita suurimpia kuluttajia sensorilta. Alla testiversio. Voi lisäviilailla lattamalla tresholdin vaikka jollekin välille jos taustalla tasaista kulutusta. Täytyy liesi, joka ei ole mittauksen perässä vielä jotenkin laskea pois tästä yhtälöstä, ja tehdä sille sama homma. Tällä hetkellä tosin ei tarvetta, koska ei ole ikinä samaan aikaan varaajan kanssa päällä.
YAML:
#LVV kulutuksen laskentaan
binary_sensor:
- platform: template
sensors:
lvv_power_threshold:
friendly_name: "LVV Power Threshold"
unique_id: 74d2f6a6-91fd-44fa-849f-44d7eb1221a7
device_class: power
value_template: >-
{{
states("sensor.lvv_power_all_substracted") | float(0) > 3000
and is_state("switch.lvv_shellypm4_katkaisija", "on")
}}
sensor:
- platform: template
sensors:
lvv_power_all_substracted:
friendly_name: "LVV kulutukseen W"
unit_of_measurement: "W"
device_class: "power"
unique_id: 3d1597de-0d07-45e2-adaa-d6fbaffb14a7
value_template: >-
{{
(states("sensor.verkko_kokonaiskulutus") | float(0)
- states("sensor.virtual_oh_lattia_power_energy") | float(0)
- states("sensor.rasia_ilp_power") | float(0)
- states("sensor.shellyplus1pm_iv_power") | float(0)) | round(0) | int
}}Ninnannunna
Jäsen
Jäi laittamatta että tuon binary sensorin (on, off) tilan perusteella voi tehdä sitten Powercalcilla kaikenmaailman kulutussensorit.
Ja tarkemmin ajatellen, kyllä liesi voi olla samaan aikaan päällä varaajan kanssa, koska halvimmat tunnit eivät nykyään välttämättä osu yölle. Pitää miettiä vähän lisää...
Ja tarkemmin ajatellen, kyllä liesi voi olla samaan aikaan päällä varaajan kanssa, koska halvimmat tunnit eivät nykyään välttämättä osu yölle. Pitää miettiä vähän lisää...
Viimeksi muokattu:
Näkyykö sulla jo jossain sensorissa se LVV:n tehonkulutus (edit: tarkoitan siis sisältyykö se johonkin)? Onko siis esim. reaaliaikainen koko talon sähkönkulutus jossain sensorissa? Kuulosti siltä, että on. En ole varma, että toimisiko, mutta ehkä trigger-based template sensor voisi toimia. Jos sulla on semmoinen sensori, niin onko siinä tosiaan terävä pudotus sen 3kW alaspäin ja toisaalta ylöspäin?
Viimeksi muokattu:
Ninnannunna
Jäsen
Noissa tuota postia seuraavissa postauksissa ratkon asiaa.
Okei, niinjoo. No voisit kokeilla jotain tämmöistä. Triggeriin perustuva sensori, jossa sensorin arvon muuttumisen ehtona on, että sensor.verkko_kokonaiskulutus -sensorin arvo vaihtuu 3000 +-100. Ja arvoksi laitetaan sitten se, että mentiinkö tehossa ylös vai alaspäin. Testaamatonta koodia ja ei välttämättä toimi, jos sensor.verkko_kokonaiskulutus näkee 3kW muutoksen esim. kahdessa eri osassa (ensin 1kW ja sitten 2kW heti seuraavassa sensorin päivityksessä).
YAML:
template:
- trigger:
- trigger: state
entity_id: sensor.verkko_kokonaiskulutus
condition:
- condition: template
value_template: >
{% set power = 3000 %}
{% set max_diff = 100 %}
{% set diff = (trigger.from_state.state | float - trigger.to_state.state | float) | abs %}
{{ a < power + max_diff and a > power - max_diff}}
binary_sensor:
- name: "LVV"
state: >
{{ trigger.from_state.state | float < trigger.to_state.state | float }}Ei nyt ihan suoranaisesti tuohon ylläolevaan kulutuksen mittaamisen olemassa olevilla palikoilla liity, mutta olen itse lisännyt LVV:n kylkeen 1wire-anturin, jotta tarvittaessa voi myös ohjata päälle sen mukaan, jos pelkkä yöllinen lämmitys ei riitä.
Tuo ylimääräinen anturihan auttaisi tuossa ylläolevassakin, kun anturi kertoisi kotiautomaatiolle milloin termari laittaa lämmityksen seis.
Tuo ylimääräinen anturihan auttaisi tuossa ylläolevassakin, kun anturi kertoisi kotiautomaatiolle milloin termari laittaa lämmityksen seis.
Ninnannunna
Jäsen
Kiitos tosiaan, ei tullut ihan ajatuksella eilen tätä mietittyä, otanpa tämän testiin myös ja katson kotvasen miten nämä pari eri lähestymistapaa toimii.