MAX from ECO to AUTO does not take the week schedule

English Forums Devices
#1

Dear all,

I have a MAX! system with a MAX! Cube transformed to a CUL (due to lost configuration in the MAX! stock application). Let´s take a configuration with a Thermostat and a Wall Thermostat. Those are linked together correctly, as well as the week program is transferred correctly to both devices. Now, I have a schedule for which between 17.00 and 19.00 the system in AUTO-MODE shall stay at 17 degC. On all other times, the system shall bring 20.5 degC.
Assume everything is correctly configured, double checked via RPC. Assume the system is now in ECO-MODE with 15 degC. When changing to AUTO-MODE at 17.30 via switch (AUTO_MODE = ON), then the system is going to AUTO, however the temperature is on 20.5 and not 17 degC. During the next day at 17.00 the system goes to the right schedule at 17 degC.

Why is my system not going to the right schedule?

Thank you for any answer.

Bests.

#2

Hi.

If you set the thermostat to Auto-Mode, it will respect the schedule from the next setpoint on. It will not check the past for previous temperature levels or apply a temperature change directly.

#3

Thank you. My suspect is then right… Is there a “best-practice” for that? For instance replicating the weekly schedule on my automation system, then setting the temperature to the right schedule as soon as a change ECO to AUTO is detected?

Thank you again. I really appreciate :slight_smile:

#4

Think of the exact opposite. Create an AUTO-schedule which contains the usual heating, then apply changes via ECO or COMFORT mode. My automation sytem does not handle the regular stuff, just the special adjustments. Regular stuff is handle by the thermostat schedule.

#5

Is it only from ECO mode to AUTO?

I have a similar (identical?) setup to you. Max! valves and thermostats controlled through an ex-Cube reflashed as a CUN. What do you use to control Homegear?

I’ve just checked my thermostat on the wall next to me. It’s set to 20 degrees at the moment and I changed it to MANUAL mode and set the temperature to 16 deg. When I set it back to AUTO it went back to 20 deg not 14 which was its previous setting earlier in the day. It does the same thing whether I put it in AUTO mode on the device itself or by MQTT to Homegear.

I get the same behaviour if I put the device in ECO mode. If I set it back to AUTO it changes to the currently set temperature according to the schedule

Just out of curiosity how do you put your devices into ECO-MODE? On the device itself? I cannot find a way to put a device into ECO or COMFORT mode except by the buttons on the device. There doesn’t seem to be a command in Homegear.

It has just occurred to me… are you changing it to ECO mode when the temperature was 17 deg and then 17:00 comes around so it would have gone to 20 deg if it had been on AUTO and then you try to put it back to AUTO later. Does that make a difference?

#6

Hi Simon,

I also believe we have the same hardware/low level control setup… MAX! Wallthermostat, MAX! Thermostat Basic, flashed CUBE, some Window Sensors and a ECO Wall Switch.

What you describe is exactly my same problem when moving from ECO to AUTO. Instead from AUTO to ECO I get the right ECO temperature set.

Now, MAX! is quite difficult protocol and not so ‘automatic’ as it was sold by ELV some years ago.

Assumptions:

  • I’m using openHAB connected to Homegear which emulates a ‘homematic’ thing.
  • All interfaces shall be reachable via RPC or any other homegear API.
  • When you have a paired Wallthermostat and a Thermostat (valve), switching via homegear/openhab to any mode shall happen on both devices.
  • Switching via the devices is no problem, since those are synced automatically by the MAX! protocol.

Switching via other intelligent systems like openHAB shall be as following:

  1. I am in AUTO-MODE (both on thermostat and wallthermostat)
  2. I want to switch to ECO-MODE:
    –> Write the ECO Temperature stored in Channel 1:#ECO_TEMPERATURE of your Wallthermostat (or Thermostat, as you like) to Channel 1:#MANU_MODE of both devices

Viceversa, switching from any MODE to ECO is simpler:
–> Write 1 on Channel 1:#AUTO_MODE of both devices. The value of #AUTO_MODE is then brought to 0 by the devices themselves as acknowledge.

Same concept applies to COMFORT: write the COMFORT temperature to 1:#MANU-MODE

See here for homegear device documentation https://ref.homegear.eu/device.html?directory=MAX!&file=BC-TC-C-WM-4.xml&familyLink=max&name=BC-TC-C-WM-4#affixSubsection1_0

