Dsmr-reader: Import old data

[conradhagemans]

Ik heb al 3 jaar historische data in een eigen database staan. Kan ik deze inlezen zodat ik direct met terugwerkende kracht deze informatie in de dashboards krijg?

[dennissiemensma]

Je kunt ze in principe inlezen via de API, of direct in de database, mits je zelf een beetje handig bent met scripten.

Er zit verder geen algemene import-functionaliteit in DSMR-reader, alleen de tools ervoor (API).

[conradhagemans]

Hoi Dennis,
Nu ik de software goed heb draaien en de telegrammen goed worden ingelezen wil ik mijn oude data inlezen.

Vraag is moet ik de file dsmr_datalogger_dsmrreading eerst leegmaken? Of kan ik oude data _toevoegen_ waarbij ik het veld processed on 0 zet?

Zijn er andere bestanden die ik eerst leeg moet maken zoals: dsmr_consumption_electricityconsumption en dsmr_consumption_gasconsumption ?

Dank vast.

[dennissiemensma]

Je kunt die tabellen niet zomaar leegmaken, want dan ben je alle data kwijt die DSMR-reader tot nu toe heeft gemeten. Het wordt een ander verhaal, wanneer je dat niet uitmaakt en gewoon schoon wilt beginnen.

Afhankelijk van hoe je bestaande data gemeten is kun je:

• ofwel de platte metingen in dsmr_datalogger_dsmrreading zetten met processed op False. Uiteindelijk verwerkt de applicatie deze metingen en zet ze in de twee tabellen die hieronder genoemd worden.

• ofwel gegroepeerde data (DSMR-reader groepeert standaard per minuut) gesplitst in dsmr_consumption_electricityconsumption en dsmr_consumption_gasconsumption zetten.

[conradhagemans]

Hoi Dennis,

Ik heb gisteravond alle historische telegram data (vanaf 1 januari 2018) geimporteerd in de dsmr_datalogger_dsmrreading tabel. Daar zitten nu ruim 101.162 records in. Vanochtend zag ik dat deze records geprocessed zijn.

Echter op de archief pagina kan ik niets terug vinden.

Kan het zijn dat hij nog bezig is de statistieken bij te werken? Of moet ik hier een iets voor opstarten?
Zie plaatje. Alleen september is beschikbaar:

[conradhagemans]

Sorry, nog een vraagje. In de configuratorzag ik negatieve gas data staan. Verwerkt hij de telegrammen chronologisch op datum of in de volgorde van binnenkomst?
En maakt dat uit voor de statistieken?

[dennissiemensma]

• De metingen worden eerst omgezet naar de twee *consumption-tabellen. Daarna naar dag- en uurstatistieken. Die laatsten worden gebruikt in het Archief. Mogelijk werkt dat niet helemaal lekker automatisch, met terugwerkende kracht. Je zou dit kunnen proberen, zodat die alles opnieuw berekent (dus ook de data die je al gemeten had met DSMR-reader):

# Wellicht wil je hiervoor het proces 'dsmr_backend' ook even uitschakelen in Supervisor, 
# zodat het command hieronder rustig zijn ding kan doen. Daarna kan die weer aan.

sudo su - dsmr
./manage.py dsmr_backend_delete_aggregated_data --statistics --readings --consumption

• Voor je andere probleem kun je denk ik ook het beste eerst bovenstaande suggestie proberen. Er zit overigens geen detectie in voor missende dagen of meterwissels, dus als de standen opeens verspringen van het ene of het andere moment, dan kan dat kloppen. Hij zou ze wel chronologisch moeten verwerken.

Ik hoor graag of dit het oplost. Anders zullen we even in de database moeten kijken wat die er exact van gemaakt heeft.

[conradhagemans]

Super. Omdat ik toch ook nog een eigen database heb met alle data ga ik vanavond alles leeg maken en dan de import doen waarbij de bron data van oud naar nieuw staat gesorteerd. Ik zet dan ook eerst de reader uit. Mis ik hooguit enkele minuten aan data.
Ik zal laten weten of het lukt.

