Landir+Gyr E350 P1 Port

Aug 4, 2014 at 12:36 PM

At the moment i am installing solar panels and last week i got a new smartmeter installed, the Landir+Gyr E350, and of course i want to read it all out with an Arduino over the P1 port. I connected the smartmeter as described in the hardware manual, but was unsuccessful to receive data with the Arduino.

After searching on Google for this specific meter type i eventually found a discussion stating that the E350 doesn't use 9600 7E1, but 115200 8N1.

Also i found an other website stating the amount of lines of data returned by the meter is less then that of other meters, only 15 lines of data in stead of the 20 from other types.

Is the solar meter softaware compatible with this new kind of meter (DSMR4.0) and if so, how do i configure it?
Aug 7, 2014 at 9:47 PM
Edited Aug 7, 2014 at 9:48 PM

The serial settings for the P1 meter can simply be changed.
Find the following code in P1Power.cpp:
void P1Power::Begin(byte i)
and change the 9600 to 115200.
The 7E1 and N81 are compatible since bit 8 is not used.

The content of the data is unknown. I cannot find information on this protocol. If it is known we can create a second version of the p1Power.cpp file that you can use.
Aug 8, 2014 at 7:23 AM
Thanks for your answer!

I will try these settings and will see if it works. From what i have gathered so far i think the part of the message with the information the program needs is still the same so chances are it will work with only the change in boudrate.
Aug 8, 2014 at 3:35 PM
It is working!!

For the software, the only thing that had to be changed is like you said the baudrate from 9600 to 115200. The hardware side is a different story. Because this meter has an open collector output, it does not output 5V for a logic zero (inverted) and 0V for a logic one out of its own like the old meters did. It needs an pull-up resistor (between the data pin and 5V) which the open collector pulls to ground to get your logic 1's and 0's. The signal still has to be inverted on a logic level for which you could use a transistor with an other pull up resistor (because of the open collector you don't really need an optocoupler), but since i already had an optoucoupler i used that with a 10K resistor for pull-up.
Aug 22, 2014 at 7:56 PM
A little update a few weeks later :-)

So besides the different baudrate, i found out the data send is also different. I captured the data with a laptop:

More information is found in the DSMR4 specs:

There are two differences, a small difference is the actual power (1-0:1.7.0) having three decimals in stead of two. The bigger difference is the gas usages. In the old standard this was divided over two lines where the newer fits it into one line. Also the code preceding the line is different (0-1:24.2.1).

There is also a problem with the 115200 baud rate not being a good match with the 16MHZ oscillator speed of the Arduino Uno or Mega causing a three percent error in received serial data. See this article for a boring explanation, but luckily we only need a good read once per five minutes so we can afford to miss some data now and then. Because of the 8N1 mechanism the damage is also contained to single characters which will be missing from the data from the buffer. But at the wrong moment this can cause enough demage, for example a missing decimal point. To filter out the corrupted data some extra data validation is needed which i am doing by counting the amount of numerical characters which are the same length every time and including for example the "*kWh)" strings in the sscanf functions.

If you want i can upload the code i have altered after i have tested it for a while longer.

Greetings, Erik
Feb 27, 2015 at 10:22 AM
Hi Erik,

I would be interested in the altered code.

I received my smart meter today, a Landir+Gyr E350. I have all components like stated in the hardware manual of this site, ready to create my own P1 logging machine.

So according to your experience, hardware site is ok, using a Hex inverter 74LS04 should do it. Software side needs some changes on the parsing side.

Is it possible to get the altered code?

kind regards

Feb 28, 2015 at 9:28 PM
Hi Ido,

Since my last post i made some more changes to not only the software, but also the hardware. The issue being that the Arduino with its default oscillator isn't able to exactly reed a baud rate of 115200. This results in missing characters in the P1 message from the L+G E350 and messing up the readout and giving you false values. Eventually i ordered an external serial port module with its own oscillator ( which buffers the received data and which communicates with the Arduino over the SPI bus (the same bus the Arduino talks with the ethernet board).

