Questions and issues of the release "gurux.dlms.c 20201214.1"

Hi,

We downloaded the latest version and we are testing it right now. We noticed all the improvements and optimization made to the serialization.

But till now the above issue is still here. When we create an object gxData of value type array[2] of bit-string[256] or array[2] of octet-string[12], it is still unreadable by the director (invalid data type) and when trying to load the meter it is giving "assertion failed"

If you please can check it and maybe add these 2 objects to the next release.

Best Regards,

Lara Wakim

PS: you can find below the 2 methods to add these 2 objects. This will also help you to repeat more easily the problem.

int addEventLogFilter_standardEventLog()
{
int ret;
const unsigned char ln[6] = { 0, 1, 94, 34, 105, 255 };
if ((ret = INIT_OBJECT(eventLogFilter_standardEventLog, DLMS_OBJECT_TYPE_DATA, ln)) == 0)
{
static char BUFFER[2][32]; //32*8= 256
for (int i = 0; i < 32; i++)
{
//Array[0]=default values: 1 for all bits (all events will be log into the buffer)
BUFFER[0][i] = 0xff;
//Array[1]=default values: 0 for all bit (no event will be sent as notification event)
BUFFER[1][i] = 0;
}
static dlmsVARIANT ARRAY[2];
GX_BIT_STRING(ARRAY[0], BUFFER[0], 256);
GX_BIT_STRING(ARRAY[1], BUFFER[1], 256);
static variantArray tmp;
VA_ATTACH(tmp, ARRAY, 2);
GX_ARRAY(eventLogFilter_standardEventLog.value, tmp);
}
return ret;
}

int addTimestampForNewCalendarActivation()
{
int ret;
const unsigned char ln[6] = { 1, 0, 94, 34, 130, 255 };
if ((ret = INIT_OBJECT(timestampForNewCalendarActivation, DLMS_OBJECT_TYPE_DATA, ln)) == 0)
{
//Array[3] of octet-string[12]
//Array[x] Date&Time for contract x (x =1..3)

static unsigned char BUFFER[3][12];
static dlmsVARIANT ARRAY[3];
GX_OCTECT_STRING(ARRAY[0], BUFFER[0], sizeof(BUFFER[0]));
GX_OCTECT_STRING(ARRAY[1], BUFFER[1], sizeof(BUFFER[1]));
GX_OCTECT_STRING(ARRAY[2], BUFFER[2], sizeof(BUFFER[2]));
static variantArray tmp;
VA_ATTACH(tmp, ARRAY, 3);
GX_ARRAY(timestampForNewCalendarActivation.value, tmp);
}
return ret;
}

Hi Mikko,

Let me share with you some comments from our side concerning the new release and especially the new implemented function svr_handleActivityCalendar():

- First we noticed that concerning the season profile you are comparing the start time of the season with the current time through "time_compare2(&tm, time)" to test it we created 2 seasons winter and summer:

//Add active season profile.
ARR_ATTACH(activityCalendar.seasonProfileActive, ACTIVE_SEASON_PROFILE, 2);
// add Summer season
SET_OCTET_STRING(ACTIVE_SEASON_PROFILE[0].name, "Summer time", 11);
SET_OCTET_STRING(ACTIVE_SEASON_PROFILE[0].weekName, "Summer week", 11);
time_init(&ACTIVE_SEASON_PROFILE[0].start, -1, 3, 31, -1, -1, -1, -1, 0x8000);
//add winter season
SET_OCTET_STRING(ACTIVE_SEASON_PROFILE[1].name, "Winter time", 11);
SET_OCTET_STRING(ACTIVE_SEASON_PROFILE[1].weekName, "Winter week", 11 );
time_init(&ACTIVE_SEASON_PROFILE[1].start, -1, 10, 30, -1, -1, -1, -1, 0x8000);

The goal is to compare current time with the start time of each season and to check in which interval we are. In our case (12/16) we are in the "winter time" but when looping through seasonProfileActive.size the time_compare2(&tm, time) is also different from 0 which is wrong because we are in the winter season. We think we should not check if the day and moth are equal but we should check in which interval our current date is included.

To be able to continue with the testing we replaced this line:
time_init(&ACTIVE_SEASON_PROFILE[1].start, -1, 10, 30, -1, -1, -1, -1, 0x8000);
with this one:
time_init(&ACTIVE_SEASON_PROFILE[1].start, 2020, 12, 16, -1, -1, -1, -1, 0x8000);
When replaced the time_compare2(&tm, time) gave 0 and we were able to continue the testing.

- Concerning the week profile it is working like expected, it checked first which weekName was selected with the chosen season and then we saved the dayId corresponding for the day of the week (Wednesday in our case). The output of this step is dayId = 1 (check below)

