Data structure for heat demand calculation is not activated

[neopholus]

Describe the bug
When I edit, e.g., the weight of the room "Wohnzimmer" in the instance configuration page "Heat Demand", the data point ems-esp.0.controls.hc1.Wohnzimmer.weight should be updated accordingly. But it is not.

** Releated to gateway(s) and/or adapter configuration B Which version of the ems-esp adapter are you using? 2.6.3

Expected behavior
When I add the configuration page of the adapter instance, the configuration should reflect these changes as soon as possible. It would be great, if changes to the objects would also trigger changes of the configuration. Then, e.g. the weights could be adapted dynamically to the situation, e.g., differnt weights during day and during night.

[tp1de]

When I edit, e.g., the weight of the room "Wohnzimmer" in the instance configuration page "Heat Demand", the data point ems-esp.0.controls.hc1.Wohnzimmer.weight should be updated accordingly. But it is not.

I do not understand. It's updated in my installation - it just takes a couple of minutes after restart of the instance. First all datafields are re-initialized which takes some time for km200 (3-6 minutes).

[tp1de]

It would be great, if changes to the objects would also trigger changes of the configuration.

That is possible to implement - but values will be changed on adapter re-start. This might cause to irritations for most users. Or shall this values be saved in the config? I hesitate to implement to save the changes in instance config. But why do you want to change the weigth in the night. The thermostat should have a lower taget temp during night. Why is this not enough?

[neopholus]

When I edit, e.g., the weight of the room "Wohnzimmer" in the instance configuration page "Heat Demand", the data point ems-esp.0.controls.hc1.Wohnzimmer.weight should be updated accordingly. But it is not.

I do not understand. It's updated in my installation - it just takes a couple of minutes after restart of the instance. First all datafields are re-initialized which takes some time for km200 (3-6 minutes).

Thanks for the clarification. I will re-test on my system and wait longer.

Update: thanks, works after some time.

[neopholus]

It would be great, if changes to the objects would also trigger changes of the configuration.

That is possible to implement - but values will be changed on adapter re-start. This might cause to irritations for most users. Or shall this values be saved in the config? I hesitate to implement to save the changes in instance config. But why do you want to change the weigth in the night. The thermostat should have a lower taget temp during night. Why is this not enough?

My idea was to use this for e.g. my office. During the day, 1°C diff should trigger heat demand. Rest of the time, 2°C should trigger heat demand to keep the room warm but as usually nobody is there, a larger difference would be ok to reduce number of burner starts.

Might be an edge case. For me it would be ok, to only use the datapoints for the calculation and not sync them into the configuration. I could handle the re-start issue within my script.

If you do not not consider that an useful change request I would propose to set the data points to read only. As write is enabled, I thought that this type of modification is supported ;-)

[tp1de]

I was changing heat demand function anyhow. The hysteresis between switch on and off per thermostat was changed now:

• Switch on when settemp - delta <= actual temp
• Switch off when actual temp > settemp (was actual temp >= settemp - delta before)

I changed heat demand function to read the object values (delta & weight) for thermostats and (weighton / weightoff) for heating circuits. These objects are kept writable - the others are read only now.

Additionally I moved log entries for heat demand switch on / off and state changes to debug mode.

You can test this version by installing from Github - adapter version is still not changed. Please give some feedback.

[tp1de]

Have you tested the GH version?

[neopholus]

Thank you for the update! Was not at home end of the week. Installed it on Friday and tested it during the weekend.

Results:

• It is not required to delete the object tree for the changes in the read/write access to kick in -- great
• After changing e.g. ems-esp.0.controls.hc1.Wohnzimmer.weight, I expected the internal head demand calculation to be triggered, but that is not the case. ems-esp.0.controls.hc1.Wohnzimmer.actualweight was not updated for more than 15 minutes. And, thus, also ems-esp.0.controls.hc1.status was not updated. What exactly triggers a re-calculation?
• New hysteresis: I think there is an error (or typo). You wrote:
  • Switch on when settemp - delta <= actual temp
  • Switch off when actual temp > settemp
    • Transforming the terms:
  • Switch on when actual temp >= settemp - delta
  • Switch off when actual temp > settemp (which is also >= settemp - delta (iff delta > 0)).
    • Shouldn't it be something like:
  • Switch on when actual temp <= settemp - delta
  • Switch off when settemp < actual temp
  • Do nothing between settemp - delta and settemp
  • OR
  • Switch on when actual temp <= settemp
  • Switch off when actual temp > settemp + delta
  • Do nothing between settemp and settemp + delta

Best regards Stefan

[tp1de]

• After changing e.g. ems-esp.0.controls.hc1.Wohnzimmer.weight, I expected the internal head demand calculation to be triggered, but that is not the case. ems-esp.0.controls.hc1.Wohnzimmer.actualweight was not updated for more than 15 minutes. And, thus, also ems-esp.0.controls.hc1.status was not updated. What exactly triggers a re-calculation?

There is no re-calculation when changing the weight. The new weight is only used when a new heat demand is found. But I need to check again.

*** update: I changed the code so that any weight changes are updated into actualweight as well (every minute during poll) You can test by installing from Github - latest 3.0 alpha version

[tp1de]

Shouldn't it be something like:

• Switch on when actual temp <= settemp - delta
• Switch off when settemp < actual temp
• Do nothing between settemp - delta and settemp

Yes you are right .... that's what I implemented ..... and hopefully it works like this. I changed the readme text accordingly to avoid misunderstandings.

[neopholus]

• After changing e.g. ems-esp.0.controls.hc1.Wohnzimmer.weight, I expected the internal head demand calculation to be triggered, but that is not the case. ems-esp.0.controls.hc1.Wohnzimmer.actualweight was not updated for more than 15 minutes. And, thus, also ems-esp.0.controls.hc1.status was not updated. What exactly triggers a re-calculation?

There is no re-calculation when changing the weight. The new weight is only used when a new heat demand is found. But I need to check again.

*** update: I changed the code so that any weight changes are updated into actualweight as well (every minute during poll) You can test by installing from Github - latest 3.0 alpha version

Hi,

I installed 3.0.1 from Github, thanks for the Update.

Regarding your post: Sorry, I don't understand fully what you mean by "when a new heat demand is found".

For me heat demand (= true/false) is the result of the calculation. Thus, I think, that a re-calculation of the heat-demand-flag should be triggered, when:

• when one of the temperatures in the rooms changes, i.e. the temperature in one of the rooms (in your configuration tab the data points configured for "actual temperature")
• when any configuration is changed (e.g. the data point used as actual temp for a room, the minimum delta, the hc, or the weight.

Thanks for clarification, Stefan

[tp1de]

Sorry, I don't understand fully what you mean by "when a new heat demand is found".

The heat demand calculation is done every minute and not triggered by temp or parameter changes. A new heat demand is found when actualtemp < settemp - delta. Then the weight from the datapoint is used and not the one from config. This weight is kept unchanged until there is no heat demand anymore.

Any other logic would require a new heat demand processing logic. I think for other users - and me as well - a constant weight is good enough.

[neopholus]

Thanks for the explanation, now I got it. That is good enough for my use case as well.

[neopholus]

Solved, thanks a lot, Thomas!