[conradhagemans]

Even een update. Het is gelukt.

Ik heb alle tabellen met telegram data leeg gemaakt (SQL Truncate). Dan staat ook de ID tellen weer op 0.

Export van alle data uit mijn eigen telegram database sinds 2015.
Alle processen stopgezet in supervisor
Ingelezen in dsmr_datalogger_dsmrreading (350k records!).
Script gedraait om alle datetime velden 2 uur terug te zetten.
Alle processen weer aangezet in supervisor.

Duurde ongeveer 24 uur toen was alle data verwerkt en statistieken bijgewerkt.

Super. Waarom staan de datetime velden in de database op -2 uur van onze tijd?
Ik ga nu de tarieven invoeren en zal dus een deel opnieuw moeten doen.

Ik heb wel een paar vragen over de tarieven of verbeter voorstellen misschien. Die zal ik vragen in een apart topic.

[dennissiemensma]

Mooi dat je zover gekomen bent!

De tijden staan niet perse op -2 uur in de database, maar worden vaak wel opgeslagen in UTC. Het is belangrijk dat je meegeeft in welke tijdzone de data zich bevindt. De database houdt daar vervolgens rekening mee en de applicatie ook en verder heb je er al het goed is geen omkijken meer naar.
Zie ook issue #227 en je kunt het zelf heel makkelijk proberen:

sudo su - postgres
psql dsmrreader

Je zit nu in de DB.

# Vervolgens geef je de gewenste tijdzone op:
set time zone 'Europe/Amsterdam' ;

# En zoek je het de eerste meting.
select id, timestamp from dsmr_datalogger_dsmrreading order by id asc limit 1;

Ik krijg bijvoorbeeld dit. Let goed om de tijdzoneaanduiding van +01 achter de tijd:

 id |       timestamp        
----+------------------------
  1 | 2015-12-11 22:25:05+01

Als ik nu de tijdzone wissel en hetzelfde doe:

# UTC
set time zone UTC;

# Meting weer zoeken.
select id, timestamp from dsmr_datalogger_dsmrreading order by id asc limit 1;

Nu is de output dezelfde meting (zie ook ID), maar een andere tijd, echter de tijdzone is ook bijgewerkt naar 00:

 id |       timestamp        
----+------------------------
  1 | 2015-12-11 21:25:05+00

Zoals je kunt zien is dat exact dezelfde tijd en dat is precies zoals het zou moeten werken. In welke tijdzone de data staat is niet zo belangrijk, zolang het maar de juiste is bij opslag. PostgreSQL converteert het dan zelf wel naar de gewenste tijdzone op het moment dat het nodig is.

Hopelijk is dit helder genoeg voor je.

[dennissiemensma]

Ter aanvulling, je kunt dus niet zomaar -1 of -2 uur doen, tenzij je dat zelf expliciet hebt opgeslagen in je eigen data en die tijdzone-bewust is.
Je zult anders moeten kijken of op dat moment de zomertijd of wintertijd gold, anders krijg je telkens vreemde verspringingen eind maart en eind oktober.

[conradhagemans]

Hmmm. Beetje apart. Ik gebruik MySQL.
Ik krijg de volgende output:

MySQL [dsmrreader]> select now();
+---------------------+
| now()               |
+---------------------+
| 2018-09-21 13:59:26 |
+---------------------+
1 row in set (0.00 sec)

MySQL [dsmrreader]> SELECT @@system_time_zone;
+--------------------+
| @@system_time_zone |
+--------------------+
| CEST               |
+--------------------+
1 row in set (0.00 sec)

MySQL [dsmrreader]> select id, timestamp from dsmr_datalogger_dsmrreading order by id desc limit 1;
+--------+---------------------+
| id     | timestamp           |
+--------+---------------------+
| 406628 | 2018-09-21 11:59:25 |
+--------+---------------------+
1 row in set (0.00 sec)

De tijd in MySQL klopt met de huidige tijd. In de records staan de tijden -2 uur. Echter in de frontend worden ze goed getoond.

