0x02 : day_profile structure
0x03 : length
0x09 : start_time, but this time as an octet-string
0x04 : length
0x00, 0x00, 0x00, 0xff : start_time value
0x09 : script_logical_name
0x06 : length
0x00, 0x00, 0x0a, 0x00, 0x64, 0xff : script_logical_name value (0.0.10.0.100.255)
0x12 <- Unsigned16 (script_selector) 0x00, 0x00 <- script_selector value
I could fix this and build my own Gurux dll file, but it would be nice to stick to the official releases.
How should I solve this? Should I build my own dll file or is there a way that you can add official support for different time types? I'm having this problem both in spec_day_entry and in day_profile_action.
Wow, that was quick. :) Thanks!
Question: When the Blue Book states "time can be represented like an octet-string, as time, as date-time" etc., is it really correct just to pick ONE of these? Shouldn't the meter support ALL of the types?
Writing day_profile_action.start_time
Hi,
We have changed time to octet-string. Get new version from GitHub or nuget.org.
BR,
Mikko
Writing day_profile_action.start_time
Wow, that was quick. :) Thanks!
Question: When the Blue Book states "time can be represented like an octet-string, as time, as date-time" etc., is it really correct just to pick ONE of these? Shouldn't the meter support ALL of the types?
Writing day_profile_action.start_time
Hi,
You can set Time like this:
GXDLMSSeasonProfile sp = new GXDLMSSeasonProfile();
sp.Start = new GXTime(DateTime.Now);
You can set DateTime like this:
GXDLMSSeasonProfile sp = new GXDLMSSeasonProfile();
sp.Start = DateTime.Now;
Most of meters are using Time and standard says that use time, but we are reading one meter type what is using DateTime.
BR,
Mikko
Writing day_profile_action.start_time
OK, interesting. I'll try this out.