ahs / am200: web-api needs corrections

[tp1de]

I got a GH issue in respect to my ioBroker adapter (tp1de/ioBroker.ems-esp#12) opened by @tglynx.
The ioBroker Adapter is polling ems-esp by using web-api calls.
I could find the following issues which need corrections:

1. the http://ems-esp/api/system command returns two times the device boiler. One for the boiler and one for the alternative heat source ahs. Device name should be unique either "boiler" and "boiler2" or even better using device name "ahs" for an am200 device
2. an http://ems-esp/api/boiler returns the "ahs" as a substructure within json - I adjusted my ioBroker to get values. Better to get the ahs values by polling http://ems-esp/api/ahs
3. Reading single ahs values e.g. http://ems-esp/api/boiler/ahs/altflowtemp do return an error: { "message": "cannot find values for entity 'ahs/altflowtemp'" }. So single field attributes can't be read.

From my point of view I recommend to adjust.

[MichaelDvP]

Please ask the user to participate here and post the system info.
We can setup a own device-class ahs, but need someone with this device to test and give feedback.
Or only fix the prefix ahs/ in point 3?

[tglynx]

Hi,

i am here and ready to test and give feedback.

I think it would be the right way to implement a separate device class for the am200 module - as for mixers (MM100 and so on) or solar modules (SM100...).
However, it is a heat source module ... the alternative heat source module can be used to directly control a pellet stove with target temperature (or just a simple wood stove) and has the ability to block the primary heat source for a given time.

As i can see the implementation that has been done already also happened on user request and i really appreciate all the work you put into this. Great project!

[MichaelDvP]

Yes, it's better to create a own device class. The boiler have a lot of entities making problems with buffer sizes.
I'll call the class heatsource and move the am200.
For now we know only the AM200 with device-id 0x60, i'll add it unnested. If more modules are possible we will need to rename with tag HS1...
The AM200 can be used as single boiler, pos 9/10. I think then it will use devcie_id 8 as a boiler and other telegrams. We have to check if someone uses this.

Boilers connected to a cascade module will still go to boiler class with tag HS1.., there are only a few values and the boilers keep there product-id, only changes device-id to 70...

I'll make a pr. @proddy please check if you agree that this is the right way.

[proddy]

@MichaelDvP yes, good to split off into its separate device class. Let me know how I can help

[MichaelDvP]

@tglynx Please check https://github.com/MichaelDvP/EMS-ESP32/releases

[tp1de]

@MichaelDvP what will be the device name within device-list of http://ems-esp/api/system ? Is it "heatsource" ?
What about single field api calls?

[tglynx]

Hi,

installed that firmware and it is working!

From the log:

2022-12-29 13:13:20.989 D 123: [emsesp] Adding new device Alternative Heatsource (deviceID 0x60, productID 228, version 03.02)
2022-12-29 13:13:20.989 I 126: [emsesp] Recognized new heatsource with deviceID 0x60

I can also confirm that the web API now returns details for the entities of the heatsource.

http://ems-esp/api/heatsource/altflowtemp

{
  "name": "altflowtemp",
  "fullname": "alternative hs flow temperature",
  "value": 66.9,
  "type": "number",
  "uom": "°C",
  "readable": true,
  "writeable": false,
  "visible": true
}

So i would say it looks good ...

@tp1de
It also comes over very nicely in the ioBroker Adapter (in native and km200 structure mode).

In KM200 mode my personal preference would be that the AM200 values would come up as hs2 under heatSources.

Here is what http://ems-esp/api/system returns

{
  "System Info": {
    "version": "3.5.0-dev.14",
    "platform": "ESP32",
    "uptime": "000+00:15:40.323",
    "uptime (seconds)": 940,
    "free mem": 98,
    "max alloc": 38,
    "free app": 5,
    "reset reason": "Software reset CPU / Software reset CPU"
  },
  "Network Info": {
    "network": "Ethernet",
    "hostname": "ems-esp",
    "MAC": "94:B5:55:FF:DF:D7",
    "IPv4 address": "192.168.123.146/255.255.255.0",
    "IPv4 gateway": "192.168.123.254",
    "IPv4 nameserver": "192.168.123.254",
    "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": "time.google.com",
    "tz label": "Europe/Berlin"
  },
  "OTA Info": {
    "enabled": true,
    "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": false,
    "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": 328,
    "API fails": 9
  },
  "Bus Info": {
    "bus status": "connected",
    "bus protocol": "Buderus",
    "bus telegrams received (rx)": 4196,
    "bus reads (tx)": 474,
    "bus writes (tx)": 0,
    "bus incomplete telegrams": 0,
    "bus reads failed": 12,
    "bus writes failed": 0,
    "bus rx line quality": 100,
    "bus tx line quality": 98
  },
  "Settings": {
    "board profile": "E32",
    "locale": "en",
    "tx mode": 2,
    "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": 5,
    "enum format": 1,
    "analog enabled": true,
    "telnet enabled": true,
    "web log buffer": 50
  },
  "Devices": [
    {
      "type": "Boiler",
      "name": "Logamax Plus/GB192/Condens GC9000/Greenstar ErP",
      "device id": "0x08",
      "product id": 208,
      "version": "01.04",
      "entities": 73,
      "handlers received": "0x10 0x11 0x15 0x1C 0x18 0x19 0x34 0x2A",
      "handlers fetched": "0x14 0x16 0x33 0x26",
      "handlers pending": "0xBF 0xC2 0x1A 0x35 0xD1 0xE3 0xE4 0xE5 0xE6 0xE9 0xEA"
    },
    {
      "type": "Thermostat",
      "name": "RC300/RC310/Moduline 3000/1010H/CW400/Sense II/HPC410",
      "device id": "0x10",
      "product id": 158,
      "version": "74.03",
      "entities": 79,
      "handlers received": "0x06 0xA2 0x02BB 0x02BC 0x02BD 0x02BE 0x02BF 0x02C0 0x031D 0x0267",
      "handlers fetched": "0x02A5 0x02B9 0x02AF 0x029B 0x02A6 0x02BA 0x02B0 0x029C 0x02CE 0x02F5 0x031B 0x023A 0x0240",
      "handlers pending": "0xA3 0x12 0x13 0x0471 0x0472 0x02A7 0x02B1 0x029D 0x0473 0x02A8 0x02B2 0x029E 0x0474 0x02A9 0x02B3 0x029F 0x0475 0x02AA 0x02B4 0x02A0 0x0476 0x02AB 0x02B5 0x02A1 0x0477 0x02AC 0x02B6 0x02A2 0x0478 0x02CC 0x02D0 0x02D2 0x031E 0xBB",
      "handlers ignored": "0x0292 0xF9 0x02E1 0x02E2 0x02EB 0x02EC 0x35 0x0291 0xBF"
    },
    {
      "type": "Thermostat",
      "name": "RC100/Moduline 1000/1010",
      "device id": "0x39",
      "product id": 165,
      "version": "12.03",
      "entities": 0,
      "handlers pending": "0x042B 0x047B 0x0273",
      "handlers ignored": "0x02BA 0x0292 0x042C 0x029C 0xF7"
    },
    {
      "type": "Mixer",
      "name": "MM100",
      "device id": "0x20",
      "product id": 160,
      "version": "24.05",
      "entities": 4,
      "handlers received": "0x02D7",
      "handlers ignored": "0x1E 0x1A 0x0255 0xBF"
    },
    {
      "type": "Mixer",
      "name": "MM100",
      "device id": "0x21",
      "product id": 160,
      "version": "24.05",
      "entities": 4,
      "handlers received": "0x02D8",
      "handlers ignored": "0x1A 0x0255 0xBF"
    },
    {
      "type": "Solar",
      "name": "SM100/MS100",
      "device id": "0x30",
      "product id": 163,
      "version": "27.07",
      "entities": 36,
      "handlers received": "0x0362 0x0363 0x0366 0x0364 0x036A",
      "handlers fetched": "0x0358 0x035A 0x0380 0x038E 0x0391",
      "handlers pending": "0x035D 0x035F 0x035C 0x0361",
      "handlers ignored": "0x0368 0x03A9 0x03AA 0x35 0xBF"
    },
    {
      "type": "Gateway",
      "name": "KM200/MB LAN 2",
      "device id": "0x48",
      "product id": 189,
      "version": "04.08",
      "entities": 0
    },
    {
      "type": "Controller",
      "name": "9000i",
      "device id": "0x09",
      "product id": 224,
      "version": "35.06",
      "entities": 0,
      "handlers ignored": "0x1A"
    },
    {
      "type": "Controller",
      "name": "BC30",
      "device id": "0x16",
      "product id": 220,
      "version": "01.05",
      "entities": 0
    },
    {
      "type": "Heatsource",
      "name": "Alternative Heatsource",
      "device id": "0x60",
      "product id": 228,
      "version": "03.02",
      "entities": 23,
      "handlers received": "0x054D 0x054E 0x0550",
      "handlers fetched": "0x054C",
      "handlers pending": "0x054F",
      "handlers ignored": "0xBF"
    }
  ]
}

For the EMS-ESP Dashboard / Devices & Sensors i would suggest that the Heatsource also gets the 'Boiler' icon and that it be named 'AM200 Alternative Heatsource'.

What else can we check? I think not all entities are identified already, is that correct?

Great work! Thanks...

[tp1de]

@tglynx
Hi Michael I have changed the ioBroker adapter so that the "heatsource" is translated to "heatSources/hs2" while using km200 structure mode. (as before). It's on GH to be tested.

[tglynx]

@tp1de
Hi Thomas, can confirm that this is working!

[MichaelDvP]

For the EMS-ESP Dashboard / Devices & Sensors i would suggest that the Heatsource also gets the 'Boiler' icon and that it be named 'AM200 Alternative Heatsource'.

Ok, but i shorten the name to "AM200", all devices are nemd only RC300, i700, etc. the extrawas only because it wassorted as boiler but isn't one.

I've looked at #573, where we added the AM200. @OlliHein, please also check the changes in https://github.com/MichaelDvP/EMS-ESP32/releases If you are using homeassistant there will be the entiies changed. Sorry, but the class change can't be done without HA changings.

@tp1de If using a cascade module the boiler will have nests with boiler/hs1/ .. boiler/hs16/, make sure that will not conflict.

[tp1de]

If using a cascade module the boiler will have nests with boiler/hs1/ .. boiler/hs16/, make sure that will not conflict.

good point @MichaelDvP ... I was already thinking about it. How can I identify the nested boilers and how many there are?
If there are nested boilers, will there be then more tham one device entry boiler in the device-list? If yes, wouldn't it be better to give unique names ... e.g. boiler1 ... n ?

Or might it be easier to name the ahs module just "hsa?". @tglynx what about "hsa" instead of fixed "hs2"?

[tglynx]

Or might it be easier to name the ahs module just "hsa?". @tglynx what about "hsa" instead of fixed "hs2"?

sure, i think it is just a matter of preference as the original KM100/KM200 gateways do not support the AM200 module.

[MichaelDvP]

How can I identify the nested boilers and how many there are?

Mainly the Cascade MC400 is a single boiler to the bus with all entities. The bus supports only one boiler. For the connected boilers there is a new ems-bus for each and the MC400 is thermostat for these busses. Only a few telegrams are forwarded in a kind of NAT (network translation), mapping the real boilers to device-id 0x70, 0x71, ...

Example: We have in database:

{208, DeviceType::BOILER, "Logamax Plus/GB192/Condens GC9000/Greenstar ErP", DeviceFlags::EMS_DEVICE_FLAG_NONE},
{210, DeviceType::BOILER, "Cascade MC400", DeviceFlags::EMS_DEVICE_FLAG_NONE},

and someone connects one MC400 and four GB192/20kW
Now the MC400 is one boiler with 80kW and depending on heat demand it starts one/two/tree/four GB192 boilers.
In web and system info the boilers show up seperatly, Boiler MC400 with device-id 0x08, Boiler GB192 with device-id 0x70, etc.
For the bus we have now in /api/boiler or mqtt boiler:

{
 "curflowtemp": 70.3,
 "selflowtemp": 52,
 "outdoortemp": 8.4,
 "boiltemp": 70.8,
 "wwsettemp": 48,
 "wwseltemp": 48,
 "wwtype": 3,
 .. all other boiler values...,
 "hs1": {
   "curflowtemp": 70.3,
   "selflowtemp": 52,
   "curburnpower": 50,
   "selburnpower":50,
   "burnworkmin": 12345
 },
 "hs2": {
   "curflowtemp": 0,
   "selflowtemp": 0,
   "curburnpower": 0,
   "selburnpower":0,
   "burnworkmin": 12000
 }
 "hs3": {
   "curflowtemp": 0,
   "selflowtemp": 0,
   "curburnpower": 0,
   "selburnpower":0,
   "burnworkmin": 11001
 }
 "hs4": {
   "curflowtemp": 0,
   "selflowtemp": 0,
   "curburnpower": 0,
   "selburnpower":0,
   "burnworkmin": 205
 }
}

The hs1..hs4 give only these 5 stati and can not be written directly, it's just info. All commands go to MC400.
The MC400 can be cascaded to support 16 heatingsources.

[MichaelDvP]

@proddy Is this way ok?
We can also move the few entities of hs1..hs16 to heatsource class. But then we should also make a ahs-nest/tag for the alternative heatsource. We can do this every time, but the tag will change the HA entities, so better decide now.
Unclear is, if there are more than one ahs possible (id 0x60, 0x61...). Use tag ahs1 to reduce futur changes?
@tglynx What would you prefere?

[tp1de]

@MichaelDvP
How would it look like on hybrid heating systems with gas boiler, heat pump and hm200 hybrid interface device?

[proddy]

@MichaelDvP I'll go with whatever you think is the right way forward is. I haven't looked at your new code yet, but is the heatsource data being pulled into the boiler_data MQTT topic too?

[tp1de]

Just to mention:
A RC310 thermostat controlled heating system can support:

• an alternative heatsource (or more?) with am200
• a hybrid system with hm200
• a (cascaded) boiler
• a solar system for dhw
• an air ventilation system
• 2 dhw systems (dhw1 and dhw2) with or without mixer
• up to 4 heating circuits with or without mixer
• and a km200/km100/IP-inside internet gateway (where I believe that the recordings -energy / temp history - are calculated and stored)

Such a system with multiple / hybrid heat sources will have global (system-wide) fields/values as well as entries per heat source.
As far as I can see multiple dhw are not supported yet by ems-esp. The mixers are then linked to dhw or hc.

[MichaelDvP]

but is the heatsource data being pulled into the boiler_data MQTT topic too?

That's the point, for mqtt we can go to single topics boiler_data_hs1 ,etc. but api/boiler/info grows.

I think it's better to move. Mixers also have only tagged entities, than we have heatsources always tagged with ahs1, hs1, hs2, etc. I'll stick to ahs1, so we can more if there are any.

@tp1de The hybrid system HM200 is listed as heatpump. Mixers could control hc1-8 or wwc 1-10, Poolmodule (PM100) or zonemodule MZ100. For RC300 some known dhw2 entities are already mapped, but nobody seems to use or miss it, so we don't know the telegrams/offsets.

[tp1de]

@MichaelDvP I wonder if I understand correctly:

Heatsources are boilers, alternative heatsources (am200), heat pumps with or without hybrid manager (hm200):
Will then be boilers and am200 within boilers and heatpumps and hm200 within heatpumps? - Even if all are heatsources and am200 not boilers?

... or in other words:
If there are already separate devices for boilers and heatpumps than I would recommend to make am200 a separate device class ahs as discussed before and not to include within boilers.

[proddy]

I do like the generic term "heatsource". The word 'boiler' was back when I created the first version of this project in 2017. If we're going to do any massive renaming, now is time. And I like big disruptive changes because it's fun and annoying!

[MichaelDvP]

@tglynx Please check my latest build and show us the system info, and check api returns and commands.

@proddy I'll do a PR so you check the code. Wait for confirmation or change requests before merging.

[tglynx]

Installed latest build.

api/system:

{
  "System Info": {
    "version": "3.5.0-dev.15",
    "platform": "ESP32",
    "uptime": "000+00:06:03.856",
    "uptime (seconds)": 363,
    "free mem": 107,
    "max alloc": 48,
    "free app": 27,
    "reset reason": "Software reset CPU / Software reset CPU"
  },
  "Network Info": {
    "network": "Ethernet",
    "hostname": "ems-esp",
    "MAC": "94:B5:55:FF:DF:D7",
    "IPv4 address": "192.168.123.146/255.255.255.0",
    "IPv4 gateway": "192.168.123.254",
    "IPv4 nameserver": "192.168.123.254",
    "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": "time.google.com",
    "tz label": "Europe/Berlin"
  },
  "OTA Info": {
    "enabled": true,
    "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": false,
    "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": 254,
    "API fails": 23
  },
  "Bus Info": {
    "bus status": "connected",
    "bus protocol": "Buderus",
    "bus telegrams received (rx)": 1730,
    "bus reads (tx)": 209,
    "bus writes (tx)": 0,
    "bus incomplete telegrams": 0,
    "bus reads failed": 17,
    "bus writes failed": 0,
    "bus rx line quality": 100,
    "bus tx line quality": 93
  },
  "Settings": {
    "board profile": "E32",
    "locale": "en",
    "tx mode": 2,
    "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": 5,
    "enum format": 1,
    "analog enabled": true,
    "telnet enabled": true,
    "max web log buffer": 50,
    "web log buffer": 45
  },
  "Devices": [
    {
      "type": "Boiler",
      "name": "Logamax Plus/GB192/Condens GC9000/Greenstar ErP",
      "device id": "0x08",
      "product id": 208,
      "version": "01.04",
      "entities": 73,
      "handlers received": "0x11 0x15 0x1C 0x18 0x19 0x34 0x2A",
      "handlers fetched": "0x14 0x16 0x33 0x26",
      "handlers pending": "0xBF 0x10 0xC2 0x1A 0x35 0xD1 0xE3 0xE4 0xE5 0xE6 0xE9 0xEA"
    },
    {
      "type": "Thermostat",
      "name": "RC300/RC310/Moduline 3000/1010H/CW400/Sense II/HPC410",
      "device id": "0x10",
      "product id": 158,
      "version": "74.03",
      "entities": 79,
      "handlers received": "0x06 0xA2 0x02BB 0x02BC 0x02BD 0x02BE 0x02BF 0x02C0 0x031D 0x0267",
      "handlers fetched": "0x02A5 0x02B9 0x02AF 0x029B 0x02A6 0x02BA 0x02B0 0x029C 0x02CE 0x02F5 0x031B 0x023A 0x0240",
      "handlers pending": "0xA3 0x12 0x13 0x0471 0x0472 0x02A7 0x02B1 0x029D 0x0473 0x02A8 0x02B2 0x029E 0x0474 0x02A9 0x02B3 0x029F 0x0475 0x02AA 0x02B4 0x02A0 0x0476 0x02AB 0x02B5 0x02A1 0x0477 0x02AC 0x02B6 0x02A2 0x0478 0x02CC 0x02D0 0x02D2 0x031E 0xBB",
      "handlers ignored": "0x0292 0xF9 0x02E1 0x02E2 0x02EB 0x02EC 0x35 0x0291 0xBF"
    },
    {
      "type": "Thermostat",
      "name": "RC100/Moduline 1000/1010",
      "device id": "0x39",
      "product id": 165,
      "version": "12.03",
      "entities": 0,
      "handlers pending": "0x042B 0x047B 0x0273",
      "handlers ignored": "0x042C 0x02BA 0x029C 0x0292 0xF7"
    },
    {
      "type": "Mixer",
      "name": "MM100",
      "device id": "0x20",
      "product id": 160,
      "version": "24.05",
      "entities": 4,
      "handlers received": "0x02D7",
      "handlers ignored": "0x1E 0xBF 0x1A 0x0255"
    },
    {
      "type": "Mixer",
      "name": "MM100",
      "device id": "0x21",
      "product id": 160,
      "version": "24.05",
      "entities": 4,
      "handlers received": "0x02D8",
      "handlers ignored": "0x1A 0x0255 0xBF"
    },
    {
      "type": "Solar",
      "name": "SM100/MS100",
      "device id": "0x30",
      "product id": 163,
      "version": "27.07",
      "entities": 36,
      "handlers received": "0x0362 0x0363 0x0366 0x0364 0x036A",
      "handlers fetched": "0x0358 0x035A 0x0380 0x038E 0x0391",
      "handlers pending": "0x035D 0x035F 0x035C 0x0361",
      "handlers ignored": "0xBF 0x35 0x0368 0x03A9 0x03AA"
    },
    {
      "type": "Gateway",
      "name": "KM200/MB LAN 2",
      "device id": "0x48",
      "product id": 189,
      "version": "04.08",
      "entities": 0
    },
    {
      "type": "Controller",
      "name": "BC30",
      "device id": "0x16",
      "product id": 220,
      "version": "01.05",
      "entities": 0
    },
    {
      "type": "Controller",
      "name": "9000i",
      "device id": "0x09",
      "product id": 224,
      "version": "35.06",
      "entities": 0,
      "handlers ignored": "0x1A"
    },
    {
      "type": "Heatsource",
      "name": "AM200",
      "device id": "0x60",
      "product id": 228,
      "version": "03.02",
      "entities": 23,
      "handlers received": "0x054D 0x054E 0x0550",
      "handlers fetched": "0x054C",
      "handlers pending": "0x054F",
      "handlers ignored": "0xBF"
    }
  ]
}

api/heatsource:

{
  "ahs1": {
    "altflowtemp": 21.5,
    "cyltoptemp": 54.9,
    "cylcentertemp": 52.6,
    "cylbottomtemp": 26.9,
    "valvebuffer": 50,
    "valvereturn": 50,
    "altpumpmod": 0,
    "vr2config": "bypass",
    "ahsactivated": "off",
    "apumpconfig": "on",
    "apumpsignal": "off",
    "apumpmin": 50,
    "temprise": "off",
    "setreturntemp": 60,
    "mixruntime": 120,
    "setflowtemp": 70,
    "bufbypass": "no",
    "bufmixruntime": 120,
    "bufconfig": "monovalent",
    "blockmode": "blocking",
    "blockterm": "n_o",
    "blockhyst": 5,
    "releasewait": 60
  }
}

api/heatsource/ahs1:

{
  "message": "cannot find values for entity 'ahs1'"
}

from the logs (querying the API with the ioBroker Adapter):

2022-12-31 18:07:31.662   ERROR 25:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/altflowtemp' (Error)
2022-12-31 18:07:31.680   ERROR 26:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/cyltoptemp' (Error)
2022-12-31 18:07:31.680   ERROR 27:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/cylcentertemp' (Error)
2022-12-31 18:07:31.680   ERROR 28:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/cylbottomtemp' (Error)
2022-12-31 18:07:31.680   ERROR 29:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/valvebuffer' (Error)
2022-12-31 18:07:31.680   ERROR 30:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/valvereturn' (Error)
2022-12-31 18:07:31.680   ERROR 31:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/altpumpmod' (Error)
2022-12-31 18:07:31.680   ERROR 32:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/vr2config' (Error)
2022-12-31 18:07:31.801   ERROR 33:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/ahsactivated' (Error)
2022-12-31 18:07:31.801   ERROR 34:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/apumpconfig' (Error)
2022-12-31 18:07:31.801   ERROR 35:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/apumpsignal' (Error)
2022-12-31 18:07:31.801   ERROR 36:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/apumpmin' (Error)
2022-12-31 18:07:31.801   ERROR 37:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/temprise' (Error)
2022-12-31 18:07:31.801   ERROR 38:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/setreturntemp' (Error)
2022-12-31 18:07:31.801   ERROR 39:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/mixruntime' (Error)
2022-12-31 18:07:31.801   ERROR 40:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/setflowtemp' (Error)
2022-12-31 18:07:31.801   ERROR 41:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/bufbypass' (Error)
2022-12-31 18:07:31.801   ERROR 42:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/bufmixruntime' (Error)
2022-12-31 18:07:31.801   ERROR 43:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/bufconfig' (Error)
2022-12-31 18:07:31.801   ERROR 44:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/blockmode' (Error)
2022-12-31 18:07:31.801   ERROR 45:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/blockterm' (Error)
2022-12-31 18:07:31.801   ERROR 46:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/blockhyst' (Error)
2022-12-31 18:07:31.801   ERROR 47:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1/releasewait' (Error)
2022-12-31 18:12:53.065   ERROR 48:     [emsesp]     Call failed with error: cannot find values for entity 'ahs1' (Error)

i like the approach with ahs1 as this does not conflict with hs1...hs2...

And I like big disruptive changes because it's fun and annoying!

Yes ... at the same time :)