Dus het gaat wel goed!
Ergens wordt de tijd dus omgezet naar +2 uur.

[dennissiemensma]

Aah juist, dat is een vrij belangrijk detail dat je MySQL gebruikt en niet PostgreSQL.

In dat geval gaat mijn verhaal niet op, ik weet niet hoe vloeiend de ondersteuning voor tijdzones in MySQL is namelijk. Het kan zijn dat het framework van DSMR-reader onderwater daarom alles naar UTC omzet, zodat het altijd goed gaat.

[luchtenburger]

Het importeren van historische data gaat bij mij ook niet helemaal goed. Ik heb mijn meterstanden vanaf 2013 vanuit een Domoticz database geëxporteerd naar een csv file. Hieruit heb ik de meterstanden op de eerste en laatste dag van de maand gehaald en in een nieuw csv bestand opgeslagen. Deze data heb ik met een Python script (gebasseerd op het voorbeeld uit de handleiding) via de API naar DSMR reader gestuurd met als tijdstip 12:00:00. Na het importeren heb ik het dsmr_backend_delete_aggregated_data commando uitgevoerd. Nadat ik de processen weer gestart heb met supervisor gaf de status pagina aan dat er ongeveer 130 telegrammen verwerkt moesten worden. Na enige tijd waren de telegrammen verwerkt en nu kan ik op de archief pagina ook alle jaren vanaf 2013 aanklikken. Er is echter geen verbruik in elk jaar.
Op de DSMR-uitlezing pagina staan netjes alle metingen vermeld met een groen viknkje bij processed. Wat doe ik fout of wat kan ik nog meer controleren om uit te zoeken hoe dit op te lossen is?
Ik maak trouwens gebruik van de PostgreSQL database.

[dennissiemensma]

@luchtenburger het zou kunnen komen doordat DSMR-reader het verbruik baseert op minimaal uren en/of dagen en niet maanden. Op maandbasis is dat waarschijnlijk te weinig detail en ik heb dat nooit zelf geprobeerd. Je kunt in de admin-interface, bijna onderaan, bij Dagstatistieken kijken of die jaren uberhaupt iets corrects hebben staan qua dagen en verbruik. De Dagstatistieken zijn namelijk leidend voor het archief.

Ik kan je aanraden om hetzelfde nogmaals te doen, maar dan te zorgen dat je een meting aan het begin en eind van elke dag hebt. Of nog beter, elk uur, als je er toch een script voor hebt. Ik verwacht dat die dan beter gaat. Je kunt bij Dagstatistieken dan zien wat die ervan gemaakt heeft.

[luchtenburger]

Bedankt voor de snelle reactie!
In de Domoticz database staan de meterstanden helaas per dag, niet per uur. Ik moet dus even uitzoeken hoe ik deze data kan manipuleren zodat ik minimaal twee waarden per dag in de database kan zetten.
Het is nu in ieder geval duidelijk wat ik moet veranderen.

[dennissiemensma]

@luchtenburger wat je nog wellicht kunt proberen is om de meterstand van dezelfde dag op 00:00 te zetten en die van de volgende dag op 23:59. En dat proces herhalen totdat je alles gehad hebt.

Als je nu hebt:

Standen:
- Dag 1: 1000 kWh
- Dag 2: 1010 kWh
- Dag 3: 1015 kWh
- Dag 4: 1022 kWh

Dan wordt het:

- Dag 1 00:00: 1000 kWh
- Dag 1 23:59: 1010 kWh

- Dag 2 00:00: 1010 kWh
- Dag 2 23:59: 1015 kWh

- Dag 3 00:00: 1015 kWh
- Dag 3 23:59: 1022 kWh

etc...

