Ok, DESS did it’s job the whole day. until the remote database went complete, poef.
Why should DESS be depended on a remote database when it already has all the dynamic pricing and the graphs showing it would sell.
And then just stops! if it has the data (or maybe could have the data?) and also already was showing the next day (yes before it went poef ) it should keep working.
True. I hate it when it decide to skip selling in the evening and keep the power for the next morning because it is 1 cent more benificial.
This power needs to be kept at 98-99% and peak shaving (witch only works above minimum charge) just cost 2 kWh extra to keep working during that night.
If the sell price is actual higher the next morning, it would be intended behavior. ( currently the Dutch 20:00 price was way higher than the tomorrow morning price )
My current issue is that because of the database, my system which was already showing all the data including the next day completely stopped selling at 20:00 when the highest day price went active. And halfway true the hour it decided to start selling.
Hi all, we’ve temporarily disabled DESS scheduling. This is the first feature on the list to re-enable.
Nevertheless, once the schedule is generated and sent to the GX device, it should indeed just carry out that schedule, regardless of the database connection. Will forward this case to the team.
So just to be complete, I’m running the latest stable in trade mode. If my dashboard on the lower half (the DESS part) was already showing the schedule and the next day prices, it should have followed that!? ( and it showed that data earlier in the day ) maybe all those systems doing all those not needed new queries (maybe a bug in the latest version) or complete instead of partial queries are causing an increased load? 461956
None of that information is known by your local device. The local device just receives a 12h schedule [which is updated every 15 minutes], so if the remote scheduler is experiencing issues, the local device can stick to a plan for upto 12h. After that time, the local cache is exhausted and the gx will just return to do regular ESS until new schedule data arrives.
Ik ben bezig met het opzetten van EMHASS Energy Management for Home Assistant. Is wel een ingewikkeld klusje maar werk een stuk beter (lineare optimalisatie) en meer configureerbaar. Ik ben dan niet meer afhankelijk van de Vicron databases voor het functioneren van DESS. Je hebt wel een API key nodig van bv Tibber voor het inlezen van de prijsdata (vrij verkrijgbaar). Daarnaast zou je ook andere publieke databases kunnen gebruiken. Je kan ook automatisch een inschatting op (weers) omstandigheden berekenen als fallback in geval de internet of de services op internet het begeven.
Victron is top spul maar internet afhankelijkheid is wel een dingetje.
Een fallback als ESS door zijn 12 uur cache heen is zou intresant zijn. Op dit moment heb ik al prijsdata in nodeRED want heb daar een simpel script welke mijn minimal Batt unless gridd failure instelt binnen een marge en 10% extra kan toe wijzen als de stroomprijs onder de 0cent komt.
DESS is helemaal van het padje. De prijs is nu (20.00 12-08) 35ct per kw, accu 75% soc en hij is aan het laden. Dit is niet acceptabel. Heb dess uitgeschakeld en de grid setpoint op -12000 gezet. Ik ga snel EMHASS op Home Assistant configureren.
Mijn DESS is weer normaal aan het verkopen (trade mode) afgelopen uur er al 5kWh uitgegooid en nu bezig met het beste uur ruim 10kWh aan het doen.
Ze zijn nu eerst bezig het probleem op te lossen, en er is al gemeld dat ze daarna gaan onderzoeken hoe ze dit in de toekomst kunnen voorkomen. Dat is voorlopig voldoende voor mij.
Persoonlijk vind ik de 12 uur lokaal cache wat kort en elke 15min contact wat overkill (en zeker voor iets wat offgrid georiënteerd) is. Maar als ik naar alles in mijn netwerk kijk en de hoeveelheid data die overal heen gaat dan vertrouw ik Victron een Nederlands bedrijf toch wat meer dan mijn WiFi aangesloten kattenvoer bak uit China.
Mee eens Victron is solide. Ik neem aan dat dit een software glitch is. Maar DESS is nog niet optimaal. tot in hoevere de Cerbo (Raspberry Pi) de computatie mogelijkheden heeft om een betere optimalisatie te runnen vraag ik mij wel af?