Data export: PVOutput about dsmr-reader HOT 67 CLOSED

Thanks for you very well detailed explanation. I've add this request to the backlog of the next (v1.6) release.

I might have some follow-up questions when working on this, or will ask you to check something, but I will mention you here again by that time. For now, I think I can make quite some progress with this feature with your information.

from dsmr-reader.

This would be very helpful indeed! I will keep an eye out for this feature.

from dsmr-reader.

Hi, this is scheduled for the upcoming release, you can view the roadmap here.

I try to plan new releases (1.6, 1.7, 1.8, etc) every 6 to 8 weeks. Things that needs a bugfix right away are release as patches (1.5.1, 1.5.2, etc), but since this is a new feature it will be part of a release.

Any testers are always welcome, but the time is not now (yet).

from dsmr-reader.

I am currently working on #230, as that would help quite some people in both importing and exporting data themselves.
An implementation for #9 will probably follow after that is complete.

from dsmr-reader.

Dennis, it is raining outside, how are you getting along? :) 👍

from dsmr-reader.

Het heeft flink wat tijd gekost, maar na meerdere pogingen heb ik het nu eindelijk werkend! Werkend in de zin dat het mogelijk is de volgende gegevens door te geven via https://pvoutput.org/help.html#api-addstatus.

Status-update van:

• v1: Teruggeleverde stroom vandaag tot nu toe (in Watt uur), naar het stroomnet toe.
• v2: Stroom'opwekking' op dat moment (in Watt), dus weinig zeggend volgens mij.
• v3: Verbruikte stroom vandaag tot nu toe (in Watt uur), dus vanaf het stroomnet.
• v4: Stroomverbruik op dat moment (in Watt), dus weinig zeggend volgens mij.
• Optioneel 'delay' in minuten (alleen wanneer je een donatie-account op PVOutput hebt)

Ik kan echter niet goed testen omdat ik zelf geen zonnepanelen heb. Mijn testaccount bij PVOutput laat sowieso alleen 'verbruik' zien en geen opwekking, ondanks dat dat 'netto' aangeleverd wordt aan de API (v1 + v2).

Echter, wellicht dat alleen v3 + v4 nodig is, zoals dit comment eerder aangaf.

Is er hier nog iemand dit dit ticket volgt en meer verstand heeft van hoe dit het beste geintegreerd kan worden met PVOutput? Indien nodig kan ik vrij makkelijk het doorgeven van v1 + v2 achterwege laten, zodat dat puur uit de omvormer komt (mits ondersteuning daarvoor).

from dsmr-reader.

v1 + v2 weglaten lijkt me geen gewenste optie.

opgewekt - meteen_gebruikt = teruggeleverd

V1 kun je dus niet uit je omvormer halen.

