[BUG] env is not reported properly in MQTT Faikin/ topic if BLE is active

[miniluma]

running the latest beta from 17.09.2024

Describe the bug livestatus active fixstatus inactive reporting = 300 nofaikinauto active

1) (as expected) Faikins with environment monitoring data received via MQTT command report env, and the env array in Faikin/ Info: I send the measured-temp from a Homematic room sensor with command/$DEVICETOPIC/control {"env":"$EVTPART1"} (with $DEVICETOPIC as the faikin name and $EVENTPART1 as temperature value).

2) (unexpected) Faikins with BLE send env in status/ but Faikin/ only receives the array. The current value is missing. The ble_.* as part of the status is sent as expected and equals the env value.

[revk]

I'll see if I can look later today.

[revk]

Hmm, the "temp" report in status is the env we are using if set, else home if set, else home if set.

The env is set from BLE if available, or command with "env", if being sent, so either of these will report the "temp" in status.

Separately, the status also includes "bletemp", "blehum", and "blebat" if available (though maybe they would be better in a "ble" object. Hmmm.

The Faikin message reports periodic statistics (array of min/ave/max, or single value, depending on setting) that are collected from the Daikin. But this includes env (set by BLE or command). It does not include the ble data separately.

So I think working as I designed...

[miniluma]

ok, when I disable livestatus, I see it as part of Faikin as well.

With livestatus=1, I see the env array (min/avg/max) in Faikin, but Faikin/env is not included. (status/env is updated as expected)

[revk]

OK that makes no sense.. I'll have to have another look.

But it was never in Faikin as it is not a real field from the aircon, the real fields are things like home, etc.

[miniluma]

Let me check something. Can you please tell me where the data for the reporting is collected? In which line? Just to make sure I'm looking at the right place.

[revk]

Depends which reporting, you can find env = in a few places, setting from temp from aircon, or BLE, or the control messages.

[miniluma]

If I understand correctly, the data for Faikin is generated with this macro: https://github.com/revk/ESP32-Faikin/blob/c17fc822ff12160f6921cddfec7ac69987fb54e0/ESP/main/Faikin.c#L3879 and finally sent here: https://github.com/revk/ESP32-Faikin/blob/c17fc822ff12160f6921cddfec7ac69987fb54e0/ESP/main/Faikin.c#L3889 right?

So for env, this will be processed to

if(daikin.countenv && !isnan(daikin.totalenv)){
    if(!fixstatus && daikin.minenv == daikin.maxenv)
        jo_litf(j, "env", "%.2f", daikin.minenv);
    else {
        jo_array(j, "env");
        jo_litf(j, NULL, "%.2f", daikin.minenv);
        jo_litf(j, NULL, "%.2f", daikin.totalenv / daikin.countenv);
        jo_litf(j, NULL, "%.2f", daikin.maxenv);
        jo_close(j);
    }
}
daikin.minenv = NAN;
daikin.totalenv = 0;
daikin.maxenv = NAN;
daikin.countenv = 0;

Which means, there will be an env in Faikin report if daikin.minenv == daikin.maxenv, which might happen if env is sent frequently (my reporting is 300s) with a pretty static temperature.

--

Also, I don't understand the fixstatus. It's described as "Send status as fixed values not array". But if env is changing a bit over my 300s (so min != max), it will always be sent as array. And with fixstatus==1 it's an array for sure.

[revk]

Sounds like the test is wrong there!

[revk]

That means fixstatus was wrong all along, I am fixing now - beta in a moment.

[miniluma]

tested with fixstatus == 1: Works perfect! Thank you.

untested for fixstatus == 0.