Extend IBT 4X decoder?

[NateEaton]

The decoder as it is works great for monitoring the probe temperatures but there are a few other features I'd like to suggest/request:

• Battery level (doesn't appear to be in mfr data but looks like it can be retrieved from service data)
• Availability topic (published as "on" statewhenever the IBT is powered, i.e., appearing in scans, with a final publish as "off" once one or several scans complete where the device is no longer appearing in scans); this is information I'm used to having in Home Assistant from other devices publishing through MQTT.
• More complete state of each probe:
  • either return 32 degrees whenever the second byte contains 'ff' instead of having that condition preclude returning a value; 32 degrees is the Inkbird "default" value when a probe is either partially inserted or has failed so it seems like a useful value to return whenever a) the device is on but b) there is no probe plugged into that port.
  • the second (and perhaps preferrable) option is to have a separate "state" property for each probe with two values: "active" when there is a temperature being read ("condition":["manufacturerdata", 22, "!", "ff"]) and "inactive" when not ("condition":["manufacturerdata", 22, "=", "ff"]). This would provide a more complete view of what''s going on in Home Assistant.

Thoughts on this? I've cloned the repository and have been reviewing everything with an eye towards doing some decoder development but given this is an existing decoder that perhaps many others are already using, it seems like changes need to be vetted (vs. creating a decoder for a new device).

[DigiH]

Battery level (doesn't appear to be in mfr data but looks like it can be retrieved from service data)

Decoder can only receive and decode freely broadcast BLE advertising data. The IBT series only broadcasts its manufacturerdata like that, no servicedata or both together like some other devices. The service you are talking about would only be accessible through a connection and READing the service/characteristic - although I didn't find such an obvious battery characteristic when briefly scanning my IBT-2X.

Availability topic (published as "on" statewhenever the IBT is powered, i.e., appearing in scans, with a final publish as "off" once one or several scans complete where the device is no longer appearing in scans);

This would require Decoder to take a whole new approach, as currently it doesn't know anything about previously scanned devices, doesn't store them anywhere for later comparison etc. not a direction we'd want to go. It would also bring up new issue like, how long do you remember devices which might just be passing by your house, and for how long etc. ;)

… this is information I'm used to having in Home Assistant from other devices publishing through MQTT.

MQTT devices themselves do have such a functionality through the LWT message through the broker, showing online when they are connected, offline when disconnected from the broker, but this does not translate to the devices MQTT these decoders send information about.

either return 32 degrees … when a probe is either partially inserted or has failed so it seems like a useful value to return whenever a) the device is on but b) there is no probe plugged into that port.

I don't think it is a good idea for any decoder to send an arbitrary temperature when no such temperature is actually being transmitted.

the second (and perhaps preferrable) option is to have a separate "state" property for each probe with two values: "active" when there is a temperature being read ("condition":["manufacturerdata", 22, "!", "ff"]) and "inactive" when not ("condition":["manufacturerdata", 22, "=", "ff"]). This would provide a more complete view of what''s going on in Home Assistant.

I agree, this would be the preferable solution, but since Decoder is not only being used on Gateway, the mobile phone App, Explorer etc. - all projects running on devices where memory isn't a big concern - but is also widely used in OpenMQTTGateway running on ESP32, trying to keep the Decoder library as compact and small as possible is a concern. Introducing this functionality would virtually double the size of the IBT-4X decoder, extending it to the 2X and 6X as well would grow it even more.

In the light of this functionality being easily implementable in Home Assistant or any other controller with the info currently already being published we'd rather keep the saved space for possible new decoders for other devices.

I'm sorry to say that these are probably not the replies you hoped for, but I do hope you understand out reasoning behind it.