Maar van pvoutput weet ik dan helaas ook nog te weinig om te vertellen hoe het wel moet :(

from dsmr-reader.

Volgens mij moet je v1 en v2 juist wel weglaten, omdat je die apart moet aanleveren aan PVOutput.
Ik 'verwacht' van DSMR-reader alleen gegevens over (netto) consumptie. Mijn slimme meter weet niet wat ik 'genereer', alleen wat ik verbruik of teruglever.

Ik gebruik PVO en lever zelf al, apart, de V1/V2 informatie aan. Echter zonder gebruiksdata is al mijn productie geregistreerd als "export", terwijl er daadwerkelijk natuurlijk ook een deel gelijk gebruikt wordt in het huis.

Also: "When uploading Net data, generation must already exist at the same data point."

from dsmr-reader.

Bedankt voor de aanvullingen. Ik zal dat dan nog verwerken.

from dsmr-reader.

from dsmr-reader.

from dsmr-reader.

Je zou even kunnen kijken wat hij exact upload. Het zou moeten kloppen, maar wellicht heb ik wat over het hoofd gezien.

Als je deze regel verandert van:
print(' - PVOutput | Uploading data @ {}'.format(data['t']))

Naar:
print(' - PVOutput | Uploading data @ {}'.format(data))

En vervolgens dit doet (reload):
sudo supervisorctl restart dsmr_backend

Dan zie je als het goed is 1x per 5, 10 of 15 minuten in /var/log/supervisor/dsmr_backend.log voorbij komen wat hij doorstuurt voor elk van de velden.

from dsmr-reader.

Remark for data exposed to pvoutput:

• v1 Energy Generation No1 number watt hours 10000 r1
• v2 Power Generation No number watts 2000 r1
• v3 Energy Consumption No number watt hours 10000 r1
• v4 Power Consumption No number watts 2000 r1

from dsmr-reader.

I don't think a Pvoutput integration will work, as it requires Generated electricity, which is not the value read by DSMR and it's mandatory. However, there is also a value for Exported which is the exact value we can read from the DSMR.
So I either have to skip this feature or set the Generated to zero at all times. The side effect of the last option is that all existing data will be wiped, as Pvoutput only allows a single record for each day. Conflicting ones will override the existing one. This can be a problem when the solar power converter (such as SMA) uploads the values to pvoutput as well (which is supported by some brands).

And besides, if we can only export the Exported value of each day, it won't make any sense as this application supports plotting this data as well...

from dsmr-reader.

I think you've checked the Add Output service, which indeed needs the obligatory Generated field. This call is intended to be called at the end of the day. The Add Status service does not have this limitation and could be very well used by DSMR Reader.

As the Slimme Meter merely measures the difference between used and produced energy, you should take into account the solar power generated energy. I understand that this is not within the scope of this project, so support for the pvoutput API would be very useful. Please reconsider reopening this request. Would you be open for a pull request (if I find time to implement it)?

from dsmr-reader.

Thank you for your input. I've indeed only checked the Add Output call and did not see the Add Status call.

I will surely reopen and implement this, if there is a valid use case for it. You are correct regarding the scope of the project, I've rejected another request regarding power generation before for that exact reason (#145).

A pull request is not needed, it will suffice when you could elaborate a bit on how you'd like to see this work exactly.

The main issue for me is that I do not have solar panels, and I'm not using PVOutput myself, so you'd have to explain it a bit more to me about what we are talking about here.

• What does the Status data on PVOutput affect (how do you use it there)?

• The API docs state something about a 5 to 15 minute interval. Is that required or does a daily sync of meter positions suffice?

• Do you have an example of what should be transmitted? The docs state for example Send an energy value of 1000Wh and power value of 150W on 01/Dec/11 at 10:00AM, but it's easier to understand from someone actually using their service.

from dsmr-reader.

By submitting Status data, you enrich your solar production graphs with consumed energy data, e.g. PV Savelsbosch Total (to which I'm not related too, just to give you an example).

It would be best to submit power usage stats each 5 minutes as then you have your live feed be up to date. If this would stress the system too much, you could consider a lower rate like once each hour, and use the Add Batch Status service (max 30 readings per batch). Once a day aggregated data would really be a poor man's solution.

Url:

• http://pvoutput.org/service/r2/addstatus.jsp

Method:

• POST

Headers:

• X-Pvoutput-Apikey: YOUR-API-KEY
• X-Pvoutput-SystemId: YOUR-SYSTEM-ID

Payload:

• d=20161230
• t=22:55
• v3=10000
• v4=2000
• n=1
• d=5

Remarks:

• v3: Energy consumption in watt hours
• v4: Power consumption in watts
• An energy value cannot be lower than the previous energy value recorded in time.
• A device recording net data (as is the Slimme Meter) needs a upload generation data feed. The Net Delay setting under the Advanced Settings section should be configured to ensure that generation data is processed before net data.
• A work around would be to upload a batch of say the last X readings in order to give the solar feed time to upload its data. X = ceil(rate_consume_feed / rate_produce_feed) + 1.
• n=1 means that the Slimme Meter feed is netto. PVOutput will add the produced solar power to the consumed power to get the (bruto) power consumption (in which you're really interested).
• The delay d is a paid-only parameter (donation). The value depends on the upload speed of the solar feed. In my case rate_produce_feed is 5 minutes.
• Time/date are in local time.

You could add more readings (like dal/normaal values) in the extended field. This should be a user selectable option.

from dsmr-reader.

How is this coming along? Do you need beta testers? :)

from dsmr-reader.

Very professional, nice. Thanks for clarifying!

from dsmr-reader.

Where can we donate to keep you going, Dennis?

from dsmr-reader.

Thank you for the kind offer but I cannot take any donations. I'm still working on the next release though, but building decent support for DSMR v5+ takes a bit longer than expected at the moment.

from dsmr-reader.

Moved to v1.7 as it'll be an API themed release.

from dsmr-reader.

from dsmr-reader.

What happened to the 1.7 milestone? 🚑

from dsmr-reader.

My original planning was to push 10 to 15 tickets into a single milestone and then release it. But since it may bring many features at once, it does seems to greatly slow down the overal feature development.

So I've changed the milestones' schedule to each month and I will add each completed feature or ticket to the upcoming milestone for release. There will be more, smaller milestones, but releasing new stuff won't stall while waiting other features anymore.

Currently there are some small issues with the v1.6 release candidate (#275), which contains improvements for DSMR v5 smart meter owners, so I'm resolving those first now.

The next milestone after will be, as accounced, be focussing on data links, such as API's and exporters (for this #9 for example). I will be starting with an API first.

from dsmr-reader.

Any updates?

from dsmr-reader.

Is this issue still alive? ;)

from dsmr-reader.

After adding the API in v1.7 I had to choose for either #9 or #141. I choose the latter :]

from dsmr-reader.

What? #9 was earlier in the queue! 🥇

from dsmr-reader.

No worries, I've finished the other ticket, which will be released shortly in v1.8.

Next on the list is #9 for v1.9. I would want to do some other frontend tickets instead, but I think #9 will help more users at the moment anyway. :]

from dsmr-reader.

Note to self: Check how Daylight Savings Time is supported by PVOutput, to prevent weird time shifts twice each year.

from dsmr-reader.

Can we test a beta already? :)

from dsmr-reader.

I've made a simple POC so far, but it's far from finished. Also, during the summer holidays I don't tend to program that much anyway. :]

from dsmr-reader.

Haha yeah, last week I already started again by cleaning up the backlog a bit and finish some low langing fruit. Will continue with this shortly. If I recall correctly, I was stuck somewhere interpreting the API.

from dsmr-reader.

@dennissiemensma

Jij kunt vanuit DSMR reader nooit V1 en V2 aanleveren. Je beschijrving hierboven klopt overigens niet helemaal.

Je schreef:

v1: Teruggeleverde stroom vandaag tot nu toe (in Watt uur), naar het stroomnet toe.

Maar dit is generation niet exported
v1 | Energy Generation | No1 | number | watt hours | 10000 | r1 |  

v2: Stroom'opwekking' op dat moment (in Watt), dus weinig zeggend volgens mij.

Klopt, v2 | Power Generation | No | number | watts | 2000 | r1 |  
Dit is interessant voor de (piek)generatiewaarde.

v3: Verbruikte stroom vandaag tot nu toe (in Watt uur), dus vanaf het stroomnet.

Juist ja, netto dus in ons geval
v3 | Energy Consumption | No | number | watt hours | 10000 | r1 |  

v4: Stroomverbruik op dat moment (in Watt), dus weinig zeggend volgens mij.

Klopt, dat is opnieuw interessant om het piekverbruik te zien (met beperkte resolutie).
v4 | Power Consumption | No | number | watts | 2000 | r1

from dsmr-reader.

Bedankt voor jullie input!

Wat betreft v1 + v2: ik twijfel vooral omdat ik, en dat had ik even moeten vermelden, alles naar PVOutput stuur met net = 1. En de docs geeft aan:

Net Data
The n parameter when set to 1 will indicate that the power values passed are net export/import rather than gross generation/consumption. This option is used for devices that are unable to report gross consumption data. The provided import/export data is merged with existing generation data to derive consumption.

En dat is de reden dat ik dus twijfel of ik wel of niet v1 + v2 moet meegeven.

Maar zoals gezegd, ik ben niet bekend met PVOutput én alle termen die daar gebruikt worden. Ik kan prima initieel v1 + v2 weglaten en dat op een later moment alsnog (weer) toevoegen aan de applicatie. Dat is voor mij weinig moeite.

from dsmr-reader.

Voor nu zal ik bovenstaande doorvoeren. Ik verwijder eerst v1 + v2 uit de API call. Daarna hoef ik alleen nog maar de documentatie(read the docs) bij te werken en dan kan in principe getest worden door liefhebbers (of wachten op de gehele release later).

Nog wel een opmerking dat ik momenteel alleen het dagverbruik doorstuur aan PVOutput. Er is een optie om 'lifetime' verbruik door te geven, maar dat heeft restricties en werkt tevens niet goed zolang DSMR-reader ondersteuning heeft voor slechts 1 slimme meter (ivm vervanging/verhuizing).

Cumulative Energy
Set the cumulative flag c1 to 1 when you wish to pass lifetime energy values for v1 instead of today's energy value. The first add status for any given date will be used as the starting energy value and v1 will be reset to 0.

Edit: Ik zie ook dat dat alleen voor v1 geldt, dus dat kan (nu) sowieso niet.

from dsmr-reader.

Over v1+v2 het lijkt mij ook correct om dit weg te laten, die informatie heeft DSMR niet tenzij we die vanaf de omvormer op e.o.a. manier in DSMR kunnen gaan plaatsen.

Ik zoek voor wat betreft PVOutput ook echt de upload van de netto kWh-export (of kWh-import als er niets opgewekt wordt) en het actuele verbruik/restant generatie. Beide netto dus want de bruto generatie heeft PVO al :)

