It's a Chinese meter (can't say which vendor specifically).
I figured out what was wrong. I was sending a GXDLMSDayProfile object with an empty list of GXDLMSDayProfileAction to the day_profile_table_passive attribute. This caused the meter to return "TemporaryFailure" every time I requested the day_profile_table_passive object. The error persisted until I wrote a complete GXDLMSDayProfile object instead (which contained full GXDLMSDayProfileAction objects) .
In my opinion, it's a bug in the meter firmware because it would be better if I'd received an error when writing incomplete data to the day_profile_table_passive object.
I'm glad that you solved this. It's a little problem that there are limited number of possible errors.
Lack of error codes is causing that we have to sometimes guess what is the problem.
Perhaps there should be a Gurux.DLMS.Validation library (optional), which provides validation for stuff that's beyond explicit data errors.
A scenario:
If I try to create a week_profile containing day id 4, but day id 4 does not exist in the day_profile_table, it will probably result in an "Other Reason" error.
But I had this (or something like it):
Gurux.Validation.RunValidation(week_profile);
I would spot the error early on and perhaps avoid a few headaches!
Your idea is good. We have actually implemented something like this, but problem is that it's newer ready. Amount of different scenarios is huge. But I'll think this if we I can get some kind of idea how to do it.
Well, how about putting up a github repo for it and it can be WIP until it has enough functionality? I would gladly contribute, it would be easy to add cases whenever they are discovered. Could be a very simple repo, based around unit tests.
I have thinking how we can use exists code. In my mind there is no point to start from scratch. Idea what I'm thinking is can or should we use XML for validation.
ActionResponse
Hi,
What meter you try to read? If you read meter again is same error sent or is this random?
BR,
Mikko
TemporaryFailure
It's a Chinese meter (can't say which vendor specifically).
I figured out what was wrong. I was sending a GXDLMSDayProfile object with an empty list of GXDLMSDayProfileAction to the day_profile_table_passive attribute. This caused the meter to return "TemporaryFailure" every time I requested the day_profile_table_passive object. The error persisted until I wrote a complete GXDLMSDayProfile object instead (which contained full GXDLMSDayProfileAction objects) .
In my opinion, it's a bug in the meter firmware because it would be better if I'd received an error when writing incomplete data to the day_profile_table_passive object.
TemporaryFailure
Hi,
I'm glad that you solved this. It's a little problem that there are limited number of possible errors.
Lack of error codes is causing that we have to sometimes guess what is the problem.
BR,
Mikko
Validation
Indeed, lots of guessing included!
Perhaps there should be a Gurux.DLMS.Validation library (optional), which provides validation for stuff that's beyond explicit data errors.
A scenario:
If I try to create a week_profile containing day id 4, but day id 4 does not exist in the day_profile_table, it will probably result in an "Other Reason" error.
But I had this (or something like it):
Gurux.Validation.RunValidation(week_profile);
I would spot the error early on and perhaps avoid a few headaches!
Validation
Hi,
Your idea is good. We have actually implemented something like this, but problem is that it's newer ready. Amount of different scenarios is huge. But I'll think this if we I can get some kind of idea how to do it.
BR,
Mikko
Validation
Well, how about putting up a github repo for it and it can be WIP until it has enough functionality? I would gladly contribute, it would be easy to add cases whenever they are discovered. Could be a very simple repo, based around unit tests.
Validation
Hi,
I have thinking how we can use exists code. In my mind there is no point to start from scratch. Idea what I'm thinking is can or should we use XML for validation.
But as I say before, I'm still thinking it.
BR,
Mikko