Besides adding the external serial port, i also changed how the P1 port is connected. You still need the Hex inverter (i actually used a NAND which i had laying around, but same difference), but now you connect the data line to the external serial port board. Also i found out that the line to the P1 meter which in the original schematic is hooked up to the 5V of the Arduino, can be used to immediately trigger the meter to send its data in stead of waiting 10 seconds. I'm using this method to prevent the data buffer of the external serial port to overrun so you don't loose any data. In the Arduino i'm using the 5ms interrupt to time the 10 seconds interval. When 10 seconds have passed, in the regular program loop (so it doesn't interrupt any other large tasks) i activate the sending of the data by setting an output high (the 5V to the P1 meter) en continuously reed the data over the SPI bus from the external serial port until al data is received, or in case of an failure a timeout has occurred.

I ended up using a prototype shield for the Arduino (an empty shield on which you can add your own components) on which i soldered the external serial port and which also houses the hex inverter. One issue however is connecting the SPI bus from the Arduino, thru the ethernet shield to this prototype board. If you have a look at your Arduino with the ethernetshield, you notice besides the four strips of single row connectors on the sides, there is a 2 by 3 connector in between. This connector houses the SPI bus, but most ethernetshields (at least the original form Arduino itself) don't feed this bus thru to the next shield so i had to modify my ethernetshield by removing this connector and replace it with one with longer wires sticking out on the upper side. Also i read online there is an issue with the original ethernetshield (i actually don't use the original so i didn't encountered this problem) which might cause a problem. Without going in to much detail, the way Arduino wired the ethernetchip makes it you're unable to extend the SPI bus because the chip doesn't free up the bus by keeping the input impedance of the chip on the wrong level.

One other problem i recently encountered was in the way the gas usage is added to the P1 message. In one of my earlier post you'll find out that the gas usage is noted as: 0-1:24.2.1(140816120000S)(00009.333*m3). Somewhere in October i found that the gas usage had stopped working. Logging the outputdata of the P1-meter to my laptop i eventually found that the letter 'S' had changed to 'W', standing for i presume Summer and Winter. This has probably something to do with some form of temperature correcting for the gas usage (the density of the gas changes with temperature).

A lot of new information , but if you're still interested i am of course willing to give you my altered software and draw up some form of a schematic, but the way i did it is a bit more advanced an electronics project then the original Solarmeter project. Especially the ethernetshield problem might cause problems i didn't encounter. But just leave a message if still interested! I just need some time to draw up a schematic.

Greetings, Erik
Mar 1, 2015 at 8:21 PM
Hoi Erik,

Even verder in het Nederlands. Bedankt voor je uitvoerig antwoord. Leuk om te lezen dat er een oplossing is, echter iets te te hoog gegrepen voor mij, ik ben helemaal niet thuis in electronica, basis solderen is het hoogst haalbare :)

Ik heb vandaag alles in elkaar gesoldeerd in de Arduino en aangesloten op de slimme meter, en hoera ik krijg output.

Het werkt \wel, maar het grootste probleem is dus dat de data dus niet altijd betrouwbaar is, wat niet echt handig is voor de betrouwbaarheid.
Het lijkt me ook wel lastig om de data te valideren, of niet? Het communicatie protocol geeft volgens mij niet aan of het ontvangen telegram niet correct is aangekomen, alhoewel er wel een checksum aan het einde van het berecht staat kennelijk, dus daarmee zou het wel moeten lukken. Kwam deze library hiervoor tegen

Het is dan inderdaad niet erg als je af en toe een bericht mist. Het idee is dan om alleen bij een goed bericht de data door te sturen naar een php/mysql oplossing.

Andere oplossing is om voor een Raspberry pi te kiezen, maar daar zie ik ook problemen mee met een DSMR 4.0 meter, moet ik me nog verder in verdiepen en het zou zonde zijn van mijn investering.

