GXDLMSDirector.Media

Getting started

Using Gurux GXDLMSDirector with own transport channel (media).

Sometimes it might be possible that you want to communicate with your meter using not yet implemented communication media (example Zigbee, Lora, Z-Wave, SigFox, etc.). In that case you can create own media component to enable communication with your meter. In this example I'll explain how to create own media component and start using it with GXDLMSDirector.
I have used Visual Studio 2015 to implement this example. You can download example source codes. Unzip file to GXDLMSDirector\Development folder.

Make project

First you need to download GXDLMSDirector source codes. Then open it with Visual Studio.
First you need to create new project for your media component. In this example I'll using name "Gurux.GXOwnMedia" for the project and "GXOwnMedia" for the class.

New project

After you have create the project you need to add reference for IGXCommon. I'm using Nuget to get it.
Select GXOwnMedia project from Solution Explorer and select "Manage Nuget Packages.."

Nuget

Now browse gurux.common and install that to Gurux.GXOwnMedia project pressing "Install button" and accept license.

GXCommon

Now you must derive GXOwnMedia class from IGXMedia and implement all methods. Visual studio can implement all methods automatically if you set cursor to GXOwnMedia row and press yellow light bulb on the left corner and press implement interface.

Implement interface

Now you need to add reference for the Windows forms. You can do this selecting GXOwnMedia project from Solution Explorer and select "Add | Reference..".

addreference

Now select "Framework" and find System.Windows.Forms, check it and press OK.

selectreference

You can now compile project. There should be no errors. Now you need to add functionality for make this work. You need to add atleast following:

MediaType

Media type is used to tell what media type is used. This is shown at device properties page of GXDLMSDirector.

Name

Name is used to identify media. This can be used if several media component uses same physical media connection. Example same media connection.

Settings

Media settings are serialized to xml, or other format if you want to. On our example we have only one property so we return it as a string.

PropertiesForm

This shows media settings dialog. This is implemented on next section.

Open

Open media.

Close

Close media.

Send

Send data (bytes) to the meter.

Receive

Receive data from own media. Usually you need to create thread that reads data from the media and that thread updates data here.

IPAddress

This is our custom property for GXOwnMedia. You can add as many properties as you need.

Add properties dialog

GXDLMSDirector uses properties dialog to show media settings for the user. Add new Form and name it GXOwnMediaProperties. Then derive class from IGXPropertyPage.

properties

Implement IGXPropertyPage methods as describe above. There are three methods.

Dirty

GXDLMSDirector uses this to check has user change media settings. You can set this to true always so settings are saved.

Initialize

Initialize is called when property page is created. Update all media settings to the UI here.

Apply

Apply is called when user has accept settings on GXDLMSDirector.

Don't update settings directly to the media component when user changes them. If you do so, new settings are kept if user cancels settings.

Now add properties for the settings form.

postbuild

Add own media to GXDLMSDirector

You must copy own media component to Medias directory under GXDLMSDirector. You can do this automatically selecting Properties under "Gurux.GXOwnMedia". Then select "Build Events" and add rows below under "Post-build event command line:"

if not exist $(SolutionDir)$(OutDir)Medias mkdir $(SolutionDir)$(OutDir)Medias
copy $(TargetFileName) $(SolutionDir)$(OutDir)Medias

postbuild

It's good to compile GXOwnMedia before starting GXDLMSDirector so you have always latest version in use. You can do this selecting "Project Build Order" under Project.

buildorder

Select Debendencies and select Gurux.GXOwnMedia.

projectdebencies

Start GXDLMSDirector and create new device. Select Media type what you have created and implement needed functionality.

settings

Thats it. You can set breakpoints where you want. Now you need to implement functionality for your own media.
You can try to read meter. Set wait time to 1 so you don't need to wait so long. It sends data, but because no data is returned exception is thrown.
Note! Settings "Trace" under View menu you can see send and received messages on GXDLMSDirector UI.
Please, let us know if there you need help or there is something what must clarify.

