Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien
mausy5043 schreef op woensdag 26 november 2025 @ 19:58:
[...]

De gain is meestal ook niet waar je aan moet zitten. Maar de I- of soms zelfs de D-actie. Soms moet je dan de gain (P-actie voor degenen die regeltechniek gehad hebben toen de nederlandse terminologie en vaan-tuit systemen nog in zwang waren ;) ) wat terug genomen worden.
Probleem is een beetje de trage input die je krijgt van de P1 meter... eens per 10 seconden. Hierdoor wordt het systeem traag en als je dan verbruikers hebt die korte tijd veel verbruiken. (Quooker, kooplaat oven etc) dan wordt het met die traagheid niet stabieler met een I actie of een D actie... Daar veranderd het te snel voor :(
Maartentux schreef op woensdag 26 november 2025 @ 20:03:
[...]


Ik wil niet het onmogelijke, dus ik verlang geen ander gedrag voor mijn meter dan voor alle andere DSMR4 meters. Wel zou ik zeker willen weten dat mijn meter als zodanig herkend wordt zodat ik binnen die groep val. Ik heb daar mijn twijfels over gezien het gedrag en omdat ik scherp heb opgelet op gedragsverandering sinds FW 1.8.6
Hoe wordt die check precies gedaan, welke regexp wordt gebruikt?
Geen idee of je dit zelf kunt checken. Misschien even aan Sessy vragen?

  • Maartentux
  • Registratie: Juli 2024
  • Laatst online: 27-11 21:27
DJP! schreef op woensdag 26 november 2025 @ 20:20:
[...]

Probleem is een beetje de trage input die je krijgt van de P1 meter... eens per 10 seconden. Hierdoor wordt het systeem traag en als je dan verbruikers hebt die korte tijd veel verbruiken. (Quooker, kooplaat oven etc) dan wordt het met die traagheid niet stabieler met een I actie of een D actie... Daar veranderd het te snel voor :(
Oke.
Ik heb het maar even een keertje 'iets' wetenschappelijker aangepakt om betrouwbaarder cijfers te krijgen. Airco uitgezet, tweede Sessy op idle gezet, pan water klaargezet op kookplaat, en stopwatch gebruikt.

Op t=0 klik ik op 'overzicht' zodat de grafieken refreshen
Op t=15 gaat de kookplaat aan op max vermogen (>2kW)
Op t=75 maakte ik het screenshot

Dit is de grafiek die resulteert:
Afbeeldingslocatie: https://tweakers.net/i/UpOYlE1HtlK9ugeqA1KTKC4dJsA=/800x/filters:strip_icc():strip_exif()/f/image/xaPA7ZwqgL3sObAtaaRmFwtK.jpg?f=fotoalbum_large

  • Maartentux
  • Registratie: Juli 2024
  • Laatst online: 27-11 21:27
Maartentux schreef op woensdag 26 november 2025 @ 20:39:
[...]


Oke.
Ik heb het maar even een keertje 'iets' wetenschappelijker aangepakt om betrouwbaarder cijfers te krijgen. Airco uitgezet, tweede Sessy op idle gezet, pan water klaargezet op kookplaat, en stopwatch gebruikt.

Op t=0 klik ik op 'overzicht' zodat de grafieken refreshen
Op t=15 gaat de kookplaat aan op max vermogen (>2kW)
Op t=75 maakte ik het screenshot

Dit is de grafiek die resulteert:
[Afbeelding]
En wat zie je dan? De P1 meter signaleert op t=25 het toegenomen verbruik. En op t=35 telt -ie er nog 250 watt bij op. Maar wat doet de batterij?????
Op t=35 verhoogt -ie de output met 300 watt. Op t=50 begint -ie langzaam verder te klimmen, naar +750 watt, en dan +1000 watt op t=55. Daarna gaan er nog 10 seconden voorbij totdat -ie besluit dat hij ook de stap maakt naar +1200 watt (max, want hij begon op ~500 watt).

Ik zit dan echt met vragen. Waarom toch nog 10 seconden wachten na t=25 ? Waarom wordt er niet begonnen met bijregelen op t=30 of zelfs direct al op t=25 ? Het is net alsof de Sessy de P1 meter waarden niet vertrouwt en wacht op een 'second opinion'. Maar dat is toch zot? En daarna gaat het bijregelen ook -mijns inziens, maar daarover kunnen we best twisten- te langzaam.

Tja, ik vind het niet echt oke. Maar inderdaad, ik heb geen meet- en regeltechniek gestudeerd. (Helemaal niets gestudeerd overigens, ik ben meteen gaan werken)

[ Voor 13% gewijzigd door Maartentux op 26-11-2025 21:03 . Reden: paar meetpunten scherper gedefinieerd ]

Maartentux schreef op woensdag 26 november 2025 @ 20:39:
[...]


Oke.
Ik heb het maar even een keertje 'iets' wetenschappelijker aangepakt om betrouwbaarder cijfers te krijgen. Airco uitgezet, tweede Sessy op idle gezet, pan water klaargezet op kookplaat, en stopwatch gebruikt.

Op t=0 klik ik op 'overzicht' zodat de grafieken refreshen
Op t=15 gaat de kookplaat aan op max vermogen (>2kW)
Op t=75 maakte ik het screenshot

Dit is de grafiek die resulteert:
[Afbeelding]
Ik zou dit even voorleggen bij Sessy om na te gaan of het correct is. Het lijkt mij aan de trage kant.

  • Maartentux
  • Registratie: Juli 2024
  • Laatst online: 27-11 21:27
DJP! schreef op woensdag 26 november 2025 @ 21:14:
[...]


Ik zou dit even voorleggen bij Sessy om na te gaan of het correct is. Het lijkt mij aan de trage kant.
Mja. Weet je, ik had daar een ticket over open staan, ref CT-219. Daarop kwam na verloop van tijd de reply (en ik quote):

We hebben gekeken naar de software en komen met een mogelijk oplossing namelijk dat je een CT meter kan aanschaffen die buiten de huidige slimme meter de in en export van de stroom in de gaten houdt.

Dat is daarna na informeren hoeveel een CT meter me zou kosten, afgeketst (en naar ik aanneem gesloten).

Ik geloof eerlijk gezegd niet dat dat ticket heropenen nu opeens soelaas gaat brengen. :N

  • helm71
  • Registratie: Februari 2012
  • Laatst online: 10:24
DJP! schreef op woensdag 26 november 2025 @ 21:14:
[...]


Ik zou dit even voorleggen bij Sessy om na te gaan of het correct is. Het lijkt mij aan de trage kant.
Misschien wacht sessy altijd op een tweede meting om het effect iets te middelen en niet op elke piek te reageren… als het alleen een hele korte piek is dan heeft het gezien om er op te schakelen, dat heeft alleen zin bij iets meer sustained verbruik en als daar sprake van is maken die 10 seconden in het begin ook niet uit ..

  • worker
  • Registratie: November 2001
  • Laatst online: 29-11 22:15

worker

2x Sessy thuisbatterij

Ik heb net een plaatje gemaakt van hoe het bij mij gaat.
Het mooie van dit plaatje is dat je de gegevens van de P1 meter op dezelfde tijdschaal ziet als de data van wat de Sessy doet.

De blauwe lijn is het vermogen wat gemeten wordt door de P1 meter.
De gele lijn is het geleverde vermogen van de Sessy.

Iets na 21:30u zette ik de Sessy in NOM mode. Je ziet dat de blauwe lijn naar nul gaat. Dan gooit nog heel even de Quooker roet in het eten (tussen 21:31 en 21:32). Ik heb even gewacht tot de blauwe lijn weer nul is.
Dat zet ik iets na 21:33 een pan op de inductieplaat op ongeveer 1kW aan. De blauwe lijn schiet naar 1kW.
De Sessy gaat bijleveren, en zorgt dat de blauwe lijn weer naar nul wordt geduwd. Dit kost bijna een minuut, en je ziet ook dat hij na een halve minuut ongeveer de helft heeft gecompenseerd.
Vlak voor 21:35u zet ik de inductieplaat weer uit, en gebeurt hetzelfde, maar dan andersom. De compensatie werkt prima, maar inderdaad niet al te snel.

Ik heb jaren geleden zelf een NOM regeling gemaakt met een geleende accu + inverter, gebaseerd op mijn DSMR4 meter. Ik kreeg het destijds niet beter als wat de Sessy nu doet, en (sorry) ik heb wel regeltechniek gestudeerd.

Ik vind jouw grafieken lastig te lezen, Het compenseren lijkt bij jou wel langzamer te gaan, maar ik zou zo even geen technische redenen kunnen verzinnen waarom dat zo zou zijn.
Soms moet je experimenten meerdere keren doen, omdat er gebruikers in je huis aan en uit gaan, en die kunnen je grafieken verstoren. Denk aan de Quooker bij mij iets na 21:31u eventjes interrumpeerde.


Afbeeldingslocatie: https://tweakers.net/i/mzk1xX4mSCfmDEKe-HQPwKtc6zU=/800x/filters:strip_exif()/f/image/g3Nf3kHGWPm1s9GNrNdAwChn.png?f=fotoalbum_large

  • worker
  • Registratie: November 2001
  • Laatst online: 29-11 22:15

worker

2x Sessy thuisbatterij

helm71 schreef op woensdag 26 november 2025 @ 22:22:
[...]


Misschien wacht sessy altijd op een tweede meting om het effect iets te middelen en niet op elke piek te reageren… als het alleen een hele korte piek is dan heeft het gezien om er op te schakelen, dat heeft alleen zin bij iets meer sustained verbruik en als daar sprake van is maken die 10 seconden in het begin ook niet uit ..
Het eerstvolgende setpoitn van de accu compenseert 30% van de regelfout. Kijk maar in de grafiek hierboven

  • HaraldBou
  • Registratie: September 2019
  • Laatst online: 23:52
MajaMestreech schreef op donderdag 20 november 2025 @ 20:32:
[...]

Als je de batterijen op idle zet dan doen ze dus niks meer. Dus niet verbruik bovenop het XOM vermogen op nul houden, opladen in ECO modus als de EV gaat laden en dan tegelijkertijd ook de goedkoopste uren voor ECO laden zijn. Dat werkt wel allemaal als je die XOM op de waarde zet van het laden van de EV. In het voorbeeld als test een vaste waarde ingezet, maar uiteindelijk komt hier het laadvermogen van de Zappi in te staan. Moet allen wel werken met de Homey.
Klopt, die gebruik ik het liefst om zo lang mogelijk de nacht door te komen. Sessy is eigenlijk te klein om voor laden van de auto te gebruiken. Bij het autoladen is 10 KWh zo weggestroomd en de sessy kan per apparaat hoogstens 2 kWh uitspuwen.
Maar dat zijn keuzes en iedereen moet de keuze maken die bij hem of haar past

  • Twan_V
  • Registratie: December 2018
  • Laatst online: 28-11 16:09
@Maartentux
Het lastige aan de P1-poort is niet alleen dat er maar één keer per 10 seconden een telegram binnenkomt, maar vooral dat de waarde die je dan ziet ook niet altijd een strak actuele weergave is van wat er in die 10 seconden precies is gebeurd. Voor een regelaar is dat echt een beroerde input.

Er is véél werk gaan zitten in het optimaliseren van die NOM-regeling. Het is geen “simpele” PID-regelaar geworden, omdat dat met dit soort meetdata gewoon niet stabiel te krijgen is. Ik heb nog de discussie gehad met de programmeur of we de tuningsparameters niet instelbaar moesten maken (mijn wens), maar de conclusie van onze regeltechnicus was dat er slechts heel beperkte winst te halen is (zoals @worker ook aantoont) en dan nog vooral op basis van het soort apparaten in huis (veel korte pieken zoals een Quooker vs. meer gelijkmatige belasting), niet zozeer op basis van het exacte type slimme meter.

Dat jij je dan toch niet helemaal comfortabel voelt bij die keuze, vind ik oprecht jammer. Tegelijk zitten we hier ook een beetje met het dilemma van de ezel van Buridan: welke kant je ook op kiest, voor een deel van de gebruikers voelt het nooit helemaal goed. De perfecte technische oplossing zie ik nog niet, maar wellicht komen we met wat meer wederzijds begrip wel voorruit

In het algemeen
Ik wil al een tijd weer een gebruikerssessie organiseren (zoals begin 2023), maar fysiek lukt nu even niet. Wat wél kan, is een online Teams-call waarin jullie mij alles mogen vragen over regelgedrag, P1, CT’s, firmware, noem maar op.

Als daar interesse in is, laat dan hier even je mailadres achter, dan ga ik iets organiseren.

p.s. het aantal engineers dat werkt aan een feature komt zelden boven de 2 uit, dat er specialisten zijn die dingen nòg beter kunnen maken geloof ik direct, daarom is er een open API zodat je zelf kunt laten zien dat het beter kan. Als je dan ook deelt waarom en hoe, kunnen wij dat met onze beperkte capaciteit sneller oppakken en heeft iedereen er wat aan. Dat is het soort input waar ik hier blij van word; als (slecht onderbouwde) discussies vooral een klaagkant op gaan, verlaagt dat eerlijk gezegd de motivatie om hier regelmatig mee te lezen en te reageren.

  • Maartentux
  • Registratie: Juli 2024
  • Laatst online: 27-11 21:27
worker schreef op woensdag 26 november 2025 @ 22:25:
Ik heb net een plaatje gemaakt van hoe het bij mij gaat.
Het mooie van dit plaatje is dat je de gegevens van de P1 meter op dezelfde tijdschaal ziet als de data van wat de Sessy doet.

De blauwe lijn is het vermogen wat gemeten wordt door de P1 meter.
De gele lijn is het geleverde vermogen van de Sessy.

Iets na 21:30u zette ik de Sessy in NOM mode. Je ziet dat de blauwe lijn naar nul gaat. Dan gooit nog heel even de Quooker roet in het eten (tussen 21:31 en 21:32). Ik heb even gewacht tot de blauwe lijn weer nul is.
Dat zet ik iets na 21:33 een pan op de inductieplaat op ongeveer 1kW aan. De blauwe lijn schiet naar 1kW.
De Sessy gaat bijleveren, en zorgt dat de blauwe lijn weer naar nul wordt geduwd. Dit kost bijna een minuut, en je ziet ook dat hij na een halve minuut ongeveer de helft heeft gecompenseerd.
Vlak voor 21:35u zet ik de inductieplaat weer uit, en gebeurt hetzelfde, maar dan andersom. De compensatie werkt prima, maar inderdaad niet al te snel.

Ik heb jaren geleden zelf een NOM regeling gemaakt met een geleende accu + inverter, gebaseerd op mijn DSMR4 meter. Ik kreeg het destijds niet beter als wat de Sessy nu doet, en (sorry) ik heb wel regeltechniek gestudeerd.

Ik vind jouw grafieken lastig te lezen, Het compenseren lijkt bij jou wel langzamer te gaan, maar ik zou zo even geen technische redenen kunnen verzinnen waarom dat zo zou zijn.
Soms moet je experimenten meerdere keren doen, omdat er gebruikers in je huis aan en uit gaan, en die kunnen je grafieken verstoren. Denk aan de Quooker bij mij iets na 21:31u eventjes interrumpeerde.
Er spelen twee dingen. De tijd die nodig is om te gaan bewegen, en de felheid/snelheid waarmee bijgeregeld wordt. Laten we de eerste gewoon 'reactietijd' noemen en de tweede deceleratie/acceleratie. Waar ik het meeste moeite mee heb is de reactietijd. Logisch, want daar zit ook het zwakke punt van de DSMR <5 meter.
Wat voor meter heb jij? Ik zag wel dat je een DSMR 4 meter noemde, maar misschien is die inmiddels vervangen. Wat opvalt bij jou (en nimmer gebeurt bij mij) is dat jouw systeem wél supersnel reageert op veranderingen, kijk maar: binnen 5 seconden nadat de P1 meter de cooker signaleerde gaat het vermogen van Sessy al omhoog. Precies eender wanneer je de kookplaat aanzet: Binnen 5 seconden reageert de Sessy. Dat is bij mij eerder 15 tot 25 seconden.

Wat je claimt ('dat hij na een halve minuut ongeveer de helft heeft gecompenseerd') is echt niet waar. Tel zelf de stapjes maar. Binnen 30 seconden na signaleren van de +1kW gebruiker is het vermogen gestegen van 500 naar 1300 watt, dus dat is al voor 80% gecompenseerd. Binnen 30 seconden! Wow. _/-\o_

Mijn grafieken zijn inderdaad wat lastiger te lezen, want ik heb geen controle over wanneer een grid lijn verschijnt, die lopen dus uit de pas. Wel is je houvast dat tussen de gridlijnen telkens 5,0 seconden zit.
Ik heb trouwens het stukje waar jouw kookplaat inschakelt even op ingezoomd en voorzien van 10-sec gridlijnen met Gimp. Dan kun je goed zien hoe snel de reactie volgt.

Ik vind het resultaat bij jou juist supersnel gaan. Had je nu een DSMR 4 meter of een DSMR 5 meter?

Je hebt gelijk over de gebruikers, maar ik ken mijn eenpersoons-huishouden goed. De boilers zitten op tijdklokken, er is een grijswaterpomp die aanslaat bij toiletgebruik, een airco, keukenapparatuur, CV pomp en voor de rest enkel computers. Ik zette dus ook expres die airco uit, want dat is samen met de koelkasten en CV pomp (en die reeds genoemde waterpomp) het enige wat er hier kan fluctueren zonder mijn actieve bemoeienis. De rest is allemaal heel regelmatig. Overigens, die kleine verhoging (van 500 watt naar 800 watt) zou best kunnen liggen aan een koelkast ja. Maar dat maakt de situatie er niet beter op, integendeel.

Afbeeldingslocatie: https://tweakers.net/i/llehEr1JidEwhhn8mnetq0ZJflc=/fit-in/4920x3264/filters:max_bytes(3145728):no_upscale():strip_icc():strip_exif()/f/image/DCdfQ2qAU2uO0HKVpxo9bxFi.jpg?f=user_large

[ Voor 3% gewijzigd door Maartentux op 27-11-2025 04:22 . Reden: paragraaf toegevoegd ]


  • Maartentux
  • Registratie: Juli 2024
  • Laatst online: 27-11 21:27
Twan_V schreef op woensdag 26 november 2025 @ 23:27:
@Maartentux
Het lastige aan de P1-poort is niet alleen dat er maar één keer per 10 seconden een telegram binnenkomt, maar vooral dat de waarde die je dan ziet ook niet altijd een strak actuele weergave is van wat er in die 10 seconden precies is gebeurd. Voor een regelaar is dat echt een beroerde input.

Er is véél werk gaan zitten in het optimaliseren van die NOM-regeling. Het is geen “simpele” PID-regelaar geworden, omdat dat met dit soort meetdata gewoon niet stabiel te krijgen is. Ik heb nog de discussie gehad met de programmeur of we de tuningsparameters niet instelbaar moesten maken (mijn wens), maar de conclusie van onze regeltechnicus was dat er slechts heel beperkte winst te halen is (zoals @worker ook aantoont) en dan nog vooral op basis van het soort apparaten in huis (veel korte pieken zoals een Quooker vs. meer gelijkmatige belasting), niet zozeer op basis van het exacte type slimme meter.

Dat jij je dan toch niet helemaal comfortabel voelt bij die keuze, vind ik oprecht jammer. Tegelijk zitten we hier ook een beetje met het dilemma van de ezel van Buridan: welke kant je ook op kiest, voor een deel van de gebruikers voelt het nooit helemaal goed. De perfecte technische oplossing zie ik nog niet, maar wellicht komen we met wat meer wederzijds begrip wel voorruit

In het algemeen
Ik wil al een tijd weer een gebruikerssessie organiseren (zoals begin 2023), maar fysiek lukt nu even niet. Wat wél kan, is een online Teams-call waarin jullie mij alles mogen vragen over regelgedrag, P1, CT’s, firmware, noem maar op.

Als daar interesse in is, laat dan hier even je mailadres achter, dan ga ik iets organiseren.

p.s. het aantal engineers dat werkt aan een feature komt zelden boven de 2 uit, dat er specialisten zijn die dingen nòg beter kunnen maken geloof ik direct, daarom is er een open API zodat je zelf kunt laten zien dat het beter kan. Als je dan ook deelt waarom en hoe, kunnen wij dat met onze beperkte capaciteit sneller oppakken en heeft iedereen er wat aan. Dat is het soort input waar ik hier blij van word; als (slecht onderbouwde) discussies vooral een klaagkant op gaan, verlaagt dat eerlijk gezegd de motivatie om hier regelmatig mee te lezen en te reageren.
Ja... Bedankt voor je reactie Twan. :) Wat mij vooral tergt... da's niet het juiste woord, intrigeert is niet dat de regeling suboptimaal zou zijn, maar dat mijn situatie afwijkt van het haalbare optimum. Dus ik ben vooral geinteresseerd in weten dat de gebreken van mijn slimme meter worden (h)erkend en dat onder de gegeven omstandigheden het beste resultaat wordt bereikt. En als dat zo is, dan ben ik happy. Een beetje dat effect dat samen in de rij voor de kassa staan geen probleem is, maar wel als jij blijkbaar de verkeerde rij hebt gekozen en iedereen naast je sneller is, haha. ;)

Verder snap ik de dilemma's en uitdagingen wel. En ik probeer ook vooral niet het wiel uit te vinden, dus ik sleutel liever niet zelf met de API. Die tijd heb ik wel gehad maar ik doe tegenwoordig liever aan houtbewerking en wat solderen dan weer automatiseren en scripten en flows maken en debuggen. Dat staat me tegen en anderen zijn er veel beter in dan ik. Mijn eigen computers beheren vind ik al ruim voldoende inspanning.

Bij linux kan ik gewoon zelf zien wat er onder de motorkap gebeurt. Dan staat er iels als 'bummer. found quirky electricity meter at offset 0x440920, enabling workaround...' in de logs en dan ben ik gerust, want dan weet ik wat de reden is dat dingen gebeuren. Bij mijn Sessy mis ik dat. Ik lijk vaak geen verklaring te hebben waarom het ding eerst 25 seconden niets doet en dan pas in aktie komt. Ook de onverklaarbare lange tijd die soms verstrijkt tussen de ene state en de andere state draagt daaraan bij. Vooral booten is vreemd. 'Waar is -ie een heel kwartier mee bezig?' denk ik dan. Oh en de statuspagina vind ik ook zo onverklaarbaar, wacht ik voeg 'm bij. Ik zie daar... elf groene bolletjes. Nul rode bolletjes. Maar wat heeft die groene bolletjes dan getriggerd? Soms staan de bolletjes bovenin, soms onderin. Wat is die vertikale as eigenlijk? Mysterieus is het.

Dus ja, wat zal ik zeggen? Ik ben minder ontevreden dan hoe ik soms allicht overkom hoor. En doorgaans interesseert het mij geen biet hoe goed of slecht iets werkt, mits ik maar een verklaring kan vinden voor dat gedrag. Alhoewel... dat zal vast bij iedereen zo zijn. Hm...

Anyway. Fijne dag! Rustig aan en veel succes!

P.S.: Komt er trouwens nog een uitbreidingsmodule met extra accus of zit dat niet meer in de pijplijn?

Afbeeldingslocatie: https://tweakers.net/i/6-0l8Cut2_WZXBV6Q7__GAGVue4=/800x/filters:strip_icc():strip_exif()/f/image/VKNOzDdDzymyHX60Yfad3gyE.jpg?f=fotoalbum_large

  • Simpel360
  • Registratie: Mei 2022
  • Laatst online: 29-11 11:30
Maartentux schreef op donderdag 27 november 2025 @ 03:34:
[...]


Ja... Bedankt voor je reactie Twan. :) Wat mij vooral tergt... da's niet het juiste woord, intrigeert is niet dat de regeling suboptimaal zou zijn, maar dat mijn situatie afwijkt van het haalbare optimum. Dus ik ben vooral geinteresseerd in weten dat de gebreken van mijn slimme meter worden (h)erkend en dat onder de gegeven omstandigheden het beste resultaat wordt bereikt. En als dat zo is, dan ben ik happy. Een beetje dat effect dat samen in de rij voor de kassa staan geen probleem is, maar wel als jij blijkbaar de verkeerde rij hebt gekozen en iedereen naast je sneller is, haha. ;)

