Zlinky_TIC
Zlinky_TIC copied to clipboard
Attribute 0xff66/0x0227 and 0x0228 seems to be a Data Type Long octet string ( 0x43) instead of String ( 0x42)
As describe in the title. It looks like 0300 is reported with data type 0x43 instead of 0x42
Attribute: 0003 ==> 0300 Status: 00 Data Type: 20 = Len = 1 byte 00
Attribute: 2702 ==> 0227 status: 00 DataType: 43 (Composite ) Len: 0000
Attriubute: 2802 => 0228 Status: 00 DataType: 43 Len: 0000
BTW, why is there no data ?
0xFF66 / 0x0300 is an uint8 data type 0xff66 / 0x0227 is 0x43 data type --> Long String 0xff66 / 0x0228 is 0x43 data type --> Long String
I'll see why 0x0227 (PJOURF+1) give no datas (the linky is supposed to transmit by default some "NONUTILE" strings For 0x0228 (PPOINTE), the Linky transmit nothing by default.
PJOURF+1 and PPOINTE value depend on EDF specific subscription. In the majority of cases, these values are not used
my question was more , why 0x43 and not 0x42 , this makes the things quiet complexe as in your documentation you are only talking about string and you don't make the difference between Long String and string. Long string is for string which are longer than 255 caracters
because in the first study I didn't know how much character the Linky would send. Who can do more can do less. As now I know I changed the type and I fix in v6
v6 is not acceptable for me due to the routing table restriction. So please provide eventually 2 firmwares one without routing table and one with routing table. This is not expected to reduce the routing table to 1 because some HUe users are generating issues
this is the case but I need to finally the first version. And your comment have no link with the issue