from dsmr-reader.

Overigens moet je even goed kijken naar de waarde (positief of negatief) van v4.

from dsmr-reader.

from dsmr-reader.

Het lijkt erop dat je alleen v3 hoeft te versturen, per x minuten, nadat de gebruiker zelf al v1 heeft ge-upload.

Standaard wordt de v1 data elke 5 minuten aangeleverd, dus een delay (in de upload) lijkt me wel handig. Misschien zou dit een instelbare waarde met een default van 6 (of hoger) moeten zijn.
Bovendien moeten gebruikers zorgen dat hun v1 upload goed gesynct is.

from dsmr-reader.

https://peter.pgit.nl/uitgelicht/nu-ook-verbruik-op-pvoutput/

http://tweaken.blogspot.nl/2015/01/domoticz-uploaden-naar-pvoutputorg.html

from dsmr-reader.

Dat laatste is een goede tip inderdaad, DSMR verbruiksgegevens met een standaard vertraging van minimaal 6 minuten uploaden. Het zou zonde zijn als het anders nog steeds mis gaat.

v4 is verder vrij optioneel en zou alleen piekvermogen op een lage resolutie kunnen geven, maar dat geldt ook voor actuele gebruik van de omvormer die we nu al eens per 5 minuten in PVO zien. Ik zou v4 dus wel gewoon meenemen als dat kan, het geeft alleen niet super veel informatie :)