Verder snap ik de dilemma's en uitdagingen wel. En ik probeer ook vooral niet het wiel uit te vinden, dus ik sleutel liever niet zelf met de API. Die tijd heb ik wel gehad maar ik doe tegenwoordig liever aan houtbewerking en wat solderen dan weer automatiseren en scripten en flows maken en debuggen. Dat staat me tegen en anderen zijn er veel beter in dan ik. Mijn eigen computers beheren vind ik al ruim voldoende inspanning.

Bij linux kan ik gewoon zelf zien wat er onder de motorkap gebeurt. Dan staat er iels als 'bummer. found quirky electricity meter at offset 0x440920, enabling workaround...' in de logs en dan ben ik gerust, want dan weet ik wat de reden is dat dingen gebeuren. Bij mijn Sessy mis ik dat. Ik lijk vaak geen verklaring te hebben waarom het ding eerst 25 seconden niets doet en dan pas in aktie komt. Ook de onverklaarbare lange tijd die soms verstrijkt tussen de ene state en de andere state draagt daaraan bij. Vooral booten is vreemd. 'Waar is -ie een heel kwartier mee bezig?' denk ik dan. Oh en de statuspagina vind ik ook zo onverklaarbaar, wacht ik voeg 'm bij. Ik zie daar... elf groene bolletjes. Nul rode bolletjes. Maar wat heeft die groene bolletjes dan getriggerd? Soms staan de bolletjes bovenin, soms onderin. Wat is die vertikale as eigenlijk? Mysterieus is het.

