stigvi

For Nobø sin termostat kan en spesifisere disse verdiene: Gulvsensor (Ekstern temperatursensor) 22kOhm ved 25˚C (standardinnstilling) Andre kompatible gulvsensorverdier: 47kOhm v/25˚C 10kOhm v/25˚C 15kOhm v/25˚C 2kOhm v/25˚C 12kOhm v/25˚C Og her finnes verdier som ikke lar seg stille inn på Namron. Så det er tydeligvis ingen standard og heller ingen garanti for at eksisterende føler kan brukes. Men normalt er de lette å dra ut så hvorfor ikke bytte den?

Et annet alternativ er å bytte ut ledningen til en tynn hvis målet er å redusere ladestrøm. Eventuelt åpne opp støpselet og bytte ut motstand som er der.

Dette punktet må du løse med muligheter som eventuelt finnes i bilen. Ladestasjonen vet ingenting om batteritilstand. Jeg har lest at dette kan endre seg i fremtiden, men det gjelder i så fall for nye biler sammen med nye ladestasjoner.

Innlegget er ment som et tips eller noe en kan dra nytte av til andre ting. Når en lager en malsensor, vil denne malen evalueres hver gang en entitet som er brukt i malen, endres. Dette er stort sett ønskelig, men noen ganger er det en hindring. I eksempelet under, beregner jeg oppvarmingstid for VVB og setter en binær sensor til På i de billigste timene og i så mange timer som det er nødvendig å varme vann. Problemet oppstår når temperaturen i vannet øker og da vil beregnet oppvarmingstid synke. Dette lager kluss når en skal plukke de billigste timene. En kan starte å varme vann i den billigste timen, men når en kommer til den nest billigste kan oppvarmingstiden sunket så mye at denne timen utelates. Å varme vannet krever bare en time til og den billigste timen er jo nettopp passert. Denne problemstillingen kan en omgå ved å bruke en ny funksjonalitet i HA. Så veldig ny er den derimot ikke. Mulig den har eksistert i et par år nå. Det dreier seg om å skille trigger / evaluering av mal til noe en selv bestemmer. Det kan være tid, tilstand, hendelse eller egentlig hva som helst. Dokumentasjon for dette, finner en her: https://www.home-assistant.io/docs/automation/trigger/ Triggere for automatisering er prikk lik triggere en kan bruke i maler og dokumentasjonen for disse er lik. I eksempelet nedenfor, trigger jeg beregning av oppvarmingstid kun i start på hver time og kun hvis VVB er avslått. Så snart en starter på å varme vann, vil ikke ny oppvarmingstid bli beregnet. Unntaket er når en setter ny temperatur en skal varme til, bare for å ta med det og å vise at en kan ha mange triggere. Etter min mening er dette en svært nyttig egenskap til mal-sensorer som ofte kan forenkle ganske mye. template: - trigger: - platform: template value_template: "{{ now().minute == 0 and states('sensor.effekt_varmtvann')|float(0) == 0 }}" - platform: state entity_id: - input_number.vvb_temperatur sensor: - unique_id: vvb_heating_time name: "vvb oppvarmingstid" unit_of_measurement: 'h' device_class: duration state: >- {{ ((states('input_number.vvb_temperatur')|float(80) - average(states('sensor.varmtvannstank_topp_temperatur')|float(60), states('sensor.varmtvannstank_senter_temperatur')|float(60), states('sensor.varmtvannstank_bunn_temperatur')|float(60))) / (iif(float(states('sensor.effektbegrensing')) > 8, 1.0, 2.0) / 194.0 / 0.001163))|round(1) }} - binary_sensor: - unique_id: billigste_timer_vvb name: billigste_timer_vvb state: >- {% set l=state_attr('pyscript.strompris', 'prices')[14:39]|sort(attribute='totalprice') %} {% set t = now().hour %} {% set d = now().day %} {% set h = states('sensor.vvb_oppvarmingstid')|float(0) %} {{ iif(h > 0, (t == as_datetime(l[0].start).hour and d == as_datetime(l[0].start).day), false) or iif(h > 1, (t == as_datetime(l[1].start).hour and d == as_datetime(l[1].start).day), false) or iif(h > 2, (t == as_datetime(l[2].start).hour and d == as_datetime(l[2].start).day), false) or iif(h > 3, (t == as_datetime(l[3].start).hour and d == as_datetime(l[3].start).day), false) or iif(h > 4, (t == as_datetime(l[4].start).hour and d == as_datetime(l[4].start).day), false) or iif(h > 5, (t == as_datetime(l[5].start).hour and d == as_datetime(l[5].start).day), false) or iif(h > 6, (t == as_datetime(l[6].start).hour and d == as_datetime(l[6].start).day), false) }}

