search

emsesp / EMS-ESP32

ESP32 firmware to read and control EMS and Heatronic compatible equipment such as boilers, thermostats, solar modules, and heat pumps
https://emsesp.github.io/docs
GNU Lesser General Public License v3.0
599 stars 101 forks source link

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

Closed tp1de closed 5 months ago

tp1de commented 5 months ago

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 commented 5 months ago

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. https://github.com/emsesp/EMS-ESP32/blob/1487f30c433e6fc87ecbba42c04f9f9ea483dd4f/src/devices/boiler.cpp#L202-L215 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. https://github.com/emsesp/EMS-ESP32/blob/1487f30c433e6fc87ecbba42c04f9f9ea483dd4f/src/emsdevice.cpp#L1712-L1718

MichaelDvP commented 5 months ago

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 commented 5 months ago

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

EMS-ESP-min_max

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

MichaelDvP commented 5 months ago

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 commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

for different entities

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

tp1de commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

tp1de commented 5 months ago

@mattreim needs to check.

mattreim commented 5 months ago

It seems to be looking good.

burnpower