from dsmr-reader.

Hier staat nog een voorbeeldscript:

http://www.domoticz.com/wiki/Upload_energy_data_to_PVoutput

from dsmr-reader.

Bedankt voor alle aanvullende informatie.

• Wat betreft de tabel. Ik denk dat dat wel goed gaat zolang ik alleen v4 upload en niet v2. v4 zal bij DSMR-reader nooit negatief zijn (want het meet de stroomvraag in huis (Watt)). En dan geldt volgens de tabel: Import = v4 (als ik het goed begrijp).

• Qua Youless ben ik hier niet bekend mee waar die exact op aangesloten is, maar als die inderdaad aangesloten is op de leiding met de zonnepanelen, dan klopt het dat die bruto uploadt. In het geval van DSMR-reader geldt dat volgens mij niet, dus is netto ok.

• http://tweaken.blogspot.nl/2015/01/domoticz-uploaden-naar-pvoutputorg.html kan ik niet vinden, ik krijg de foutmelding: "Blog is verwijderd"

• Het LUA script-voorbeeld lijkt te beschikken over drie bronnen (import, export, opbrengst). Wellicht dat daar een net iets andere situatie voor geldt dan hier. Tevens wordt daar gebruik gemaakt van c1 = 1 (Cumulative Energy), wat ik (nog) niet kan doen.

