How to change the content of time programs?

[krusta4711]

Hi,

I'm considering to change the heating on and off times of my CHA-7 dependent on room temperatures. I could do it easily by changing the heating program between "Permanent" and "Standby". But I'm in fear that in case of an error (e.g. connection lost) the CHA stays in the Standby forever.

Therefore I'm trying to find a less risky way. My idea is the live change of the time programs:

1. Set heating program to "Auto"
2. Set time program to 1 with 24h run time (00:00 to 23:59)
3. Change this one time program live dependent on the room temperatures:
   3.1. In case that at - let's say 15:00 o'clock - the room temperature gets to high, I want to change the time program 1 in that way, that it is set to "00:00 - 15:00" and "17:00 - 23:59"
   3.2. When now the temperature is too high again at 19:00, I want to change the same time program to "00:00 - 19:00" and "21:00 - 23:59".

So my plan is to overwrite the time program each time the CHA needs a break. In case of an error the worst thing that can happen is, that I ran into the single break each day.

My question:
Can somebody explain, how the time programs can be set with ism7mqtt? @alexkno79 seems to have some experience? I even do not know which values have to be changed. For days and times I only see the PTIDs starting from "330000". But as there are also dates I guess that these are for Party mode, not for the heating time program. There might be days and times also for DeviceTemplateId "360000" (e.g. PTID "320090"). These are not in my generated parameter.json and I have no clue which parameter represents what I need. Which start and end dates belongs to which day?

[alexkno79]

Well, times for the programs cannot be set. Zivilian was going to look into it.

I have a similar approach which I solve by using Urlaubsmodus and Partymodus. I have a rjme program running in the morning . So when temps ar are too high I start Urlaubsmodus to safely stop heating and ensuring it returns back to the usual time program for next morning. If during the day the temperature is to low I start Partymoduus for 2 hours. This way I ensure I will always be able to be in a safe state even if ism7mqtt cannot communicate for any reason

[krusta4711]

Thank @alexkno79 for the insides. :-) As the timer programs are not working yet, I will have a look into "Urlaubsmodus" and "Partymodus". I'm not sure whether they will help me, as the "Urlaubsmodus" only switches to "Sparbetrieb", not to "Standby", right?

As my CHA is oversized for my house I need real breaks. And as I do not have floor heating but only regular radiators, the temperature goes down very fast in my hydraulic system. So I guess that even in "Sparbetrieb" the pump would start very early to heat again. And as the pump is too big, the "Kessel" temperature will rise and it will get too warm again, even with a very low desired value. A bit contradictory, but it is what it is.

At present I work with the three time programs plus switching between Auto and Permanent. So I have four programs I can choose from. Some programs have longer Standby phases, some shorter. I switch them automatically via home assistant dependent on the outside temperature.

That works pretty well. But my inner play instinct likes to create the perfect solution with taking the room temperature into account. :-P It would be possible with Shelly relays which could have a fall back to "on" in case of an error case. But I do not want to have self installed hardware changes as long as I am in the warranty phase.

[alexkno79]

Yes, it starts Sparbetrieb. But as I set ECO/ABS to -8 it goes to standby unless it is really really cold.
But I am using floor heating which is very slow in heating and cooling so I usually can cope with slow reaction times on inside and outside temperature. In fact at present I do not switch automatically based on inside temps but receive from my script a warning that the thermostats are close to lower heating level and wolf is running or vice versa and then I start or stop the Partymoduus or Urlaubsmodus manually via related scripts

[krusta4711]

@alexkno79 Can you tell me which parameters are for Partymodus and which are for Urlaubsmodus? The namings are the same. I have twice a parameter set for end-time/end-date/start-time/start-date:

PTID 330000 to 330003 and
PTID 330006 to 330009

I guess the second set (starting with 330006) is for Urlaubsmodus as it is called ProgramType="Lowering" in the file sub-dialogs.xml?

[alexkno79]

Yes the higher ones are Urlaub the lower numbers Partymode

[krusta4711]

Thank you, @alexkno79 👍 The more I think about the idea, the more I like it. :-) It is even safer than changing the time programs, as the Urlaubsmodus contains a date and therefore is only executed once.

Question (I guess a few more will come ;-) ):
How do you handle the problem that Wolf is overwriting the values every minute? Example: in case I change the end time via home assistant at 13:37 from 16:37 to 16:40, the CHA excepts the value and is changing it correctly. But at 13:38 it overwrites my value with 16:38. Do I have to turn on the Urlaub mode first and set the times afterwards to avoid the risk that something is overwritten?

[alexkno79]

I am sending the time and flag in one JSON. This works usually. Only when applying also a future start time I run into this issue sometimes. In such case I found no solution yet but resubmitting the mqtt.

Here a sample of the mqtt I use

Wolf/192.168.178.xx/BM-2_0x35/set -m '{"Datum Ende":{"330007":"12\/28\/2024"},"Uhrzeit Ende":{"330006":"12:17"},"Urlaubsmodus":{"value":1}}'

[krusta4711]

Yes, I do have the HA flag activated. So I do have separate topics. The problem could also be related to the new HW/FW version of the ism module (FW 4.x). It already did behave differently in other areas (more strict in message structures, more problems with the connection).

[krusta4711]

As the "Urlaubsmodus" works I still have a little bit hope left and will play around a bit more. If that does not work I will have to set the values one by one, which is not as I would like to have it. But it is what it is.

[krusta4711]

I did more investigations and I think, that it even might be a problem in ism7mqtt itself (maybe in combination with the new ism module FW/HW version). As setting "Urlaubsmodus" with json works, I tried to set only the end time alone in a json (both, with and without underscore):

{
  "Uhrzeit Ende": {
    "330006": "16:49"
  }
}

This led to errors in the HA log:

I had a quick look in the code and the message "nothing to send for topic" seems to indicate that ism7mqtt does not find the property. A cross check with writing "Urlaubsmodus" wrong by purpose showed the same error log message.

My gut feeling said to me that it looks like the space vs. the underscore might be the problem. So I tested another value which includes a space/underscore and got the same error:

A cross check with another attribute ("Absenkstopp") showed, that JSON works fine in case there is no space/underscore included in the name. I would have to go deeper into the code to get to know whether it is the ism module which does not understand the space/underscore names or whether it is ism7mqtt which does not even try to send the data because it declares them as invalid.

As setting the attributes as single attribute (without json) works for all names, I tend to believe that the second case might be true.

I do not have enough time anymore today for deeper code analyzes and would have to debug. Maybe @zivillian has an idea?

[zivillian]

it is ism7mqtt which does not even try to send the data because it declares them as invalid

[zivillian]

@krusta4711 I checked it against the parameter.json you uploaded in #112 and the following json should work:

{"Uhrzeit Ende":{"330006":"16:49"}}

[krusta4711]

Thank you @zivillian

Unfortunately it does not work. You can see in my error log screenshot of my last comment, that the json is not excepted.

I do not need it for now as I found another solution by setting the values as single attribute without json.

But just for curiosity I will try to change the code to add underscores. But that might not be before spring.