[MichaelDvP]

api/heatsource/ahs1:

try again.

[tglynx]

/api/heatsource returns

{
  "ahs1": {
    "altflowtemp": 69.0,
    "cyltoptemp": 55.7,
    "cylcentertemp": 59.3,
    "cylbottomtemp": 54.0,
    "valvebuffer": 50,
    "valvereturn": 50,
    "altpumpmod": 50,
    "vr2config": "bypass",
    "ahsactivated": "off",
    "apumpconfig": "on",
    "apumpsignal": "off",
    "apumpmin": 50,
    "temprise": "off",
    "setreturntemp": 60,
    "mixruntime": 120,
    "setflowtemp": 70,
    "bufbypass": "no",
    "bufmixruntime": 120,
    "bufconfig": "monovalent",
    "blockmode": "blocking",
    "blockterm": "n_o",
    "blockhyst": 5,
    "releasewait": 60
  }
}

/api/heatsource/ahs1 returns

{
  "altflowtemp": 69.3,
  "cyltoptemp": 55.7,
  "cylcentertemp": 59.3,
  "cylbottomtemp": 54.0,
  "valvebuffer": 50,
  "valvereturn": 50,
  "altpumpmod": 50,
  "vr2config": "bypass",
  "ahsactivated": "off",
  "apumpconfig": "on",
  "apumpsignal": "off",
  "apumpmin": 50,
  "temprise": "off",
  "setreturntemp": 60,
  "mixruntime": 120,
  "setflowtemp": 70,
  "bufbypass": "no",
  "bufmixruntime": 120,
  "bufconfig": "monovalent",
  "blockmode": "blocking",
  "blockterm": "n_o",
  "blockhyst": 5,
  "releasewait": 60
}

