First, thank you very much for providing this quite nice piece of software! Lets hope a community will build up around it, and you will continue to have the time for it!
Q1: What exactly does airing time mean?
Q2: What does the percentage mean to the right of the qube name?
Q3: Quite often I get a timeout, when trying to transmit heating schedules to the cube. One day might be transmitted and the next time I try the following day perhaps gets transmitted. Is there any reason for this timeout?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, for late response. I am busy preparing new version.
Airing time is the time when the window is open. Possibly, it is the time before the thermostat goes from the airing temperature to the eco temperature if a window is open.
It is the duty cycle. The cube's radio traffic is limited. When it sends some commands out, it spends some of the limit. When all is spent (100%) it stops sending further commands until the next hour. Commands using the traffic are setting the thermostat mode, the thermostat schedule, the valve parameters.
One reason is because of the traffic limit. Setting the schedule uses much of it. Another might be sleeping devices or malfunctioning ones. When the indicator is about 100%, wait for an hour and then try again. Note that the indicator is updated only when you actually send a command. When only polling the cube it does not report duty cycle information. In other words you cannot wait for 0%. If you send nothing the indicator will stay unchanged.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's okay with the late response, no hurry :)
Thanks for you responses, though, I still can't figure out to make airing time having any impact on my setup (Eq-3 Cube, valves, window sensors and thermostats).
I was hoping for some kind of delay after closing the window/door before temperature sets bach to schedule, but it does not seem to have any impact what so ever in my setup.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Follow up on Q3:
I have five simple rooms with a single radiator valve, a wall thermostat, and one or two window sensors. Transmitting schedules on these rooms works just fine.
My living room is a bit more complex, it has three radiator valves, one wall thermostat, and a single window sensor. Every time I try to transmit to either a single radiator valve, the wall thermostat or all radiator valves I get a timeout. When using the Eq-3 Max! application I have no problems transmitting my schedules. Could it be, that the timeout is a bit too tight for complex rooms?
Kind regards,-
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Usually timeout means that the cube does not respond the s-commands that sets the schedule. Setting schedule is two s-commands per weekday.
When the configuration of a thermostat in the cube is broken, it rejects any commands for the thermostat. This can be seen in the trace as well. In this state you cannot change the thermostat mode too. When the damage is serious the cube crashes and drops the connection. This is also visible in the trace. The last case will give a timeout, if we exclude software bug, which is another possibility.
For broken configuration I know no cure. So far, if cube power down and up does not help, the only working method is to remove the device and pair it back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There must be a second response which is missing. That is the reason for a timeout. Normally the cube always either confirms or rejects each command. The reason why it does not do this can be either connection loss or else internal problem in the cube. If the latter, then things are really bad. You should probably try to update the firmware, reset the cube etc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At 21:51:11 I get the timeout error popup message and the next trace event is 21:51:36 reading from the cube with 30 second interval.
Sometimes it correctly transfer one day of schedule, e.g., Monday, and then times out on tuesday. I've succesfully, one day at a time, transfered an entire week schedule for this room with three valves, a wall termostat and a window sensor, but it takes many tries. Again, using the original software there is no problems.
The software version is 1.4.6. It might be an internal cube issue. It's just a quite tedious task to reconfigure all rooms after a reset, including waiting for transfer windows.
Another newly arised issue, which suddenly occurs in all my rooms are the following:
1. Example: In a room with one wall thermostat, a radiator valve and a window sensor, the automatic schedule temperature is set to 21 degrees.
2. When the window is opened, the temperature is correctly lowered to 12 degrees.
3. When the window is closed, the temperature resumes to 21 degrees.
4. After a few minutes the temperature is automatically reduced on the radiator valve to 12 degrees (even though the window is still closed) and i stays this way, unless I manualle increase the temperature to 21 degrees. Then i stays at this temperature.
Havent figured out why this happens yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding the original software, it usually transfers only the first part of the schedule program, i.e. the first 7 points using single s-command. The schedule consists of 13 points, though. So the rest remains unset. I cannot tell what the effect this might have. MAX! home automation always overwrite the schedule program completely.
From what you describe with window contacts, it seems that you have a configuration problem. A thermostat must be linked to each window contact and each window contact must be linked to the thermostat back. Each linking action is one s-command. The commands are issued when you pair the device. If your cube has a tendency to ignore half of the s-commands, you can expect anything.
You could try to reset the cube and pair all devices new. The parameters of the thermostats are not influenced by pairing. The schedule program and other parameters are kept in the thermostat, not in the cube.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First of all, thank you for your time in helping me troubleshooting! :)
Yesterday I tried to remove all valves, thermostats, and sensors from the cube, performed a reset on the cube and repaired my setup.
Doing this i found out that one radiator valve, in my problem-room was faulty and could not be paired anymore. When this thermostat is not part of my system you application works quite well. It happens once in a while I still get a timeout but then I just re-apply the schedules and the following days gets send to the valves.
Concerning the window sensors and radiator valve issue, resetting temperatures back to window temperatures, it seems like the problem is solved too from the cube reset.
So thank you, and we all hope you will continue to have the time for working on this great application!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am working on the version 3.0 which would allow pairing devices. But it is very difficult because there is no information about how devices must be linked to each other. Any minor error makes thermostats stop responding.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, my window problem still exists, after having configured my rooms using your software.
Example:
Room min temperature: 10 degrees
Airing temperature: 12 degrees
Automatic temp: 21 degrees
After a window in a room has been opened and closed, the temperature returns to 21 degrees, but after a minute or two it drops to 10 degrees. This happens to all my rooms individually, but only after having configures temperatures and schedules using this software.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Found a fix for this. Using the original MAX! software (webpage), going to configure a room (gears icon), Temperatures, and sending some new default temperatures fixes seems to fix the problem.
I will try to make my valves fail again, so I can reproduce the problem and describe what makes them behave this odd way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Found a fix for this. Using the original MAX! software (webpage), going to configure a room (gears icon), Temperatures, and sending some new default temperatures fixes seems to fix the problem.
I will try to make my valves fail again, so I can reproduce the problem and describe what makes them behave this odd way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now it becomes clearer. I think this is a bug that has been already fixed.
The following happens. When you set the thermostat parameters, not the schedule program, but only the parameters like airing time. Some of these values land at wrong places.
You can see the effect of that on the thermostat settings page once you changed something. E.g. say, you changed the airing time and sent parameters to the cube. Then you restart the application and it will get these parameters new from the cube. Now on the page shows not what you set. That should have the effect you observed. When you change parameters using the official software, they are OK again.
I don't remember when I fixed that. It seems that not in the version you use. You can send me the screenshots so that I could verify it, though I am 70% sure it was fixed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bingo, I'm quite sure that is what happens to me and that has some weird consequences. I'm running the 2.18 version, available on the download page.
A screenshot is attached.
First, thank you very much for providing this quite nice piece of software! Lets hope a community will build up around it, and you will continue to have the time for it!
Q1: What exactly does airing time mean?
Q2: What does the percentage mean to the right of the qube name?
Q3: Quite often I get a timeout, when trying to transmit heating schedules to the cube. One day might be transmitted and the next time I try the following day perhaps gets transmitted. Is there any reason for this timeout?
Sorry, for late response. I am busy preparing new version.
It's okay with the late response, no hurry :)
Thanks for you responses, though, I still can't figure out to make airing time having any impact on my setup (Eq-3 Cube, valves, window sensors and thermostats).
I was hoping for some kind of delay after closing the window/door before temperature sets bach to schedule, but it does not seem to have any impact what so ever in my setup.
Follow up on Q3:
I have five simple rooms with a single radiator valve, a wall thermostat, and one or two window sensors. Transmitting schedules on these rooms works just fine.
My living room is a bit more complex, it has three radiator valves, one wall thermostat, and a single window sensor. Every time I try to transmit to either a single radiator valve, the wall thermostat or all radiator valves I get a timeout. When using the Eq-3 Max! application I have no problems transmitting my schedules. Could it be, that the timeout is a bit too tight for complex rooms?
Kind regards,-
I cannot tell without seeing the trace file.
Usually timeout means that the cube does not respond the s-commands that sets the schedule. Setting schedule is two s-commands per weekday.
When the configuration of a thermostat in the cube is broken, it rejects any commands for the thermostat. This can be seen in the trace as well. In this state you cannot change the thermostat mode too. When the damage is serious the cube crashes and drops the connection. This is also visible in the trace. The last case will give a timeout, if we exclude software bug, which is another possibility.
For broken configuration I know no cure. So far, if cube power down and up does not help, the only working method is to remove the device and pair it back.
Hi again, here is a stack trace for when trying to transmit the schedule, if it can help you or me :)
You see here:
The first s-command, the first half of day schedule program sent to the cube
The second s-command, the second half of day schedule program sent to the cube
The response from the cube, the second parameter 0 means success
There must be a second response which is missing. That is the reason for a timeout. Normally the cube always either confirms or rejects each command. The reason why it does not do this can be either connection loss or else internal problem in the cube. If the latter, then things are really bad. You should probably try to update the firmware, reset the cube etc
Humm, more really seems to come. Here is a second try:
At 21:51:11 I get the timeout error popup message and the next trace event is 21:51:36 reading from the cube with 30 second interval.
Sometimes it correctly transfer one day of schedule, e.g., Monday, and then times out on tuesday. I've succesfully, one day at a time, transfered an entire week schedule for this room with three valves, a wall termostat and a window sensor, but it takes many tries. Again, using the original software there is no problems.
The software version is 1.4.6. It might be an internal cube issue. It's just a quite tedious task to reconfigure all rooms after a reset, including waiting for transfer windows.
Another newly arised issue, which suddenly occurs in all my rooms are the following:
1. Example: In a room with one wall thermostat, a radiator valve and a window sensor, the automatic schedule temperature is set to 21 degrees.
2. When the window is opened, the temperature is correctly lowered to 12 degrees.
3. When the window is closed, the temperature resumes to 21 degrees.
4. After a few minutes the temperature is automatically reduced on the radiator valve to 12 degrees (even though the window is still closed) and i stays this way, unless I manualle increase the temperature to 21 degrees. Then i stays at this temperature.
Havent figured out why this happens yet.
You have still one S-response to two s-command.
Regarding the original software, it usually transfers only the first part of the schedule program, i.e. the first 7 points using single s-command. The schedule consists of 13 points, though. So the rest remains unset. I cannot tell what the effect this might have. MAX! home automation always overwrite the schedule program completely.
From what you describe with window contacts, it seems that you have a configuration problem. A thermostat must be linked to each window contact and each window contact must be linked to the thermostat back. Each linking action is one s-command. The commands are issued when you pair the device. If your cube has a tendency to ignore half of the s-commands, you can expect anything.
You could try to reset the cube and pair all devices new. The parameters of the thermostats are not influenced by pairing. The schedule program and other parameters are kept in the thermostat, not in the cube.
Hi again,
First of all, thank you for your time in helping me troubleshooting! :)
Yesterday I tried to remove all valves, thermostats, and sensors from the cube, performed a reset on the cube and repaired my setup.
Doing this i found out that one radiator valve, in my problem-room was faulty and could not be paired anymore. When this thermostat is not part of my system you application works quite well. It happens once in a while I still get a timeout but then I just re-apply the schedules and the following days gets send to the valves.
Concerning the window sensors and radiator valve issue, resetting temperatures back to window temperatures, it seems like the problem is solved too from the cube reset.
So thank you, and we all hope you will continue to have the time for working on this great application!
I am working on the version 3.0 which would allow pairing devices. But it is very difficult because there is no information about how devices must be linked to each other. Any minor error makes thermostats stop responding.
Great, looking forward to trying it.
Unfortunately, my window problem still exists, after having configured my rooms using your software.
Example:
Room min temperature: 10 degrees
Airing temperature: 12 degrees
Automatic temp: 21 degrees
After a window in a room has been opened and closed, the temperature returns to 21 degrees, but after a minute or two it drops to 10 degrees. This happens to all my rooms individually, but only after having configures temperatures and schedules using this software.
Found a fix for this. Using the original MAX! software (webpage), going to configure a room (gears icon), Temperatures, and sending some new default temperatures fixes seems to fix the problem.
I will try to make my valves fail again, so I can reproduce the problem and describe what makes them behave this odd way.
Found a fix for this. Using the original MAX! software (webpage), going to configure a room (gears icon), Temperatures, and sending some new default temperatures fixes seems to fix the problem.
I will try to make my valves fail again, so I can reproduce the problem and describe what makes them behave this odd way.
Now it becomes clearer. I think this is a bug that has been already fixed.
The following happens. When you set the thermostat parameters, not the schedule program, but only the parameters like airing time. Some of these values land at wrong places.
You can see the effect of that on the thermostat settings page once you changed something. E.g. say, you changed the airing time and sent parameters to the cube. Then you restart the application and it will get these parameters new from the cube. Now on the page shows not what you set. That should have the effect you observed. When you change parameters using the official software, they are OK again.
I don't remember when I fixed that. It seems that not in the version you use. You can send me the screenshots so that I could verify it, though I am 70% sure it was fixed.
Bingo, I'm quite sure that is what happens to me and that has some weird consequences. I'm running the 2.18 version, available on the download page.
A screenshot is attached.
Thanks, but in order to verify if that problem was already fixed in the incoming version, I need more:
Then I could compare it with what the new version does.