I’m not sure of the right homegear syntax to call those transitions… In openHAB this concept is enclosed in a rule.

Does it make sense?

However I’m getting more and more convinced that I need to leave the temperature schedule (so AUTO-MODE management) outside of the MAX! devices, as @job is suggesting. The schedule can be easily managed via, e.g., openHAB, by transitioning between COMFORT and ECO, thus no hassle in programming the devices, for which I still do not have a working scheduler GUI…right now I’m managing the schedule via text files, generating php script to feed Homegear which transfers with the 1% limitation to the devices… it’s just too much to be maintained for a very old yet powerful system :slight_smile:

#7

Hi

It’s a bit late at night now so I’ll try to add more tomorrow. Yes we have a similar setup. I use openHAB too but I do most of my rules programming with Node-Red see this thread on heating.

I use MQTT from Node Red to control Homegear schedules although I use Habpanel to visualise what’s going on and to change temperatures manually if I need to. I am working on a scheduler and so far I have used the JSONata functionality within Node Red (which is very powerful) to take a human readable schedule and turn it into the MQTT messages that the Max devices will understand.

I like the idea that the thermostats contain the schedule and so will continue to run if the CUN breaks down or OpenHAB goes offline or whatever but I want to be able to have a fine level of control including to be able to change the schedule to different profiles depending on whether I’m in or out or working at home or have guests for example but I don’t want to have to rewrite every time slot in every schedule for every room every time. I also have more complex schedules than you. Night time temperatures, 14 deg or so, are different from rooms during the day that are not being used right now say 17 deg but will be used later when they are brought up to 21 deg.

The plan is to have a GUI with a timeline interface but until then I’ll settle for having standard schedules that I can apply to some or all of a group of rooms based on drop downs.

Interestingly are you controlling homegear direct from openHAB using the binding? I noticed what seems to be a bug in the binding. If you have a string item linked to the Control Mode channel, changing that to MANU-MODE will indeed change the device to manual but changing it to AUTO-MODE does not set the mode back to AUTO even though it says it does. For me it sets the device to the comfort temperature. I don’t know why. I wondered if that is related to your problem.

#8

No, the opposite. I suggest using a basic schedule, just with general temperature changes, not every single detail which happens.

AUTO-MODE is ON all the time, just if something special happens AUTO is enhanced with ECO or COMFORT.

But i am using Homematic, not Max! so some details might differ. Although theses systems behave quite similar.

1 Like
#9

I’d agree with Job. Keep the schedules in the thermostats and build a control system to change the schedules for different purposes. For example:

  • guests over a weekend - you might need a new schedule with guest rooms / bathrooms / dining room coming on at different temperatures at different times. You don’t want to have to reprogram every affected room for two or three days and then reprogram them back again when your guests leave so you want a “guest” schedule you can just implement with one or two clicks

  • going out for half a day - you don’t need to change the schedule; just hit a button and a time picker in some UI to implement a PARTY-MODE temperature to let the house cool down and come back up to temperature before you come back. Or link it to GPS on your phone (page 2 of my list of priorities)

  • still watching a late night film - have openHAB detect that the lights and the TV are still on and keep implementing PARTY-MODE to keep parts of the house warm. Then catch up with the schedule when you go to bed.

But why build a scheduler in Node Red or openHAB when the thermostats have got one built in?

2 Likes
#10

Exactly. Heating must work even if all computers fail.

#11

Nothing destroys hard-earned WAF like the house getting cold!

2 Likes
#12

@job sorry, I understood you wrong. Why I’m getting convinced of the opposite? Because rewriting a Config to the Thermostats is a titanic thing for my CUBE and its 1% rule.
Actually, if I do manage one “standard” AUTO schedule on the MAX!, you’re really right in saying that all special adjustments can be done by a second automation system… no need to update the config on the thermostats --> you are enlightening me! Thank you!

@SimonB I need some time to read through your post and digest your setup.
In general I use the CONTROL_MODE only in reading.
For the transitions (say from my UI to MAX!) I have a proxy item which can trigger some rules (e.g., request boolean BOOST, request boolean AUTO, request Number SET_TEMPERATURE…).
Viceversa from MAX! to UI I just send some postUpdate around to reflect the MAX! status in the proxy item. -sorry, this was really openHAB- :slight_smile:

#13

Ah the 1% rule.

<Removed by @sathya>