/api/heatsource/ahs1/altflowtemp (as an example) returns

{
  "name": "altflowtemp",
  "fullname": "ahs1 alternative hs flow temperature",
  "circuit": "ahs1",
  "value": 69.8,
  "type": "number",
  "uom": "°C",
  "readable": true,
  "writeable": false,
  "visible": true
}

looks good for the ems-esp part i would say...
No errors in log when walking the API with the ioBroker adapter.

@tp1de will need to adjust the ioBroker adapter to support the heatsource structure in ioBroker now
Let me know if input is needed here ...

From my point of view it would be heatsource/ahs1/...entities... in native ems-esp mode and heatSources/ahs1/...entities... in KM200 mode.

[proddy]

@tp1de can you check this again against the latest dev build and either comment or close it. thanks

[tp1de]

can you check this again against the latest dev build and either comment or close it. thanks

Everything works from my point of view ... I adjusted my ioBroker adapter to new version as well.

[Snypes88]

Hello everyone, not sure if this is the right place to comment, but I also have an AM200 in my heating system and use a flue gas sensor on TF1 to measure the exhaust gas temperatures from my wood stove with a water jacket. My plan is when the temperatures fall below a certain value I trigger a notification through HA and know to throw some wood back on the fireplace without having to check every 30 mins XD. I do not see the flue gas temperature reading in the EMS ESP dashboard but do on my RC310. Anyone have the same behavior/use case?