Alternatief
Als simpeler alternatief kun je ook in de tabel dsmr_stats_daystatistics zelf direct vullen met je bestaande gegevens. Daar komt dan je daadwerkelijke verbruik in (zie bijvoorbeeld data die je zelf meet met DSMR-reader en die die al gegenereerd heeft). Je kunt vervolgens gebruik maken van het Archief en maanden/jaren zijn te bekijken. Individuele dagen geven ook de dagtotalen weer in de tabel, maar echter geen grafieken (daarvoor zijn uurstatistieken nodig).
Als je dit doet, zorg er dan wel voor dat je, na import, even een backup maakt van je gegevens in dsmr_stats_daystatistics. Het zou zonde zijn als die gegevens namelijk met een migratie, of door een handmatige actie, opnieuw gegenereerd worden en de applicatie ze niet opnieuw kan maken, want de brondata (metingen) is er niet.
Een ander bijeffect is dat de Trends-pagina zonder uurstatistieken niet werkt voor je vorige jaren, maar ik ga er vanuit dat je daar niet heel rouwig om zult zijn. Als het goed is werkt de pagina wel voor alle nieuwe data die DSMR-reader zelf meet (of binnenkrijgt) namelijk.

[luchtenburger]

Na een paar avonden experimenteren heb ik het voor elkaar. Ik heb de strategie zoals door Dennis hierboven beschreven ongeveer gevolgd:

• Data N importeren op dag 1 23:59:00
• Data N importeren op dag 2 00:00:00
• Data N+1 importeren op dag 2 23:59:00
• Data N+1 importeren op dag 3 00:00:00
• Data N+2 importeren op dag 3 23:59:00
• enz.

Meter wisseling geeft sprongen in de data, ik ben dus begonnen met negatieve data (zodat ik op de dag van de meter wisseling uit kwam bij meterstand 0)

Data in Domoticz wordt in Wh opgeslagen, hier moet dus een punt in gezet worden om kWh te krijgen voor DSMR reader (in het gas verbruik moet ook een punt gezet worden).

Tijdens het importeren heb ik alle processen met 'supervisorctl' stop gezet.

Ik heb het Python script en een kort sample van mijn CSV data toegevoegd voor anderen die willen migreren.

DSMR_reader_import_script.zip

[dennissiemensma]

Bedankt voor je update en mooi dat het gelukt is.

Je kunt nog eventueel de sprongen bij meterwisselingen handmatig verbeteren bij Dagstatistieken. Als het goed is wijkt er slechts steeds één dag af, per meterwisseling.

[remb0]

hoi luchtenburg hier ben ik dus ook op zoek naar een optie om 6 jaar Domoticz in dsmr te krijgen. alleen als ik naar jouw csv kijk kom ik er niet helemaal achter welke gegevens in je CSV zitten. en met welke export je die daar gekregen hebt.
ik heb een meter met piek en dal en daarnaast nog eens gas.

kun je dat misschien uit de doeken doen en me hierbij op weg helpen?

[luchtenburger]

hallo @remb0, ik weet de details niet meer zo goed, maar ik ga een poging doen ;)
De Domoticz database moet in te lezen zijn met 'DB browser for SQLite' (https://sqlitebrowser.org/). Ik heb hier zelf geen domoticz database meer, ik kan dus niet zien hoe de tabellen eruit zien... Dat is nog wel een beetje een puzzel, maar als je weet welke tabel je moet hebben (google, tweakers en het domoticz forum zijn een rijke bron aan informatie) kun je deze exporteren naar een CSV file.
Dat bestand moet je dan eventueel eerst in Excel nog bewerken om de formattering goed te krijgen, maar daarna moet je deze dus in DSMR reader kunnen inlezen.
Ik hoop dat je hier wat aan hebt, als je meer specifieke informatie nodig hebt hoor ik het wel.

[remb0]

super!
allereerst bedankt voor je reactie.

sql kan ik gebruiken om mijn db te openen dat moet geen probleem zijn. ook
kan ik vanuit domoticz nog csv exporteren als dat moet en de csv aanpassen.
ging mij meer om de kolommen die je in de csv had.
als ik weet wat ik in welke kolom moet zetten zou ik er moeten komen.
ik heb een dubbele meter en gas in domoticz. en de getallen die ik in jou
voorbeeld zie kan ik niet stroken.

sinds vandaag heb ik zonnepanelen en gebruik wil ik dus helemaal
overstappen op dsmr :) en dan is het natuurlijk super om alle historische
data er ook in te hebben.