Dus ja, wat zal ik zeggen? Ik ben minder ontevreden dan hoe ik soms allicht overkom hoor. En doorgaans interesseert het mij geen biet hoe goed of slecht iets werkt, mits ik maar een verklaring kan vinden voor dat gedrag. Alhoewel... dat zal vast bij iedereen zo zijn. Hm...

Anyway. Fijne dag! Rustig aan en veel succes!

P.S.: Komt er trouwens nog een uitbreidingsmodule met extra accus of zit dat niet meer in de pijplijn?

[Afbeelding]
Vwb de snelheid van het NOM regelen weet je de volgorde van de flowchart. Zorgen voor een goede meting, dit is je startvoorwaarde, focus daarop ;)

Oh, en een woord niet willen benoemen maar dat toch doen zet toch een bepaalde toon van je schrijfsel. Hm... retorisch O-)

Hm... niet iedereen wil overal een waterdichte verklaring voor hebben, dat is nogal persoons gebonden, zo ook het daarna geen biet kunnen schelen. Als ik met een hamer mis sla en een lichaamsdeel raak is het voor mij voldoende om te weten dat het au gaat doen, de fysiologie maakt mij dan nix uit.

Rode bolletje foutmelding, groene herstelde fout melding. Hoogte in de grafiek het (ongespecificeerde) aantal van diezelfde melding (zo interpreteer ik het).