Undefined

Comments

Hi Team,
Thanks for building such a perfect solution for this international standard DLMS adapter. We have found this code is very much suitable for doing POC on DLMS meters.
While doing one such POC, we have planned to put one IoT device with LoRa module in the DLMS meter side and set-up a LoRa GW to get the meter data from the server. We are trying to implement the GXMedia interface as mentioned in this forum. But we found that the main source code is based on VS2017 but the GXMedia implementation has followed VS2015. So I need your help on the two following things:
a) Kindly give us some reference so that we can implement the GXMedia also in VS2017.
b) As I mentioned earlier, we are going to use an Arduino/STM processor to run the client end of the GXMedia. Is it a valid or good approach to implement DLMS access from a remote server? What is the normal approach of accessing DLMS meter data remotely? Do you have any sample Arduino code?

Thanks and regards,

SANTANU

kurumi's picture

Hi SANTANU,

Steps should be same even you are using VS 2017.
Are you using this example?
http://www.gurux.fi/GXDLMSDirector.Media

What kind of problems you have?

We have tried to implement DLMS to Arduino. Memory limitations are causing problems. 28 KB of flash is not enough to implement the meter side, even with ANSI C.

BR,

Mikko

________________________________________
Mikko Kurunsaari
Gurux Ltd
Hermiankatu 6-8 H 33720 TAMPERE, FINLAND
Phone: +358 3 265 1244
Home page: http://www.gurux.org

Hi Kurunsaari,

Thanks for your immediate reply :)

Yes, I am following (http://www.gurux.fi/GXDLMSDirector.Media). Actually, when I am trying to add a reference, I don't find System.Windows.Forms in the list. I am using Visual Studio 2017 with Windows 10. Possibly this is related to Windows 10.

Regarding the implementation strategy, we have found two possible options:

1) Implement complete DLMS modeling and data extraction on Arduino/any other microcontroller based application. Then meter data will be send via LoRa from Arduino.

2) Implement GXMedia client in Arduino or any other microcontroller but the actual DLMS data modeling and extraction will happen in the server side where the custom GXMedia will be implemented to connect Arduino remotely.

So which approach is better and if you know any better approach please suggest.

Thanks and regards,

SANTANU

kurumi's picture

Hi SANTANU,

OK. Your project for is for .Net Core. Is this correct?

DLMS is a complicated protocol.
It's easier/faster/smaller to implement if Arduino only sends data to Lora.
The bad side is that all business logic is on the client side.
If data is lost, the client must re-sent the data to the Arduino.

BR,

Mikko

________________________________________
Mikko Kurunsaari
Gurux Ltd
Hermiankatu 6-8 H 33720 TAMPERE, FINLAND
Phone: +358 3 265 1244
Home page: http://www.gurux.org

Hi Mikko,

Thanks for your immediate reply :)

Thanks again that you will modify the project :)

As I can understand, you are recommending to follow option #2 that is use Arduino to only send/receive data to/from the server but the actual DLMS modeling and extraction will be done in the Server side.
But I don't understand "The bad side is that all business logic is on the client side.".. as I told you the data extraction will be done at the server end, so why you are saying that the business logic will be in the client side or maybe I am missing something. Please comment.

Thanks and regards,

SANTANU

kurumi's picture

Hi SANTANU,

Sorry, I believe that we are talking about the same thing with different terms.
I'll change this:
"The bad side is that all business logic is on the server side."

I think the client as an app that is reading the meter and you are thinking it as a server.

BR,

Mikko

________________________________________
Mikko Kurunsaari
Gurux Ltd
Hermiankatu 6-8 H 33720 TAMPERE, FINLAND
Phone: +358 3 265 1244
Home page: http://www.gurux.org

Hi Mikko,

Thanks for your clarifications and understanding !!
I will let you know our progress. Will contact you if we will face any issue.

Thanks and regards,

SANTANU