• Wat betreft dit verhaal, ik neem v4 wel initieel mee dan. Ik denk dat het een kwestie van proberen is of dit goed werkt. Zelf zag ik dat PVOutput de piek qua Watt bijwerkte, dus wellicht is dat zoals het hoort.

• Aanvullend: Is het overigens nodig om een vertraging (van 6 minuten) in te stellen? Het lijkt er namelijk op dat PVOutput zelf ook al tijdstippen rechttrekt. PVOutput rond dit af en dat zag ik ook terug bij mijn eigen uploads. 20:47 werd 20:45 en 20:49 werd 20:50.

The time parameter is rounded to the nearest Status Interval configured for the system.

Mocht ik iets over het hoofd zien of verkeerd heb gelezen, dan hoor ik het graag. :]

from dsmr-reader.

Aanvullend: Is het overigens nodig om een vertraging (van 6 minuten) in te stellen?

Ja volgens mij wel, omdat de timing van de upload van de omvormer niet gelijk is aan die van DSMR. Juist ook vanwege de afronding is dit een probleem. Volgens de eerder gegeven documentatie moet de upload van het verbruik ná die van opbrengst komen als deze niet gelijktijdig geüpload worden. Dus als DSMR net iets eerder is dan de upload van de opbrengst, bijvoorbeeld:

DSMR om 11:59
Omvormer om 12:01

Dan rond dat hetzelfde af naar 12:00 maar was DSMR eerder en gaat het dus mis. Tenminste ik vermoed dat dat kan gebeuren. Als DSMR altijd data van minimaal 6 minuten oud upload, kan dat niet mis gaan is de gedachte. Dat rondt dan naar minimaal één status interval (5 minuten) later af.

from dsmr-reader.

from dsmr-reader.

Ik heb nu v4 aangepast qua plus/min en de uploadvertraging optioneel gemaakt.

from dsmr-reader.

Alles zou afgerond moeten zijn. Docs zijn bijgewerkt. Wil iemand dit uitproberen?

from dsmr-reader.

from dsmr-reader.

Hah, ik had de range op 0 tot 15 minuten gezet, maar bij deze is die aangepast naar 0 - 30.

from dsmr-reader.

Voor degenen die willen testen.

Upgraden naar v1.9rc:

• Zorg dat je sowieso een recente database-backup hebt (geldt voor elke upgrade overigens).
• sudo su - dsmr
• git fetch (je ziet als het goede is allemaal branches voorbij komen, waaronder origin/development)
• git checkout -b development origin/development (of git checkout development wanneer je dat in het verleden al eerder hebt gedaan, GIT zal dan een fout geven dat de branch al bestaat)
• ./deploy.sh
• Als het goed is wordt een upgrade uitgevoerd. Dit kan even duren, gezien het een redelijk grote release is en er ook een hoop dependencies zijn bijgewerkt naar de meest recente versie.
• Versie is nu iets als v1.9rc4
• Docs: http://dsmr-reader.readthedocs.io/nl/development/faq.html#pvoutput-org-automated-electricity-consumption-export

Downgraden (alleen wanneer het écht moet):

• sudo su - dsmr
• ./manage.py migrate dsmr_consumption 0007_settings_documentation (deze is nodig omdat een aantal database velden hernoemd waren, als het goed is is de output: Unapplying dsmr_consumption.0008_energysupplier_return_prices... OK)
• git checkout master
• ./deploy.sh
• Je zit nu als het goed is weer op v1.8

from dsmr-reader.

from dsmr-reader.

Toch gelukt!

from dsmr-reader.

Het is live! https://www.pvoutput.org/intraday.jsp?id=54886&sid=49900

from dsmr-reader.

Goed om te horen!

Die databasemigratie zou overigens niet zo lang moeten duren, gezien het een tabel betreft met hooguit enkele records (je prijzen).

