Today I saw this strange (for me) thing.
The device is ZBMINI with FW 2.0.
The Cluster is 0006 On/Off
Sometimes there are
and sometimes there are
If I read the attribute while the value is zero or one I get
Moved to deconz - general support.
So I have an answer from manup
When a device sends data in a different data type format as the general.xml has, via ZCL report/read attribute response, the data type is changed in the deCONZ::ZclAttribute (but only for that cluster on that device).
This is needed to be able to read the correct value out. This was added back in the day since a device did send uint8 instead a boolean (or something like that).
So yes it s possible, if the device have buggy firmware and not use the good type, deconz can update it in the GUI.
The normalised value is the bool, but it seem your device use u8 at a moment, and deconz update it, but after that the device refuse the u8 type ???
As Smanar already said, the defined data type for that cluster/attribute is bool. However, as there’s so many quality products around not following the standard, deconz has a mechanism implemented to “override” spec defined types in order to make those oddities work.
If things really get worse, a device uses different data types on different zigbee commands which can potentially lead to data types even jumping around.