Proposal for the implementation, in FW, of absolute temperature thresolds for triggering a device wakeup and status update/reporting

    Hi,

    since I've seen that the underlying issue has been discussed a few times here (in English, but I'm sure the same happened in German), let me propose, here as well, what I just proposed to Shelly, by means of the dedicated form on their website:

    In order to partially overcome the big functional limitation resulting from the current very high (0.5C) lower bound for the temperature variation threshold, let me suggest to implement in FW the possibility to trigger a device wakeup and a status update/report when a programmable temperature (absolute, not variation) threshold is crossed, even better if two different absolute thresholds could be set (one for a rising temperature, one for a dropping temperature). This would support the implementation of a kind of "interrupt-driven" temperature control, rather than a "polling-based" one. No need to say that those thresholds should be programmable from the outside of the device through one of the existing APIs, in addition to the web GUI.

    Ciao, Nicola.

    The sleep mode has a meaning and purpose. In continuous operation, the device heats up itself and the displayed temperature is incorrect

    I don't see a problem in the sleeping mode, as long as the device sends regular updates.

    But indeed, a +0,5°C and -0,5°C is way to much.

    At least give us a possibility to go to 0,1°C when connected to power, and 0,2°C when in battery mode.

    Make room for a disclaimer so the user understands this has a huge impact on battery life.

    I love the design of the device, really, but this threshold is making the device useless (for me).

  • Dieses Thema enthält 8 weitere Beiträge, die nur für registrierte Benutzer sichtbar sind, bitte registrieren Sie sich oder melden Sie sich an um diese lesen zu können.