Hi,
We are working in the server example 2.
The function below take 2 arguments:
int time_compare2(gxtime* value1, uint32_t value2)
When the value1 is equal to 0, it is throwing an error (check the uploaded picture).
We were able to narrow exactly the origin of this exception.
1. We set the capture period to a number different from 0 (if not the issue will not appear) for example 300s(5min).
2. Each 5 mins in the svr_handleProfileGeneric the svr_invoke will be called with these arguments :
ret = svr_invoke(
settings,
(gxObject*)object,
2,
time,
NULL,
NULL,
&object->executedTime,
next);
So, the gxtime start and end arguments are both equal to NULL.
3. In the svr_invoke function we find this condition:
if (end == NULL)
{
exec = *executed < time && time_compare2(start, time) == 0;
}
The end and start gxtime variable are NULL so the time_compare2 is taking NULL as start arguments and this is exactly the reason that is throwing the exception.
Hope this will help you to solve this issue.
Best Regards,
Lara Wakim
Hi Mikko,
Hi Mikko,
We downloaded the latest release (version 20200721.1) and tested it.
- The exception due to the time_compare2() is gone and the capture period feature of the profile generic worked perfectly
- The issue concerning the single action scheduler that was only triggered on execution time ending by 00s or 30 s is also solved.
- One issue left not solved yet: the deviation of our country is not taken into consideration when setting the execution time from the GXDLMSDirector. In fact, the deviation is skipped and the single action scheduler is triggered based on UTC time and not our country time. This issue needs to be solved.
Thank you for your hard work.
Best Regards,
Lara Wakim
Hi Lara,
Hi Lara,
Single Action Schedule doesn't use deviation. It's manually added in svr_run.
What time zone you are using? Have you set the time zone for the clock object?
BR,
Mikko
Hi Mikko,
Hi Mikko,
Our time zone is equal to -120 and we set the time zone for the clock object and tested the single action scheduler but the issue is still here.
In fact, when introducing the execution time for the GXDLMSDirector the deviation is skipped and the single action scheduler is triggered based on UTC time and not our country time.
For example, our country time is equal to UTC+3. When testing, to trigger the single action scheduler at 4:00 pm (our time UTC+3) we introduced the execution time equal to 1:00 pm (UTC time) and it worked. Instead, we expected to introduce as execution time 4:00 pm and the action to be triggered at 4:00 pm.
You told us the last time it could be solve by calling the clock_utcToMeterTime(&meterData.clock1, &tm).
Best Regards,
Lara Wakim
Hi,
Hi,
There has been a misunderstanding. clock_utcToMeterTime(&meterData.clock1, &tm) is used when you read data to profile generic. You don't use it when setting execution time.
Single action execution time is split to two parts. Date and time and deviation is ignored.
execution_time_date ::= structure
{
time: octet-string,
date: octet-string
}
Try to clear execution times and write a new execution time using GXDLMSDirector. Will it work?
Do you try to set an exact time or do you want that this schedule is executed example daily?
BR,
Mikko
Hi,
Hi,
Our first objective of testing is to set an exact time delayed 1 min from our time and wait the triggering of the action scheduler. We tried to clear the execution times and write a new one using GXDLMSDirector equal to our time delayed of 1 min, but it didn't work. However when we tried to put from the GXDLMSDirector a time equal to the UTC time not ours and delayed of 1 min, it worked and the action is triggered.
We followed the code and we noticed when we are setting a new execution time it goes to the cosem_setActionSchedule() function in the "gxset.c" file. In this function, at the index number 4, we noticed for example if we set an execution time equal to 11:00:00 am (our time now) from the GXDLMSDirector, the "tm" variable is saved equal to 2:00:00 pm (they added the deviation to the set value like they were expecting the UTC time not our real time), so the saved value is equal to the UTC time plus the deviation(3h)*2. Maybe the problem is due to the GXDLMSDirector not the server.
To avoid this problem and trigger the action at 11:00:00 am our time, we set an execution time equal to 8:00:00 am from the GXDLMSDirector. Afterwards, the "tm" variable in the cosem_setActionSchedule() function is saved as 11:00:00 am, and the action schedule is triggered at 11:00:00 am like wanted.
Hope the issue is more clear now.
Best Regards,
Lara Wakim
Hi,
Hi,
We downloaded the latest version of the server example 2, but this issue is still not solved. The execution time of the single action schedule is still triggered based on UTC time and not our country time. Can you check it please.
Best Regards,
Lara Wakim
Hi Lara,
Hi Lara,
Can you show how you add the time? Have you set Time Zone for the clock object? It should be -120.
BR,
Mikko
Hi Mikko,
Hi Mikko,
Knowing our country time is equal to UTC+3, we made the below test:
- First we set the time zone for the clock object and it was equal to -120
- We introduced the time now delayed of 1 min, but the single action schedule was not triggered.
- We tried to introduce a time minus 3 hours from now and delayed of 1 min, but the single action schedule was not triggered.
- So we tried to introduce a time minus 1 hours from now and delayed of 1 min, the single action schedule was triggered. It was totally logic because the time zone of our country is 2 hours + 1 hour from the daylight savings.
- We enabled the daylight savings for the clock object with a deviation equal to 60 and tested to trigger the single action schedule on the time now but it didn't work. However it still worked on an execution time minus 1 hours from now (taking in consideration the time zone but not the daylight savings).
N.B: DLMS_USE_UTC_TIME_ZONE is not defined in the project.
Why not using clock_utcToMeterTime() function or time_toUTC() function to save directly the execution time in the server as UTC based with the help of the deviation?
If you need more details or explanation, don't hesitate.
Best Regards,
Lara Wakim
Hi,
Hi,
Now I believe I know the reason. Single action schedules are executed in that second. If you try to set execution time to yesterday, it's never executed. That time is gone. Reason for this is that meter might be off for some reason. We don't want to execute all actions when power is on again.
There are no time zone in Singe Action Schedule time. Single Action Schedule is always executed using meter time.
BR,
Mikko
Hi,
Hi,
We sent to your email a macro editor describing in details the issue concerning the single action schedule. If you can check it, hope it will help you to solve the problem.
Best Regards,
Lara Wakim
Hi Lara,
Hi Lara,
We have checked the macro that you sent and I believe that I know the reason now for this.
When you add a Single Action Schedule time it's meter's time, not PC time.
If you don't use DST in the meter, but your PC is using, you need to decrease time by one hour.
If you don't do that, the action is executed one hour later than time what you have given.
Time zone and DST info are not sent in part of the script schedule time.
Can you check this and let me know if you agree with me?
BR,
Mikko
Hi Mikko,
Hi Mikko,
Yes, we totally agree with you on what you said before. This is exactly the problem that we are facing.
We can resume this problem into three scenarios:
- In fact, when the time zone and DST are not set through the client by using the clock object, the action is executed THREE hours (time zone 2h + DST 1h) later than the time that we have given.
- When we set the time zone (-120) only without the DST, the action is executed ONE hours (DST 1h) later than the time that we have given.
- When we set the time zone (-120) and we enable the DST through the clock object, the action is still executed ONE hours later than the time that we have given. We can conclude that the DST is not taken into consideration. The DST should be checked.
Why not use the deviation directly to synchronize the time instead of relying on the time zone and the DST? Because if the time zone and DST are not set by the client the single action scheduler will not be triggered on the desired time.
Is it not better to add and store the single action schedule time like you are doing in the profile generic when capturing the time and value to store?
Best Regards,
Lara Wakim
Hi,
Hi,
Everything is working correctly in all your scenarios.
The deviation information is not sent in part of the execution time. That is the reason. There is only a time and date field, but not deviation.
execution_time_date ::= structure
{
time: octet-string,
date: octet-string
}
BR,
Mikko