Skip to main content
Home
for DLMS smart meters
Open source solutions for DLMS smart metering

Main navigation

  • Home
  • Products
  • About us
  • Open Source
  • Community
  • Forum
  • Downloads
User account menu
  • Log in

Breadcrumb

  1. Home
  2. New Release Issues: Profile Generic

New release issues: Profile generic

Forum Rules

Before commenting read Forum rules

Don't comment the topic if you have a new question.

You can create a new topic selecting correct category from Gurux Forum and then create a new topic selecting "New Topic" from the top left.

By lara.wakim , 9 October, 2020
Forums
General discussion

Hi Mikko,

We are facing an issue concerning the profile generic.

In fact, when we start the meter for the first time and create the file corresponding for each profile generic, a random value is saved even before capturing the first element. (check the picture)

We think that error is leading to a second issue: when reading all the data of a profile generic the row are incremented of 1 due to the first random row so we are missing to see the last row.

Example of the picture:
In real we have 4 entries in use:
10/9/2020 2:49:48 pm -> power up
10/9/2020 2:50:45 pm -> output relay state
10/9/2020 2:51:13 pm -> output relay state
10/9/2020 3:01:07 pm -> power up

but when reading (you can check the picture) this is what is shown:
8/29/1972 1:.6:56 am -> 0
10/9/2020 2:49:48 pm -> power up
10/9/2020 2:50:45 pm -> output relay state
10/9/2020 2:51:13 pm -> output relay state

In fact to be able to see this event "10/9/2020 3:01:07 pm -> power up" we have to wait that another event happens. So instead of seeing the information about the new event we will see this one "10/9/2020 3:01:07 pm -> power up". We are delayed of one row all the time.

This issue is also happening with the load profile.

Best Regards,

Lara Wakim

Image

lara.wakim

5 years 8 months ago

Hi,

Hi,

We want to add another issue concerning the profile generic. When we start the meter the first time and for example captured 2 rows in the load profile. When we stop the debugging and restart the meter the load of the load profile data are correct. After this we captured again 2 new row to the load profile. We stop the debugging and restart the meter. When reading the load profile, we expect to see 4 rows loaded from the last time but surprisingly there is only 2 (the first 2 data only).

We tried to repeat this scenario and we noticed the number of entries in use that is reached the first time we run the meter is the same one that is load each time we re run the meter.

We think maybe that the problem is that when capturing new data through the capture action, the code doesn't pass in saveSettings to save the new value and entries.

Best Regards,

Lara Wakim

Profile picture for user Kurumi

Kurumi

5 years 8 months ago

Hi,

Hi,

There is an issue with the server example. This is fixed and tests are in progress. We'll release a new version today.

BR,
Mikko

Profile picture for user Kurumi

Kurumi

5 years 8 months ago

Hi,

Hi,

This is fixed. Get the latest version.

BR,
Mikko

lara.wakim

5 years 8 months ago

Hi,

Hi,

Perfect, we will check it when it released.

But we want to insist that our test till now are totally and only focused on the gurux server example 2.

Best Regards,

Lara Wakim

Profile picture for user Kurumi

Kurumi

5 years 8 months ago

Hi,

Hi,

New versions are released. There were small differences between the examples and that causes the issue. Now example codebases are the same.

BR,
Mikko

lara.wakim

5 years 8 months ago

Hi,

Hi,

Can you please explain to us what do you mean by that : "Profile generic entries in use and Profile entries are not serialized." ? and what the number 0x60 means in : "IGNORE_ATTRIBUTE(BASE(loadProfile), 0x60)"?

We noticed that you create a function named getProfileGenericBufferEntriesInUse(gxProfileGeneric* pg) but you didn't use it, is it intended or not?

The issue is not solved, all the reading data are now wrong and illogic. (check the picture)

Best Regards,

Lara Wakim

Image

lara.wakim

5 years 8 months ago

Picture of the load profile

Picture of the load profile showing the error described above.

Image
Profile picture for user Kurumi

Kurumi

5 years 8 months ago

Hi,

Hi,

IGNORE_ATTRIBUTE was not planned to add to this release and it's still on testing. Using IGNORE_ATTRIBUTE you can skip values that you don't want to save to the EEPROM. Example register value.

getProfileGenericBufferEntriesInUse is used in in next release. It's not used at the moment.

Can you try to remove the rows file and check is this still happening?

BR,

Mikko

lara.wakim

5 years 8 months ago

Hi,

Hi,

What do you mean by remove the rows file?

If you meant to reset the profile generic then capture new values, we try it and the error is still happening. All the values and date/time are wrong and illogic.

Best Regards,

Lara Wakim

Profile picture for user Kurumi

Kurumi

5 years 7 months ago

Hi Lara,

Hi Lara,

By removing the rows file I mean to reset the capture file. For some reason, ServerExample2 was not updated to GitHub from our internal repo. It's not updated and the profile generic is working. I'm sorry about this hassle.

BR,
Mikko

lara.wakim

5 years 7 months ago

Hi Mikko,

Hi Mikko,

It is not a problem.

We downloaded and tested the latest release and the profile generic is working just fine and like expected.

Best Regards,

Lara Wakim

lara.wakim

5 years 6 months ago

In reply to Hi, by Kurumi

Hi Mikko,

Hi Mikko,

1- Like you said above getProfileGenericBufferEntriesInUse() function is not used. We want to know what is the use of this function in the future?

2 - Like you said above the IGNORE_ATTRIBUTE is not used yet in the example code. But we think it is an important feature to avoid the saving of all the objects even the useless ones that don't need to be save. If you can please implement this feature for the next release.

3 - Plus, we are thinking concerning the saving of all the objects each time. Will it be better to save only the object that has been changed or modified not all the objects? It will be faster and more efficient for the EEPROM. Can you also implement this logic?

Best Regards,

Lara Wakim

Profile picture for user Kurumi

Kurumi

5 years 6 months ago

In reply to Hi Mikko, by lara.wakim

Hi,

Hi,

#1. It's coming in the next version.
#2. This is in the testing phase. It'll help to save a lot of memory.
#3. I need to think about this.

BR,
Mikko

lara.wakim

5 years 6 months ago

In reply to Hi, by Kurumi

Hi Mikko,

Hi Mikko,

Thank you for your hard work.

Concerning the 2# point, yes it will save a lot of memory this is why it is important to implement.

Concerning the 3# point, this is not a priority at all right now, the way it is implemented now is working fine.

Best Regards,

Lara Wakim

  • Create new account
  • Reset your password

Hire Us!

Latest Releases

  • Tue, 06/09/2026 - 11:16
    gurux.dlms.java 4.0.95
  • Tue, 06/09/2026 - 10:03
    Gurux.DLMS.Python 1.0.199
  • Mon, 06/08/2026 - 13:39
    gurux.dlms.cpp 9.0.2606.0801
  • Mon, 06/01/2026 - 10:15
    gurux.dlms.cpp 9.0.2606.0101
  • Thu, 05/28/2026 - 16:06
    gurux.dlms.java 4.0.94

New forum topics

  • Error reading L&G Meter
  • Pass a TCP Client to GXNet
  • Australian EDMI Mk10D (Essential Energy area)
  • Strange mix of data notificiation vs get response
  • DLMS Connection
More

Who's new

  • Tuanhgg
  • Adel
  • charnon
  • Paddles
  • Miguel Ángel
RSS feed
Privacy FAQ GXDN Issues Contact
Follow Gurux on Twitter Follow Gurux on Linkedin