Hi @MarstekEnergy ,
I see, that the default value for most sensors is '0' for the situations, like an API answer might be missed or timeouts or device not reachable...
I think it is wrong to do it that way, because the 0-values are transmitted as if they were "real" values, which makes the logged data look crappy:
Also it is just a wrong value, because the value is just missing and not '0'!
Basically it should be handled as a gap in the data, which should not just be filled with '0's.
I am not sure how other integrations handle that. But I think it would be preferable to set missing/lost values to something like "unknown" instead of '0'.
I kindly ask you to check out, how other integrations handle hat. But asserting the value to be '0' is not a good solution in my opinion...
Greetings and best wishes!
Hi @MarstekEnergy ,
I see, that the default value for most sensors is '0' for the situations, like an API answer might be missed or timeouts or device not reachable...
I think it is wrong to do it that way, because the 0-values are transmitted as if they were "real" values, which makes the logged data look crappy:
Also it is just a
wrong value, because the value is just missing and not '0'!Basically it should be handled as a gap in the data, which should not just be filled with '0's.
I am not sure how other integrations handle that. But I think it would be preferable to set missing/lost values to something like "unknown" instead of '0'.
I kindly ask you to check out, how other integrations handle hat. But asserting the value to be '0' is not a good solution in my opinion...
Greetings and best wishes!