Hva med fordeler og bakdeler med å samle alle eggene i en kurv? For meg er det et poeng å spre hjemmeautomasjonen utover på flere "dingser". Og å ha en raspberry pi4 liggende på lager i skuffen, koster heller ikke mye. Å ha en i reserve, klar til å brukes, gir en viss trygghet på at automasjonen ikke er nede i dagevis. Jeg har en Sonoff zigbee koordinator liggende på lur også. Og vitale data fra den som brukes nå, er kopiert slik at den nye kan settes opp som en nøyaktig kopi. Å samle alt på en server, skaper ikke det problemer med hjemmeautomasjon når denne serveren skal vedlikeholdes?

Har drivstoff/bensinapp'en en intent med pris? I så fall kan en jo prøve dette hvis en er på Home Assistant. https://community.home-assistant.io/t/android-intents-sending-receiving-list-starting-activities-too/276192 Edit: Siste "Varsel" på tlf kan også plukkes opp av HA appen og sendes til HA. Så hvis drivstoff/bensinapp sender varsler på prisendringer, kan det også plukkes opp via appen. Men intents hadde vært kult. Da skulle jeg også vurdert dette........ Edit2: Regner med dette gjelder kun android appen. Iphone brukere er jo forskånet for kule ting som dette..............

Hva er "dette"?

En trenger ikke noe som helst "spesielt" for å kjøre backup. Selv den enkleste raspberry pi (som kan kjøre HA) kan kjøre backup til skytjenester automatisk. PS. Dette er ment som et svar til andre som eventuelt leser tråden. Hardware hindrer definitivt ikke muligheten til å kjøre automatisk backup.

Hva er standard vedlikehold på en varmepumpe? Skal en skifte olje etter X antall timer?

Som thoralex skriver, netteiere skrur opp spenningen på transformatorer for å kompensere for spenningsfall. Når solceller leverer så får en da ekstra høy spenning etter trafo fordi spenningsfallet blir for lite. Selvsagt kan netteiere redusere spenning. Men jeg tipper det er en manuell jobb som også krever at de må skru av strømmen et lite øyeblikk (med forbehold om uvitenhet) Nå er det svært lite sannsynlig med rasjonering, men hvis det skulle bli så er det bedrifter som må stenge ned først. Jeg jobbet en stund som innleid konsulent for et smelteverk i Trondheim. De hadde kjøpt strøm til fast lav pris. Når spotprisen ble høy nok, stengte de ned verket og solgte strømmen videre til spotprisen. Dette skjer av seg selv uten at det blir tvungen rasjonering. Når spotprisen blir høy nok, er det masse kraft som blir frigjort til husholdninger og bedrifter som ikke kan stenge ned.

Nei, kanskje ikke. Men samtidig er det økonomi som diskuteres. Jeg er, som en kanskje forstår, veldig skeptisk til private solcelleanlegg. Rett og slett fordi de blir for små i forhold til utgiftene. Men også fordi det norske nettet ikke er i stand til å takle at det blir for mange solcellepanel (hvis en skal selge strømmen om sommeren). Dette med solkonto forstår jeg heller ikke mye ut av. Hvor lenge kan bedrifter som Fjordkraft drive på å dele ut penger? For det er jo nettopp det de gjør. Og hvordan går det med din og hflatoey sin ROI hvis solkonto forsvinner eller endres? I regnearket ovenfor så virker det som om det er 5000 kr i inntekt for November og Desember. Er dette innløsing av solkonto? Fjordkraft kan jo ikke holde på med slikt over lang tid så jeg antar at dette er noe de gjør for å kapre kunder. Edit: Hvis det er slik at antall kwh en putter inn på solkonto er det en kan ta ut. Det virker slik i fra regneark der 4900kWh er solgt og 4900kWh er kjøpt. Jeg klarer ikke å se ut i fra regnearket hva strømleverandør sin konto er, altså hva de betaler for 4900kWh og hva den er solgt for. Det naturlige ville vært en konto som baserer seg på kroner og øre og ikke energi. Men jeg har større tro på solcellepanel hos bedrifter som kan bruke strømmen selv. Da unngår en nettleie og eventuell skatt på inntekt av salg av strøm.

Men hadde du kjøpt aksjer for 200.000? 🙂

Det tallet øverst til høyre, er det reellt? I så fall er jo egne solcellepanel totalt uinteressant.

Node red er sikkert fint for deg. Men jeg hadde nok savnet en god mobil app som HA har. Det jeg derimot sliter litt med å forstå er de som bruker HA og installerer Node red for å kjøre automasjoner. Men jeg er kanskje ekstra fokusert på KISS. Jeg vet at hvis noe skal rusle og gå i årevis så er det viktig å ha det enkelt. Node red kan sikkert hjelpe HA brukere å lage automasjoner, men samtidig får de to systemer å vedlikeholde. Hvis en ikke gjør som du og bare bruker Node red. Men da må en klare seg uten HA appen........

Lett i Home Assistant. Men Nodered kjenner jeg ikke til overhodet.

Og så kan en jo lure på hva faktura blir. For et firma som Tibber som lever av å kjøpe og selge strøm, er det merkelig at de ikke kan presentere en pris til kundene som er å stole på.