btw timestamp + S/W staat in de DSMR 4.0 specs
ASCII presentation of Time stamp with Year, Month, Day, Hour, Minute, Second, and an indication whether DST is active (X=S) or DST (Daylight saving time) is not active (X=W).


Mar 1, 2015 at 9:57 PM
Hoi Ido,

Nederlands is ook prima hoor :-)

De checksum van het hele bericht gebruiken is niet handig nee. Gezien de theoretische 3% kans op fouten (door de oscillator mismatch) welke ik door het loggen van de data zelf ook wel z'n beetje kan onderschrijven, zullen de meeste berichten niet door de check gaan komen. De dsmr library die je aanhaalt doet zo te zien wat ik destijds ook van plan was (voordat ik de externe uart ging gebruiken), namelijk controleren of de karakters zijn wat je er van verwacht (bijvoorbeeld een getal en niet een ander karakter). Ook hebben de regels een vaste lengte waarmee je veel van de fouten kan detecteren.

Wat ik doorgaans zag gebeuren, was dat de seriële poort zelf al de foute bytes weg gegooid had (soms ook meerdere op een rij) waardoor bijvoorbeeld het /r karakter wegviel en twee regels achter elkaar kwamen te staan en de lengte al niet meer klopte. Daarnaast zag je zo nu en dan dat een karakter een andere waarde kreeg. Probleem blijft alleen dat één fout bitje in een byte welke net niet door de seriële poort weggefilterd werd zo nu en dan een andere getalswaarde oplevert die je ook niet weg kan filteren door te controleren op wat voor karakter het is. Wel zou je nog iets kunnen doen door te gaan vergelijken met de vorige meterstandwaarden. Als bijvoorbeeld je gas verbruik tussen twee opvolgende berichten in eens 1000m3 hoger is, klopt er natuurlijk iets niet. Ook een nieuwe waarde die lager ligt dan de voorgaande kan niet kloppen (voor gas en kW/h tenminste, de actuele verbruiken in kW wel natuurlijk).

Ik was destijds zover dat ik op lengte en karaktersoort controleerde, maar had soms dat ik meerdere minuten lang geen gasmeting had (is ook de langste regel die je wilt uitlezen, dus ook de meeste kans dat er wat fout in gaat) doordat ik de meeste berichten afkeurde. Dus te streng kan je het ook niet maken omdat er dan haast niets meer door je check heen komt. De externe UART blijft denk ik de enigste oplossing waarmee je gewoon betrouwbaar elk bericht kan uitlezen. Door zelf de 5V lijn hoog te maken wanneer je data wilt hebben voorkom je ook meteen buffer overflows (gaat met 119200 baud immers een stuk sneller dan met 9600 baud bij de oudere meters) doordat je je de software laat wachten totdat alles binnen is. Ik draai hier nu sinds de zomer probleemloos mee (nou ja, op die S en W na dan....).

Dat de S of W in de gas usage de zomer- of wintertijd aangeeft kan wel kloppen ja, volgens PV-output was mijn gasmeting ook precies op die datum gestopt toen :-) Is ook niet het eerste waar je aan denkt gezien DST in de industrie doorgaans weggelaten wordt in protocollen bedoeld voor automatische verwerking. In de specificatie die ik er toen bij gezocht had werd deze hele letter trouwens niet eens genoemd.

Kan je bij een Rasberry pi overigens een serial naar usb kabel gebruiken? Die hebben hun eigen oscillator special voor de standaard baudrates zodat je geen mismatch problemen hebt. Met een Rasberry pi kan je er overigens ook voor kiezen om de 5V lijn zelf steeds hoog en laag te maken en zo vaker dan eens per 10 seconden data te krijgen, bijvoorbeeld elke 2 seconden. Voor een Arduino zal dat te veel data worden ben ik bang, zeker gezien er ook nog het nodige moet gebeuren voor het uploaden naar pv-output enzo en het draaien van een webservertje. Maar een Rasberry Pi zou hier meer dan snel genoeg voor moeten zijn. Wel is het zo dat de P1 meter de data volgens mij niet vaker dan eens per 10 seconden ververst, maar je kan dan de zelfde data meerdere keren uitlezen en wellicht zelfs met elkaar gaan vergelijken om fouten op te sporen.

