haraldov

Jeg smart styrer elbil laderen (Easee) så du får maks effekt ledd kontroll og smart gridd intjening (Grid Award). Jeg bruker ikke Emhass til elbil ladning ennå. En grunn til det er at å beregne total antall timer bilen skal lade er unøyaktig. Formel en kan bruke for å beregne antall timer er: EV_total_hours = (charge_limit - current_state_of_charge)/charging_rate (https://community.home-assistant.io/t/emhass-an-energy-management-for-home-assistant/338126/2968), men svaret du får er et desimaltall for antall timer som f.eks: 1,25 timer som er 1 timer og 15 minutter, men som Emhass avrunder til 1 time (https://github.com/davidusb-geek/emhass/issues/373). Men utvikleren har tenkt å lage støtte for elbilladning (Support for EVs (see Peter Pflaum Thesis), https://github.com/davidusb-geek/emhass/wiki. Jeg bruker emhass til bare å styre varmvannsberederen nå. I fremtiden skal jeg styre varmekablene med den nye termo modellen (https://emhass.readthedocs.io/en/latest/thermal_model.html.)

Jeg har bestilt 2 stk selv. Har i dag en raspberry pi som er installert med Wyoming Satellite https://github.com/rhasspy/wyoming-satellite hvor jeg har koblet til en Microsoft Teams USB microfon og høytaler. Jeg bruker Home Assistant Cloud til å prosessere Wake Word deteksjon (Hey Jarvis) og gjøre endringer som å slå av og på lys. Dette går veldig bra på norsk. Eneste minus er at når tv står på så tror den tv stemme er Hey Jarvis av og til. Har prøvd å gjøre støy kansellering med å gjøre endringer på innstillingene Wyoming Satellite, men hittil har det ikke hjulpet. Kunne nok har brukt Open AI til å filterere ut noise fra tv, men ønsker å kunne gjøre dette stemmestyring mest mulig lokalt. Håper nå at HA Voice Preview ikke har dette problemet. I fremtiden vurderer jeg også å kjøpe en Jetson Orin Nano Super for å drive en LLM chat server: https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-orin/nano-super-developer-kit/

Scenes i HA har blitt oppgradert i 2024.12 https://www.home-assistant.io/blog/2024/12/04/release-202412/#improved-scene-editor-experience Det kan derfor være bugs i scenes eller i zigbee/z-wave. Men jeg har ikke opplevd det du beskriver. Bruker ZHA og Z-Wave-JS for å styre mine lys.

Minimum dager for "machine learning forecaster" er 9 dager med strømdata. Men som utvikleren skriver så blir det mer nøyaktig med flere dager med data. Jeg bruker Tibber Pulse for å registere effekt dvs "sensor.tibber_pulse_hjemmeadresse_power". Problemet er som du skriver at ett år med data vil bli enorme mengder med data skrevet til filen home-assistant_v2.db. Jeg bruker filter i recorder https://www.home-assistant.io/integrations/recorder/ for å prøve å logge minst mulig data, men ett år gikk ikke. Så nå bruker jeg 10 dager med data og filtrer uønskede sensor data. Dette gir fortsatt en del data for å bruke maskin læring, men fungerer fint hvis du ikke ønsker enda mere nøyaktighet. Alternativet er jo å bruke en databaseserver som Maria db, men jeg ønsker KISS prinsippet (Keep it simple and stupid) eller bare droppe å bruke maskinlæring. Jeg spurte utvikler om man kunne bruke statistics data (e.g. energy data) da dette tar ikke så stor plass, men han skrev at emhass trengte Wattdata fra Pulse.

Jeg bruker en Appdaemon app som jeg er godt fornøyd med som heter ad-automoli https://github.com/benleb/ad-automoli for å styre lys. . 1. Jeg bruker flere HA scener som har forskjellig lysstyrke og varme 2. Se på disable_switch_entities: En annen app jeg også er fornøyd med når jeg bruker Appdaemon er ControllerX, https://xaviml.github.io/controllerx/ som gjør det veldig enkelt å sette opp fjernkontroller for å styre lys eller media. Jeg vil også anbefale Schedy https://hass-apps.readthedocs.io/en/stable/apps/schedy/ når du først bruker Appdaemon. Den beste multi purpose scheduler som finnes for HA, mener nå jeg.

Med så mange noder tror jeg mesh nettverket ditt er bra nok. Jeg ville ha vurdert enten å gå tilbake til Aeotec Gen 5+ eller kjøpt Zooz - ZST10-700 som vil gi deg lengre rekkevidde.

Har ikke kjøpt noe ny z-wave kontroller ennå. Aeotec Gen 5+ fungerer fortsatt fint. Vurderer likevel å kjøpe Zooz - ZST10-700 som Tronika selger. Denne er støtte i Home Assistent https://www.home-assistant.io/docs/z-wave/controllers/ Kunne også vurdert zooz 800serie, men NVM Backup/Restore er ennå ikke støttet for 800 serie. En ting du kunne ha prøvd er å bygge opp et mer stabilt z-wave mesh nettverk med flere zwave repetere. Selv om antennen på kontrolleren er dårlig vil zwave repetere som er nærme kontrolleren videresende meldinger fra batteri noder eller andre noder som også er zwave repetere. Mer informasjon her: https://docs2.hubitat.com/how-to/build-a-solid-zwave-mesh

Det er mulig jeg har misforstått dette, men jeg har løst problemet med at jeg får en time forsinkelse i HA Dashboard ved å bruke sensor.ams_cf58_houruse. Du kan også sende en mail til strømselskapet å be de rekonfigurere strømmåler til å bruke DLMS data. Mer om dette her: https://github.com/UtilitechAS/amsreader-firmware/issues/630

Du kan f.eks. gå fra zha til zigbee2mqtt da det meste av zigbee enhet informasjonen ligger på usb stick https://community.home-assistant.io/t/migrate-from-zha-to-z2m/634440/5. Men du må knytte navn på nytt til hver enhet noe som kan være en del arbeid med. Er litt usikker på om dette fungerer med deconz. Det beste er nok likevel å starte nytt.

Du har tre valg og det er ZHA som er innebygd i Home Assistant (https://www.home-assistant.io/integrations/zha/) og Deconz (https://www.home-assistant.io/integrations/deconz/) og zigbee2mqtt du må kjøre som en Home Assistant addon. Conbee 2 er støttet i alle de tre zigbee løsningene. Jeg bruker zha nå etter å ha brukt deconz og deretter zigbee2mqtt tidligere. Fordelen med zha er den tette intergrasjonen med home assistant. Ulempen er ikke så god støtte for alle zigbee enheter. Men kjøper en riktig enhet så slipper man mye av dette bryet. Blackadder har en godt oppdatert liste: https://zigbee.blakadder.com/zha.html Zigbee2mqtt bruker nok de fleste. God zigbee enhet støtte og godt bruker webgrensesnitt. Kommuniserer med Home Assistant ved hjelp av mqtt.

For Forfatter av programmet mener at en kan spare 5 % og 8% daglig med lineær optimisering enn å bruke en regel basert fremgangsmåte. Kilde: https://community.home-assistant.io/t/emhass-an-energy-management-for-home-assistant/338126 Men det blir likevel ikke mye i kroner på å spare strøm (ENØK tiltak) når vi har tidenes beste strømstøtte https://www.nrk.no/norge/xl/de-som-tjener-best_-fikk-mest-stromstotte-1.16638845

Nei, machine learning forecast (ml forecast) av ditt historiske strømforbruk vil ikke forsvinne. ml forecast data lagres og brukes når du bruker mpc til å optimere den beste strømsparing. Model Predictive Control (mpc) eller day-ahead optimisering kan bruke forecast data om historisk strømforbruk (naive eller ml forecast data), strømproduksjon fra solceller, strømpris for salg av solcellestrøm og kjøp av importert strøm til å lage en 24 timers forecast av hvilke tidspunkter det er best å bruke eller spare strøm. Håper dette hjelper.

Er ikke sikker på om jeg svarer på spørsmålet ditt, men her hvordan jeg bruker mlforecast i emhass. Jeg bruker ml forecast i emhass med default verdier (https://emhass.readthedocs.io/en/latest/mlforecaster.html) bortsett fra at jeg bruker "days_to_retrieve" = 10 i rest kommandoene for å spesifisere 10 dager med sensordata som mlforecast skal hente ut i fra homeassistant databasen. Dette er data fra "sensor.power_load_no_var_loads". Skal helst være flere dager enn dette. Jeg bruker også i "num_lags" = 24 (tilsvarer 24 timer i døgnet) da jeg bruker nordpool data som har strømpriser for hver time. rest_command: ml_forecast_fit: url: http://localhost:5000/action/forecast-model-fit method: POST content_type: "application/json" timeout: 300 payload: >- { "days_to_retrieve": 10, "num_lags": 24 } ml_forecast_tune: url: http://localhost:5000/action/forecast-model-tune method: POST content_type: "application/json" timeout: 300 payload: >- { } Kjører hver uke denne automatiseringen for å oppdatere mlforecast fit: alias: EMHASS ml forecaster model fit each sunday 23:05 description: "" trigger: - platform: time at: "23:05:00" condition: - condition: time weekday: - sun action: - service: rest_command.ml_forecast_fit data: {} mode: single og deretter ml forecast tune: alias: EMHASS ml forecaster model tune each sunday 23:15 description: "" trigger: - platform: time at: "23:15:00" condition: - condition: time weekday: - sun action: - service: rest_command.ml_forecast_tune data: {} mode: single I loggen ser det slik ut etter å ha kjørt mlforecast automatiseringen. 2023-12-21 17:29:24,348 - web_server - INFO - Setting up needed data 2023-12-21 17:29:24,461 - web_server - INFO - Retrieve hass get data method initiated... 2023-12-21 17:29:57,908 - web_server - INFO - >> Performing a machine learning forecast model fit... 2023-12-21 17:29:57,910 - web_server - INFO - Performing a forecast model fit for load_forecast 2023-12-21 17:29:57,930 - web_server - INFO - Training a KNeighborsRegressor model 2023-12-21 17:29:58,042 - web_server - INFO - Elapsed time for model fit: 0.11151599884033203 2023-12-21 17:29:58,128 - web_server - INFO - Prediction R2 score of fitted model on test data: -0.333963984019525 2023-12-21 17:30:00,257 - web_server - INFO - Setting up needed data 2023-12-21 17:30:00,265 - web_server - INFO - >> Publishing data... 2023-12-21 17:30:00,265 - web_server - INFO - Publishing data to HASS instance 2023-12-21 17:30:00,330 - web_server - INFO - Successfully posted to sensor.p_pv_forecast = -6.44 2023-12-21 17:30:00,375 - web_server - INFO - Successfully posted to sensor.p_load_forecast = 1917.72 2023-12-21 17:30:00,407 - web_server - INFO - Successfully posted to sensor.p_deferrable0 = 1964.0 2023-12-21 17:30:00,437 - web_server - INFO - Successfully posted to sensor.p_deferrable1 = -5331.21 2023-12-21 17:30:00,466 - web_server - INFO - Successfully posted to sensor.p_deferrable2 = 2193.0 2023-12-21 17:30:00,499 - web_server - INFO - Successfully posted to sensor.p_deferrable3 = 0.0 2023-12-21 17:30:00,528 - web_server - INFO - Successfully posted to sensor.p_deferrable4 = 1450.0 2023-12-21 17:30:00,564 - web_server - INFO - Successfully posted to sensor.p_deferrable5 = 0.0 2023-12-21 17:30:00,592 - web_server - INFO - Successfully posted to sensor.p_deferrable6 = 3110.06 2023-12-21 17:30:00,621 - web_server - INFO - Successfully posted to sensor.p_grid_forecast = 5310.0 2023-12-21 17:30:00,646 - web_server - INFO - Successfully posted to sensor.total_cost_fun_value = -202.03 2023-12-21 17:30:00,671 - web_server - INFO - Successfully posted to sensor.optim_status = Infeasible 2023-12-21 17:30:00,702 - web_server - INFO - Successfully posted to sensor.unit_load_cost = 1.4 2023-12-21 17:30:00,734 - web_server - INFO - Successfully posted to sensor.unit_prod_price = 0.065 2023-12-21 17:30:31,107 - web_server - INFO - Setting up needed data 2023-12-21 17:30:31,117 - web_server - INFO - Retrieve hass get data method initiated... 2023-12-21 17:31:00,751 - web_server - INFO - >> Performing a machine learning forecast model tune... 2023-12-21 17:31:00,757 - web_server - INFO - Bayesian hyperparameter optimization with backtesting Number of models compared: 70, 10 bayesian search in each lag configuration. lags grid: 0%| | 0/7 [00:00<?, ?it/s] lags grid: 14%|█▍ | 1/7 [00:09<00:59, 9.97s/it] lags grid: 29%|██▊ | 2/7 [00:11<00:25, 5.17s/it] lags grid: 43%|████▎ | 3/7 [00:13<00:14, 3.58s/it] lags grid: 57%|█████▋ | 4/7 [00:15<00:08, 2.84s/it] lags grid: 71%|███████▏ | 5/7 [00:16<00:04, 2.40s/it] lags grid: 86%|████████▌ | 6/7 [00:18<00:02, 2.24s/it] lags grid: 100%|██████████| 7/7 [00:20<00:00, 2.05s/it] lags grid: 100%|██████████| 7/7 [00:20<00:00, 2.91s/it] 2023-12-21 17:31:21,247 - web_server - INFO - Elapsed time: 20.490362644195557 2023-12-21 17:31:21,355 - web_server - INFO - R2 score for optimized prediction in train period: -0.30239850496571674 2023-12-21 17:31:21,362 - web_server - INFO - R2 score for optimized prediction in test period: -0.08380513951771618 2023-12-21 17:31:21,362 - web_server - INFO - Number of optimal lags obtained: 48 I Emhass konfigurasjonen endrer du fra naive til mlforecast. Kjør deretter automatiseringen for day-ahead forecast optimisering. For mitt vedkommende er det å kjøre rest kommandoen: alias: EMHASS day-ahead optimization description: "" trigger: - platform: time at: "13:45:00" condition: [] action: - service: rest_command.trigger_tibber_forecast data: {} mode: single Loggen ser slik ut i emhass hvis alt går bra. 2023-12-21 17:34:21,698 - web_server - INFO - Setting up needed data 2023-12-21 17:34:21,710 - web_server - INFO - Retrieving weather forecast data using method = scrapper 2023-12-21 17:34:29,123 - web_server - INFO - Retrieving data from hass for load forecast using method = mlforecaster 2023-12-21 17:34:29,124 - web_server - INFO - Retrieve hass get data method initiated... 2023-12-21 17:34:56,966 - web_server - INFO - >> Performing dayahead optimization... 2023-12-21 17:34:56,967 - web_server - INFO - Performing day-ahead forecast optimization 2023-12-21 17:34:57,005 - web_server - INFO - Perform optimization for the day-ahead 2023-12-21 17:34:57,133 - web_server - INFO - Status: Infeasible 2023-12-21 17:34:57,133 - web_server - INFO - Total value of the Cost function = -138.77

Vannbåren varmesystem er en flyttbar last så i utgangspunktet kan emhass brukes til å styre varmen. Jeg bruker emhass til oppvarming av varmtvannsbereder noe som også gjøres ved vannbåren varmesystem. Du tenker kanskje på å bygge et blått batteri istedenfor et husbatteri. Leste litt om dette her før monterte solceller: https://solcellekysten.no/2016/09/24/energistyring/

Kampstrup og Pulse - kjente utfordringer https://support.tibber.com/nb/articles/5697101-kampstrup-og-pulse-kjente-utfordringer