PVOutput exports schedulen naar ingestelde upload interval #441
Conversation
Opgelost: dsmr_pvoutput/services.py:30: [W] W293 blank line contains whitespace [pycodestyle] dsmr_pvoutput/services.py:36: [C] E711 comparison to None should be 'if cond is None:' [pycodestyle]
|
Duurde beetje lang, ik had geen notificatie gekregen van de falende Travis CI build (weet niet of dat überhaupt gebeurt trouwens). Bij deze zijn de fouten daarvan gefixed. Zou nu goed moeten zijn voor zover ik kan zien. |
Codecov Report
@@ Coverage Diff @@
## development #441 +/- ##
===============================================
- Coverage 100% 99.91% -0.09%
===============================================
Files 96 96
Lines 2318 2327 +9
Branches 183 184 +1
===============================================
+ Hits 2318 2325 +7
- Misses 0 1 +1
- Partials 0 1 +1 |
Codecov Report
@@ Coverage Diff @@
## development #441 +/- ##
==========================================
Coverage 100% 100%
==========================================
Files 96 96
Lines 2318 2324 +6
Branches 183 183
==========================================
+ Hits 2318 2324 +6 |
|
Bedankt voor je request! Het klinkt inderdaad vrij aannemelijk dat de timing telkens een paar seconden verschuift. Ik zal er even naar kijken. Mocht je trouwens de mogelijkheid hebben om te kunnen ontwikkelen op een Linux-machine, dan is het vrij makkelijk om een ontwikkelomgeving op te zetten (ik heb alleen de stappen daarvoor nog niet concreet gedocumenteerd). Mocht je er behoefte aan hebben. |
|
Volgens mij kan ik wel een VM de lucht in schoppen met Linux erin voor ontwikkeling. Op zich is dat nog niet het grootste probleem denk ik, het is meer de omgeving eromheen dus een dev-database met toch wat inkomende data vanuit een slimme meter. Ik zag niet helemaal voor me hoe ik dat even snel kon opzetten hiervoor :-) De python code zelf schreef prima in Visual Studio Code; moet alleen even een goede linter installeren. Maar inderdaad, een guide met hoe een ontwikkelomgeving op te zetten voor dsmr is wel praktisch denk ik. Dan zijn ook complexere punten te tackelen, buiten steeds testen op m'n 'productie' dsmr installatie dan ;-) |
|
Ik heb het nu volgens mij simpeler voor je opgelost met alleen modulo-aftrekken op basis van de interval. Wil je eens meekijken in de tests of ik je probleem en oplossing goed heb begrepen?
|
|
Ik had ook aan deze aanpak gedacht maar ik dacht dat een modulo methode niet kon werken omdat je over het hele uur of zelfs dag heen zou kunnen gaan. Je tests testen volgens mij het juiste probleem plus assert maar wat zou de volgende casus doen met de huidige oplossing:
Gebeurt dat wel met de *= Het zou kunnen dat deze casus ook gedekt is en dat ik dat niet zie vanwege mijn wat mindere Python kennis hoor. Maar deze situatie was voor mij de reden voor de ietwat complexere aanpak 🙂 |
|
Bedankt voor je terugkoppeling. De huidige oplossing rond niet af naar boven en dat zou ook niet nodig moeten zijn, dus test 4 gaat niet werken in dit geval. Hij gaat altijd terug naar het eerstvorige punt en dat is altijd vooruit, ten opzichte van 'nu' (omdat hij eerst nu + interval doet). De backend wordt doorgaans elke seconde aangeroepen en is daarmee vrijwel gegarandeerd dat die telkens minstens één keer binnen de kleinste interval, van 5 minuten, draait en daarmee zou bovenstaande oplossing moeten werken. Je oorspronkelijke probleem zou hierdoor echter niet meer voor moeten komen, er van uitgaande dat de backend minstens 1x per interval (van minimaal 5 minuten) aangeroepen wordt en er daardoor geen gat ontstaat. De secondewijzer wordt daarnaast ook nog eens hard gereset. Hopelijk begrijp je wat ik bedoel. Het is wat lastig uit te typen. Wellicht wil je anders de branch |
|
Dennis Siemensma schreef op 2018-02-22 19:40:
… Bedankt voor je terugkoppeling. De huidige oplossing rond niet af naar
boven en dat zou ook niet nodig moeten zijn, dus test 4 gaat niet
werken in dit geval. Hij gaat altijd terug naar het eerstvorige punt
en dat is altijd vooruit, ten opzichte van 'nu' (omdat hij eerst nu +
interval doet).
De backend wordt doorgaans elke seconde aangeroepen en is daarmee
vrijwel gegarandeerd dat die telkens minstens één keer binnen de
kleinste interval, van 5 minuten, draait en daarmee zou bovenstaande
oplossing moeten werken.
Uitzonderingen zijn langdraaide runs, zoals het maken van de
database-backup en upload naar dropbox. Echter, dat probleem blijft
ook bestaan bij afronden naar boven, want er kan eenmaal een gat van X
minuten komen daardoor. De backend wordt gedurende de backup of upload
vastgehouden door dat proces.
Je oorspronkelijke probleem zou hierdoor echter niet meer voor moeten
komen, er van uitgaande dat de backend minstens 1x per interval (van
minimaal 5 minuten) aangeroepen wordt.
De .replace() vervangt letterlijk de waarde en voor de seconde zet ik
die op nul en voor de minuut gaat dat goed door de modulo (hij gaat
eerst naar het volgende uur en doet dan pas de module, dus resultaat
is daar altijd nul).
Test #3 [1] heeft een verspringing van het uur en ik heb nu ook nog
wat checks in de tests toegevoegd die het uur + seconde controleren.
Zie de nieuwe versie in 6febab4 [2].
Hopelijk begrijp je wat ik bedoel. Het is wat lastig uit te typen.
Wellicht wil je anders de branch pyrocumulus-pvoutput-schedule een
dagje thuis uitproberen voordat ik hem definitief doorvoer?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub [3], or mute the
thread [4].
*
Links:
------
[1] #3
[2]
6febab4
[3]
#441 (comment)
[4]
https://github.com/notifications/unsubscribe-auth/AWkkBr1hc2JubF--yRlmUKN9C6QN5eD6ks5tXbStgaJpZM4SO51o
|
|
Ah ik had over het hoofd gezien dat je nooit naar boven afrond; dan klopt je oplossing inderdaad en dat maakt alles wel een stuk simpeler :) Je aangepaste tests zijn prima, stukje explicieter op deze manier door hele timestamp te verifiëren. Je verhaal is verder duidelijk hoor! Ik wil de branch wel even testen hoor; zou je me wel de commando's kunnen geven waarmee ik dat tijdelijk in mijn installatie kan doen? Dat soort dingen heb ik nog niet vaak gepoogd met |
|
Als het goed is: Terug kan met: |
|
Oh dat is geheel niet moeilijk. Ga kijken of ik dat vanavond even kan fixen, dan kan ik het weekend mooi testen. Ik laat het je weten! |
|
Hmm, ik krijg het volgende na het switchen naar de andere branch: Processen blijven daarop vastlopen. Terug switchen naar master helpt helaas ook niet, ook tijdens de |
|
Damn, ik weet het denk ik al. Ik heb op de verkeerde manier m'n lokale changes ongedaan gemaakt. Ik ben letterlijk m'n |
|
Oké, opgelost. Sorry voor de spam ;-) Je kunt bovenstaande veilig negeren. M'n pi draait nu de test branch voor het komende weekend! Note to self: |
|
GIT kan soms best complex zijn, je bent niet de enige die wel eens wat kwijt is geraakt door GIT ;-)
Je zou ook nog dit kunnen doen om een volgende keer lokale wijzigingen weg te halen:
git reset --hard
|
|
Haha, no kidding! Reset hard is wel de juiste weg inderdaad. Ik had alleen
nog drie losse untracked bestanden die ik ook weg wilde gooien. En ik was
lui dus wilde dat ook met git doen. Maar ja inclusief ignored files was wel
beetje dom.
Fijn weekend alvast!
On Fri, 23 Feb 2018, 20:10 Dennis Siemensma, ***@***.***> wrote:
GIT kan soms best complex zijn, je bent niet de enige die wel eens wat
kwijt is geraakt door GIT ;-)
Je zou ook nog dit kunnen doen om een volgende keer lokale wijzigingen weg
te halen:
git reset --hard
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#441 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABpEJvlemntRwGtLsTvNqiFYzJsGDy8lks5tXw0egaJpZM4SO51o>
.
--
Sent from Samsung Galaxy.
|
|
Branch heeft het hele weekend goed gedraaid hoor. Doorgaans had ik in zo'n periode al minimaal één ontbrekend uploadmoment bij PVO gehad, dus ik beschouw het als opgelost 👍 |
|
Bedankt voor je terugkoppeling! Ik zal mijn versie dan voor je mergen naar |
|
Uitgebracht in de nieuwe release. |
Deze PR lost een klein schoonheidsfoutje op in de PVOutput export. Af en toe laat de export namelijk een gat vallen aan de kant van PVO en dat ziet er dan zo uit:
Na wat pluiswerk in de logs, kwam ik tot de conclusie dat de upload tijd uiteindelijk een beetje gaat verschuiven in seconden en niet exact altijd 5 minuten is als je dat ingesteld hebt. De timestamp van de upload wordt daarnaast afgerond op hele minuten, waardoor de hele tijd ineens met een minuut aangepast wordt. Dit veroorzaakt timings als:
Dit betekent dat de uploads aan de kant van PVO ook anders afgerond worden, namelijk naar respectievelijk: 15:15, 15:20 en 15:30. Je mist in dit scenario dus de 15:25 upload. Ik heb meerdere van deze situaties bekeken en vergeleken met de log en de oorzaak lijkt elke keer zo'n versprongen minuut te zijn.
In deze PR die ik inmiddels al een paar dagen lokaal gebruik, rond ik het schedule tijdstip af naar het ingestelde aantal minuten maar dan alvast aan de kant van DSMR. De timing kan nog altijd wel een paar seconden afwijken maar dit verschil wordt elke keer weg 'afgerond'. Dit is voldoende om het probleem op te lossen, denk ik.
Ik ben geen Python eindbaas noch Django maar ik heb wel m'n best er op gedaan. Kon dit alleen testen door de code op mijn productie dsmr te draaien eigenlijk en heb alleen met mijn interval van 5 minuten getest (maar ik zie niet hoe dat een probleem kan zijn). Kijk er dus nog even goed naar zou ik zeggen 👍 Maar wellicht dat anderen dit verschijnsel ook af en toe bij PVO zien.