Met vriendelijke groet,

Remco van Geel

Op wo 9 jan. 2019 om 22:05 schreef luchtenburger [e-mail]:

hallo @remb0 https://github.com/remb0, ik weet de details niet meer zo
goed, maar ik ga een poging doen ;)
De Domoticz database moet in te lezen zijn met 'DB browser for SQLite' (
https://sqlitebrowser.org/). Ik heb hier zelf geen domoticz database
meer, ik kan dus niet zien hoe de tabellen eruit zien... Dat is nog wel een
beetje een puzzel, maar als je weet welke tabel je moet hebben (google,
tweakers en het domoticz forum zijn een rijke bron aan informatie) kun je
deze exporteren naar een CSV file.
Dat bestand moet je dan eventueel eerst in Excel nog bewerken om de
formattering goed te krijgen, maar daarna moet je deze dus in DSMR reader
kunnen inlezen.
Ik hoop dat je hier wat aan hebt, als je meer specifieke informatie nodig
hebt hoor ik het wel.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dennissiemensma/dsmr-reader/issues/520#issuecomment-452834410,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnpqg-PaQbGrYQAIZLsEswDOL0Jk49Fks5vBlmmgaJpZM4WpLg8
.

[luchtenburger]

Ik heb nog even in mijn gegevens gekeken, ik zie dat ik een Meter_Calendar.csv en een MultiMeter_Calendar.csv bestand heb. Dit moeten de twee tabellen zijn die ik uit de Domoticz database heb gehaald om in DSMR te importeren.

Informatie over deze tabellen wordt besproken in de volgende topics op het Domoticz forum:
https://www.domoticz.com/forum/viewtopic.php?t=18412
http://www.domoticz.com/forum/viewtopic.php?t=17465

Ik hoop dat je hier wat aan hebt!

[Baseje]

Ook bij mij gelukt oude data te importeren middels Powershell en API en de volgende stappen;
Domoticz to DSMRReader.zip

1. Export database binnen Domoticz
2. Open de database middels 'DB browser for SQLite' (https://sqlitebrowser.org/)
3. Exporteer de tabellen 'Meter_Calendar' en 'Multimeter_Calendar' met als seperator ';'.
4. Zet de API binnen DSMR Reader aan en kopieer de key.
5. Open het powershell script middels de Powershell ISE.
6. Pas het powershell de volgende zaken aan: 'LOCATIE CSV' , 'APIKEY' en 'URL-DSMR' met de gegevens zoals eerder geëxporteerd.
7. Start vervolgens het Powershell script, waarna je flink een aantal API calls ziet gebeuren.

Het powershell script importeert de CSV's en zorgt ervoor dat exact de juiste conventie gepusht word per API call. Dit gebeurd voor iedere meting om 00.00 en om 23.59 (Dit zodat de dagen gevuld worden).

Vervolgens kan het wel even duren voordat gegevens zichtbaar worden in DSMR Reader Archief.
Overigens zagen we pas de gegevens van het terugleveren nadat we middels de P1 kabel werkelijk een teruglevering hadden, echter dan ook wel netjes in de historie.

[remb0]

bij stap 6 misschien goed om te vermelden om het juiste deviceID in te voeren. :)
Ik heb hem gedraait en het lijkt te werken:

`StatusCode        : 201
StatusDescription : Created
Content           : {"id":3115609,"timestamp":"2019-02-24T23:59:00+01:00","electricity_delivered_1":"8746.197","electricity_returned_1":"57.655","electricity_delivered_2":"8637.564","electricity_returned_2":"87.522","ele...
RawContent        : HTTP/1.1 201 Created
                    Connection: keep-alive
                    Allow: GET, POST, HEAD, OPTIONS                                                                                                                                                                                                              X-Content-Type-Options: nosniff                                                                                                                                                                                                              X-Frame-Options: DENY                                                                                                                                                                                                                        Vary: Accept-Language                                                                                                                                                                                                                        Content-Language: en
                    Content-Length: 743...
Forms             : {}
Headers           : {[Connection, keep-alive], [Allow, GET, POST, HEAD, OPTIONS], [X-Content-Type-Options, nosniff], [X-Frame-Options, DENY]...}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : mshtml.HTMLDocumentClass
RawContentLength  : 743

StatusCode        : 201
StatusDescription : Created
Content           : {"id":3115610,"timestamp":"2019-02-25T00:00:00+01:00","electricity_delivered_1":"8746.197","electricity_returned_1":"57.655","electricity_delivered_2":"8637.564","electricity_returned_2":"87.522","ele...
RawContent        : HTTP/1.1 201 Created
                    Connection: keep-alive
                    Allow: GET, POST, HEAD, OPTIONS                                                                                                                                                                                                              X-Content-Type-Options: nosniff                                                                                                                                                                                                              X-Frame-Options: DENY                                                                                                                                                                                                                        Vary: Accept-Language                                                                                                                                                                                                                        Content-Language: en
                    Content-Length: 743...
Forms             : {}
Headers           : {[Connection, keep-alive], [Allow, GET, POST, HEAD, OPTIONS], [X-Content-Type-Options, nosniff], [X-Frame-Options, DENY]...}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : mshtml.HTMLDocumentClass
RawContentLength  : 743`

Bij DSMR zag ik bij status wel meldingen als: 4 jaar geleden voor het laatst ontvangen. (wat kan kloppen omdat ik een aardige Domoticz historie had. maar daarna lijkt het archief niet te zijn aangevuld. is er nog iets wat ik kan doen of checken?

[Baseje]

Ik heb nergens in het script iets van een ID staan dus snap niet zogoed wat je bedoeld..
Archief kan dus flink even duren voordat hij gevuld word, leek wel dat als ik de geplande taak starten die ieder uur draait dat dit sneller ging.
Zie je de metingen wel in de admin panel?

[remb0]

ik doelde op:

Filter Specific DeviceRowID

$MULTIMETERCALENDARFILTER = $MULTIMETERCALENDAR | Where {$_.DeviceRowID -eq "29"}

we zijn nu een dag verder maar zie nog niets.

waar zou ik moeten kijken in het admin panel?

[pepijng]

Ik heb last van hetzelfde euvel. Ik vermoed dat het mis gaat omdat er reeds bestaande data in de DSMR database zit. De data uit domoticz staat netjes in de DSMR Readings tabel echter is er geen verwerking naar de andere tabellen van het archief. Tijdens een proef naar een lege database ging het wel goed.
Op dit moment ben ik een testje aan het doen om de data opnieuw te laden in een lege database, dus gecombineerd de oude data uit domoticz + de reeds gelezen data uit DSMR reader. De test loopt nog maar als dit werkt kan ik een kopie maken van de bestaande database, dan een nieuwe lege DSMR database aanmaken en alle data gesorteerd op originele datum opnieuw inlezen (voordat de datalogger weer aan gezet gaat worden :))

Update : Het werkt

PS Een andere uitdaging zit in de data die door Domoticz is verzameld tussen 2013 en eind 2014. Destijds werden alleen de dagelijkse verschillen opgeslagen, niet de actuele meterstanden. Met behulp van het PowerShell script zal hier dus een 0 worden geïmporteerd.
Deze (hele) oude data zal ik op een later moment misschien nog wel een keer herberekenen.

[remb0]

ik probeer deze data toe te voegen.
bron files.zip

uit mijn database backup zie ik in notepad++ wel dat de data is ingelezen. maar omdat de tabel en backup zo groot is crasht notepad hier gelijk.
Ik weet niet of er een check/repareer command is wat ik hiervoor zou kunnen draaien?

[EYEVO]

Toevallig iemand dit ook gedaan van p1mon (sqlite) naar DSMR reader?

[dennissiemensma]

@EYEVO als je in de gelegenheid bent om daar de datastructuur of voorbeeld van te delen, kun je er het beste een los issue van maken voor verder onderzoek.