selflowtemp resets every 5 minutes when writing same value

[poelstra]

Bug description

selflowtemp is resetting back to 7 degC when e.g. writing a value of 75 degC every minute. When writing a different value (70, 71, 70, 71, ...) it keeps the indicated value.
It worked fine on 3.5.0b7 and started to appear after updating to 3.5.0.

Steps to reproduce

• Use just a boiler (without external thermostat), and write the same value to selflowtemp (in my case using the REST API).

Expected behavior

• Value should persist.

Unexpected behavior

• Value reset back exactly 5 minutes after the value last changed.
• E.g. writing 73, 73, 73, 74, 74, 74, 74, 74, 74 every minute, the selflowtemp will reset back to 7 after exactly 5 minutes since the transition from 73 to 74. On the next write of 74, it will change to 74 and stays like that for another 5 minutes, etc.

Screenshots

Logs when things work fine (i.e. when the selflowtemp changes to a different value):

2023-02-11 16:04:23.105 DEBUG 455: [command] Calling command 'boiler/selflowtemp' (selected flow temperature) with value 75
2023-02-11 16:04:23.105 DEBUG 456: [command] Calling command 'boiler/values'
2023-02-11 16:04:23.285 DEBUG 457: [telegram] Sending write Tx [#221], telegram: 0B 08 1A 00 4B
2023-02-11 16:04:23.285 DEBUG 458: [emsesp] Last Tx write successful
2023-02-11 16:04:23.285 DEBUG 459: [telegram] Sending post validate read, type ID 0xE4 to dest 0x08
2023-02-11 16:04:25.332 DEBUG 460: [telegram] Sending read Tx [#222], telegram: 0B 88 E4 00 1B
2023-02-11 16:04:25.362 DEBUG 461: [emsesp] Last Tx read successful
2023-02-11 16:04:25.362 DEBUG 462: [emsesp] This telegram (UBAMonitorFastPlus) is not recognized by the EMS bus
2023-02-11 16:04:33.233 DEBUG 463: [command] Calling command 'boiler/values'
2023-02-11 16:04:43.161 DEBUG 464: [command] Calling command 'boiler/values'

Logs when sending the same selflowtemp:

2023-02-11 16:05:23.071 DEBUG 479: [command] Calling command 'boiler/selflowtemp' (selected flow temperature) with value 75
2023-02-11 16:05:23.122 DEBUG 480: [command] Calling command 'boiler/values'
2023-02-11 16:05:23.122 DEBUG 480: [command] Calling command 'boiler/values'
2023-02-11 16:05:33.202 DEBUG 481: [command] Calling command 'boiler/values'
2023-02-11 16:05:43.235 DEBUG 482: [command] Calling command 'boiler/values'
2023-02-11 16:05:50.121 DEBUG 483: [emsesp] Fetching values for deviceID 0x08

Note how there's no Sending write Tx in this case.

Device information

{
  "System Info": {
    "version": "3.5.0",
    "platform": "ESP32",
    "uptime": "000+00:30:22.192",
    "uptime (seconds)": 1822,
    "free mem": 120,
    "max alloc": 73,
    "free app": 6151,
    "reset reason": "Software reset CPU / Software reset CPU"
  },
  "Network Info": {
    "network": "WiFi",
    "hostname": "ems-esp",
    "RSSI": -57,
    "IPv4 address": "192.168.3.15/255.255.255.0",
    "IPv4 gateway": "192.168.3.1",
    "IPv4 nameserver": "192.168.3.1",
    "static ip config": false,
    "enable IPv6": false,
    "low bandwidth": false,
    "disable sleep": false,
    "enable MDNS": true,
    "enable CORS": false,
    "AP provision mode": "disconnected",
    "AP security": "wpa2",
    "AP ssid": "ems-esp"
  },
  "NTP Info": {
    "NTP status": "connected",
    "enabled": true,
    "server": "nl.pool.ntp.org",
    "tz label": "Europe/Amsterdam"
  },
  "OTA Info": {
    "enabled": false,
    "port": 8266
  },
  "MQTT Info": {
    "MQTT status": "disconnected",
    "enabled": false,
    "client id": "ems-esp",
    "keep alive": 60,
    "clean session": false,
    "entity format": 0,
    "base": "ems-esp",
    "discovery prefix": "homeassistant",
    "nested format": 1,
    "ha enabled": true,
    "mqtt qos": 0,
    "mqtt retain": false,
    "publish time heartbeat": 60,
    "publish time boiler": 10,
    "publish time thermostat": 10,
    "publish time solar": 10,
    "publish time mixer": 10,
    "publish time other": 10,
    "publish time sensor": 10,
    "publish single": false,
    "publish2command": false,
    "send response": false
  },
  "Syslog Info": {
    "enabled": false
  },
  "Sensor Info": {
    "temperature sensors": 0,
    "temperature sensor reads": 0,
    "temperature sensor fails": 0,
    "analog sensors": 0,
    "analog sensor reads": 0,
    "analog sensor fails": 0
  },
  "API Info": {
    "API calls": 212,
    "API fails": 1
  },
  "Bus Info": {
    "bus status": "connected",
    "bus protocol": "Buderus",
    "bus telegrams received (rx)": 870,
    "bus reads (tx)": 118,
    "bus writes (tx)": 12,
    "bus incomplete telegrams": 0,
    "bus reads failed": 0,
    "bus writes failed": 0,
    "bus rx line quality": 100,
    "bus tx line quality": 100
  },
  "Settings": {
    "board profile": "S32",
    "locale": "en",
    "tx mode": 1,
    "ems bus id": 11,
    "shower timer": false,
    "shower alert": false,
    "hide led": false,
    "notoken api": false,
    "readonly mode": false,
    "fahrenheit": false,
    "dallas parasite": false,
    "bool format": 1,
    "bool dashboard": 1,
    "enum format": 1,
    "analog enabled": true,
    "telnet enabled": true,
    "max web log buffer": 50,
    "web log buffer": 50
  },
  "Devices": [
    {
      "type": "boiler",
      "name": "Topline/GB162",
      "device id": "0x08",
      "product id": 115,
      "version": "03.06",
      "entities": 68,
      "handlers received": "0x10 0x11 0x15 0x1C 0x18 0x19 0x34",
      "handlers fetched": "0x14 0x16 0x33",
      "handlers pending": "0xBF 0xC2 0x1A 0x35 0x26 0x2A 0xD1 0xE3 0xE4 0xE5 0xE6 0xE9 0xEA"
    },
    {
      "type": "controller",
      "name": "BC10",
      "device id": "0x09",
      "product id": 114,
      "version": "01.03",
      "entities": 0
    }
  ]
}

[MichaelDvP]

Yes, some guys are flooding the tx queue with write commands, always the same value, and wonder why fetched values do not update (the writes have priority and ems-reads will never be executed). So we added a logic that write is skiped if the value is unchanged.

EMS-ESP32/src/devices/boiler.cpp

Line 1713 in f385854

// no write/verify if there is no change, see https://github.com/emsesp/EMS-ESP32/issues/654

[MichaelDvP]

I think we can add a logic to to write the value, but without verify read and put it to end of queue. Boiler line 1713 ff.
:

    // no verify if value is unchanged, put it  to end of tx-queue, no priority
    if (v == selFlowTemp_) {
        EMSESP::txservice_.add(Telegram::Operation::TX_WRITE, device_id(), EMS_TYPE_UBASetPoints, 0, (uint8_t *) &v, 1, 0, false);
        return true;
    }

[MichaelDvP]

Please try with: https://github.com/MichaelDvP/EMS-ESP32/releases/tag/latest

[tjvdmolen]

I have a similar issue with my boiler (Nefit Topline/GB162). Where consistently 5 minutes after sending a selflowtemp the temperature returns back to the default (7 deg C in my case). I tried a build from a tech-upgrade branch containing the fix from @MichaelDvP and it doesn't appear to fix my issue. In my case I am confident I am not spamming values.

[MichaelDvP]

You have to write selflowtemp periodical to avoid the setback. The fix was that writing the same value is possible to keepthe boiler at this value. For #951 we test a periodical send by emsesp for heating off, maxbe we can combine this. Something for the future.

[tjvdmolen]

You have to write selflowtemp periodical to avoid the setback. The fix was that writing the same value is possible to keepthe boiler at this value. For #951 we test a periodical send by emsesp for heating off, maxbe we can combine this. Something for the future.

I'll give this a try, and report back if that helps. Thanks for the assistance!

[MichaelDvP]

Writing the value every minute is what the thermostats do. So this is good interval to start with.

[tjvdmolen]

Writing the value every minute is what the thermostats do. So this is good interval to start with.

Seems like that fixed it. Fantastic, looks like I finally can get rid of my physical thermostat altogether. I appreciate your support!

And I can confirm that multiple writes within a short period of time, do persist the value now.