Read DSMR P1 i.o. having a CT for mains connection current

Hello ,

In The Netherlands and Belgium we have introduced the “smart meter”. I have one at home. Its specification is called “DSMR”. You can read import and export energy directly from the P1 port. If you can, no need for a CT. It would be cool if emonPI could use that port.

You can find information on it on this website: Data lezen van de P1 poort op de Belgische digitale elektriciteitsmeter | Jensd's I/O buffer

It is all Dutch, but there is a nice video in denglish with a Python script.

1 Like

FWIW, if I google for DSMR smart meter, I find multiple English language reports of existing integrations with e.g. Home Assistant, openHAB and Domoticz and Tasmota.

So it seems there should be plenty of information on what is required to do an integration to the P1 serial port. You can also find P1 serial to USB adapter cables on Amazon.

edit: Oh and there’s an English language version of the article the OP mentioned at Read data from the Belgian digital meter through the P1 port | Jensd's I/O buffer

Thank you Dave, I agree, I just had hoped it could be “packaged” the same way emonPI is packaged for PV Solar Divert on OpenEVSE.

Yes, I was just hoping that pointing out extra documentation in English might help persuade somebody to take a stab at packaging it, or help you to do it yourself.

I’ve done it and it works. Almost.

I started off with the European version of OpenEVSE. From the stellar Openenergymonitor bunch.

A Dutch company called Smart Gateways sells a little gizmo for 37€ including delivery at home. It connects to the P1 port, is powered by it, reads out the smart meter data and makes it available over WiFi to an MQTT broker.

I have a NAS, a Synology DS220+. That is powerful enough to be an MQTT broker, so I even did not need to buy a Raspberry Pi ! It runs Mosquitto in Docker. The Dutch Gizmo can be made to publish the DSMR stuff it reads from the P1 port to that broker. Using WiFi.

The DSMR data is not readily useful for the OpenEVSE Solar PV Divert implementation. A bit of Python fixes this. Developed in PyCharm on my laptop, I can (have not yet) containerize it and run on the NAS in a Docker container. It calculates and publishes the Power1 topic to which the OpenEVSE subscribes and voila ! It works !!

OpenEVSE power calculation.pdf (58.5 KB)

But… not entirely. I still face a problem. The OpenEVSE will stop charging if there is not enough surplus PV power - that is good! - and the car, a Peugeot e-208, goes to sleep after one minute no energy. When after such a charge interruption the OpenEVSE presents a charge, the car stays asleep and nothing happens. Using the keyfob to open / close the doors, it wakes up the car and it accepts the charge.

I’m currently learning about the Peugeot remote control services. My aim is to have another Python program waking up the car over the cellular network when it is asleep and OpenEVSE wants to charge. That is why I did not containerize in Docker yet. I still have to fix this.

It seems there is no need to “wake up” the Peugeot e-208 to resume charging after the charger stopped charging due to surplus current unavailable (no export).

Now, if the OpenEVSE is on Solar PV divert (eco mode) using the +I/-E in the Solar PV Divert panel of the Services tab, and the available current drops to zero, the charge will stop after “some time”. If that lasts for more than one minute, the Peugeot e-208 goes into sleep mode. When current is available again, the charger wants to resume charging but the car does not respond, hence no charging happens.

If I cycle the door locks with the keyfob, the charging does resume. So I thought the only fix was to automatically “wake up” the car over the cellular network.

But there is another possibility I found. If you restart the OpenEVSE, it also resumes charging. Restarting using the button on the GUI OpenEVSE tab’s Hardware panel. Without touching the car. So it seems to me that shows it is as much an OpenEVSE issue as it is a car issue, in other words: a compatibility issue.