d:)b

  • Sandburd
  • Registratie: September 2008
  • Niet online
mausy5043 schreef op woensdag 26 november 2025 @ 18:56:
En dat brengt mij eigenlijk bij een andere vraag: Hoe "reboot" ik de batterijen?

Ik zou ze kunnen power-cyclen door de automaat handmatig te trippen. Maar heb ook ergens gehoord dat de omvormer (mn. die van de zonnepanelen en die zit bij mij achter dezelfde automaat) daar niet vrolijk van wordt.
Je zou de dongel kunnen rebooten door middel van de (shameless plug) My Home Battery app of door middel van de integratie van Homeassistant, gemaakt door Pim.
Dus... Is er een schakelaar of een API-call die ik kan gebruiken om de batterijen een soft-restart te geven?
Je kunt een "POST" doen op <local_ip>/system/restart
Dat is wat zowel My Home Battery als de homeassistant integratie doen.

  • mausy5043
  • Registratie: April 2021
  • Nu online

mausy5043

Don't panic.

@Twan_V mag ik even zeggen dat ik het ontzettend fijn vind dat er hier zo nu en dan iemand met kennis van zaken wat toelichting kan geven op relevante actuele discussies . Echt top! Dankjewel!

  • Maartentux
  • Registratie: Juli 2024
  • Laatst online: 27-11 21:27
Simpel360 schreef op donderdag 27 november 2025 @ 08:27:
[...]

Vwb de snelheid van het NOM regelen weet je de volgorde van de flowchart. Zorgen voor een goede meting, dit is je startvoorwaarde, focus daarop ;)

Oh, en een woord niet willen benoemen maar dat toch doen zet toch een bepaalde toon van je schrijfsel. Hm... retorisch O-)

Hm... niet iedereen wil overal een waterdichte verklaring voor hebben, dat is nogal persoons gebonden, zo ook het daarna geen biet kunnen schelen. Als ik met een hamer mis sla en een lichaamsdeel raak is het voor mij voldoende om te weten dat het au gaat doen, de fysiologie maakt mij dan nix uit.

Rode bolletje foutmelding, groene herstelde fout melding. Hoogte in de grafiek het (ongespecificeerde) aantal van diezelfde melding (zo interpreteer ik het).

d:)b
Ik snap al deze teksten niet. Zeg je nu in de eerste paragraaf dat iedereen met een DSMR 4 meter in de boom kan gaan zitten? En indien niet, wat zeg je daar dan wel? Het gaat langs me heen.

Ook dat hamer voorbeeld gaat aan me voorbij. De pijn die je hebt van het misslaan is er nu eenmaal, dat is een voldongen feit, dus je daarom bekommeren levert niets extra op. Wat je beter kunt doen is proberen te begrijpen hoe het misslaan gebeurde, want alleen op die manier kun je proberen te voorkomen dat het opnieuw gebeurt. En dát is wel winst.

Kijk naar de afbeelding! Er zijn geen rode bolletjes. Dus van welke events zijn de groene bolletjes nu een herstel? En wat is nou de meerwaarde van een "staat opgetreden" melding? Dit is wat ik nou unhelpful info noem. Het doet denken aan die prachtige meldingen die microsoft weet te genereren ;)

Afbeeldingslocatie: https://tweakers.net/i/5RWBpVXKmiBvFCwwkMqXrYavU-I=/fit-in/4920x3264/filters:max_bytes(3145728):no_upscale():strip_exif()/f/image/PDYnDLAt0hulxZdzTQQpxsuU.webp?f=user_large

  • Simpel360
  • Registratie: Mei 2022
  • Laatst online: 29-11 11:30
Maartentux schreef op donderdag 27 november 2025 @ 18:44:
[...]


Ik snap al deze teksten niet. Zeg je nu in de eerste paragraaf dat iedereen met een DSMR 4 meter in de boom kan gaan zitten? En indien niet, wat zeg je daar dan wel? Het gaat langs me heen.

Ook dat hamer voorbeeld gaat aan me voorbij. De pijn die je hebt van het misslaan is er nu eenmaal, dat is een voldongen feit, dus je daarom bekommeren levert niets extra op. Wat je beter kunt doen is proberen te begrijpen hoe het misslaan gebeurde, want alleen op die manier kun je proberen te voorkomen dat het opnieuw gebeurt. En dát is wel winst.

Kijk naar de afbeelding! Er zijn geen rode bolletjes. Dus van welke events zijn de groene bolletjes nu een herstel? En wat is nou de meerwaarde van een "staat opgetreden" melding? Dit is wat ik nou unhelpful info noem. Het doet denken aan die prachtige meldingen die microsoft weet te genereren ;)

[Afbeelding]
Ik was hier al bang voor. (y)

  • Maartentux
  • Registratie: Juli 2024
  • Laatst online: 27-11 21:27

  • helm71
  • Registratie: Februari 2012
  • Laatst online: 10:24
Ik heb een verbeterde regeling gemaakt voor mijn laad/ontlaad script.. In de vorige versie werkt ik met " de vier duurste" en " vier goedkoopste". uren per 12 uur blok. Maar er zijn me te veel dagen met geen twee pieken, maar 1 piek, of zelfs helemaal geen piek. Dat werkte op zich ook , maar kon beter... Ik heb nu een ander uitgangspunt gekozen..

Ook weer een staaltje vibecoden met chatgtp, ik heb de resultaten gecheckt en een lijkt prima te werken:

Trots op me @Twan_V ? ;-)

———————————————————

Zo werkt het:

🔹 1. Prijzen van morgen ophalen
Het script haalt de Tibber-uurprijzen op voor de volgende dag. Als dat mislukt of als er geen 24 prijzen beschikbaar zijn, zet het script automatisch een speciale foutvariabele op true en schakelt alles veilig naar “Hold”.

🔹 2. Beste laad- en ontlaaduur bepalen
De prijzen worden gesorteerd van laag naar hoog.
Daarna berekent het script voor k = 1 t/m 12 steeds:
• de k goedkoopste uren
• de k duurste uren
• en het percentage prijsverschil tussen die twee sets

🔹 3. Dynamische drempel (instelbaar)
Ik heb een variabele waarin ik zelf een drempel instel, bijv. 20%.
Alleen als het prijsverschil tussen goedkoop en duur boven die drempel ligt, is het economisch zinvol om te laden/ontladen.

Het script zoekt vervolgens de grootste k waarbij dat nog steeds rendabel is.
Dus als 8 goedkoopste en 8 duurste uren samen >20% verschil geven, maar 9 niet meer → dan wordt k=8 gekozen.

🔹 4. Uur-variabelen zetten
Voor elk uur van de dag bestaat een variabele zoals:
• Dynprice_00
• Dynprice_01
• …
• Dynprice_23

Het script vult die met:
• “Charge” → in de goedkoopste k uren
• “Discharge” → in de duurste k uren
• “Hold” → in de overige uren

Deze variabelen kunnen daarna gewoon in normale Homey-flows gebruikt worden om apparaten en de batterij daadwerkelijk te schakelen.

🔹 5. Veiligheid ingebouwd
Als er iets misgaat (bijv. geen data of onverwachte waarden):
• alle 24 uurvariabelen worden op “Hold” gezet
• de error-variabele wordt op true gezet
• Homey kan daarop reageren of loggen

🔹 Resultaat
Elke dag krijg ik automatisch:
• de beste laaduren
• de beste ontlaaduren
• optimale arbitrage op basis van echte data
• en volledige controle in Homey-flows

De code:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
**
 * HomeyScript – Dynamische uurstrategie (maximale k, som-variant)
 * Kijkt altijd naar de prijzen van MORGEN.
 *
 * Variabelen:
 * - Dynprice_00 t/m Dynprice_23 (string: "Charge", "Discharge", "Hold")
 * - Sessy_ontlaad_drempel (percentage, numeriek)
 * - ontladen_error (boolean)
 */

const TOKEN = 'VUL HIER JE TIBBER API CODE IN';

const query = `
{
  viewer {
    homes {
      currentSubscription {
        priceInfo {
          tomorrow {
            startsAt
            total
          }
        }
      }
    }
  }
}`;

async function main() {

  const vars = await Homey.logic.getVariables();

  async function setVar(name, value) {
    const v = Object.values(vars).find(x => x.name === name);
    if (!v) throw new Error(`Variabele '${name}' niet gevonden`);
    await Homey.logic.updateVariable({ id: v.id, variable: { value } });
  }

  async function fail(reason) {
    for (let h = 0; h < 24; h++) {
      await setVar(`Dynprice_${String(h).padStart(2, '0')}`, "Hold");
    }
    await setVar("ontladen_error", true);
    return `❌ Fout: ${reason}`;
  }

  // --- Tibber ophalen ---
  let res;
  try {
    res = await fetch("https://api.tibber.com/v1-beta/gql", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "Authorization": "Bearer " + TOKEN
      },
      body: JSON.stringify({ query })
    });
  } catch (e) {
    return fail("Netwerkfout bij ophalen Tibber");
  }

  const json = await res.json();
  const raw = json?.data?.viewer?.homes?.[0]?.currentSubscription?.priceInfo?.tomorrow;

  if (!Array.isArray(raw) || raw.length !== 24) {
    return fail(`Tibber gaf ${raw?.length ?? "null"} prijsregels voor morgen i.p.v. 24`);
  }

  // --- Prijzen + uurindex ---
  const hours = raw.map((p, idx) => ({
    hour: idx,
    price: parseFloat(p.total)
  }));

  if (hours.some(x => isNaN(x.price))) {
    return fail("Onleesbare prijsdata ontvangen");
  }

  // --- Drempel inlezen ---
  const drempelVar = Object.values(vars).find(v => v.name === "Sessy_ontlaad_drempel");
  let threshold = 20;
  if (drempelVar) {
    const v = parseFloat(drempelVar.value);
    if (!isNaN(v)) threshold = v;
  }

  // --- Sorteren op prijs (laag → hoog) ---
  const sorted = [...hours].sort((a, b) => a.price - b.price);

  // --- Maximale k bepalen op basis van SOM-diff ---
  let optimalK = 0;
  const debugLines = [];

  for (let k = 1; k <= 12; k++) {
    const lowest  = sorted.slice(0, k);
    const highest = sorted.slice(24 - k);

    const sumLow  = lowest.reduce((a, x) => a + x.price, 0);
    const sumHigh = highest.reduce((a, x) => a + x.price, 0);

    if (sumLow === 0) continue;

    const diff = ((sumHigh - sumLow) / sumLow) * 100;

    debugLines.push(
      `k=${k}: sumLow=${sumLow.toFixed(4)}, sumHigh=${sumHigh.toFixed(4)}, diff=${diff.toFixed(2)}%`
    );

    if (diff >= threshold) {
      optimalK = k;  // steeds de grootste k bewaren die nog voldoet
    }
  }

  if (optimalK === 0) {
    for (let h = 0; h < 24; h++) {
      await setVar(`Dynprice_${String(h).padStart(2, '0')}`, "Hold");
    }
    await setVar("ontladen_error", false);
    return `ℹ️ Geen strategie voor morgen (verschil < ${threshold}%). Alles HOLD.\n` +
           debugLines.join('\n');
  }

  // --- Sets van uren bepalen ---
  const lowSet  = new Set(sorted.slice(0, optimalK).map(x => x.hour));
  const highSet = new Set(sorted.slice(24 - optimalK).map(x => x.hour));

  for (let h = 0; h < 24; h++) {
    const varName = `Dynprice_${String(h).padStart(2, '0')}`;
    let val = "Hold";
    if (lowSet.has(h))  val = "Charge";
    if (highSet.has(h)) val = "Discharge";
    await setVar(varName, val);
  }

  await setVar("ontladen_error", false);

  return `✅ Strategie voor morgen: k=${optimalK}, drempel=${threshold}%.\n` +
         debugLines.join('\n');
}

return main();

  • Soeski
  • Registratie: Februari 2000
  • Nu online
helm71 schreef op donderdag 27 november 2025 @ 21:45:
Ik heb een verbeterde regeling gemaakt voor mijn laad/ontlaad script.. In de vorige versie werkt ik met " de vier duurste" en " vier goedkoopste". uren per 12 uur blok. Maar er zijn me te veel dagen met geen twee pieken, maar 1 piek, of zelfs helemaal geen piek. Dat werkte op zich ook , maar kon beter... Ik heb nu een ander uitgangspunt gekozen..

Ook weer een staaltje vibecoden met chatgtp, ik heb de resultaten gecheckt en een lijkt prima te werken:

Trots op me @Twan_V ? ;-)

———————————————————

Zo werkt het:

🔹 1. Prijzen van morgen ophalen
Het script haalt de Tibber-uurprijzen op voor de volgende dag. Als dat mislukt of als er geen 24 prijzen beschikbaar zijn, zet het script automatisch een speciale foutvariabele op true en schakelt alles veilig naar “Hold”.

🔹 2. Beste laad- en ontlaaduur bepalen
De prijzen worden gesorteerd van laag naar hoog.
Daarna berekent het script voor k = 1 t/m 12 steeds:
• de k goedkoopste uren
• de k duurste uren
• en het percentage prijsverschil tussen die twee sets

🔹 3. Dynamische drempel (instelbaar)
Ik heb een variabele waarin ik zelf een drempel instel, bijv. 20%.
Alleen als het prijsverschil tussen goedkoop en duur boven die drempel ligt, is het economisch zinvol om te laden/ontladen.

Het script zoekt vervolgens de grootste k waarbij dat nog steeds rendabel is.
Dus als 8 goedkoopste en 8 duurste uren samen >20% verschil geven, maar 9 niet meer → dan wordt k=8 gekozen.

🔹 4. Uur-variabelen zetten
Voor elk uur van de dag bestaat een variabele zoals:
• Dynprice_00
• Dynprice_01
• …
• Dynprice_23

