new / missing entities worked out for AM200 (alternative heat source) module support.

[tglynx]

Hi, the fact that ems-esp32 supports the AM200 module now is really great! i have missed this feature in my KM100 gateway since our new heating system has been installed in 2021. So first of all thank you so much for putting so much effort already in supporting this module!

When looking at the RC310 display, one can see the following values in the 'Info' Menu for the 'Alternative HS':
(sorry, in german)

• Submenu for the Cylinder / Buffer <- we come to this later
• Flow temperature for the AHS <- we have this entity in ems-esp (altflowtemp)
• Brenner / Burner Flame on/off <- this entity is missing! <- This is ON when the system is requesting heat from the AHS
• Leistungsvorgabe / Burner set point <- this entity is missing! <- this is how much heat is requested in %
• Kesselsperre / Boiler blocking <- this entity is missing! <- this is ON then the primary heat source (boiler) is blocked

When scrolling down we also have

• Restl. Sperrzeit / Remaining blocking time -> this entity is missing! <- this is the remaining time of the blocking of the boiler
• Restl. Sperrzeit WW / Remaining blocking time WW -> this entity is missing! <- this is the remaining time of the blocking of the warmwater system

In the Pufferspeicher / Cylinder buffer Menu we have

• Puffersp.temo Oben -> cyltoptemp (we have this)
• Puffersp.temp. Mitte -> cylcentertemp (we have this)
• Puffersp.-Temp. unten -> cylbottomtemp (we have this)
• Pufferladepumpe / AHS pump ON/OFF -> we kinda have this with altpumpmod > 0

I think i have worked out most if not all of the missing entities an would propose that these be implemented :)

The AmStatus Message

From the source (AmStatus Message)

// 0x054E AM200 status (6 bytes long)
// Rx: 60 00 FF 00 04 4E 00 00 00 00 00 00 86
void Heatsource::process_amStatusMessage(std::shared_ptr<const Telegram> telegram) {
    has_update(telegram, aPumpMod_, 0); // PR1
    // offset 1: bitfield 01-pump on, 02-VR1 opening, 04-VR1 closing, 08-VB1 opening, 10-VB1 closing
    // uint8_t stat = aPump_ | setValveBuffer_ << 3 | setValveReturn_ << 1;
    // if (telegram->read_value(stat, 1)) {
    //     has_update(aPump_, stat & 0x01);
    //     has_update(valveBuffer_, (stat >> 3) & 0x03);
    //     has_update(valveReturn_, (stat >> 1) & 0x03);
    // }
    // actually we dont know the offset of VR2
    // has_update(telegram, valveBypass_, ?); // VR2
    has_update(telegram, valveReturn_, 4); // VR1, percent
    has_update(telegram, valveBuffer_, 5); // VB1, percent
}

What i found is that the Status for 'burner on/off' is the value 20 in the bitfield in offset 1
I would propose that this information is implemented as an entity called ahsburner (on/off)

As already documented in the comment of the source the value 01 in that bitfield is the ahspump (on/off) entity.

In offset 2 we have the 'Leistungsvorgabe' ahsheatrequest in % (not sure about the name).
00 is 0% and 64 is 100%

Here are some corresponding AmStatus Messages from the log

000+13:26:28.718 N 3: [emsesp] Heatsource(0x60) -B-> All(0x00), AmStatus(0x054E),   data: 00 00 00 04 32 32
002+15:41:43.430 N 28: [emsesp] Heatsource(0x60) -B-> All(0x00), AmStatus(0x054E),  data: 00 20 64 04 32 32
002+15:59:43.453 N 327: [emsesp] Heatsource(0x60) -B-> All(0x00), AmStatus(0x054E), data: 32 21 4C 04 32 32
002+16:25:43.751 N 547: [emsesp] Heatsource(0x60) -B-> All(0x00), AmStatus(0x054E), data: 32 21 00 04 32 32
002+16:32:43.999 N 599: [emsesp] Heatsource(0x60) -B-> All(0x00), AmStatus(0x054E), data: 32 01 00 04 32 32
002+16:35:44.124 N 619: [emsesp] Heatsource(0x60) -B-> All(0x00), AmStatus(0x054E), data: 32 01 00 04 32 32
002+16:52:44.847 N 19: [emsesp] Heatsource(0x60) -B-> All(0x00), AmStatus(0x054E),  data: 32 01 00 04 32 32
002+17:23:45.418 N 223: [emsesp] Heatsource(0x60) -B-> All(0x00), AmStatus(0x054E), data: 32 01 00 04 32 32
002+17:26:45.843 N 241: [emsesp] Heatsource(0x60) -B-> All(0x00), AmStatus(0x054E), data: 32 01 00 04 32 32
002+18:34:47.909 N 2: [emsesp] Heatsource(0x60) -B-> All(0x00), AmStatus(0x054E),   data: 32 01 00 04 32 32
002+18:44:48.182 N 68: [emsesp] Heatsource(0x60) -B-> All(0x00), AmStatus(0x054E),  data: 00 00 00 04 32 32
002+19:12:49.028 N 362: [emsesp] Heatsource(0x60) -B-> All(0x00), AmStatus(0x054E), data: 32 01 00 04 32 32