SET_OCTET_STRING(ACTIVE_WEEK_PROFILE[0].name, "Summer week", 11 );
wp = &ACTIVE_WEEK_PROFILE[0];
wp->monday = wp->tuesday = wp->wednesday = wp->thursday = wp->friday = 2;
wp->saturday = wp->sunday = 3;

SET_OCTET_STRING(ACTIVE_WEEK_PROFILE[0].name, "Winter week", 11 );
wp = &ACTIVE_WEEK_PROFILE[1];
wp->monday = wp->tuesday = wp->wednesday = wp->thursday = wp->friday = 1;
wp->saturday = wp->sunday = 3;

- Concerning the day profile, it is implemented in a different way from our requirements. If you check the attached picture the day profile should be implemented in this way:
Start_time: is a TIME(OCTET-STRING[4]) where seconds and hundredths are not configurable (value0x00).
script_logical_name: octet-string[6], is a dummy script.
Script_selector: Less significant byte identifies directly the rate.
Example for less significant Byte: (0x01 means rate1, 0x02 means rate2, 0x03 means rate3,…0x04 means rate 4)

This means that the script is null and the script selector is used to identify which is the current tariff.

In fact, in our examlple we are interested with the dayId = 1 implemented like this:

ARR_ATTACH(activityCalendar.dayProfileTableActive, ACTIVE_DAY_PROFILE, 3);
ACTIVE_DAY_PROFILE[0].dayId = 1;
ARR_ATTACH(ACTIVE_DAY_PROFILE[0].daySchedules, ACTIVE_DAY_PROFILE_ACTIONS1, 4);
time_init(&ACTIVE_DAY_PROFILE_ACTIONS1[0].startTime, -1, -1, -1, 1, 0, -1, -1, 0x8000);
ACTIVE_DAY_PROFILE_ACTIONS1[0].scriptSelector = 1;
time_init(&ACTIVE_DAY_PROFILE_ACTIONS1[1].startTime, -1, -1, -1, 11, 0, -1, -1, 0x8000);
ACTIVE_DAY_PROFILE_ACTIONS1[1].scriptSelector = 2;
time_init(&ACTIVE_DAY_PROFILE_ACTIONS1[2].startTime, -1, -1, -1, 12, 0, -1, -1, 0x8000);
ACTIVE_DAY_PROFILE_ACTIONS1[2].scriptSelector = 1;
time_init(&ACTIVE_DAY_PROFILE_ACTIONS1[3].startTime, -1, -1, -1, 23, 0, -1, -1, 0x8000);
ACTIVE_DAY_PROFILE_ACTIONS1[3].scriptSelector = 2;

So first we have to check and compare our time with the different start time which IS NOT implemented in your code AND SHOULD BE PRESENT. After comparing and identifying in which interval we are (our case around 2:30 pm so third case between 12:00 and 23:00) so the scriptSelector = 1 so the current tariff is equal to 1. This is what we need in our case.
Surely the svr_invoke() function is needed in case the script is different from Null and should be triggered on time.

- Finally there is a last feature that is not taken in consideration yet. In fact before checking all this step starting with the season, we should check if the current date is included in the special day table. If not, we follow the step described above. If yes, we jump directly to the day profile table because with each special day we have its own dayId leading us to the current tariff.

Sorry for this long text and explanation.

Hope you will be able to add the missing piece and correct the bugs. If you need more information or you need any help feel free to ask.

Best regards,

Lara Wakim

Hi Mikko,

We are sorry for the above long explanation.

After checking the blue book, we noticed that you followed the attached scheme (check the picture) and this is exactly what we want and the implementation that you did is almost done and correct. We noticed that you already created the tariffication script table and the register activation.

To sum up what is missing in the activity calendar:
1- To check the special day table before checking the season table
2 - When checking the season table, we should only see in which interval season our current date is included (not compare equally)
3 - When checking the day table, we should also see in which interval of time our current time (hours and minutes) is included and then we can trigger the tariffication script with the expected script selector.

We are very grateful for your hard work.

Best Regards,

Lara Wakim

Hi Mikko,

Concerning the day profile:

1 - Concerning the start time of the day profile, you are right.
But don't forget that you should check in which time interval (day schedule) we are currently before triggering the tariffication script exactly like you did with the season profile.

2 - We are not interested anymore with the NULL script. We want to trigger the tariffication script already implemented like suggested in the DLMS standard.

3 - You are right.
But also don't forget that when reaching the day profile we have to check if this day is one of the special day (in the special day table object):
If no we continue the testing normally by checking the start time then triggering the tariffication script
If yes we should use the dayId table noted with the corresponding special day then checking the start time then triggering the tariffication script

If you have any comment or need more information feel free to ask.

Best Regards,

Lara Wakim