Tibber vet ikke hva som er netteierpriser over det ganske land. De tok iniativ til et felles system for å rapportere inn netteierpriser og noen netteiere ble med på dette og sender inn sine priser. Disse får du med i appen og hvis du henter ned det tillegget som christbj nevner. Men det er mange netteiere som gir blaffen og ikke sender inn priser. https://support.tibber.com/nb/articles/6337608-hvorfor-er-ikke-prisinformasjon-fra-nettselskapet-mitt-tilgjengelig

Ikke nødvendigvis. Tibber har ikke info om alle netteierpriser i Norge.

Jeg bruker Nobø sitt system som er dønn stabilt. Har ikke hatt problem en eneste gang siste par årene. Du må i så fall ha Nobø hub. Denne finnes det en integrasjon til for Home Assistant. I tillegg har Nobø en app. Edit: Nobø hub kobles til nett via kabel så du er da ikke avhengig av wifi

Hehe. Når jeg gjorde samme type overgang fra deconz til zigbee2mqtt så jobbet systemet en hel måned med å oppgradere firmware.

Det er de samme personene som vedlikeholder zigbee2mqtt som også vedlikeholder add-on. De oppdateres samtidig.

Home Assistant har kalender og oppgaveliste. I kalender legger jeg inn ferie slik at varme og lys styres riktig. I tillegg har jeg laget en trykknapp i HA for å opprette oppgaver over det jeg ikke bør glemme før avreise. I januar utgaven av HA (2024.01) er det lagt til tidspunkt for når en oppgave skal være ferdig og dette bruker jeg nå slik at jeg henter avreise fra kalender og setter "due_datetime". alias: Ferieoppgaver description: "" trigger: - platform: state entity_id: - input_button.opprett_ferieoppgaver condition: [] action: - service: todo.add_item data: item: Fyll vann i sluk på bad og vaskerom due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(hours=10)).isoformat() }} target: entity_id: todo.ferie - service: todo.add_item data: item: Ta ut søppel due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(hours=10)).isoformat() }} target: entity_id: todo.ferie - service: todo.add_item data: item: Lad batteri på gardiner due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(days=3)).isoformat() }} target: entity_id: todo.ferie - service: todo.add_item data: item: Sjekk hagemøbler due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(days=3)).isoformat() }} target: entity_id: todo.ferie - service: todo.add_item data: item: Sjekk mat i kjøleskap due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(hours=10)).isoformat() }} target: entity_id: todo.ferie - service: todo.add_item data: item: Stopp post og reklame due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(days=5)).isoformat() }} target: entity_id: todo.ferie - service: todo.add_item data: item: Klipp plen due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(days=1)).isoformat() }} target: entity_id: todo.ferie - service: todo.add_item data: item: Ta inn nøkler til utekraner due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(hours=10)).isoformat() }} target: entity_id: todo.ferie - service: todo.add_item data: item: Stopp avis due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(days=5)).isoformat() }} target: entity_id: todo.ferie - service: todo.add_item data: item: Steng krane til vaskemaskin due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(hours=3)).isoformat() }} target: entity_id: todo.ferie - service: todo.add_item data: item: Steng krane til oppvaskmaskin due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(hours=3)).isoformat() }} target: entity_id: todo.ferie - service: todo.add_item data: item: Stopp klima kl 1500 i Golf due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(days=1)).isoformat() }} target: entity_id: todo.ferie - service: todo.add_item data: item: Tøm vannbeholder på avfukter due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(hours=10)).isoformat() }} target: entity_id: todo.ferie - service: todo.add_item data: item: Sjekk låser på glassdører due_datetime: >- {{ (as_datetime(state_attr('calendar.ferie', 'start_time'))-timedelta(hours=10)).isoformat() }} target: entity_id: todo.ferie mode: single

Har ingen erfaring selv med Plejd, men har forstått det slik at dette er proprietært og vanskelig å integrere med andre systemer. Men det finnes løsninger, i alle fall for Home Assistant. Men jeg vil allikevel anbefale standard løsninger for lys og her har helt klart zigbee det beste utvalget.

Men hvis en slår på gulvvarme på fullt og venter til en Aqara romtemperaturføler rapporterer en gitt temperatur pluss en hysterese, så kan jo gulvet allerede være alt for varmt og temperaturen i rommet vil fortsette å stige selv om en slår av all varme. Å regulere romtemperatur med gulvvarme er ingen lett øvelse. Og etter å ha lest på dette forumet i et par - tre år, så sitter jeg igjen med et inntrykk av at mange implementerer varmestyringen som enten helt av eller fullt på sammen med en hysterese. Det er en dårlig løsning på både panelovner og gulvvarme.

Mitt tips er å lese seg opp på reguleringsteknikk før en setter i gang og lager egen varmestyring. Et hull å falle ned i kan være å lage systemet ustabilt og en får en reell temperatur som svinger for mye rundt satt temperatur. Det optimale er jo en stabil temperatur som ikke svinger i det hele tatt, men at en tilfører akkurat nok varme som trengs.