• I was watching the log and the RC310 and saw the heatrequest 'Brenner EIN' coming in at 002+15:41:43.430 with 100%
• I made a nice fire and the pump started running at 002+15:59:43.453 / heat request in % already going down
• 'Brenner AUS' and 'Leistungsvorgabe 0%' at 002+15:59:43.453 .. the fire still burning (pump running)

The AmExtra Message

From the source (AmExtra Message)

// 0x0550 AM200 broadcasted message, all 27 bytes unkown
// Rx: 60 00 FF 00 04 50 00 FF 00 FF FF 00 0D 00 01 00 00 00 00 01 03 01 00 03 00 2D 19 C8 02 94 00 4A
// Rx: 60 00 FF 19 04 50 00 FF FF 39
void Heatsource::process_amExtraMessage(std::shared_ptr<const Telegram> telegram) {
}

I watched the log again

003+11:24:13.161 N 480: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550), data: 00 06 0A FF 0A FF FF 32 01 32 C0 00 00 00 03 00 00 03 00 32 1B 58 02 62 3C
003+11:28:13.460 N 517: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550), data: 00 06 0A FF 0A FF FF 2F 01 32 9C 00 00 00 03 00 00 03 00 2F 1B 58 02 62 3C
003+19:14:26.081 N 3: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550),   data: 00 06 00 FF 0A FF FF 24 01 00 9C 00 00 00 03 00 00 03 00 24 17 D4 02 62 3C
003+19:18:26.406 N 30: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550),  data: 00 06 00 FF 0A FF FF 25 01 00 9C 00 00 00 03 00 00 03 00 25 17 D4 02 62 3C 
003+19:19:28.463 N 41: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550),  data: 00 06 00 FF 0A FF FF 25 01 00 64 00 00 00 03 00 00 03 00 50 17 D4 02 62 3B 
003+19:20:26.212 N 49: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550),  data: 00 06 00 FF 0A FF FF 25 01 00 64 00 00 00 03 00 00 03 00 50 17 D4 02 62 3A
003+19:21:25.812 N 56: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550),  data: 00 06 00 FF 0A FF FF 25 01 00 64 00 00 00 03 00 00 03 00 50 17 D4 02 62 39
003+19:22:26.612 N 64: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550),  data: 00 06 00 FF 0A FF FF 25 01 00 64 00 00 00 03 00 00 03 00 50 17 D4 02 62 38
003+19:23:25.762 N 72: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550),  data: 00 06 00 FF 0A FF FF 25 01 00 64 00 00 00 03 00 00 03 00 50 17 D4 02 62 37
003+19:24:26.712 N 81: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550),  data: 00 06 00 FF 0A FF FF 25 01 00 64 00 00 00 03 00 00 03 00 50 17 D4 02 62 36
003+19:25:26.437 N 88: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550),  data: 00 06 00 FF 0A FF FF 25 01 00 64 00 00 00 03 00 00 03 00 50 17 D4 02 62 35 
003+19:26:26.287 N 96: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550),  data: 00 06 00 FF 0A FF FF 25 01 00 64 00 00 00 03 00 00 03 00 50 17 D4 02 62 34
003+19:27:26.562 N 103: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550), data: 00 06 00 FF 0A FF FF 25 01 00 64 00 00 00 03 00 00 03 00 50 17 D4 02 62 33
...
003+19:32:28.336 N 144: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550), data: 00 06 00 FF 0A FF FF 24 01 00 1C 00 00 00 03 00 00 03 00 37 17 D4 02 62 2E
003+19:33:25.861 N 152: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550), data: 00 06 00 FF 0A FF FF 24 01 00 1C 00 00 00 03 00 00 03 00 37 17 D4 02 62 2D
003+19:33:25.861 N 152: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550), data: 00 06 00 FF 0A FF FF 24 01 00 1C 00 00 00 03 00 00 03 00 37 17 D4 02 62 2D
003+19:34:25.986 N 163: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550), data: 00 06 00 FF 0A FF FF 23 01 00 1C 00 00 00 03 00 00 03 00 37 17 D4 02 62 00 
003+19:36:26.360 N 177: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550), data: 00 06 00 FF 0A FF FF 23 01 00 1E 00 00 00 03 00 00 03 00 37 17 D4 02 62 00
003+19:38:25.835 N 189: [emsesp] Heatsource(0x60) -B-> All(0x00), AmExtra(0x0550), data: 00 06 00 FF 0A FF FF 23 01 00 1E 00 00 00 03 00 00 03 00 37 17 D4 02 62 00