Het script vult die met:
• “Charge” → in de goedkoopste k uren
• “Discharge” → in de duurste k uren
• “Hold” → in de overige uren

Deze variabelen kunnen daarna gewoon in normale Homey-flows gebruikt worden om apparaten en de batterij daadwerkelijk te schakelen.

🔹 5. Veiligheid ingebouwd
Als er iets misgaat (bijv. geen data of onverwachte waarden):
• alle 24 uurvariabelen worden op “Hold” gezet
• de error-variabele wordt op true gezet
• Homey kan daarop reageren of loggen

🔹 Resultaat
Elke dag krijg ik automatisch:
• de beste laaduren
• de beste ontlaaduren
• optimale arbitrage op basis van echte data
• en volledige controle in Homey-flows

De code:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
**
 * HomeyScript – Dynamische uurstrategie (maximale k, som-variant)
 * Kijkt altijd naar de prijzen van MORGEN.
 *
 * Variabelen:
 * - Dynprice_00 t/m Dynprice_23 (string: "Charge", "Discharge", "Hold")
 * - Sessy_ontlaad_drempel (percentage, numeriek)
 * - ontladen_error (boolean)
 */

const TOKEN = 'VUL HIER JE TIBBER API CODE IN';

const query = `
{
  viewer {
    homes {
      currentSubscription {
        priceInfo {
          tomorrow {
            startsAt
            total
          }
        }
      }
    }
  }
}`;

async function main() {

  const vars = await Homey.logic.getVariables();

  async function setVar(name, value) {
    const v = Object.values(vars).find(x => x.name === name);
    if (!v) throw new Error(`Variabele '${name}' niet gevonden`);
    await Homey.logic.updateVariable({ id: v.id, variable: { value } });
  }

  async function fail(reason) {
    for (let h = 0; h < 24; h++) {
      await setVar(`Dynprice_${String(h).padStart(2, '0')}`, "Hold");
    }
    await setVar("ontladen_error", true);
    return `❌ Fout: ${reason}`;
  }

  // --- Tibber ophalen ---
  let res;
  try {
    res = await fetch("https://api.tibber.com/v1-beta/gql", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "Authorization": "Bearer " + TOKEN
      },
      body: JSON.stringify({ query })
    });
  } catch (e) {
    return fail("Netwerkfout bij ophalen Tibber");
  }

  const json = await res.json();
  const raw = json?.data?.viewer?.homes?.[0]?.currentSubscription?.priceInfo?.tomorrow;

  if (!Array.isArray(raw) || raw.length !== 24) {
    return fail(`Tibber gaf ${raw?.length ?? "null"} prijsregels voor morgen i.p.v. 24`);
  }

  // --- Prijzen + uurindex ---
  const hours = raw.map((p, idx) => ({
    hour: idx,
    price: parseFloat(p.total)
  }));

  if (hours.some(x => isNaN(x.price))) {
    return fail("Onleesbare prijsdata ontvangen");
  }

  // --- Drempel inlezen ---
  const drempelVar = Object.values(vars).find(v => v.name === "Sessy_ontlaad_drempel");
  let threshold = 20;
  if (drempelVar) {
    const v = parseFloat(drempelVar.value);
    if (!isNaN(v)) threshold = v;
  }

  // --- Sorteren op prijs (laag → hoog) ---
  const sorted = [...hours].sort((a, b) => a.price - b.price);

  // --- Maximale k bepalen op basis van SOM-diff ---
  let optimalK = 0;
  const debugLines = [];

  for (let k = 1; k <= 12; k++) {
    const lowest  = sorted.slice(0, k);
    const highest = sorted.slice(24 - k);

    const sumLow  = lowest.reduce((a, x) => a + x.price, 0);
    const sumHigh = highest.reduce((a, x) => a + x.price, 0);

    if (sumLow === 0) continue;

    const diff = ((sumHigh - sumLow) / sumLow) * 100;

    debugLines.push(
      `k=${k}: sumLow=${sumLow.toFixed(4)}, sumHigh=${sumHigh.toFixed(4)}, diff=${diff.toFixed(2)}%`
    );

    if (diff >= threshold) {
      optimalK = k;  // steeds de grootste k bewaren die nog voldoet
    }
  }

  if (optimalK === 0) {
    for (let h = 0; h < 24; h++) {
      await setVar(`Dynprice_${String(h).padStart(2, '0')}`, "Hold");
    }
    await setVar("ontladen_error", false);
    return `ℹ️ Geen strategie voor morgen (verschil < ${threshold}%). Alles HOLD.\n` +
           debugLines.join('\n');
  }

  // --- Sets van uren bepalen ---
  const lowSet  = new Set(sorted.slice(0, optimalK).map(x => x.hour));
  const highSet = new Set(sorted.slice(24 - optimalK).map(x => x.hour));

  for (let h = 0; h < 24; h++) {
    const varName = `Dynprice_${String(h).padStart(2, '0')}`;
    let val = "Hold";
    if (lowSet.has(h))  val = "Charge";
    if (highSet.has(h)) val = "Discharge";
    await setVar(varName, val);
  }

  await setVar("ontladen_error", false);

  return `✅ Strategie voor morgen: k=${optimalK}, drempel=${threshold}%.\n` +
         debugLines.join('\n');
}

return main();
Ziet er tof uit - maar hoe verwerk je dit in een NIET Advanced flow? Hoe check je 24x uur-variabelen in relatie tot de juiste tijd van de dag en zorg je dat het juiste gebeurt? In een Advanced Flow kan ik me nog iets voorstellen, maar in een simpele flow... ik ben benieuwd hoe dit eruit ziet.

  • helm71
  • Registratie: Februari 2012
  • Laatst online: 10:24
Soeski schreef op donderdag 27 november 2025 @ 22:47:
[...]

Ziet er tof uit - maar hoe verwerk je dit in een NIET Advanced flow? Hoe check je 24x uur-variabelen in relatie tot de juiste tijd van de dag en zorg je dat het juiste gebeurt? In een Advanced Flow kan ik me nog iets voorstellen, maar in een simpele flow... ik ben benieuwd hoe dit eruit ziet.
Paar opties… de meest simpele vorm zou zijn om 48 standaard flows te maken die allemaal starten op 1 vol uur..

Dat werkt maar heel charmant is het niet… ik heb een tweede homey script gemaakt dat elk uur draait, en dan een variabele vult met “wat de batterij nu moet gaan doen”. Als dat werkt hoef ik alleen maar 1 of 2 flows te maken om op basis van die ene variabele de juiste aktie te nemen, de normale flows hoeven dan de uren niet te kennen…

Dit draait nu bij mij, ik wil even kijken of dat goed werkt voordat ik de code deel.

  • Boeryepes
  • Registratie: Januari 2016
  • Niet online
helm71 schreef op vrijdag 28 november 2025 @ 07:35:
[...]


Paar opties… de meest simpele vorm zou zijn om 48 standaard flows te maken die allemaal starten op 1 vol uur..

Dat werkt maar heel charmant is het niet… ik heb een tweede homey script gemaakt dat elk uur draait, en dan een variabele vult met “wat de batterij nu moet gaan doen”. Als dat werkt hoef ik alleen maar 1 of 2 flows te maken om op basis van die ene variabele de juiste aktie te nemen, de normale flows hoeven dan de uren niet te kennen…

Dit draait nu bij mij, ik wil even kijken of dat goed werkt voordat ik de code deel.
State engine 😁 dat brengt me 30 jaar terug in de tijd toen ik nog echt leuke dingen deed in C.

The biggest communication problem is we do not listen to understand. We listen to reply.


  • Soeski
  • Registratie: Februari 2000
  • Nu online
helm71 schreef op vrijdag 28 november 2025 @ 07:35:
[...]


Paar opties… de meest simpele vorm zou zijn om 48 standaard flows te maken die allemaal starten op 1 vol uur..

Dat werkt maar heel charmant is het niet… ik heb een tweede homey script gemaakt dat elk uur draait, en dan een variabele vult met “wat de batterij nu moet gaan doen”. Als dat werkt hoef ik alleen maar 1 of 2 flows te maken om op basis van die ene variabele de juiste aktie te nemen, de normale flows hoeven dan de uren niet te kennen…

