boiler.burnmaxpower min/max attributes are not correctly set for api

[tp1de]

For some heating systems boiler.burnmaxpower min/max is not properly set. E.g. min=0 / max = 0 and actual power is up to 100;
While creating the entities in ioBroker using API definitions like above, this gives a warning for actual values > max.

I would propose to set max to 100 within API field definition, if value otherwise would be 0.
(This could be done in Customizations, but starters with the gateway will complain about the errorlog in between and I need to explain)

[MichaelDvP]

Hmm, do you have an example? The min/max for percent values are set to 0-100% if not set explicid in initialization. This 0-100% affects burnminpower, for the burnmaxpower we have max 254% because some boilers are calibrated to 100% for heating and can power more for dhw.

EMS-ESP32/src/devices/boiler.cpp

Lines 202 to 215 in 1487f30

	register_device_value(DeviceValueTAG::TAG_DEVICE_DATA,
	&burnMinPower_,
	DeviceValueType::UINT,
	FL_(burnMinPower),
	DeviceValueUOM::PERCENT,
	MAKE_CF_CB(set_min_power));
	register_device_value(DeviceValueTAG::TAG_DEVICE_DATA,
	&burnMaxPower_,
	DeviceValueType::UINT,
	FL_(burnMaxPower),
	DeviceValueUOM::PERCENT,
	MAKE_CF_CB(set_max_power),
	0,
	254);

Also we adapt the min/max if the value is not in range, in HA this creates a update in HA-config, but i think the ioBroker-adapter reads the min/max on start and keep the init values.

EMS-ESP32/src/emsdevice.cpp

Lines 1712 to 1718 in 1487f30

	if (v < dv.min) {
	dv.min = v;
	dv.remove_state(DeviceValueState::DV_HA_CONFIG_CREATED);
	} else if (v > 0 && (uint32_t)v > dv.max) {
	dv.max = v;
	dv.remove_state(DeviceValueState::DV_HA_CONFIG_CREATED);
	}

[MichaelDvP]

Forgot that we also set the burner limits from the factory storage in telegram 0x04. But if both read zero, the default for percentage will reset to 0-100%. I can't find a way the values are both zero.

[mattreim]

The min(14) value was greater than the max(0) value. It appears after the initial setup(GB172i/BC400).

I have now set max to 100 and the error is gone.

[MichaelDvP]

I have now set max to 100 and the error is gone.

In ioBroker? Then it come back on next adapter restart if delete_states on start is set.
Or in ems-esp customization? Then it come back on next ems-esp restart. I've fixed that in my build, now custom setting is always priority.
Can you give me the output of read 8 4 in terminal? I think the strange values come from there.

[tp1de]

@MichaelDvP
Within ioBroker all entities (objects) are defined by reading API per entity on startup once - this includes min/max values.
Afterwards all values are polled. If an actual value is out of boundaries it produces a warning from ioBroker base system.
Same if Max is < Min when defining the object.
I told @mattreim to set the ems-esp customizations for boiler.burnmaxpower. This works.

[tp1de]

btw: I get 2 - 5 warnings per week that values are not within min/max range. This happens on km200 and ems-esp for different entities. I do not understand the reason.

I was considering to skip this values by changing the ioBroker adapter code. But I haven't done so far.

[MichaelDvP]

for different entities

I love these exact and reproducible error descriptions. Now i know where to search in code.

[tp1de]

I love these exact and reproducible error descriptions. Now i know where to search in code.

Since it happens for km200 and em-esp this should not be coding problem.
Telegram values seems to be corrupted sometimes. ioBroker base system produces a warning - Home Assistant not.
I just wanted to mention.

@MichaelDvP would you recommend to skip these values? I hesitate to implement, since with wrong Customizations this could create confusion, when values are not shown anymore.

[MichaelDvP]

For mqtt we adapt the min/max if the value is out of range, also HA-config is re-generated.
We can also adapt on api calls, but you'll need to refetch the min/max. Or you check in the adapter the range and adapt min/max if value is lower/higher.
We have only some values with limits documented in the manuals. Most values just have min/max of the used value range, eg. -127 to 1127 for INT, 0 to 254 for UINT, etc.

[tp1de]

Thanks for input. For the cases observed I can identify the polled values to be wrong. They are corrected anyhow within next poll.
I have never seen two successive polling cycles with these wrong values unless min/max is set wrongly. (burnmaxpower)
I rather prefer not to update min/max in these cases.
The warning from ioBroker base system indicates at least that manual adjustments within Customizations might be needed.
For the rest these are rare exceptions generated by telegram traffic errors.

[tp1de]

We have only some values with limits documented in the manuals. Most values just have min/max of the used value range, eg. -127 to 1127 for INT, 0 to 254 for UINT, etc.

The original km200 gateway has more boundaries then ems-esp. Some min/max values are changed when updating corresponding values. E.g. by changing the comforttemp for a heating circuit the max value for ecotemp is set 0.5 °C lower then the comfortemp value. The km200 will not accept then setting values outside these new boundaries and will return an error.

Temp Sensors have no min/max but next to the actual value two enum values for open / close circuits to identify sensor / cable defects. E.g. roomtemperature:

"native": {
"km200": {
"id": "/heatingCircuits/hc1/roomtemperature",
"type": "floatValue", "writeable": 0, "recordable": 1,
"value": 20.7, "unitOfMeasure": "C",
"state": [ { "open": -3276.8 }, { "short": 3276.7 } ],
"valIs": "value"
}, "ems_km200": "heatingCircuits.hc1.roomtemperature" },

[MichaelDvP]