Ben je overigens van plan zelf wat te programmeren (je noemt php/mysql) in plaats van Solarmeter met PV-output te gebruiken?
Mar 2, 2015 at 12:10 PM
Edited Mar 2, 2015 at 12:12 PM
Het is natuurlijk 3% kans op fouten per byte? Dus dan is de kans dat er ergens in het bericht een fout zit, vrij groot.

Het is zeker niet mogelijk om de freq van de Arduino aan te passen, ik zie dat er wel frequenties zijn zonder fouten bij 115200 baud.

Het zelf valideren van de data zal wel redelijk werken, zeker als je de eerdere weggeschreven data bekijkt, maar is ook niet 100% sluitend. Als ik eerst een hogere waarde weg schrijf en later een lagere wat niet zou moeten kunnen, welke is dan fout...

De gasmeter update volgens mij maar 1x uur.
Kan je bij een Rasberry pi overigens een serial naar usb kabel gebruiken?
Yep, althans, ik lees ook wel over problemen, maar deze persoon verkoopt volgens mij wel een kabel die werkt

Dat over zelf de lijn hoog laag maken snap ik niet helemaal. De slimme meter pushed toch alleen maar, of kan je ook op eigen initiatief informatie eruit krijgen?
Ben je overigens van plan zelf wat te programmeren (je noemt php/mysql) in plaats van Solarmeter met PV-output te gebruiken?
Is wel de bedoeling, ben voor lange tijd java programmeur geweest, alleen wil ik het oplossen m.b.v. php of python. Complex hoeft het niet te zijn, data binnen krijgen en opslaan in een mysql db. Daarna kijken of ik de data dan ook grafisch kan maken.
Mijn eerste plan was om alles ook naar pvoutput te sturen, maar eigenlijk is dat gek, je privé data zo publiek te maken, zeker met het hoge detail niveau van 10sec. Dus ik kies er nu voor om het intern te houden.

Ik wil wel eens gaan spelen met de dsmr library en kijken of ik dezelfde hoeveelheid fouten krijg met mijn arduino mega.
Mar 2, 2015 at 1:51 PM
Hoi Ido,

Hoe het precies zit met die 3% is mij niet helemaal duidelijk, zou zelfs per bit kunnen zijn. Maar afgezien van de theoretische fout, ben ik door zelf alle telegrammen te loggen er wel achter dat nagenoeg elk telegram wel één of meerdere fouten zal bevatten.

Het is theoretisch mogelijk om de (ik meen 8 Mhz) oscillator van de Arduino te vervangen door één die wel matcht met 119K2, maar hier ga je op een ander vlak dan weer problemen mee krijgen. In bijvoorbeeld de Solarmeter software wordt er steeds een interrupt van 5ms bepaald waarop tijdsgerelateerde zaken worden uitgevoerd. Met een andere oscillator kan het dus weer zo zijn dat je matcht met je baudrate, maar weer niet exact met je 5ms en zo een klok krijgt die steeds wat afwijkt.

Voor wat die usb-kabel betreft, ik heb zelf een kabel met prolific chipset (in goedkope Sweex kabeltjes vaak al te vinden) met daarvoor het zelfde schemaatje als met de Solarmeter met de hexinverter en kan daar met een laptop met windows foutloos de data uitlezen. Daar zal je met een eigen stuk software op een Rasberry Pi dan net zo min problemen mee moeten hebben. Dat kabeltje op tweakers zal min of meer het zelfde zijn en in het besturingssysteem terugkomen als een com-port. Een beetje goede kabel kan omgaan met de 5V tty die van de hex-inverter afkomt.