Wat betreft de upload, klopt het verder voor je gevoel qua gegevens? Het is voor mij lastig om te beoordelen of het goed werkt, ook qua uploadvertraging.

from dsmr-reader.

Ik ben nog een beetje aan het experimenteren met de delay, maar het lijkt te werken!

from dsmr-reader.

Oke bedankt voor het proberen en de input. In dat geval release ik het, samen met alle andere wijzigingen. Mocht er echt iets uit komen dat anders moet, kan ik dat altijd nog aanpassen in een follow-up release.

Ik zal hier straks nog even laten weten hoe je (na release) weer terug kan naar master.

from dsmr-reader.

Het is gereleased.

@mkruiver je kunt weer terug met:

• sudo su - dsmr
• git fetch
• git checkout master
• ./deploy.sh

Als het goed is zit je dan op v1.9

from dsmr-reader.

Hier upgrade naar 1.9 ook gedaan, ging heel vlot. Heb een duplicaat testsysteem aangemaakt op PVO en daar pushen zowel mijn omvormer en DSMR nu naar toe. Data komt in elk geval binnen :)

Vraag me nog wel een gekkigheidje af maar dat zou misschien kunnen komen doordat ik echt direct ben gaan uploaden na de upgrade. Ik heb de volgende gegevens in DSMR staan:

Totaal gebruik voor vandaag tot nu toe 2,37 kWh, teruglevering 2,72 kWh.

Ik ben vanaf 11:40 of zo vanaf DSMR gaan pushen naar mijn test systeem maar daar lijkt het verbruik te starten op 0 kWh en op te lopen met het verbruik vanaf dat punt. Kan dat kloppen? Ik had verwacht dat hij daar meteen rond 2 kWh zou starten (de actuele totaalwaarde van dat moment):

Zou wellicht ook aan PVO kunnen liggen hoor want je vult v3 wel met het totaal van de dag toch? Of zou het kunnen dat dankzij de upgrade/recente inschakeling van de PVO koppeling hij per abuis een ander dagtotaal berekend?

Ik vermoed dat het bij een complete dag wel goed zal zijn maar ik denk toch even checken :)

from dsmr-reader.

Thanks voor snelle reactie! Die wijziging maakt een hoop duidelijk:

2017-10-08 14:07:16.106262+02:00: Calling backend services
 - PVOutput | Uploading data @ {'t': '14:07', 'd': '20171008', 'delay': 10, 'v3': 2520, 'v4': -244, 'n': 1}
 - PVOutput | Delaying the next export until: 2017-10-08 12:12:17.264054+00:00
Command completed. Sleeping for 1 second(s)...

Zo te zien wordt de juiste waarde geüpload! Zit dus gewoon aan de kant van PVO. Uploaden van verbruiksgegevens daar is ook nieuw voor mij, zal wellicht wat instellingen verkeerd hebben staan.

Bedankt!

from dsmr-reader.

Hah, ik keek gewoon helemaal verkeerd.. De standaardgrafiek laat zien wanneer je inderdaad energie geïmporteerd hebt en dat is een cumulatief voor de import die oploopt, niet het netto totaal van de dag. Daar is een aparte grafiek voor en die klopt helemaal:

Nogmaals super bedankt Dennis; het werkt allemaal prachtig en ik heb zo veel beter inzicht in m'n verbruik en opbrengst 👍 Ik laat het nog een een ruime dag draaien op m'n test systeem bij PVO en dan gooi ik de boel naar m'n officiële systeem.

from dsmr-reader.

Top, bedankt voor het uitproberen en bevestigen. 👍

from dsmr-reader.

from dsmr-reader.

@mkruiver inderdaad, dat zag ik pas nadat ik de 'Net generation' grafiek opende. Toen viel het spreekwoordelijke kwartje want daar is de naamgeving wel energy imported :)

from dsmr-reader.

Ook geupgrade naar 1.9, en lijkt mooi te werken.

Is het een idee om op /status ook te vermelden of deze export werkt? en wanneer de volgende POST is.

from dsmr-reader.

Bedankt voor de feedback en suggestie. Ik zal het toevoegen aan het redesign ticket voor de Status-pagina.

from dsmr-reader.