[tglynx]

Hi, i am almost sure the exaust gas temperature is not yet implemented.

You should really create a new issue for this (enhancement).

As a preparation, could you please post a photo of this information on the RC310 (as i do not have that sensor / to get an idea where the RC310 displays that info)... also please do a telnet session to the ems-esp and type 'watch 60' ... let the output run for a while when having a fire burning.

i assume the value will be in the amTemperatures message ...
Here is what has been found in that message already:

// 0x054D AM200 temperatures
// Rx: 60 00 FF 00 04 4D 0103 0108 8000 00C6 0127 0205 8000 0200 0000 8000 6C
//                        TB4  TR2       TA1  TR1  TB1  TB2* TB3

If possible send some amTemperatures messages along with the temperature that is displayed on the RC310 at the same time the message has been received.

Michael

[Snypes88]

Hi Michael, thanks for the super quick response!

I have attached a picture, however, the PT1000 isn't yet connected to the exhaust pipe, hence the low temperature reading as I'm still experimenting :) Tomorrow I should get around to installing the sensor in the exhaust and will add the telnet output when the fire is burning and I am picking up a feasible temperature reading from the sensor. So far when I run watch 60 I get the following from telnet

000+01:41:44.832 N 8: [emsesp] heatsource(0x60) -B-> All(0x00), AmTemperatures(0x054D), data: 80 00 80 00 80 00 02 BB 02 6E 02 6C 80 00 02 44 00 00 80 00 01

would a screenshot from my EMS ESP dashboard also help?

[tglynx]

okay, nice... you could already experiment with your current config by warming the PT1000 with your hands and see if you can identify the changing values in the AmTemperatures message (still assuming it is in that message) ... i also do not have a return temperature sensor but that value is implemented as far as i can see (so you can see AHS return temp in the dashboard, right)?

what would also be helpflull ... please copy some AmTemperature messages for later analysis. It should be easy to identify if you have much larger values after tomorrow...

[Snypes88]

Yea, a lot of Temperature readouts are actually already supported in the dashboard which is really great! It seems I'm quite lucky that support was recently added and so much dev work has been taking place to better the AM200 support 👌 I was experimenting with a heat gun and running upstairs to the RC310 controller and then back down to the AM200 in the basement and it is definitely picking up and spitting out feasible information! And seeing as it at least works in the EMS+ I will wait till my temperature resistant PT1000 arrives tomorrow and I get around to properly installing the sensor to the exhaust pipe to ping telnet.

I also already created an enhancement here #906 as per your recommendation, so if you prefer to continue the conversation there I'm game 🙌