I think KM200 reads these values from ems+ via the F9 telegram. I don't have a ems+ system but afaik the F9 gives min, max and default and some other settings for each value. Maybe you can check on your system.
<src><dest>F9<offset><ems><emsh><emsl><ofs><data....>
The telegram id <ems><emsh><emsl> is for an ems telegram like 0xE9: E9 00 00 and for ems+ like 2A5: FF 01 A5
How data is organized is unknown. <ofs> means the offset of the data in the original telegram.
If you like to request a F9:
<src><dest+0x80>F9<offset><length><ems><emsh><emsl><ofs>

We have issue #150 since a long time. For F7 we know now the <data> as one bit per byte to show the value in menu of RC300.

[tp1de]

ems-esp:$ watch f9
Watching incoming telegrams, displayed in decoded format
Filtering only telegrams that match a telegram type of 0xF9
001+04:27:05.414 N 62: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:05.472 N 63: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 69 08 4F 00 00 00 02 00 00 00 02 00 03 00 03 00 03 00 02
001+04:27:06.036 N 64: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:06.098 N 65: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 6A 08 4F 00 00 00 02 00 00 00 02 00 03 00 03 00 03 00 02
001+04:27:06.814 N 66: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:06.857 N 67: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 6B 08 4F 00 00 00 02 00 00 00 02 00 03 00 03 00 03 00 02
001+04:27:07.660 N 68: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:07.720 N 69: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 6C 08 4F 00 00 00 02 00 00 00 02 00 03 00 03 00 03 00 02
001+04:27:08.413 N 70: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:08.472 N 71: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 6D 08 4F 00 00 00 02 00 00 00 02 00 03 00 03 00 03 00 02
001+04:27:24.812 N 72: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:24.875 N 73: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 AF 08 0B 00 00 00 14 00 00 00 19 00 00 00 36 00 00 00 1E
001+04:27:25.612 N 74: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:25.678 N 75: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 9B 08 07 00 00 00 1E 00 00 00 4B 00 00 00 5A 00 00 00 36
001+04:27:26.188 N 76: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:26.245 N 77: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 9B 07 03 00 00 00 1E 00 00 00 30 00 00 00 3C 00 00 00 30
001+04:27:26.812 N 78: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:26.874 N 79: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 9B 00 4F 00 00 00 01 00 00 00 01 00 0B 00 07 00 0B 00 01
001+04:27:34.788 N 80: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:34.852 N 81: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 B0 08 0B 00 00 00 14 00 00 00 19 00 00 00 2D 00 00 00 19
001+04:27:35.540 N 82: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:35.600 N 83: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 9C 08 03 00 00 00 1E 00 00 00 4B 00 00 00 5A 00 00 00 4B
001+04:27:36.116 N 84: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:36.176 N 85: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 9C 07 07 00 00 00 1E 00 00 00 30 00 00 00 3C 00 00 00 2D
001+04:27:36.516 N 86: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:36.577 N 87: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 9C 00 4F 00 00 00 01 00 00 00 01 00 2B 00 07 00 2B 00 01
001+04:27:44.718 N 88: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:44.780 N 89: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 9D 08 03 00 00 00 1E 00 00 00 4B 00 00 00 5A 00 00 00 4B
001+04:27:45.341 N 90: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:45.406 N 91: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 9D 07 03 00 00 00 1E 00 00 00 30 00 00 00 3C 00 00 00 30
001+04:27:45.883 N 92: [emsesp] gateway(0x48) -R-> thermostat(0x10), ?(0xF9), length: 0x11
001+04:27:45.945 N 93: [emsesp] thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 9D 00 4B 00 00 00 01 00 00 00 01 00 0B 00 07 00 0B 00 01
ems-esp:$ watch off

[MichaelDvP]

Any idea where the min/max is? Let's take one of them:
thermostat(0x10) -W-> gateway(0x48), ?(0xF9), data: FF 01 9B 07 03 00 00 00 1E 00 00 00 30 00 00 00 3C 00 00 00 30
This means telegram 29B offset 7: hc1 maxflowtemp for floor heating, it's a scale 1 value, we don't know min and max
data: 03 00 00 00 1E 00 00 00 30 00 00 00 3C 00 00 00 30`
max could be one of the 30 (48°C) or the 3C (60°C), 1E (30°C) the min?

[tp1de]

hc1 are radiators and hc2 floor heating.
For both we have maxflowtemp and minflowtemp as control parameters in ems-esp. (not available in km200)
Actual settings for heating curve and installer documentation for RC310:

         minflowtemp    maxflowtemp    docu min      max

  hc1       30               54          20            85
  hc2       25               45          20            60

You believe that the corresponding min/max values are within F9? Why?

[MichaelDvP]

You believe that the corresponding min/max values are within F9? Why?

Yes, the F9 gives some extra info to each value, i don't know what else it could be. But the manuals are often wrong, better to check in the thermostat-UI what could be set. But i don't have ems+ and can't check.

[mattreim]

Here is the Terminal output of read 8 4:

002+05:51:20.912 N 5: [emsesp] boiler(0x08) -W-> Me(0x0B), UBAFactory(0x04), data: 4F 14 05 60 0F 0E 00 00 00 00 6B 00 00 00 00 20 00 00 00 0F 00 00 0E 64 64 00 0F
002+05:51:20.931 N 6: [emsesp] boiler(0x08) -W-> Me(0x0B), UBAFactory(0x04), data: 00 03 06 17 1B 20 52 0A 05 (offset 27)

[MichaelDvP]

I think this is fixed in the new 3.7.dev.

[tp1de]

@mattreim needs to check.

[mattreim]

It seems to be looking good.