Dit draait nu bij mij, ik wil even kijken of dat goed werkt voordat ik de code deel.
Dank! Ik vermoedde al zoiets, want ik zag al niet voor me hoe er in een simpele flow in één run 24 variabelen uitgelezen worden en daar iets mee laat doen. Misschien kan je de variabelen wel weer laten inlezen door een andere, en de flow leest die uit. Ik ben nog vrij vers in flows en variabelen, maar ik ontdek elke keer meer.

  • helm71
  • Registratie: Februari 2012
  • Laatst online: 10:24
Soeski schreef op vrijdag 28 november 2025 @ 08:53:
[...]

Dank! Ik vermoedde al zoiets, want ik zag al niet voor me hoe er in een simpele flow in één run 24 variabelen uitgelezen worden en daar iets mee laat doen. Misschien kan je de variabelen wel weer laten inlezen door een andere, en de flow leest die uit. Ik ben nog vrij vers in flows en variabelen, maar ik ontdek elke keer meer.
Het script heeft nog geen 24 uur gedraaid maar al wel een aantal uren en het lijkt goed te werken. Ik heb wel een u-bochtje moeten inbouwen omdat Homey standaard in UTC tijd draait en er dus iets mis ging met de planning, daarom een timezoneoffset variabele gemaakt die weet wat de correctie met UTC moet zijn, niet ideaal, maar goed, hoeft maar twee keer per jaar te veranderen..

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
/**
 * HomeyScript – Bepaalt de actie voor de thuisbatterij op basis van Dynprice_XX
 * Zet:
 *  - Sessy_Action
 *  - Sessy_Action_Note
 *
 * Tijdzone-offset via logica-variabele TimezoneOffsetHours (1 = winter, 2 = zomer)
 */

async function main() {

  const vars = await Homey.logic.getVariables();

  function getVar(name) {
    return Object.values(vars).find(v => v.name === name);
  }

  async function setVar(name, value) {
    const v = getVar(name);
    if (!v) throw new Error(`Variabele '${name}' niet gevonden`);
    await Homey.logic.updateVariable({ id: v.id, variable: { value } });
  }

  // ---- Tijdzone uit variabele ----
  const tzVar = getVar("TimezoneOffsetHours");
  const tz = Number(tzVar?.value ?? 1);   // default CET

  // ---- Tijd-diagnose ----
  const now = new Date();
  const utcHour = now.getUTCHours();
  const localHour = (utcHour + tz + 24) % 24;
  const hour = String(Math.floor(localHour)).padStart(2, "0");

  const timeStr = now.toString(); // HomeyScript's eigen tijd (UTC)

  // Variabele van het uur ophalen
  const dynName = `Dynprice_${hour}`;
  const dynVar = getVar(dynName);

  let noteText;

  if (!dynVar) {
    noteText =
      `❌ ${dynName} niet gevonden → Actie: Hold ` +
      `| UTC-uur=${utcHour} | Lokale-uur=${hour} | Tijd=${timeStr}`;
    await setVar("Sessy_Action", "Hold");
    await setVar("Sessy_Action_Note", noteText);
    return noteText;
  }

  const status = (dynVar.value || "").trim();
  const allowed = ["Charge", "Discharge", "Hold"];

  if (allowed.includes(status)) {
    noteText =
      `⏱️ Uur ${hour}: ${dynName} = ${status} ` +
      `| UTC-uur=${utcHour} | Lokale-uur=${hour} | Tijd=${timeStr}`;
    await setVar("Sessy_Action", status);
    await setVar("Sessy_Action_Note", noteText);
    return noteText;
  }

  // Onverwachte waarde → veiligheid
  noteText =
    `⚠️ Uur ${hour}: onverwachte waarde "${status}" in ${dynName} → Hold ` +
    `| UTC-uur=${utcHour} | Lokale-uur=${hour} | Tijd=${timeStr}`;
  await setVar("Sessy_Action", "Hold");
  await setVar("Sessy_Action_Note", noteText);
  return noteText;
}

return main();


