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.
Forums
When using the function GXDLMSClient.write(GXDLMSObject, attributeIndex) to write some data to either DLMS Class id 1 or 3 fails for some data types.
For example, If we consider writing to an Alam register to clear it, The alarm register is of type GXDLMSdata and in our implementation the value of the register is unsigned32. When this object is read the value is stored as Long in the GXDLMSData class and after modifying the value and when we try to write to the meter it fails. This is because when the COSEM message is created by the write function it is converting the Long data type to Unsigned64 and when this message is sent to the meter it returns data type mismatch as this expects unsigned32.
I understand this is because of Java limitation that there is so support for unsigned data types in Java and as a workaround we are using the other write method which accepts the data type and object type.
For this, the data type has to be hardcoded and not good for maintaining. Is there any way where this could be done generic enough like using the GXDLMSClient.write(GXDLMSObject, attributeIndex) method.
Thank You
BR
Pramod G
Hi Pramod,
Hi Pramod,
Java is really causing problems because there are no unsigned numbers. For this reason, the original data type is lost. We modified the implementation so data type is saved automatically.
At the meantime, you can set datatype manually.
GXDLMSData d = new GXDLMSData("OBIS CODE");
d.setDataType(2, DataType.UINT32);
d.setValue(1);
Now when you write data, the type is correct.
BR,
Mikko