Voor het zelf hoog maken van de 5V lijn naar de P1 toe; als deze van 0V naar 5V gaat, zal de P1 meter meteen zijn data versturen (wat met 119200 binnen een seconde wel klaar is). Blijft deze hoog, zal de meter elke 10 seconden automatisch een nieuw bericht sturen. Zou je bijvoorbeeld deze lijn steeds 2 seconden op 5V zetten en daarna 1 seconde op 0V, zal je elke 3 seconden een telegram ontvangen ipv elke 10 seconden. Waar ik dit truukje voor gebruik is niet om vaker data te krijgen, maar om het moment waarop ik data ga krijgen vanuit de Arduino software te bepalen in plaats van continue te blijven wachten tot de meter weer eens wat stuurt. Dit doe ik om te voorkomen dat de 64 byte data buffer in de externe UART (64 byte is dus te weinig voor een compleet telegram) vol raakt omdat de Arduino eventjes bezig is met wat anders. Dus om op jouw vraag terug te komen, je kan hiermee inderdaad op eigen initiatief de meter data laten versturen.

Voor wat PV-output betreft, deze krijgt van de Arduino niet de data met een interval van 10 seconden, maar met een interval van 5 minuten. Voor het loggen van je opbrengsten en verbruik over een hele dag is dit meer dan ruim genoeg. Daarnaast kan je in pv-output door jaarlijks een kleine donatie te doen je eigen verbruik verbergen, kunnen andere mensen alleen je opbrengsten zien.
Mar 4, 2015 at 6:59 PM
Hoi Erik,

Weer paar dagen verder en heb kunnen spelen met de Arduino en de slimme meter. Ben bezig geweest met de DSMR library en moet zeggen dat het lekker werkt. De library controleert ook de checksum van het gehele bericht en parsed alleen juiste berichten. Als ik de Arduino aansluit stromen de berichten elke 10sec binnen. Ik lijkt dus nog niet veel last te hebben van de 3% fout gelukkig.

Volgende stap om de data op mijn NAS/mysql te krijgen en te visualiseren. Daarna ook nog iets maken voor de kWh meter voor de zonnepanelen via de s0 aansluiting en op sturen naar pvoutput. Daar kan solarmeter me wel bij helpen.
Jammer dat de DSMR lib niet door solarmeter gebruikt wordt, zou een perfecte combinatie zijn.
Mar 5, 2015 at 8:21 AM
Hoi Ido,

Mooi om te horen dat de DSMR library goed werkt, zou inderdaad wel mooi zijn als deze standaard in de Solarmeter zou komen omdat er op dit moment verder geen kant en klare methode is voor DSMR4 meters en mijn methode qua hardware weer een stuk omslachtiger is (ethernetschield verbouwen, extra UART printje).

Voor wat je volgende stap betreft, ik denk dat het het handigst is dat je de methode van Solarmeter wat aan probeert te houden zodat je eventueel later ook makkelijker naar PVoutput kan door koppelen. Hiermee bedoel ik dat je dus elke vijf minuten nieuwe meetsamples bepaald en deze in je database opslaat. Een aantal berekeningen doet PVoutput zelf (zoals je netto opbrengst te bepalen uit je gegenereerde energie met je panelen en je opgenomen energie uit het net), maar in de Solarmetersources kan je dat wel terugvinden wat er verwacht wordt aan input. Veel vaker dan eens per vijf minuten loggen heeft naar mijn mening niet zoveel zin. Voor je opbrengst en verbruik over een dag heb je zo al een grafiek met 288 meetpunten en doorgaans ben je meer geïnteresseerd in de totaalwaarden per dag. Bijkomend voordeel van die vijf minuten interval is dan ook dat je je kan veroorloven enkele telegrammen te missen.

Succes met je project, komt zo te lezen helemaal goed!!