Dit script draait elk uur met een normale " ieder uur" flow ( de " ieder uur". flow doet dat ook keurig aan start van het uur. Script kijkt dan naar de variabelen die per uur gezet zijn door het script dat 1 keer per dag draait en vult dan twee variabelen:

Sessy_Action: alfanummerieke variabele waarin gezet wordt "Charge", "Discharge" of "Hold"
Sessy_Action_Note: alfanumerieke variabele die vertelt wat het script gedaan heeft, hij geeft daarin ook de tijd aan die hij denkt dat het is, dan is een eventueel probleem daarmee snel zichtbaar (zie offset hierboven), draait nu overigens prima.

Voor de Sessy_Action variabele maak je een "If variable changed" flow dat doet:

- als waarde CHARGE wordt, dan Sessy aansturing op API en laadstand op LADEN
- als waarde DISCHARGE wordt, dan Sessy aansturing op NOM
- als waarde HOLD wordt, dan Sessy aansturing op LADEN (of een IDLE stand oid, liefst wil je iets waardoor hij wel zonnestroom laad als dat er is maar voor de rest niets)

Met een normale flow zou dat met twee afzonderlijke flows moeten, ik denk dat ik hier een advanced flow voor maak, dan is dat simpeler (en gedrag kan ik met de variabelen goed volgen.

Voor de Sessy_Action_Note variabele maak ik een " if variable changed". flow die de inhoud van die variabele in de tijdlijn van Homey duwt zodat je mooi weet wat het systeem aan het doen is.

Aandachtspunt was nog:

Ik heb een paar flows die kijken of er sprake van fase overbelasting en als hij dat ziet laat ik de sessie 10 minuten ontladen, om daarna weer terug te gaan naar LADEN (als de sessie al op NOM staat doet hij dat zelf al). Als die switch gebeurt rondom een uur waarin de waarde van CHARGE naar DISCHARGE gaat, zouden mijn scripts hem na de 10 minuten "fase helpen". terug zetten naar LADEN terwijl dat inmiddels DISCHARGE moet zijn... Om dat op te lossen voeg ik aan het einde van mijn " klaar met fase helpen". flow (10 minuten zandloper leeg) het script dat elk uur draait nog een keer toe, dan wordt de sessie_action variabele weer gezet zoals hij moet zijn en nemen de flows die daarop sturen vanzelf weer actie..

  • BerndGaykema
  • Registratie: December 2017
  • Laatst online: 28-11 11:03
MajaMestreech schreef op donderdag 20 november 2025 @ 16:25:
Ik heb nu een homey en probeer te voorkomen dat bij het laden van de EV de batterij wordt leeggetrokken. Hierbij wil ik gebruik maken van de optie "Waarde Grid Target" zoals die ook in de My Home Battery app zit.
Hiervoor de onderste flow gemaakt, echter de actie "Zet XOM Net doelvermogen" op 1000W die geeft een error. Heeft iemand dit wel werkend?

[Afbeelding]
In de nieuwste versie (3.2.1) van de Sessy app in Homey is dit probleem opgelost.

  • helm71
  • Registratie: Februari 2012
  • Laatst online: 10:24
helm71 schreef op vrijdag 28 november 2025 @ 11:01:
[...]


Het script heeft nog geen 24 uur gedraaid maar al wel een aantal uren en het lijkt goed te werken. Ik heb wel een u-bochtje moeten inbouwen omdat Homey standaard in UTC tijd draait en er dus iets mis ging met de planning, daarom een timezoneoffset variabele gemaakt die weet wat de correctie met UTC moet zijn, niet ideaal, maar goed, hoeft maar twee keer per jaar te veranderen..
de bijbehorende Advanced Flow. Zoals ik het nu kan zien werkt dit prima:

Afbeeldingslocatie: https://tweakers.net/i/zZ45XyV1cR7KD09NwpUZWU6QuLI=/800x/filters:strip_exif()/f/image/XjXElSaqzHGe2ArmlV5kZFLZ.png?f=fotoalbum_large

  • MajaMestreech
  • Registratie: Februari 2022
  • Laatst online: 00:28
BerndGaykema schreef op vrijdag 28 november 2025 @ 11:01:
[...]

In de nieuwste versie (3.2.1) van de Sessy app in Homey is dit probleem opgelost.
Yes en al getest en teruggekoppeld naar de ontwikkelaar.

  • Soeski
  • Registratie: Februari 2000
  • Nu online
helm71 schreef op vrijdag 28 november 2025 @ 13:08:
[...]

de bijbehorende Advanced Flow. Zoals ik het nu kan zien werkt dit prima:

[Afbeelding]
Ik heb een advanced flow gemaakt die ook meteen het script elk uur draait, welke de Sessy_Action aanpast. Ben benieuwd hoe het allemaal gaat lopen. Zeker in relatie tot de standaard ECO instelling die de helft hiervan ook al doet. Alleen; ECO weet niet wanneer er NIET ontladen mag worden. Die kijkt alleen naar goedkoop LADEN, niet naar duur ONTLADEN (ofwel de 20% prijsverschil, want onder de 20% heb je alleen maar met laad- en ontlaadverliezen te maken en win je niks inderdaad).

  • helm71
  • Registratie: Februari 2012
  • Laatst online: 10:24
Soeski schreef op vrijdag 28 november 2025 @ 17:26:
[...]

Ik heb een advanced flow gemaakt die ook meteen het script elk uur draait, welke de Sessy_Action aanpast. Ben benieuwd hoe het allemaal gaat lopen. Zeker in relatie tot de standaard ECO instelling die de helft hiervan ook al doet. Alleen; ECO weet niet wanneer er NIET ontladen mag worden. Die kijkt alleen naar goedkoop LADEN, niet naar duur ONTLADEN (ofwel de 20% prijsverschil, want onder de 20% heb je alleen maar met laad- en ontlaadverliezen te maken en win je niks inderdaad).
Precies dat…. Eco gaat op het juiste moment laden maar ontladen direct daarna en dat is dus niet maximaal voordeel…

Je kunt in de advanced flow sowieso van alles onder elkaar zetten, ik probeer het gebruik van advanced flow te vermijden als het niet nodig is… ik vind het lastig dat ik op mijn telefoon niets kan wijzigen… maar in het geval hier zou ik juist onnodige complexiteit toevoegen door het in een reguliere flow te maken, en dat is paard achter de wagen..

Ik ben heel benieuwd hoe het je bevalt..

Ik heb net wat pauzes tussen de commando’s die sessy aansturen gezet, als die te snel achter elkaar komen mist hij regelmatig de helft… met een paar keer 10 seconden pauze draait het stabiel.

[ Voor 10% gewijzigd door helm71 op 28-11-2025 18:15 ]


  • helm71
  • Registratie: Februari 2012
  • Laatst online: 10:24
helm71 schreef op vrijdag 28 november 2025 @ 13:08:
[...]

de bijbehorende Advanced Flow. Zoals ik het nu kan zien werkt dit prima:

[Afbeelding]
Inmiddels gezien dat alles na 24 uur nog steeds prima draait en de Advanced Flow aangepast zodat deze ook kan acteren op negatieve stroomprijzen. In basis had ik tot nu toe per uur een CHARGE, DISCHARGE of HOLD, ik heb nu een NEGATIVE toegevoegd.

Op het moment dat de variabele NEGATIVE wordt, gaat de batterij in oplaadstand, gaan alle lampen aan, en moduleer ik mijn omvormers naar 0% stroomproductie. Daarmee zorg ik voor geen teruglevering en tevens voor maximaal gebruik op het moment dat de stroom negatief is. Ik denk dat ik ook nog in staat ga zijn om mijn vaatwasser dan een heel duur 65 graden programma van een uur te laten starten als de klep toevallig dicht zit :-)

Om de rest van de flow niet kapot te maken heb ik nu natuurlijk bij CHARGE, DISCHARGE en HOLD ook commando's toegevoegd die de Solaredge omvormers weer 100% laten werken.

Het wordt steeds mooier...

Wel een voorbeeld van iets dat zonder een Advanced Flow niet te doen is..

(Note: Ik moet het script dat de variabele VULT nog aanpassen, alleen de Advanced Flow is al voorbereid.)

De wijziging op het script is al gemaakt, maar ik ga eerst kijken of de Advanced Flow keurig blijft werken voordat ik weer daar aan pruts, voorlopig toch geen negatieve prijzen (wat het overigens ingewikkeld maakt om te testen of dit überhaupt werkt..).

Wat ik in het dagelijks script doe is de logica gelijk laten aan nu maar aan het eind een soort overrule inbouwen die whatever er ook als strategie gekozen was dit omzet naar NEGATIVE als de prijs negatief is. Ik overweeg nog om een numeriek variabele toe te voegen die ik kan gebruiken om "negatief". te definiëren, dat is nu " minder dan 0", maar misschien wil ik wel "minder dan X cent" .. Dat is dan weer onhandig om hard in het script te zetten, dat moet dan via een variabele..

[ Voor 20% gewijzigd door helm71 op 29-11-2025 08:53 ]


  • mausy5043
  • Registratie: April 2021
  • Nu online

mausy5043

Don't panic.

Mijn vrouw ontdekte vannacht voor het eerst dat er een groen lampje knippert onder de batterijen elke 10s. Iemand een idee wat dat is? Ik heb het ook gezien, volgens mij is het de WiFi module.

Afbeeldingslocatie: https://tweakers.net/i/Erp7WIkuaCuECZDAekG_0ZWh-1k=/800x/filters:strip_icc():strip_exif()/f/image/J6fSZKHAxIJnvinURZKOxivA.jpg?f=fotoalbum_large

Kan het worden uitgeschakeld?
mausy5043 schreef op zondag 30 november 2025 @ 09:23:
Mijn vrouw ontdekte vannacht voor het eerst dat er een groen lampje knippert onder de batterijen elke 10s. Iemand een idee wat dat is? Ik heb het ook gezien, volgens mij is het de WiFi module.

[Afbeelding]

Kan het worden uitgeschakeld?
Een groen knipperend ledje is het heartbeat signaal.... Staat beschreven in de release notes. Volgens mij kun je dit niet uitzetten.

Sessy firmware

  • mausy5043
  • Registratie: April 2021
  • Nu online

mausy5043

Don't panic.

DJP! schreef op zondag 30 november 2025 @ 09:38:
[...]
Een groen knipperend ledje is het heartbeat signaal.... Staat beschreven in de release notes. Volgens mij kun je dit niet uitzetten.
Dat wordt dan het betere ducttape plakwerk. :)

  • ocaj
  • Registratie: Juli 2011
  • Niet online
Maar er is inderdaad iets veranderd aan de ledjes sinds 1.11.6, dus goed mogelijk dat je dit pas sinds kort ziet:

LED-statusindicatoren – Uniforme LED-signalen op de Sessy dongel, P1- en CT-meter
  • Groen – Heartbeat; standaard knippert het lampje groen
  • Wit – Ontbrekend signaal; de Sessy P1-of CT-meter ontvangt geen meetdata
  • Oranje – Verbindingsprobleem; geen verbinding met router of internet
  • Rood – Apparaatfout; er is een fout opgetreden in het apparaat
  • Blauw/wit – Het Access Point wordt opgestart of uitgezet
bron: https://www.sessy.nl/firmware-updates/

[ Voor 3% gewijzigd door ocaj op 30-11-2025 10:23 ]


  • mausy5043
  • Registratie: April 2021
  • Nu online

mausy5043

Don't panic.

Wist niet dat er ook een knop op het apparaat zit. Helaas kun je er alleen mee herstarten en niet volledig uitschakelen.

  • Soeski
  • Registratie: Februari 2000
  • Nu online
mausy5043 schreef op zondag 30 november 2025 @ 09:23:
Mijn vrouw ontdekte vannacht voor het eerst dat er een groen lampje knippert onder de batterijen elke 10s. Iemand een idee wat dat is? Ik heb het ook gezien, volgens mij is het de WiFi module.

[Afbeelding]

Kan het worden uitgeschakeld?
Als ik de foto zo zie, ben ik oprecht benieuwd hoe je last kan hebben van dit lampje? Je batterij lijkt niet in de buurt te zijn van waar je zit/leeft/bent.

  • mausy5043
  • Registratie: April 2021
  • Nu online

mausy5043

Don't panic.

@Soeski Foto is genomen, staande op de trap naar zolder. Links van mij is de slaapkamer. Mijn vrouw kijkt vanuit bed zo het trappegat in. Dat lampje projecteert mooi op de muur rechts.
Pagina: 1 ... 98 99 Laatste