Thank you again Alex for the custom channel datatype switch to number. I’ll integrate and test asap.
Concerning the status channels there could be a misunderstanding in the way i described the current behaviour.
As a matter of fact, these status channels defined as String do not report anymore the strings ‘Yes’ or ‘No’ nor any other lexical labelling in the case of a choice list. What is currently returned instead is the raw number itself (an integer) represented in a string, that is the string ‘0’ or ‘1’ or whatever other integer directly turned into a string. This happens since the change you have applied consisting in translating directly the RAW value (which i understand would be on March 28, looking at the related post). In other words, the former representation in earlier versions were indeed returning lexical string statuses such as ‘Yes’ or ‘No’ but these are no more returned, now we get ‘1’ or ‘0’. this is the reason why i was suggesting to make it all consistent with using number type directly.
In fact, on this subject i realised the following in the meantime: Before being uploaded to NibeUplink, all the nibe equipment parameters are also published/accessible via the Modbus40 interface. As a matter of fact, the Modbus protocol does not support strings but integers. This could explain why the RAW value, which is probably the native representation of these parameters in the equipment, is always an integer number (then to be scaled by a given factor when it is to represent a floating-point). What i’m saying is that all these parameters that NibeUplink publishes through the API are also the so-called Modbus ‘registers’ that can be published locally by the equipment (through the Modbus40 box), and so the native datatype of all parameters is most probably Integer since the start.
Sorry for this long post but i realise it could explain better what i observed and tried to summarise in the previous post.