In offset 24 (here at the end of the message)
3C = 60 Minutes ahsblockremaining (remaining blocking time) ... also > 0 would mean 'Kesselsperre' ahsblocking (on)
As a heatrequest came in from the WW system (in this case) we can see that the blocking time is decreasing every minute starting at 003+19:19:28.463 ...
00 = 0 Minutes ahsblockremaining = ahsblocking (off)

i also found that in offset 2 we have the ahspump (on/off) (same information as in the AmStatus offset 1 bitfield (value (01))
00 = pump off; 0A = pump on

and also offset 4 is the 'heatrequest' ahsburner (on/off) (same information as in the AmStatus offset 1 bitfield (value 20))
00 = burner off; 0A = burner on

Just as additional information
offset 9 is the pump modulation (same as offset 0 in AmStatus)
Also the values of offset 7, 10, 19, 20, 21 seem interesting but i have not had the time to compare them or investigate further.

[MichaelDvP]

To summerize:
apump: 0x54E, offset 1, bit 0, bool
burner: 0x54E, offset 1, bit 5, bool
heatRequest: 0x54E, offset 2, percent
blockRemain: 0x550, offset 24, minutes

We don't have a option to mix text(off)/number in the output of a value. If usefull we can add a bool value on/off with (blockRemain !=0) as extra entitiy. But we are short with memory, I would prefere to create such logical entities in HA/ioBroker, etc. and not in ems-esp.

Since we have the device "heatsource" with tag "ahs1" we can skip the prefixes (used in first boiler implementation).
Mqtt should use heatsource_data = {"ahs1": {"burner": "on"}} or heatsource_data_ahs1 = {"burner": "on"}, so no conflict with double names.
In Web the long names should also have a prefix, maybe skip the " alternative hs" in all names?
You could look at it and decide what is better readable.

I think we merge my current build to the official dev now and could test a bit forward backward with changed names in my repo.

[tglynx]

perfect!

We don't have a option to mix text(off)/number in the output of a value. If usefull we can add a bool value on/off with (blockRemain !=0) as extra entitiy. But we are short with memory, I would prefere to create such logical entities in HA/ioBroker, etc. and not in ems-esp.

i understand and that is fine - we just need blockRemain: 0x550, offset 24, minutes
maybe other messages reflect the blocking status (working on it) - i have not yet looked at the rest of the AmExtra message after offset 24 yet. i suppose we will find another blockRemaining there + maybe the boolean state as well...
I am not sure how i can 'create' different states fi blocking and WWblocking yet... so we will see...

this already will be really great now!

[tglynx]

i want to update my findings

apump: 0x54E, offset 1, bit 0, bool
burner: 0x54E, offset 1, bit 5, bool
heatRequest: 0x54E, offset 2, percent
blockRemain: 0x550, offset 24, minutes
blockRemainWW: 0x550, offset 25, minutes <- new

heatRequest might also be named burnerSetpoint ... up to you ...

[tglynx]

@MichaelDvP , i am currently running your build from yesterday (07.01.2023) and everything works nicely.

[proddy]

in dev-16