Mitsubishi Ecodan warmtepomp uitlezen via cn105 + esp32

[HeJ]

xoror schreef op dinsdag 9 juni 2026 @ 21:36:
Vandaag een drukke dag, out in the lab. Hier een klein stukje over Odin beschikbaarheid: https://github.com/gekkek...iscussioncomment-17241472

@Loonen138 Hmm dat is apart die overwrite. Ik zal even na proberen te spelen. Over het haperen van Asgard, zou je logging naast kunnen laten lopen ? Dus in een aparte tab logging mee laten lopen en kijken wat je ziet op het moment dat hij weg valt? Ik zie die gedrag namelijk niet bij mij.

Ik revert die webhook, en kijk daar later een keer naar. Aangezien je al wat anders gaat gebruiken.

@bilgy_no1 Je kan altijd zelf de hoek invullen. Maar Oost + West lijken mij 2 arrays of niet? (sorry handleiding moet ik nog updaten: zie https://github.com/gekkek...iscussioncomment-17200633)
De shelly kan aan de USB, dan kan je toch iets van 1x per 5m updaten? dat zou wel voldoende moeten zijn.

@HeJ select.ecodan_heatpump_energy_meter_source op HA/REST api, en dan waarde (dagelijkse teller) wegschrijven in number.ecodan_heatpump_kwh_meter_feedback

Mijn energy meter schrijft alleen ‘totale’ meterstand weg, deze is ‘out of range’ voor Asgard.

kan iemand mij helpen met een script dit naar dagelijks om te zetten?

[xoror]

@HeJ Kan je niets hiervan gebruiken ?
https://github.com/gekkek...n/automations/energy.yaml

Onderin staat ook hoe je z'n integral moet maken. Een van die opties is een dagelijkse reset, moet je even de HA documentatie raadplegen.

[ Voor 20% gewijzigd door xoror op 24-06-2026 00:18 ]

[drluna]

Hoe voorkom ik dat Odin gaat koelen bij de extreme energieprijzen vanavond?

Min Solar Coverage staat op 75, kWh Penalty staat op 0,3

Wellicht een idee om naast "Cheap" Threshold ook een "Expensive" toe te voegen?

[img=800,161]blob:https://gathering.tweakers.net/e8afd668-c52d-4b60-9bf2-11732a2f9a0a[/img]

[bilgy_no1]

drluna schreef op woensdag 24 juni 2026 @ 07:30:
Hoe voorkom ik dat Odin gaat koelen bij de extreme energieprijzen vanavond?

Min Solar Coverage staat op 75, kWh Penalty staat op 0,3

Wellicht een idee om naast "Cheap" Threshold ook een "Expensive" toe te voegen?

[[url="blob:https://gathering.tweakers.net/e8afd668-c52d-4b60-9bf2-11732a2f9a0a"]Afbeelding[/url]]

Prohibit Cooling in Asgard aanvinken?

[xoror]

Hier doe ik solar only cooling met 100 solar coverage. Hij skipt hier de dure uren.

Het probleem is dat alle woningen nu te warm zijn ws. De straf daarvoor is hoger (5x dag gemiddelde) dan die 1.2 euro / kWh. Hij zal dus altijd willen koelen om binnen de comfort bandbreedte te komen.

Je zou tijdelijk de band breedte kunnen verruimen voor die uren vandaag.

Even handmatig prohibit cooling die uren instellen kan ook.

Als dit regelmatig gaat voorkomen, moet ik even kijken of ik die penalty daarvoor kan tweaken. Voorlopig is dit heel uitzonderlijk

[ Voor 13% gewijzigd door xoror op 24-06-2026 07:47 ]

[bilgy_no1]

xoror schreef op woensdag 24 juni 2026 @ 07:45:
Hier doe ik solar only cooling met 100 solar coverage. Hij skipt hier de dure uren.

Het probleem is dat alle woningen nu te warm zijn ws. De straf daarvoor is hoger (5x dag gemiddelde) dan die 1.2 euro / kWh. Hij zal dus altijd willen koelen om binnen de comfort bandbreedte te komen.

Je zou tijdelijk de band breedte kunnen verruimen voor die uren vandaag.

Even handmatig prohibit cooling die uren instellen kan ook.

Als dit regelmatig gaat voorkomen, moet ik even kijken of ik die penalty daarvoor kan tweaken. Voorlopig is dit heel uitzonderlijk

Of een harde prohibit boven een instelbare prijs indien onvoldoende solar coverage? Want hoewel deze prijzen heel uitzonderlijk kan ik me ook voorstellen dat mensen vanaf een veel lagere prijs (€0,40 per kWh bijv) al denken "laat maar zitten die koeling".

Maar goed. Ik heb lucht-lucht airco's los van de warmtepomp. Werkt prima en geen condens issues. Nu moet ik alleen die Daikins nog even net zo slim maken als Odin...

[drluna]

bilgy_no1 schreef op woensdag 24 juni 2026 @ 10:20:
[...]

Of een harde prohibit boven een instelbare prijs indien onvoldoende solar coverage? Want hoewel deze prijzen heel uitzonderlijk kan ik me ook voorstellen dat mensen vanaf een veel lagere prijs (€0,40 per kWh bijv) al denken "laat maar zitten die koeling".

Maar goed. Ik heb lucht-lucht airco's los van de warmtepomp. Werkt prima en geen condens issues. Nu moet ik alleen die Daikins nog even net zo slim maken als Odin...

Precies dit, nu heb ik een automation in home assistant welke Prohibit cooling aanzet.

[Johnny_Hasselt]

@xoror is het mogelijk om ODIN zichtbaar te maken in HA? Vermits ik veel in het buitenland verblijf is het te omslachtig om via HA web interface ODIN te bereiken.

Bedankt, J

[xoror]

@Johnny_Hasselt Wat zou je willen zien in HA dan ? De Odin settings zijn eenmalig in stellen en verder doe je niet zoveel meer aan.

Wat ik zelf doe is naar thuis netwerk inloggen dmv wireguard of tailscale. Dat werkt veel beter, en heb je toegang tot alles ?

[Johnny_Hasselt]

xoror schreef op maandag 29 juni 2026 @ 10:25:
@Johnny_Hasselt Wat zou je willen zien in HA dan ? De Odin settings zijn eenmalig in stellen en verder doe je niet zoveel meer aan.

Wat ik zelf doe is naar thuis netwerk inloggen dmv wireguard of tailscale. Dat werkt veel beter, en heb je toegang tot alles ?

Niet zoveel maar de mogelijkheid hebben om de ESP te restarten en de logs......online status kan ik zien in Asgard.

De rest zijn fixed values, dat weet ik.... Maar voor de meesten is dit nieuw en die instellingen voor de scheduler was ook nuttig voor mij in HA.. het zal wat tuning zijn de eerste maanden van mijne kant.

Als ik weg van huis ben kan dit voor maanden zijn, vrouwke thuis zal moeite hebben als ik zeg doe dit en dan dat aan de phone 🤗.

Was ma een vraag en indien te moeilijk zal ik wel een manier vinden om bv een reset te doen.... Mss die USB poort van mijn HA gebruiken, die wordt ook effe spanningsloos na een update/re-start van HA.

En ja, ik heb toegang tot alles...

Bedankt, J

[xoror]

@Johnny_Hasselt Odin hoef je niet te herstarten. Als hij 'hangt' dan reboot hij vanzelf. Er draait een watchdog timer, als hij te lang ergens hangt wordt hij herstart.

Bij normaal gebruik is het dus niet nodig. Wat betreft logging, dat is geen sensor die je in HA kan hangen. Logging is voor trouble shooting.

Mijn idee was juist stand alone, zodat we geen afhankelijkheden en beperkingen hebben. Voor HA moet je weer met mqtt gaan rommelen. Het voegt vrij weinig toe vergeleken met de lokale web interface voor al dat extra werk. Heb helaas alleen 2 handjes hier, en focus is om de engine voor iedereen goed laten werken.

[tromphakvoort]

Sinds de update van ODIN naar 1.0.1 faalt het ophalen van energieprijzen bij mij. @xoror enig idee wat dit kan veroorzaken? Heb al geprobeerd de data source terug te zetten naar origineel maar dat lijkt t.o.v. entso-e geen verschil te maken.

Hierbij mijn laatste logs:

W (37790413) [2026-06-30 11:03:00.559] FETCH: ENTSO-E: gap at local h=38, using average 50.00
W (37790423) [2026-06-30 11:03:00.568] FETCH: ENTSO-E: gap at local h=39, using average 50.00
W (37790433) [2026-06-30 11:03:00.576] FETCH: ENTSO-E: gap at local h=40, using average 50.00
W (37790443) [2026-06-30 11:03:00.584] FETCH: ENTSO-E: gap at local h=41, using average 50.00
W (37790443) [2026-06-30 11:03:00.592] FETCH: ENTSO-E: gap at local h=42, using average 50.00
W (37790453) [2026-06-30 11:03:00.601] FETCH: ENTSO-E: gap at local h=43, using average 50.00
W (37790463) [2026-06-30 11:03:00.609] FETCH: ENTSO-E: gap at local h=44, using average 50.00
W (37790473) [2026-06-30 11:03:00.617] FETCH: ENTSO-E: gap at local h=45, using average 50.00
W (37790483) [2026-06-30 11:03:00.625] FETCH: ENTSO-E: gap at local h=46, using average 50.00
W (37790493) [2026-06-30 11:03:00.634] FETCH: ENTSO-E: gap at local h=47, using average 50.00
I (37790493) [2026-06-30 11:03:00.642] FETCH: ENTSO-E: 0/48 local hours parsed for BZN=NL
W (37790503) [2026-06-30 11:03:00.650] FETCH: ENTSO-E: low count (0). Payload: <?xml version="1.0" encoding="UTF-8"?>
<Acknowledgement_MarketDocument
	xmlns="urn:iec62325.351:tc57wg16:451-1:acknowledgementdocument:7:0">
	<mRID>9ff5fc9d-f46d-4</mRID>
	<createdDateTime>2026-06-30T0W (37790523) [2026-06-30 11:03:00.673] FETCH: ENTSO-E retry failed — trying Energy-Charts fallback
I (37790543) [2026-06-30 11:03:00.683] FETCH: Energy-Charts URL: https://api.energy-charts.info/price?bzn=NL&start=2026-06-30&end=2026-07-01
I (37791003) [2026-06-30 11:03:01.152] esp-x509-crt-bundle: Certificate validated
E (37791543) [2026-06-30 11:03:01.691] FETCH: Energy-Charts fetch failed! HTTP status: 404
I (37791543) [2026-06-30 11:03:01.692] FETCH: Weather source: Open-Meteo (free)
I (37791683) [2026-06-30 11:03:01.829] esp-x509-crt-bundle: Certificate validated
I (37792023) [2026-06-30 11:03:02.167] FETCH: Open-Meteo fetched 48 hours (2 arrays, total_kwp=9.20) in 1 HTTP request
I (37792023) [2026-06-30 11:03:02.170] FETCH: nvs_load_prices: cached day 180 != logical day 181, skipping

[xoror]

@tromphakvoort Ja sinds 18 juni is de data niet zo betrouwbaar meer.
Ik ben het al een dag aan het tracen, maar de fout zit bij entso-e. Of specifiek, de partij die de feed moet uploaden voor NL.

Andere landen werkt gewoon goed. Met een beetje geluk komt de data wel vandaag door.
Odin 1.0.1 brengt juist verbetering hiervoor. Hij probeert namelijk elk uur net zo lang tussen 15.00-00:00 tot de data binnenkomt. Iedereen haalt data van entso-e, en de data van vandaag is er gewoon niet. Als je met de hand queried by energy charts zie je dat de data voor NL er gewoon niet is: https://api.energy-charts...2026-06-30&end=2026-07-01

https://api.energy-charts...2026-06-29&end=2026-06-30 is er dan wel, maar alleen data voor 29e Voor BE of andere landen bestaat de data wel.

Maar ziet er naar uit dat ik gewoon hele dag moet proberen.

[tromphakvoort]

@xoror ah okey, dan blijf ik het gedurende dag/week wel checken.

[xoror]

@tromphakvoort Ik zal ergens deze week de update pushen die hele dag door probeert.
Maar andere projecten hebben er dus ook helaas last van: https://github.com/JaccoR/hass-entso-e/issues/314

[Blackraven]

@xoror Ik vond je keuze voor Entso-e al dapper, mijn ervaringen in HA zijn dat Nordpool stabieler is...
Tegenwoordig gebruik ik GE-spot, die probeert beide, weet niet of dat voor Odin ook een oplossing is als bron?

[ Voor 28% gewijzigd door Blackraven op 30-06-2026 12:52 ]

[xoror]

@Blackraven iedereen zou bij entsoe-e moeten reporten. Maar nordpool moet ik kijken of ik dat mag gebruiken in een product, dat is ook nog een 2e issue. Ik zal GE-Spot eens bekijken, thnx voor de tip

[ Voor 13% gewijzigd door xoror op 30-06-2026 14:23 ]

[tante Truus]

Ik kwam er vanmorgen achter dat Asgard vindt dat de connection status van Odin 'offline' is, maar Odin is gewoon online. Een half uur geleden een update naar 1.0.2 gedaan. Dat ging heel soepel.
Ook heb ik daarvoor vanmorgen de thermostaat op cooling gezet, dat kan er toch niet mee te maken hebben?

De log toont dit (vanaf 12:05:27 in het rood):
12:04:39[I][auto_adaptive:166]: Solver soft-stop: enable stop for hour 12

12:04:39[D][auto_adaptive:612]: [*] Auto-adaptive cycle: independent_zone_temps=0 has_cooling=1 cold_factor=0.00 min_delta=2.00 max_delta=6.50

12:04:39[D][auto_adaptive:377]: Z1 src=2 room=24.7 target=20.5 flow=28.0 flow_rate=0.0 outside=22.0 bias=0.0 H=0 C=0

12:04:39[D][auto_adaptive:415]: Z1 ODIN heating/cooling stopped, solver_load_ratio: -1.00, mode: 0

12:05:27[E][component:389]: http_request set Error flag: unspecified

12:05:27[E][http_request.idf:139]: HTTP Request failed: ESP_ERR_HTTP_CONNECT

12:05:28[E][component:414]: http_request cleared Error flag

12:06:27[E][component:389]: http_request set Error flag: unspecified

12:06:27[E][http_request.idf:139]: HTTP Request failed: ESP_ERR_HTTP_CONNECT

12:06:28[E][component:414]: http_request cleared Error flag

12:07:27[E][component:389]: http_request set Error flag: unspecified

12:07:27[E][http_request.idf:139]: HTTP Request failed: ESP_ERR_HTTP_CONNECT

12:07:28[E][component:414]: http_request cleared Error flag

[xoror]

@tante Truus hmm nee hoort niets uit te maken. Als de cost optimizer maar aan staat. Je ziet in de Odin logs dat hij elk xx:55 wel een optimize request doet?

@tromphakvoort @tante Truus kunnen jullie deze Asgard build proberen? https://github.com/gekkek...eleases/tag/2026-07-01.01

Daar heb ik 10s http timeout ipv 3s. Ik gok dat jullie netwerk net te traag is om binnen de 3s te reageren en daardoor die errors krijgen

[ Voor 47% gewijzigd door xoror op 01-07-2026 12:34 ]

[tante Truus]

@xoror update gedaan.
Asgard kan de Odin nog steeds niet vinden, en in de log nog steeds foutmeldingen:
12:41:59

12:41:59--- Connected to EventStream ---

12:42:16[D][auto_adaptive:057]: Passive thermal window started: room=24.70C

12:42:58[E][component:389]: http_request set Error flag: unspecified

12:42:58[E][http_request.idf:139]: HTTP Request failed: ESP_ERR_HTTP_CONNECT

12:42:59[E][component:414]: http_request cleared Error flag

12:43:58[E][component:389]: http_request set Error flag: unspecified

12:43:58[E][http_request.idf:139]: HTTP Request failed: ESP_ERR_HTTP_CONNECT

12:43:59[E][component:414]: http_request cleared Error flag

12:44:58[E][component:389]: http_request set Error flag: unspecified

12:44:58[E][http_request.idf:139]: HTTP Request failed: ESP_ERR_HTTP_CONNECT

12:44:59[E][component:414]: http_request cleared Error flag

12:45:58[E][component:389]: http_request set Error flag: unspecified

12:45:58[E][http_request.idf:139]: HTTP Request failed: ESP_ERR_HTTP_CONNECT

12:45:59[E][component:414]: http_request cleared Error flag

12:46:58[E][component:389]: http_request set Error flag: unspecified

12:46:58[E][http_request.idf:139]: HTTP Request failed: ESP_ERR_HTTP_CONNECT

12:46:58[D][auto_adaptive:624]: [*] Auto-adaptive cycle: independent_zone_temps=0 has_cooling=1 cold_factor=0.00 min_delta=2.00 max_delta=6.50

12:46:58[D][auto_adaptive:389]: Z1 src=2 room=24.7 target=20.5 flow=28.0 flow_rate=0.0 outside=22.0 bias=0.0 H=0 C=0

12:46:58[D][auto_adaptive:423]: Z1 ODIN data still pending (+5m). Falling back to auto adaptive.

12:46:58[D][auto_adaptive:489]: Z1 target_delta=6.50 cold_factor=0.00 dyn_min=2.00 eff_range=2.00 error_factor=1.00 boost=1.00 linear=0, use_solver=1

12:46:59[E][component:414]: http_request cleared Error flag

[tante Truus]

En Odin toon geen prijzen in de grafiek, maar dat was al bekend en is tgv externe oorzaak heb ik begrepen

[ Voor 8% gewijzigd door tante Truus op 01-07-2026 12:49 ]

[xoror]

@tante Truus Ja zie release notes van 1.02 staat in hoe je even tijdelijk in kan plakken, tot dat gefixed is.

kan je zo kijken of hij de optimization call uit zichzelf doet rond 12:55 ? in Odin log moet je dan een optimization request log zien.

Het ip adres klopt verder ? dus als je http://odin-ip/api/version (vervang odin-ip met echte ip) doet, krijg je dan wel antwoord in je browser ?

[ Voor 23% gewijzigd door xoror op 01-07-2026 12:55 ]

[tante Truus]

@Xoror: Nee, ik merk dat Odin vandaag veel off line is, dat was voorheen niet.
Om 12:55 is er geen optimization geweest. Odin was rond die tijd ook een aantal minuten oflline.
De upload van day-ahead lukt mij ook niet, na plakken gebeurt er niets na klikken op 'upload data'

[xoror]

wat is de wifi status van odin? Klinkt als hele slechte wifi berbinding. Zit hij op een 'verkeerde' access point ?

[ Voor 57% gewijzigd door xoror op 01-07-2026 13:23 ]

[tante Truus]

xoror schreef op woensdag 1 juli 2026 @ 13:21:
wat is de wifi status van odin? Klinkt als hele slechte wifi berbinding. Zit hij op een 'verkeerde' access point ?

Nee, de wifi verbinding is sinds de nieuwe firmware online/offline.
Met firmware 1.0.0 had ik een heel goede stabiele verbinding.
De Odin hangt op 10cm afstand van de wifirouter, dus daar zou het niet aan moeten liggen.

[xoror]

Odin geeft rechts boven wifi sterkte. Met je muis even op staan dan krijg je de waarde te zien.

Druk op de reset knop om odin te rebooten, kijk of hij dan betere wifi krijgt. Je kan ook altijd naar de vorige firmware gaan, maar er is niets gewijzigd tov netwerk, dus dat zou niets uitmaken.

Je had verder al wel recentelijk die Asgard usb upgrade eenmalig gedaan toch?

[tante Truus]

yep, ik heb een paar weken terug de warmtepomp weer open geschroefd om de Asgard met een kabeltje aan de labtop te kunnen flashen. En sindsdien trouw de OTA updates gedaan.

Wifi sterkte Odin is -30dBm, maar hij is een minuutje online, en dan weer een tijdje offline.
Ik heb inmiddels wel in de logs een == NEW OPTIMIZATION REQUEST == voorbij zien komen

[tante Truus]

ik denk dat Odin zich steeds opnieuw opstart, de oudere logdata is na het opnieuw verbinden niet meer zichtbaar.

[xoror]

@tante Truus -30 is goed.
Je kan aan de uptime zien op de main page of hij is gereboot

[ Voor 37% gewijzigd door xoror op 01-07-2026 14:32 ]

[tante Truus]

xoror schreef op woensdag 1 juli 2026 @ 14:05:
@tante Truus -30 is goed.
Je kan aan de uptime rechtsboven in Odin zien of hij is herstart

die is inmiddels 55 minuten, dus opnieuw herstarten is het niet.
Ik heb nu sinds ca 20 minuten wel verbinding tussen Odin en Asgard, en Odin is sinds die tijd ook niet offline geweest. De log geeft ook geen rode teksten meer.

Ik heb vanmorgen (voor het eerst) mijn systeem op koelen gezet (via de MRC). Daarna ook in Asgard bij de Thermostat mode, en de lockout duration op 45 min.

Het enige dat anders is, is dat de DHW-run gestart is. Sinds die tijd lijkt de Odin continu online te zijn.

[ Voor 12% gewijzigd door tante Truus op 01-07-2026 14:18 ]

[xoror]

@tante Truus Moet je even in de gaten houden. Maar er zit geen wijziging in jet netwerk deel, alleen data fetch retry.

Het is wel zo dat wanneer je Odin upgraded, hij even voor Asgard offline is. Hij zou meestal wel weer binnen 5m online moeten zijn in Asgard.

[bilgy_no1]

Vandaag de updates gedaan. Beide goed verlopen.

Op Entso-E lijkt weer een glitch te zitten, want de prijzen voor vandaag zijn niet meer te zien. Gemiddelde tot aan middernacht; 2 juli staat er wel goed in. Op de website van Entso-E zelf is inderdaad ook geen data te vinden voor vandaag, dus het ligt echt aan die bron.

En wellicht kunnen we nog meer lol verwachten met de prijzen... Ook Zonneplan gaat over op kwartierdata. Daarmee zijn de meesten nu over denk ik. Ik weet niet of het voor de aansturing met Odin/Asgard veel uitmaakt, aangezien een run per kwartier toch niet zo nuttig is denk ik.

[xoror]

plak deze prijzen in voor vandaag en morgen:

YAML:

{"prices":[0.3272,0.3125,0.3059,0.3076,0.3122,0.3199,0.3591,0.3708,0.3424,0.3066,0.2811,0.2724,0.2677,0.2554,0.2482,0.2428,0.2437,0.2575,0.2784,0.3338,0.4072,0.427,0.3723,0.3221,0.3232,0.3036,0.293,0.2729,0.2633,0.2652,0.2724,0.2652,0.2359,0.1819,0.1389,0.1391,0.1392,0.1393,0.1343,0.1314,0.1328,0.1377,0.1929,0.2426,0.2746,0.2896,0.3031,0.2913]}

Ben aan het bekijken of ik een secundaire bron kan instellen. Dus als NL prijzen er niet zijn, dat je bijv BE prijs kan pakken. Voor de optmizer maakt het niet zoveel uit. De organisatie die de NL prijzen moet publiceren laat nogal wat steken vallen

[edit] De data voor 2 juli is er idd. Dus na vannacht moet hij het weer normaal doen.

We rekenen met uur prijzen, je warmte pomp kan niet per kwartier reageren. Ik haal dus ook kwartier prijzen op, maar pak dan gemiddelde daarover per uur

[ Voor 15% gewijzigd door xoror op 01-07-2026 16:52 ]

[Johnny_Hasselt]

ODIN actie op DHW:

Setpoint staat op 50, er was een Legionella run geweest waardoor temperatuur nog boven setpoint was.

ODIN wilt toch een run doen om 19h00 maar als die 66 graden wilt bereiken zal moeilijk zijn met mijn WP.

Klopt deze actie?

[xoror]

@Johnny_Hasselt Hmm nee dat hoort niet.

Ik denk dat het volgende aan de hand is.
- Legionella is gestart, en je hebt mijn automation gebruikt om de dhw setpoint naar 56c in te stellen
- Tijdens legeionella is er waarschijnlijk een optimalisatie call geweest, die ziet: water temp is laag, setpoint is 56c. Hij gaat dan ook dhw inplannen. Dit doet hij door tijdelijk +10c bij de huidige setpoint op te tellen. Na 5m zou hij het weer moeten herstellen. Het zou geen effect moeten hebben, de legionella heeft voorrang.

Dus dat is even een timing issue. Ik denk dat ik het volgende moet doen:
Bij het plannen, moet ik kijken of er een legionella actief is. Zo ja, dan moet ik de dhw planning uitzetten voor dat uur. Genoteerd, en gaan we oplossen (in Asgard).

[bilgy_no1]

xoror schreef op woensdag 1 juli 2026 @ 16:17:
plak deze prijzen in voor vandaag en morgen:

YAML:

{"prices":[0.3272,0.3125,0.3059,0.3076,0.3122,0.3199,0.3591,0.3708,0.3424,0.3066,0.2811,0.2724,0.2677,0.2554,0.2482,0.2428,0.2437,0.2575,0.2784,0.3338,0.4072,0.427,0.3723,0.3221,0.3232,0.3036,0.293,0.2729,0.2633,0.2652,0.2724,0.2652,0.2359,0.1819,0.1389,0.1391,0.1392,0.1393,0.1343,0.1314,0.1328,0.1377,0.1929,0.2426,0.2746,0.2896,0.3031,0.2913]}

Ben aan het bekijken of ik een secundaire bron kan instellen. Dus als NL prijzen er niet zijn, dat je bijv BE prijs kan pakken. Voor de optmizer maakt het niet zoveel uit. De organisatie die de NL prijzen moet publiceren laat nogal wat steken vallen

[edit] De data voor 2 juli is er idd. Dus na vannacht moet hij het weer normaal doen.

We rekenen met uur prijzen, je warmte pomp kan niet per kwartier reageren. Ik haal dus ook kwartier prijzen op, maar pak dan gemiddelde daarover per uur

Beetje vreemd:

Odin log zegt:

mRID>71b4f11f-d24b-4</mRID>E (20950758) [2026-07-01 20:46:20.590] FETCH: ENTSO-E: both hosts failed for BZN=NL
W (20950768) [2026-07-01 20:46:20.599] FETCH: ENTSO-E retry failed — trying Energy-Charts fallback
I (20950778) [2026-07-01 20:46:20.608] FETCH: Energy-Charts URL: https://api.energy-charts...2026-07-01&end=2026-07-02
I (20951248) [2026-07-01 20:46:21.077] esp-x509-crt-bundle: Certificate validated
W (20951728) [2026-07-01 20:46:21.565] FETCH: Energy-Charts: no data for local hour 0, using average 75.89
W (20951728) [2026-07-01 20:46:21.565] FETCH: Energy-Charts: no data for local hour 1, using average 75.89
W (20951738) [2026-07-01 20:46:21.573] FETCH: Energy-Charts: no data for local hour 2, using average 75.89
W (20951748) [2026-07-01 20:46:21.582] FETCH: Energy-Charts: no data for local hour 3, using average 75.89
W (20951758) [2026-07-01 20:46:21.591] FETCH: Energy-Charts: no data for local hour 4, using average 75.89
W (20951768) [2026-07-01 20:46:21.601] FETCH: Energy-Charts: no data for local hour 5, using average 75.89
W (20951778) [2026-07-01 20:46:21.610] FETCH: Energy-Charts: no data for local hour 6, using average 75.89
W (20951788) [2026-07-01 20:46:21.619] FETCH: Energy-Charts: no data for local hour 7, using average 75.89
W (20951798) [2026-07-01 20:46:21.629] FETCH: Energy-Charts: no data for local hour 8, using average 75.89
W (20951808) [2026-07-01 20:46:21.638] FETCH: Energy-Charts: no data for local hour 9, using average 75.89
W (20951818) [2026-07-01 20:46:21.648] FETCH: Energy-Charts: no data for local hour 10, using average 75.89
W (20951828) [2026-07-01 20:46:21.657] FETCH: Energy-Charts: no data for local hour 11, using average 75.89
W (20951828) [2026-07-01 20:46:21.666] FETCH: Energy-Charts: no data for local hour 12, using average 75.89
W (20951838) [2026-07-01 20:46:21.676] FETCH: Energy-Charts: no data for local hour 13, using average 75.89
W (20951848) [2026-07-01 20:46:21.685] FETCH: Energy-Charts: no data for local hour 14, using average 75.89
W (20951858) [2026-07-01 20:46:21.695] FETCH: Energy-Charts: no data for local hour 15, using average 75.89
W (20951868) [2026-07-01 20:46:21.704] FETCH: Energy-Charts: no data for local hour 16, using average 75.89
W (20951878) [2026-07-01 20:46:21.714] FETCH: Energy-Charts: no data for local hour 17, using average 75.89
W (20951888) [2026-07-01 20:46:21.723] FETCH: Energy-Charts: no data for local hour 18, using average 75.89
W (20951898) [2026-07-01 20:46:21.733] FETCH: Energy-Charts: no data for local hour 19, using average 75.89
W (20951908) [2026-07-01 20:46:21.742] FETCH: Energy-Charts: no data for local hour 20, using average 75.89
W (20951918) [2026-07-01 20:46:21.752] FETCH: Energy-Charts: no data for local hour 21, using average 75.89
W (20951928) [2026-07-01 20:46:21.761] FETCH: Energy-Charts: no data for local hour 22, using average 75.89
W (20951938) [2026-07-01 20:46:21.771] FETCH: Energy-Charts: no data for local hour 23, using average 75.89
I (20951948) [2026-07-01 20:46:21.780] FETCH: Energy-Charts: produced 48 hourly prices for BZN=NL
I (20951958) [2026-07-01 20:46:21.791] FETCH: apply_tax: converted 48 prices to all-in for BZN=NL (tax=0.1088 EUR/kWh, VAT=1.210x)
I (20951968) [2026-07-01 20:46:21.800] FETCH: fetch_prices: gap at h=0 filled with cached price 0.2235 (was avg-fallback)
I (20951978) [2026-07-01 20:46:21.811] FETCH: fetch_prices: gap at h=1 filled with cached price 0.2235 (was avg-fallback)
I (20951988) [2026-07-01 20:46:21.821] FETCH: fetch_prices: gap at h=2 filled with cached price 0.2235 (was avg-fallback)
I (20951998) [2026-07-01 20:46:21.832] FETCH: fetch_prices: gap at h=3 filled with cached price 0.2235 (was avg-fallback)
I (20952008) [2026-07-01 20:46:21.843] FETCH: fetch_prices: gap at h=4 filled with cached price 0.2235 (was avg-fallback)
I (20952018) [2026-07-01 20:46:21.853] FETCH: fetch_prices: gap at h=5 filled with cached price 0.2235 (was avg-fallback)
I (20952028) [2026-07-01 20:46:21.864] FETCH: fetch_prices: gap at h=6 filled with cached price 0.2235 (was avg-fallback)
I (20952038) [2026-07-01 20:46:21.875] FETCH: fetch_prices: gap at h=7 filled with cached price 0.2235 (was avg-fallback)
I (20952048) [2026-07-01 20:46:21.885] FETCH: fetch_prices: gap at h=8 filled with cached price 0.2235 (was avg-fallback)
I (20952058) [2026-07-01 20:46:21.896] FETCH: fetch_prices: gap at h=9 filled with cached price 0.2235 (was avg-fallback)
I (20952078) [2026-07-01 20:46:21.907] FETCH: fetch_prices: gap at h=10 filled with cached price 0.2235 (was avg-fallback)
I (20952088) [2026-07-01 20:46:21.918] FETCH: fetch_prices: gap at h=11 filled with cached price 0.2235 (was avg-fallback)
I (20952098) [2026-07-01 20:46:21.928] FETCH: fetch_prices: gap at h=12 filled with cached price 0.2235 (was avg-fallback)
I (20952108) [2026-07-01 20:46:21.939] FETCH: fetch_prices: gap at h=13 filled with cached price 0.2235 (was avg-fallback)
I (20952118) [2026-07-01 20:46:21.950] FETCH: fetch_prices: gap at h=14 filled with cached price 0.2235 (was avg-fallback)
I (20952128) [2026-07-01 20:46:21.961] FETCH: fetch_prices: gap at h=15 filled with cached price 0.2235 (was avg-fallback)
I (20952138) [2026-07-01 20:46:21.971] FETCH: fetch_prices: gap at h=16 filled with cached price 0.2235 (was avg-fallback)
I (20952148) [2026-07-01 20:46:21.982] FETCH: fetch_prices: gap at h=17 filled with cached price 0.2235 (was avg-fallback)
I (20952158) [2026-07-01 20:46:21.993] FETCH: fetch_prices: gap at h=18 filled with cached price 0.2235 (was avg-fallback)
I (20952168) [2026-07-01 20:46:22.004] FETCH: fetch_prices: gap at h=19 filled with cached price 0.2235 (was avg-fallback)
I (20952178) [2026-07-01 20:46:22.014] FETCH: fetch_prices: gap at h=20 filled with cached price 0.2235 (was avg-fallback)
I (20952188) [2026-07-01 20:46:22.025] FETCH: fetch_prices: gap at h=21 filled with cached price 0.2235 (was avg-fallback)
I (20952198) [2026-07-01 20:46:22.036] FETCH: fetch_prices: gap at h=22 filled with cached price 0.2235 (was avg-fallback)
I (20952208) [2026-07-01 20:46:22.047] FETCH: fetch_prices: gap at h=23 filled with cached price 0.2235 (was avg-fallback)
I (20952228) [2026-07-01 20:46:22.057] FETCH: fetch_prices: restored 24 of today's hours from cache instead of day-average
W (20952238) [2026-07-01 20:46:22.068] FETCH: fetch_prices: all 24 of today's hours are gap-filled — source has no data for today, signalling retry.
E (20952248) [2026-07-01 20:46:22.081] SCHEDULER: Price fetch failed — will retry at next :15 or :45.
I (21193258) [2026-07-01 20:50:23.092] SCHEDULER: Hourly weather refresh (hour 20)...
I (21193258) [2026-07-01 20:50:23.092] FETCH: Weather source: Open-Meteo (free)
I (21193498) [2026-07-01 20:50:23.327] esp-x509-crt-bundle: Certificate validated
I (21193808) [2026-07-01 20:50:23.640] FETCH: Open-Meteo fetched 48 hours (2 arrays, total_kwp=4.80) in 1 HTTP request
I (21193808) [2026-07-01 20:50:23.642] SCHEDULER: Hourly weather refresh done (48 hours).
I (21485218) [2026-07-01 20:55:15.051] ODIN_SERVER:

Zegt dus overal average ingevuld vanwege missing values.

Maar in de Data tab staat wel een grafiek met schijnbaar juiste prijzen:



In Asgard zie ik dan echter nog steeds een gap in de prijsgrafiek:

[xoror]

De prijs in Asgard komt met de volgende optimalisatie verzoek mee. Dus komt vanzelf goed.
De prijzen zijn er niet voor vandaag maar wel voor morgen, dus hij zeurt dat er geen prijzen zijn voor uur 0-24 en zal terug vallen op wat hij al heeft.

Je moet dus eenmalig die data inladen, en daarna weer op entso-e/open energy charts zetten. Dan gaat het vanaf 00:00 vanzelf goed.

De 1.02 versie heeft ook hele dag door retry om de 30m

[Loonen138]

@xoror Raar probleem bij mij zelf (dus niet bij mijn ouders), op de een of andere manier staat de IN1 Thermostat op OFF sinds 1-7-2026 00:11 (Als ik in Home Assistant terug kijk dan zie ik die tijd).

Bekabeling nagelopen van IN1 naar R1 al is daar niks in veranderd, kast zit dicht, toch voor de zekerheid de UTP kabel vervangen maar helaas geen verschil. Kabel maar vervangen voor zo'n 2 aderige thermostaatkabel van 0,8mm maar dat maakt ook geen verschil.
IN1 blijft op OFF staan en rood lampje van de asgard brand ook niet, dus je zou zeggen dat het aan de kabel\connectie van IN1 naar R1 moet liggen.

ODIN draait op V1.0.2 en Asgard op 2026-06-20.02.
Er is gister nog een DHW gedraaid en vannacht 04:00 nog legionella.

Asgard en ODIN al herstart maar ook geen verschil.
Ecodan uit\aan gezet maar ook geen verschil.
ODIN is online volgens Asgard.
Er is demand volgens de virtual thermostat, 22,6 graden in de woonkamer.
Thermostat mode staat op Cool en temp sensor source op virtaul thermostat input.
Operating mode op Cool Flow Temperature.
Server control staat aan.
Master Room Sensor z1 staat op MRC.
DIPswitches staan nog goed, SW1-8 op 0 en SW2-1 op 1
Het is de FTC6.

Gister waren de problemen rondom het ophalen van de dynamische prijzen maar op dit moment staat ze er gewoon weer in via ENTSO-E source.

En volgens de solver zou die moeten draaien maar lukt dus niet omdat IN1 op off staat.

Ik zag wel dat de aardedraad los zat en dus niet meer aan de schroef vast, leuk die installateurs van de aannemers dus die heb ik weer even vast gemaakt maar lijkt mij sterk dat dit het probleem was\heeft veroorzaakt.

ODIN logs;

code:

=== NEW OPTIMIZATION REQUEST ===
I (142889998) [2026-07-02 14:56:50.093] ODIN_SERVER: Mode: COOLING | Calculated Base EER: 5.61 (Raw EER: 5.44 at 26.7C, Run: 11.0h)
I (142890008) [2026-07-02 14:56:50.101] ODIN_SERVER: Mode: COOLING | Learned Max Cool Capacity: 2.24kW (Avg Run Power: 1.94kW over 11.0h)
I (142890018) [2026-07-02 14:56:50.115] OPTIMIZER: Required memory: 49392 bytes for 6174 nodes.
I (142890028) [2026-07-02 14:56:50.126] ODIN_SERVER: === MEMORY CHECK ===
I (142890038) [2026-07-02 14:56:50.128] ODIN_SERVER: Free RAM before solve: 7134892 bytes
I (142890038) [2026-07-02 14:56:50.136] ODIN_SERVER: Free RAM after solve : 7133648 bytes
I (142890048) [2026-07-02 14:56:50.144] ODIN_SERVER: Lowest RAM ever seen : 6974276 bytes
I (142890058) [2026-07-02 14:56:50.151] ODIN_SERVER: ======================
I (142890068) [2026-07-02 14:56:50.158] ODIN_SERVER: Projected 24h Cons: 0.00 kWh, Prod: 0.00 kWh, Solar: 0.00 kWh, Cost: ~€0.00
I (142890078) [2026-07-02 14:56:50.170] ODIN_SERVER: === OPTIMIZATION COMPLETE (10 ms) | states=161 | nodes=1702/881314 (100% pruned) ===

Asgard logs;

code:

14:43:47
--- Connected to EventStream ---
14:45:53 [D][auto_adaptive:612]: [*] Auto-adaptive cycle: independent_zone_temps=0 has_cooling=1 cold_factor=0.00 min_delta=2.00 max_delta=6.50
14:45:53 [D][auto_adaptive:377]: Z1 src=2 room=22.6 target=21.0 flow=30.5 flow_rate=0.0 outside=21.0 bias=0.0 H=0 C=0
14:45:53 [D][auto_adaptive:415]: Z1 ODIN heating/cooling stopped, solver_load_ratio: -1.00, mode: 0
14:50:53 [D][auto_adaptive:612]: [*] Auto-adaptive cycle: independent_zone_temps=0 has_cooling=1 cold_factor=0.00 min_delta=2.00 max_delta=6.50
14:50:53 [D][auto_adaptive:377]: Z1 src=2 room=22.6 target=21.0 flow=30.5 flow_rate=0.0 outside=21.0 bias=0.0 H=0 C=0
14:50:53 [D][auto_adaptive:415]: Z1 ODIN heating/cooling stopped, solver_load_ratio: -1.00, mode: 0
14:55:23 [I][auto_adaptive:288]: Pre-hour trigger at 13:55 — requesting ODIN solve for hour 14.
14:55:53 [I][auto_adaptive:135]: ODIN production targets loaded (48h). current_hour=13
14:55:54 [D][auto_adaptive:612]: [*] Auto-adaptive cycle: independent_zone_temps=0 has_cooling=1 cold_factor=0.00 min_delta=2.00 max_delta=6.50
14:55:54 [D][auto_adaptive:377]: Z1 src=2 room=22.6 target=21.0 flow=30.5 flow_rate=0.0 outside=21.0 bias=0.0 H=0 C=0
14:55:54 [D][auto_adaptive:415]: Z1 ODIN heating/cooling stopped, solver_load_ratio: -1.00, mode: 0

[ Voor 0% gewijzigd door Loonen138 op 02-07-2026 15:29 . Reden: typfout ]

[xoror]

@Loonen138
Even dubbel checken die rood en blauwe draad zitten wel in R1 op Asgard right?

Test de relay handmatig:
- zet je virtual thermostat op "OFF"
- Ga gaar http://asgard-ip
- zet daar manual relay 1 aan. Controleer of het led rood is, zo ja, controleer de in1 status in asgard.

Het lampje moet eigenlijk rood worden als de manual relay aan staat. Als in1 niet aangaat dat zit er ws iets in de bekabeling weer

[Loonen138]

xoror schreef op donderdag 2 juli 2026 @ 16:12:
@Loonen138
Even dubbel checken die rood en blauwe draad zitten wel in R1 op Asgard right?

Test de relay handmatig:
- zet je virtual thermostat op "OFF"
- Ga gaar http://asgard-ip
- zet daar manual relay 1 aan. Controleer of het led rood is, zo ja, controleer de in1 status in asgard.

Het lampje moet eigenlijk rood worden als de manual relay aan staat. Als in1 niet aangaat dat zit er ws iets in de bekabeling weer

Ja, zit netjes in de R1 maar helaas geen rood lampje op de asgard en IN1 blijft op off met de manual relay op on.
Ik hoor ook de kabel netjes klikken, als ik beide kabels in IN1 druk.



Raar dat het opeens niet meer werkt zonder iets te doen.
Zou het nog nut hebben om de Z2 te testen? IN6 en R2?
Ik heb echter maar een 1 zone warmtepomp.

Anders kan ik nog proberen om het originele aansluiting van asgard terug te zetten om te kijken wat er dan gebeurt, weet ik in ieder geval op de IN1 poorten gewoon normaal werken.

[xoror]

@Loonen138 dat is heel raar. Je zou een z2 firmware op kunnen zetten om R2 te testen, maar R1 moet ook gewoon werken.

Kan je evt buiten de warmtepomp testen ?, dus aan de usb hangen aan je pc, en dan met een multi meter kijken of er verbinding is ?

[bilgy_no1]

Loonen138 schreef op donderdag 2 juli 2026 @ 16:32:
[...]


Ja, zit netjes in de R1 maar helaas geen rood lampje op de asgard en IN1 blijft op off met de manual relay op on.
Ik hoor ook de kabel netjes klikken, als ik beide kabels in IN1 druk.

Op je foto van Asgard lijkt het alsof ze in het 2e en 3e poortje zitten ipv het 1e en 2e vanaf links. Misschien is het vertekend door het perspectief, maar ik zo lijkt het voor mij obv die foto.

[Johnny_Hasselt]

@xoror enkel Om te verstaan en om te leren, wat is deze actie? Die komt elk uur terug met hogere waardes.

[Loonen138]

xoror schreef op donderdag 2 juli 2026 @ 16:43:
@Loonen138 dat is heel raar. Je zou een z2 firmware op kunnen zetten om R2 te testen, maar R1 moet ook gewoon werken.

Kan je evt buiten de warmtepomp testen ?, dus aan de usb hangen aan je pc, en dan met een multi meter kijken of er verbinding is ?

Ik heb met @xoror in de DM getroubleshoot en na een factory flash werkte het weer, raar probleem.

[xoror]

Johnny_Hasselt schreef op donderdag 2 juli 2026 @ 19:13:
@xoror enkel Om te verstaan en om te leren, wat is deze actie? Die komt elk uur terug met hogere waardes.

[Afbeelding]

[Afbeelding]

Jouw huis vertoont extremen, als in 6c verschil op een dag. Daar moet ik wat voorzieningen voor treffen, anders krijg je no path found. Maar is goed dus dat jij het ziet, want dat was voor jouw huis. We schalen de stapjes iets op om het algo te laten werken binnen de geheugen limieten. normaal werken we met 0.05c, bij jou kan dat schalen naar 0.07c. Merk je verder niets van.

[Johnny_Hasselt]

xoror schreef op donderdag 2 juli 2026 @ 19:20:
[...]


Jouw huis vertoont extremen, als in 6c verschil op een dag. Daar moet ik wat voorzieningen voor treffen, anders krijg je no path found. Maar is goed dus dat jij het ziet, want dat was voor jouw huis. We schalen de stapjes iets op om het algo te laten werken binnen de geheugen limieten. normaal werken we met 0.05c, bij jou kan dat schalen naar 0.07c. Merk je verder niets van.

Ik heb wel geupgrade naar 1.0.3

Dat mocht toch of moest ik blijven op de versie die je mij stuurde?

[xoror]

@Johnny_Hasselt altijd laatste versie pakken. dus 1.0.3 is goed.

[trippelb]

@xoror ik gebruik geen Odin of Asguard dus voor mij niet van toepassing maar mogelijk dat je hier wat aan hebt in je project. Hier namelijk ook gerust temperatuurschommelingen van 5-7 graden op een dag. Met name door de zon.

[xoror]

@trippelb Omhoog door de zon, maar omlaag is ws airco?

[trippelb]

Nee uitsluitend ventilatie en natuurlijk de warmtepomp

[Johnny_Hasselt]

Ik heb wel extremen indien de zon schijnt maar niet met die bokkensprongen.

Zoals vandaag, wanneer de zon schijnt op al dat glas - geel gemarkeerd - (glazen dak van 7 op 3,5 en 16m+ glazen vensters van 2.5m hoog... Tja, als alles toe blijft wordt dat een sauna... Dus ik moet wel vensters (schuiframen) openen wat dus goed is. Enkel wanneer het buiten 30+ wordt hou ik alles toe en gebruik ik airco.

Ik heb 2 airco hangen om de temperatuur onder controle te houden in hete zomers... Ik gebruik momenteel niet de vloerkoeling.

Bij 'normale' zomers is het hier gelijk als op Bali.... Alles open wat heerlijk is.

[xoror]

@Johnny_Hasselt Mooi! Maar dat verklaart een hoop.

Je kan wat doorkijk planten zoals bamboe om een beetje natuurlijke schaduw te krijgen.

Ik zou de airco gebruiken vooral om de luchtvochtigheid omlaag te brengen zodat je vloer koeling kan doen. Blijft het langer koel

[ Voor 31% gewijzigd door xoror op 02-07-2026 21:33 ]

[xoror]

Voor de mensen die al 1.0.3 draaien:
Werkt de nieuwe kamer temp schatting goed voor koelen? Deze is sinds 1.0.3 aangepast om met meer data rekening te houden. Hier lijkt hij vrij goed te schatten

[bilgy_no1]

xoror schreef op vrijdag 3 juli 2026 @ 09:35:
Voor de mensen die al 1.0.3 draaien:
Werkt de nieuwe kamer temp schatting goed voor koelen? Deze is sinds 1.0.3 aangepast om met meer data rekening te houden. Hier lijkt hij vrij goed te schatten

[Afbeelding]

Ik vind de schatting gewoon eng goed... Wij hebben airco in de woonkamer die meestal wel lichtjes aan staat. Geen koeling met de warmtepomp. Als ik het grafiekje in de Solver tab bekijk liggen de Actual waarden echt precies op de Expected lijn...

[bilgy_no1]

xoror schreef op donderdag 2 juli 2026 @ 21:32:
@Johnny_Hasselt Mooi! Maar dat verklaart een hoop.

Je kan wat doorkijk planten zoals bamboe om een beetje natuurlijke schaduw te krijgen.

Voor het echte Bali gevoel van @Johnny_Hasselt zou ik palmbomen in de tuin adviseren...

[xoror]

Met laatste pre-release kan je in asgard nu ook de totalen zien in de grafieken. Maakt het toch weer wat eenvoudiger om te monitoren

https://github.com/gekkek...eleases/tag/2026-07-04.01

[Loonen138]

@xoror Feature Request, laatst waren de prijzen meer dan €1 per kWh en vond ik koelen toch best prijzig.
De "Solar-Only Cooling" kan ik niet gebruiken omdat ik geen zonnepanelen heb maar ik heb wel een dynamisch contract.
Kan je iets inbouwen dat je een threshold kan instellen met prijs met kwh wanneer je ook mag koelen?
Bijvoorbeeld onder €0,20 mag je koelen en daarboven niet. Zou wel handig zijn als het veld
(Price per kWH) vrij invulbaar is.
Ik neem aan dat odin/solver er dan ook rekening mee houdt?

Nu los ik dat op via HA maar Odin snapt dat natuurlijk niet in de solver dus geeft vertekend beeld.

P.s. mijn HA automation.

code:

alias: "Ecodan Heatpump - : Cooling Z1 Prohibit op stroomprijs"
description: >
  Zet Cooling Z1 Prohibit aan als stroomprijs > €0,30/kWh, en uit als prijs ≤
  €0,30/kWh.
triggers:
  - entity_id:
      - sensor.tibber_elektriciteitsprijs
    above: 0.25
    id: prijs_hoog
    trigger: numeric_state
  - entity_id:
      - sensor.tibber_elektriciteitsprijs
    below: 0.25
    id: prijs_laag
    trigger: numeric_state
conditions: []
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: prijs_hoog
        sequence:
          - type: turn_on
            device_id: 9bf66944f1c958b985a2ceae4cf5fefe
            entity_id: dffd37f3464b4f12293e8eedb3ac24bd
            domain: switch
      - conditions:
          - condition: trigger
            id: prijs_laag
        sequence:
          - type: turn_off
            device_id: 9bf66944f1c958b985a2ceae4cf5fefe
            entity_id: dffd37f3464b4f12293e8eedb3ac24bd
            domain: switch
mode: single

[xoror]

@Loonen138 @drluna
Ja die is eerder langsgekomen. Ik zal het bekijken.

Odin gaat de dure uren gebruiken in de volgende gevallen
- je zit buiten je band breedte
- je dreigt er buiten te gaan in de komende tijd, en het kost meer om dat te herstellen

We zouden iets van een cap kunnen instellen, als je dat enabled, dan doet hij daarboven niets. Maar dan moet je dus wel accepteren dat je buiten je bandbreedte gaat vallen en dat het mogelijk duurder is om het te herstellen uiteindelijk

@drluna @Loonen138 @barcomoon Ik had al wat testjes meegedaan, maar jullie kunnen nu ook mee helpen testen of het naar behoren werkt. Het gaat om de "stop price". Zie release page voor de pre-release 1.0.4-02

[ Voor 18% gewijzigd door xoror op 04-07-2026 11:50 ]

[Johnny_Hasselt]

@xoror in de Asgard logs word melding gemaakt van outside ecodan temperature....

Wordt die mee in uw algoritmes genomen?

Indien zo, is het mogelijk om die selectief te maken... Reden is dat mijn WP in de zon staat en die temperatuur meting geeft een vertekend beeld....

Ik heb een aparte temperatuur meter die juist meet.... Zie beneden... Die piek van de WP meter is wanneer de zon er vol opstaat en ook nog eens stralingswarmte krijgt van de muur erachter.

[xoror]

@Johnny_Hasselt
Odin kijkt elk uur naar het weer, en heeft als je je lat/lon goed hebt ingesteld, de juiste buiten temperatuur. Odin doet de planning, en laat Asgard uitvoeren. Hij print wel de data, maar wordt overruled dus door Odin. Die schrijft echt een bepaalde vermogen / Ta voor.

Als je alleen auto adaptive gebruikt, dan heeft het een beetje effect bij defrost, maar we hebben al voorzieningen daarvoor (dan wordt de buiten temp gelocked) bijv. Mijn unit staat verder ook vol in de zon hoor.

[Johnny_Hasselt]

@xoror ik merk op dat mijn operating band zeer narrow is in de avond uren, desondanks dat ik die toch breed heb staan in de settings.

Wanneer ik manueel optimization doe is de band juist maar na enkele seconden springt die terug naar een smallere band.

Wat is hier de reden voor dat gebeurd?

[xoror]

@Johnny_Hasselt Dat is hier beschreven: https://github.com/gekkek...-an-optimisation-manually

Je kan dus even snel 'what-if-scenario' doen. De echte planning wordt altijd xx:55 gedaan. Je kan dan je settings testen/uitproberen met die knop. In jouw geval heb je bandwidth aangepast, en die zijn past zichtbaar op de volgende xx:55. De "run optimization" laat het wel direct zien.

[tromphakvoort]

Ik heb een aantal dagen terug de sw1-8 dipswitch weer op on gezet om van de fout in mijn Mitsubishi draadloze thermostaat af te komen, kan het zijn dat daardoor Asgard de wp niet meer kan aansturen? Het lijkt wel of sinds die tijd er geen koeling meer gestuurd wordt. Ik zie bijvoorbeeld voor vandaag dat de verwachtte temperatuur ver buiten de bandbreedte stijgt. Ik zou toch verwachten dat Odin dan nu al gaat sturen om te beginnen met koelen?

[xoror]

@tromphakvoort Nee, als je SW2-1 aan hebt, dan heeft in1 voorrang. Zou gewoon goed moeten gaan.
Heb je de laatste Asgard en Odin draaien ? Ik had van de week een issue opgelost met een passieve woning die maar 0.04c schommeling had per dag terwijl mijn limiet 0.1c was.

[tromphakvoort]

@xoror Heb Odin v1.0.3 draaien en Asgard nog op mijn debug versie, die zal ik even bijwerken naar de laatste versie van jou.

[xoror]

@tromphakvoort Als je in Odin die debug.json kan maken en naar mij kan sturen, kan ik kijken waarom de temp afwijkt. Als je een passief huis hebt, of waarde gemiddelde kamer temp schommeling < 0.1c, moet je ook 1.0.4-xx pre-release draaien.

[Kecin]

Melcloud geeft hier een update aan voor de wifimodule. Is dat veilig om te doen? Of heeft iemand dat al gedaan?

[Gugl]

@Kecin hier al gedraaid voor de airco waaraan dezelfde wifi module hangt, geen problemen. Aan de warmtepomp heb ik m niet meer hangen

[barcomoon]

Ik ben nog even goed aan het kijken naar de Odin set-up. De PV opbrengst lijkt wat achter te blijven in vergelijking met de echte opbrengsten. Vandaag bijvoorbeeld, werkelijke opbrengst 18.9 in Home Assistant en Expected in Asgard 11.8.

Nu heb ik in Home assistant via HACS even de Open Meteo Solar Forecast geïnstalleerd met dezelfde settings als in Odin (zou dus op hetzelfde moeten uitkomen denk ik). Dan krijg ik toch best wel een wat hogere forecast die veel beter overeenkomt met de werkelijke opbrengsten. Is er een manier om dit te debuggen in Odin/Asgard/Home Assistant? Of maak ik een denkfout?

PV:
3500wp
3000watt inverter


Settings Odin:


Settings Home Assistant:


Expected Asgard:


Werkelijk Home Assistant vs. OpenMeteo Solar Forecast in Home Assistant:

[xoror]

@barcomoon Je kijkt wel in de production graph he?
Bij mij is het 57kWh (van de inverter zelf) vs 51 kWh via de Odin schatting. Odin gebruikt een relatief eenvoudig model om de schatting te doen, ik zal kijken wat er evt beter kan en past qua reken capaciteit op de esp32.

[ Voor 36% gewijzigd door xoror op 07-07-2026 21:51 ]

[xoror]

@barcomoon Dank voor de tip, ik heb even het achterliggende algo bekeken en mijn simpele model aangepast. Kan je 1.0.4-04 downloaden en testen en laten weten of het goed werkt?

Anderen met zonnepanelen, graag ook uitproberen.

[_RRM_]

xoror schreef op dinsdag 7 juli 2026 @ 22:58:
@barcomoon Dank voor de tip, ik heb even het achterliggende algo bekeken en mijn simpele model aangepast. Kan je 1.0.4-04 downloaden en testen en laten weten of het goed werkt?

Anderen met zonnepanelen, graag ook uitproberen.

Zag ook al wat verschil en vroeg me af of het opnemen van realtime opbrengst nog iets zou zijn in het optimaliseren van het algo?

Hoe krijg je de totaal verwachte opbrengst boven in de grafiek? Die heb ik namelijk niet. Is misschien in het vergelijken/testen wat eenvoudiger.

[xoror]

@RRM laatste Asgard pre release installeren

Odin heeft toekomstige waarden nodig om te plannen. Ik doe niets met realtime waarden.

[ Voor 49% gewijzigd door xoror op 07-07-2026 23:22 ]

[_RRM_]

xoror schreef op dinsdag 7 juli 2026 @ 23:17:
@RRM laatste Asgard pre release installeren

Odin heeft toekomstige waarden nodig om te plannen. Ik doe niets met realtime waarden.

Dacht meer in de richting van expected room temp en actual lopen samen op. Misschien ook in solar handig? Maar als dit binnen Odin geen verdere optimalisatie oplevert voor de lokale situatie dan heeft het geen waarde.

Waar vind ik de Odin pre-release 1.0.4-04? Zal er wel weer scheel over heen kijken

https://github.com/gekkekoe/heatpump-optimizer/releases

[ Voor 5% gewijzigd door _RRM_ op 07-07-2026 23:59 ]

[bilgy_no1]

Hier ook even gekeken naar de waarden over 7 juli:

Voorspelling Odin (gecheckt in Asgard Solver tab) was 14,01 kWh production.

Werkelijke productie (uit Zonneplan app waar de omvormer van is): 22,94 kWh.

Nu kan de voorspelling altijd anders uitpakken; het blijft een kwestie van weer voorspellen... Eigenlijk zou je dit langduriger terug moeten kijken.

Anyway, ik zal de pre-release installeren en kijken hoe het morgen uitpakt.

edit:

Nieuwe versie geïnstalleerd. Ik zie maar weinig verschil in de voorspelde PV productie morgen. Oude versie gaf aan 17,73 kWh. Nieuwe versie 15,22. Zelfs iets minder dus, maar dat kan uiteraard ook aan bijgewerkte weerdata liggen.

Ik zie nu in Asgard ook een voorspelling nog een dag vooruit voor overmorgen. En hoewel die in de ochtend een iets andere verdeling heeft is het na 16:00 bijna precies hetzelfde als de voorspelling voor morgen en is het totaal ook precies 15,22 kWh.

[ Voor 37% gewijzigd door bilgy_no1 op 08-07-2026 01:13 ]

[xoror]

@bilgy_no1 Je hebt wel hour = 0, en run optimization gedaan en dan pas gekeken (en ook snel kijken voordat het systeem weer restored)? of anders pa na xx:55 nadat de call door het systeem is getriggered.

Hier was het met oude schatting: 51 vs 57 en met nieuwe schatting 56 vs 57.

[ Voor 11% gewijzigd door xoror op 08-07-2026 08:58 ]

[Mulderjari]

Wat ik me afvraag; is hier ook iemand die, uiteraard tegen betaling, bij ons de warmtepomp in/af kan stellen zodat hij perfect staat afgesteld? Lees allemaal dingen over smart grid, etc, maar heb daar de ballen verstand van😁🙈

[xoror]

@Mulderjari Het is verstandig om een beetje te begrijpen hoe je systeem werkt, er is geen magische instelling die altijd werkt.

Zoiets als Odin neemt wel veel werk uit handen, maar je moet wel snappen wat het doet om soms bij te kunnen sturen.

Als je bepaalde dingen niet snapt kan je dat hier op het forum nalezen/vragen stellen. En wellicht is het handig regio te vermelden, voor het geval er een tweaker in de buurt woont @Grolsch hahaha

[bilgy_no1]

xoror schreef op woensdag 8 juli 2026 @ 08:56:
@bilgy_no1 Je hebt wel hour = 0, en run optimization gedaan en dan pas gekeken (en ook snel kijken voordat het systeem weer restored)? of anders pa na xx:55 nadat de call door het systeem is getriggered.

Hier was het met oude schatting: 51 vs 57 en met nieuwe schatting 56 vs 57.

Ik heb meerdere keren Run Optimization gedaan. Weet niet waar ik hour = 0 kan doen...

Ik heb eerst de waarden uit de grafiek in Asgard overgenomen. Daarna de update gedraaid. Run Optimization en vervolgens de nieuwe waarden overgenomen. Ik zag aan de actual DHW run de dag van gisteren. Die waarden bleven gelijk.

Wat wellicht bij mij speelt is dat er twee strings zijn. Ik ga ook nog even kijken naar de instellingen in Odin. Daar val wellicht nog wat te tweaken met efficiency van de omvormer enz.

[xoror]

@bilgy_no1 Links van die "run optimization" knop kan je het uur invullen. Maar nu zou je al nieuwe data moeten hebben. Wat ook 'vervelend' is, is dat het weer aangepast kan zijn. Dan kan je in de calendar view, gisteren kijken, daar zou het historisch goed moeten staan

Ik heb verder ook 2 strings.

[ Voor 48% gewijzigd door xoror op 08-07-2026 11:51 ]

[bilgy_no1]

bilgy_no1 schreef op woensdag 8 juli 2026 @ 11:38:
[...]

Ik heb meerdere keren Run Optimization gedaan. Weet niet waar ik hour = 0 kan doen...

Ik heb eerst de waarden uit de grafiek in Asgard overgenomen. Daarna de update gedraaid. Run Optimization en vervolgens de nieuwe waarden overgenomen. Ik zag aan de actual DHW run de dag van gisteren. Die waarden bleven gelijk.

Wat wellicht bij mij speelt is dat er twee strings zijn. Ik ga ook nog even kijken naar de instellingen in Odin. Daar val wellicht nog wat te tweaken met efficiency van de omvormer enz.

OK Ik zie dat daar het actuele uur staat. Dan zal dat inderdaad 0 zijn geweest toen ik het deed, want dat was vlak na middernacht.

Voor de uren t/m 11 lijkt de nieuwe voorspelling aardig te kloppen. De oude voorspelling zit over het algemeen iets te hoog. Lijkt te wijzen op veranderde weersverwachting. Het is hier inderdaad best bewolkt.

Ik heb wel even de settings gecheckt en de oriëntatie van de strings iets aangepast. Kijken wat dat doet.

Het lijkt me heel lastig om dit binnen Odin echt precies te voorspellen (je mikt immers op een moving target aangezien de voorspelling ieder uur wordt bijgewerkt) en tegelijkertijd is het waarschijnlijk voldoende als het 80% goed is. Zeker icm dynamische tarieven zal er een grote overlap zijn tussen PV opbrengst en lage prijzen.

Voor mensen met een hele grote PV installatie die ook in de winter hun verwarming daar grotendeels op willen draaien is het wellicht belangrijker. Dan zou je eigenlijk op een totaal on bewolkte dag eens moet kijken naar de voorspelling en de gerealiseerde waarde en eventueel kalibreren.

[xoror]

@bilgy_no1 Het gaat vooral om de ochtend en avond uren. Daar wil je over het algemeen iets conservatiever schatten. Of je moet je solar coverage hoger zetten.

Bij volle zon uren, is het niet zo spannend meer. Wat je moet doen is na 21:00 uur kijken, en dan per uur kijken of het een beetje overeenkomt met het werkelijke. Als het ongeveer klopt is het goed genoeg voor Odin.

[bilgy_no1]

xoror schreef op woensdag 8 juli 2026 @ 12:41:
@bilgy_no1 Het gaat vooral om de ochtend en avond uren. Daar wil je over het algemeen iets conservatiever schatten. Of je moet je solar coverage hoger zetten.

Bij volle zon uren, is het niet zo spannend meer. Wat je moet doen is na 21:00 uur kijken, en dan per uur kijken of het een beetje overeenkomt met het werkelijke. Als het ongeveer klopt is het goed genoeg voor Odin.

Ik houd het vandaag en morgen in de gaten. In de avonduren zijn de totalen nu al niet zo vreselijk interessant, laat staan in de periode oktober-maart wanneer de warmtepomp het meeste draait.

De iets aangepast oriëntatie doet niet zoveel. Gek genoeg lijkt er vanaf 15:00 uur steeds nagenoeg dezelfde voorspelling uit te rollen in de drie varianten:

• Voor de update
• Na de update
• Na de update plus aanpassing oriëntatie (was maar 15° aanpassing)

Gisteren klopte de (pre-update) voorspelling best aardig vanaf ongeveer 17:00 uur. Maar dat gaat dan om best kleine hoeveelheden: voorspeld 4,21 kWh, opgewekt 4,24 kWh na 17:00 uur. Het grote verschil zit hem dus midden op de dag waar ik een veel hoger vermogen krijg dan voorspeld. Is dat het weer of het algoritme? Je ne sais pas...

[xoror]

Voor mensen met WiFi issues, kunnen jullie Asgard https://github.com/gekkek...eleases/tag/2026-07-08.01 proberen en kijken of dat verbeteringen geeft?

@bilgy_no1 Er komt nog een kleine tweak voor hele warme dagen, maar daar zou je nu geen last van moeten hebben. Verder is dat ook maar iets van 2% afwijking max.

[ Voor 32% gewijzigd door xoror op 08-07-2026 12:54 ]

[Zjemm]

@xoror dit koel seizoen gaat een stuk beter qua compressor runs. dankzij asguard draait het een stuk rustiger. en komt er een punt waarop pendelen begint dan zie je dat meteen en kun je bijsturen.

ik haal nu vaak gewoon runs van een hele dag of meer

[xoror]

Even een huishoudelijke mededeling: Ook ik begin last te krijgen van de AI hype. Alle componenten die ook maar iets met DRAM te maken hebben, zijn explosief gestegen. Soms wel 10x - 15x omhoog gegaan. Gemiddeld zijn de inkoop kosten daardoor z'n 25% gestegen. De huidige batch absorbeer ik dat nog, maar de volgende batch moet ik de prijs helaas verhogen. Ik wil niemand dwingen/bang maken, maar dat jullie dat weten. Dus als je Asgard nog wilt, wacht niet te lang.

[tromphakvoort]

Ik zie zojuist dat ik de hele dag al vraag heb vanuit de IN1 thermostaat en dat er ook koeling gepland staat maar de WP lijkt niet gestart te zijn. Hebben jullie een idee waardoor dit kan komen? Omdat de actual temp binnen de bandbreedte is? Of zijn er andere redenen die dit kunnen veroorzaken? Ik draai momenteel nog versie asgard-z1-en-2026-07-06.01 en Odin v1.0.4-03

[xoror]

@tromphakvoort toevallig tijdschema actief ? kijk bij settings, zie je prohibit cooling?

[tromphakvoort]

@xoror Nee geen tijdschema en geen prohibit cooling actief:
Hier de Asgard logs die ik sinds net heb:

15:56:53
--- Connected to EventStream ---
15:57:10
[D][auto_adaptive:057]: Passive thermal window started: room=21.70C
15:57:40
[I][auto_adaptive:288]: Pre-hour trigger at 14:55 — requesting ODIN solve for hour 15.
15:57:43
[I][auto_adaptive:146]: ODIN production targets loaded (48h). current_hour=14 midnight_wrap=0 data_day=188
15:57:44
[I][auto_adaptive:146]: ODIN production targets loaded (48h). current_hour=14 midnight_wrap=0 data_day=188
16:01:38
[I][auto_adaptive:192]: Solver soft-stop: disable stop for hour 15
16:01:38
[D][auto_adaptive:155]: ODIN -> Hour 15 | Prod: 3.2/7.5 | factor: 0.43 | mode: 3
16:01:38
[D][auto_adaptive:624]: [*] Auto-adaptive cycle: independent_zone_temps=0 has_cooling=1 cold_factor=0.00 min_delta=2.00 max_delta=6.50
16:01:38
[D][auto_adaptive:389]: Z1 src=2 room=21.7 target=21.0 flow=29.5 flow_rate=0.0 outside=23.0 bias=0.0 H=0 C=0
16:01:38
[D][auto_adaptive:155]: ODIN -> Hour 15 | Prod: 3.2/7.5 | factor: 0.43 | mode: 3
16:01:38
[D][auto_adaptive:452]: Z1 ODIN (Heuristic) Low Flow (0.0 L/min). Load Ratio: 0.43 -> ΔT: 3.92
16:01:38
[D][auto_adaptive:309]: Z1 COOLING: calc=25.1°C (return 29.0 - delta 3.9)
16:01:38
[W][auto_adaptive:196]: Heating/DHW flow adjust: 29.00°C to prevent compressor stop! (setpoint: 25.08°C is 4.42°C below actual feed temp)
16:01:38
[W][auto_adaptive:055]: Flow limited to 18.0°C (Zone Max Limit), calculated_flow: 29.0
16:01:38
[D][auto_adaptive:466]: Z1 ODIN COOLING: delta=3.9 → flow=18.0°C

[xoror]

post ook je settings scherm, staat je flow temp setpoint not toevallig heel hoog ? zet hem even handmatig naar 18c

[tromphakvoort]

@xoror setpoint nu zelf even op 17 gezet

Extra logs:

16:06:38
[D][auto_adaptive:155]: ODIN -> Hour 15 | Prod: 3.2/7.5 | factor: 0.43 | mode: 3
16:06:38
[D][auto_adaptive:624]: [*] Auto-adaptive cycle: independent_zone_temps=0 has_cooling=1 cold_factor=0.00 min_delta=2.00 max_delta=6.50
16:06:38
[D][auto_adaptive:389]: Z1 src=2 room=21.8 target=21.0 flow=29.5 flow_rate=0.0 outside=23.0 bias=0.0 H=0 C=0
16:06:38
[D][auto_adaptive:155]: ODIN -> Hour 15 | Prod: 3.2/7.5 | factor: 0.43 | mode: 3
16:06:38
[D][auto_adaptive:452]: Z1 ODIN (Heuristic) Low Flow (0.0 L/min). Load Ratio: 0.43 -> ΔT: 3.92
16:06:38
[D][auto_adaptive:309]: Z1 COOLING: calc=25.1°C (return 29.0 - delta 3.9)
16:06:38
[W][auto_adaptive:196]: Heating/DHW flow adjust: 29.00°C to prevent compressor stop! (setpoint: 25.08°C is 4.42°C below actual feed temp)
16:06:38
[W][auto_adaptive:055]: Flow limited to 18.0°C (Zone Max Limit), calculated_flow: 29.0
16:06:38
[D][auto_adaptive:466]: Z1 ODIN COOLING: delta=3.9 → flow=18.0°C
16:11:38
[D][auto_adaptive:155]: ODIN -> Hour 15 | Prod: 3.2/7.5 | factor: 0.43 | mode: 3
16:11:38
[D][auto_adaptive:624]: [*] Auto-adaptive cycle: independent_zone_temps=0 has_cooling=1 cold_factor=0.00 min_delta=2.00 max_delta=6.50
16:11:38
[D][auto_adaptive:389]: Z1 src=2 room=21.8 target=21.0 flow=29.5 flow_rate=0.0 outside=23.0 bias=0.0 H=0 C=0
16:11:38
[D][auto_adaptive:155]: ODIN -> Hour 15 | Prod: 3.2/7.5 | factor: 0.43 | mode: 3
16:11:38
[D][auto_adaptive:452]: Z1 ODIN (Heuristic) Low Flow (0.0 L/min). Load Ratio: 0.43 -> ΔT: 3.92
16:11:38
[D][auto_adaptive:309]: Z1 COOLING: calc=25.1°C (return 29.0 - delta 3.9)
16:11:38
[W][auto_adaptive:196]: Heating/DHW flow adjust: 29.00°C to prevent compressor stop! (setpoint: 25.08°C is 4.42°C below actual feed temp)
16:11:38
[W][auto_adaptive:055]: Flow limited to 18.0°C (Zone Max Limit), calculated_flow: 29.0
16:11:38
[D][auto_adaptive:466]: Z1 ODIN COOLING: delta=3.9 → flow=18.0°C
16:11:38
[D][auto_adaptive:140]: CMD: Set Dependent Cool Flow -> 18.0°C (17.0°C)
16:11:39
[W][ecodan.component:363]: Command timed out. Retrying (attempt 2/30)...[1]

[ Voor 78% gewijzigd door tromphakvoort op 08-07-2026 16:14 . Reden: Extra logs toegevoegd ]

[xoror]

toggle server control even aan, na paar sec.kijken of een van de prohibits aan gaan. dan evt uitdoen. start hij dan wel?

[tromphakvoort]

Server control aangezet en 3 min gewacht maar geen prohibits aan zien gaan, handmatig alle prohibits aangezet en na 3 minuut weer uit. Zie in de logs wel:

16:28:19~[W][ecodan.component:363]: Command timed out. Retrying (attempt 3/30)...[2]

Voorbij komen als ik prohibit aan of uit vink, mogelijk dat de communicatie tussen de wp en Asgard niet/niet goed werkt?

De wp is nu wel begonnen met een DHW run, mogelijk door de prohibit op dhw die aan en uit gegaan is?

[ Voor 3% gewijzigd door tromphakvoort op 08-07-2026 16:32 ]

[xoror]

DHW is omdat je prohibit dhw uit/aan doet. Het is wel raar, hij wil het plannen maar kan het niet.

je ziet ook dat hij wil koelen:
~[I][auto_adaptive:192]: Solver soft-stop: disable stop for hour 15
16:01:38
~[D][auto_adaptive:155]: ODIN -> Hour 15 | Prod: 3.2/7.5 | factor: 0.43 | mode: 3
16:01:38

Kan je zien of hij gereboot is ? bij uptime, ik zie nu 11m, heb je dat zelf gedaan? Recompile even of installeer de laatste Asgard pre-release voor de zekerheid. Ik heb het idee dat hij gereboot is en in een uit state is beland (override door odin). Maar dat had vanzelf rond 16:00 opgelost moeten worden. Dus het is een beetje wazig.

[ Voor 25% gewijzigd door xoror op 08-07-2026 16:48 ]

[tromphakvoort]

Ja ik heb net nog de laatste versies geïnstalleerd daardoor is de uptime laag, dat was daarvoor een wel een stuk langer (dag/dagen) en tussendoor niet herstart o.i.d.

[xoror]

@tromphakvoort kan het zijn dat je wireless thermostat nog problemen geeft?
Je had SW1-8 weer aangezet, dat moet gewoon kunnen. en SW2-1 staat ook aan. Je ziet netjes dat er demand is via In1, maar de WP gaat niet aan, dan moet iets anders dat tegen houden.

disable Odin (cost optimizer)
Gaat koeling dan aan ? Want dan werkt de auto adaptive gewoon

[tromphakvoort]

@xoror ben nu niet thuis om even fysiek op de thermostaat te kijken maar die leek afgelopen dagen wel goed samen te werken met Asgard en Odin. Heb gister nog koeling gedraaid bijvoorbeeld.

Lijkt toch iets te zijn met de communicatie, zodra ik met de hand de flow aanpas dan zie ik dit in de logs voorbij komen:
16:56:38[D][auto_adaptive:466]: Z1 ODIN COOLING: delta=3.9 → flow=18.0°C

16:56:38[D][auto_adaptive:140]: CMD: Set Dependent Cool Flow -> 18.0°C (17.5°C)

16:56:39[W][ecodan.component:363]: Command timed out. Retrying (attempt 2/30)...[1]

Ik ga de solver even uitzetten en dan kijken of AA hem aan kan sturen.

Zojuist wel force dhw aangezet en toen is de wp meteen begonnen met verwarmen met de compressor van het dhw, er lijkt dus wel iets aan communicatie goed te verlopen.

[ Voor 12% gewijzigd door tromphakvoort op 08-07-2026 17:01 . Reden: extra toelichting ]

[tromphakvoort]

Logging sinds het uitzetten van de solver tab, lijkt nog steeds geen communicatie te kunnen maken om de koeling aan te sturen

17:01:38
[I][auto_adaptive:192]: Solver soft-stop: disable stop for hour 16
17:01:38
[D][auto_adaptive:155]: ODIN -> Hour 16 | Prod: 2.7/7.5 | factor: 0.36 | mode: 3
17:01:38
[D][auto_adaptive:624]: [*] Auto-adaptive cycle: independent_zone_temps=0 has_cooling=1 cold_factor=0.00 min_delta=2.00 max_delta=6.50
17:01:38
[D][auto_adaptive:389]: Z1 src=2 room=21.9 target=21.0 flow=52.5 flow_rate=0.0 outside=21.0 bias=0.0 H=0 C=0
17:01:38
[D][auto_adaptive:155]: ODIN -> Hour 16 | Prod: 2.7/7.5 | factor: 0.36 | mode: 3
17:01:38
[D][auto_adaptive:452]: Z1 ODIN (Heuristic) Low Flow (0.0 L/min). Load Ratio: 0.36 -> ΔT: 3.60
17:01:38
[D][auto_adaptive:309]: Z1 COOLING: calc=26.4°C (return 30.0 - delta 3.6)
17:01:38
[W][auto_adaptive:196]: Heating/DHW flow adjust: 52.00°C to prevent compressor stop! (setpoint: 26.40°C is 26.10°C below actual feed temp)
17:01:38
[W][auto_adaptive:055]: Flow limited to 18.0°C (Zone Max Limit), calculated_flow: 52.0
17:01:38
[D][auto_adaptive:466]: Z1 ODIN COOLING: delta=3.6 → flow=18.0°C
17:01:41
[W][ecodan.component:363]: Command timed out. Retrying (attempt 2/30)...[1]

[xoror]

@tromphakvoort Het is denk ik een bug in Auto adaptive.
Na DHW is je feed temp nog hoog, we gaan dan starten met koelen.

code:

16:06:38~~~[D][auto_adaptive:155]: ODIN -> Hour 15 | Prod: 3.2/7.5 | factor: 0.43 | mode: 3
16:06:38~~~[D][auto_adaptive:624]: ~~~[*] Auto-adaptive cycle: independent_zone_temps=0 has_cooling=1 cold_factor=0.00 min_delta=2.00 max_delta=6.50
16:06:38~~~[D][auto_adaptive:389]: Z1 src=2 room=21.8 target=21.0 flow=29.5 flow_rate=0.0 outside=23.0 bias=0.0 H=0 C=0
16:06:38~~~[D][auto_adaptive:155]: ODIN -> Hour 15 | Prod: 3.2/7.5 | factor: 0.43 | mode: 3
16:06:38~~~[D][auto_adaptive:452]: Z1 ODIN (Heuristic) Low Flow (0.0 L/min). Load Ratio: 0.43 -> ΔT: 3.92
16:06:38~~~[D][auto_adaptive:309]: Z1 COOLING: calc=25.1°C (return 29.0 - delta 3.9)
16:06:38~~~[W][auto_adaptive:196]: Heating/DHW flow adjust: 29.00°C to prevent compressor stop! (setpoint: 25.08°C is 4.42°C below actual feed temp)
16:06:38~~~[W][auto_adaptive:055]: Flow limited to 18.0°C (Zone Max Limit), calculated_flow: 29.0
16:06:38~~~[D][auto_adaptive:466]: Z1 ODIN COOLING: delta=3.9 → flow=18.0°C

Hij wil om 16:06 koeling starten. De return temp is op dat moment 29c. Doordat de pomp nog niet draait (flow rate = 0), probeer ik een delta T van 3.92 te hanteren. Maar als we dat instellen, wordt er ingegrepen om de compressor stop te voorkomen. Dat is onterecht, want die zorgt ervoor dat de compressor niet start.

De circulatie pomp moet eerst tijd krijgen om te draaien, zodat de Ta/Tr afnemen (Vermenging). Ik zal even kijken hoe ik dit het beste kan oplossen.

Als je autoadaptive draait ga je er helaas ook last van hebben. Ik denk dus dat ik geen setpoint moet instellen als er geen flow is, moet even over nadenken

edit: als het goed is reboot hij vanzelf, even paar mins wachten

[ Voor 3% gewijzigd door xoror op 08-07-2026 17:09 ]

[tromphakvoort]

@xoror Ah okey dat klinkt inderdaad erg logisch, is er in de tussentijd denk je een manier hoe ik de wp kan laten denk dat hij kan gaan starten met koelen?