Alternative to MaxCube binding

1

I was quite sure that there was an external and alternative control software to replace MAX!Cube, which was able to do even more as with the CUL variant (incl. control algorithms). I thought that there was once also a Openhab Binding for it, but now I am unable to find it. Any ideas?

2

maxcul binding
There’s a wiki page for it. Also see this thread

3

Actionally, I did not mean the MAX! CUL Binding, there should be something else around that really replaces the control features of the MAX! Cube - it is a pitty that I do not remember the name - just I thought that once there was a OpenHAB binding available as well (should be a piece of external software). I am looking for something, where I can set the MANUAL temperature (according to https://github.com/openhab/openhab/wiki/MAX!-CUL-Binding there is no such feature there) and the MAX!Cube Binding has theses feature, but in a limited and unstable manner (https://github.com/openhab/openhab/issues/4369).
Any hints that this will work better in the OpenHAB2 binding (https://github.com/openhab/openhab2-addons/tree/master/addons/binding/org.openhab.binding.max)?

4

MAX!buddy maybe?
To the best of my knowledge, there’s no OH binding other than maxcul and maxcube.
Some patience, please. The maxcube binding author (@marcel_verpaalen , I believe) is quite responsive.

5

quickly cross-read your request … try setting VACATION mode instead of MANUAL.

6

OH2 version is hopefully much more stable. Major rework is done to improve the stability. e.g. network connectivity code has been replaced, the commands are now passed to a queue, than executed etc.

I have not received stability concerns for the OH2 one. As the re-write was quite extensive, I am/was hesitant to port the code back to the OH1 version.

7

btw. I’m on holidays now, but will try to reproduce your issue once back.
Would you mind trying if the same error occurs for OH2, as that may give a hint of what is happening.

8

No, MAX!buddy is not around since some time any more. It was something else, hopefully not just available in my dreams.
According to http://www.fhemwiki.de/wiki/MAX FHEM should support the temperature setting in MANUAL mode.
Does anybody know, if FHEM and OpenHAB can be operated in parallel in order to use the MANUAL setting feature of FHEM, while using the rest (e.g. temperature monitoring) still with OpenHAB (if, of course, the property maxcube:exclusive in the openhab.cfg is set to false)?
I have done something similar with to use the EnOcean protocol, since the OpenHAB EnOcean binding is really very limited (I have used the HTTP binding on OpenHAB side to send commands to FHEM and using the REST API of OpenHAB to receive notification from FHEM. However, I have not activated the EnOcean binding on OpenHAB, since there would be then a race condition between the two home automation systems regarding EnOcean events. The question is, if something similar would happen in case of the MAX!Cube binding.

9

MaxCul can set the manual temperature, if that’s the only thing you’re seeking to do.

10

Good to know, thanks for that hint. The only thing is that I do not have the Busware CUL Stick yet, which would be some unnecessary investment, if it would work with MAX!Cube too. Especially, if the MAX!Cube binding will be more stable in OpenHAB2 I may will wait for that…

11

Hi Marcel, thx for your answers. In order to avoid the queueing problem I send the commands in a slow sequence with corresponding timers that send a command only every second, e.g. (this particular code, lead to a freeze and further command are ignored from the Cube)

(MAX!WallThermostat is in AUTOMATIC)

rule SummerModeLivingRoom
	when
		Item SummerModeLivingRoom received command
	then
		var Timer setTimer
		var Timer manualTimer
		if (SummerModeLivingRoom.state == ON) 
		{
			logInfo("SummerModeLivingRoom", "Turn heating off")
			sendCommand(LivingWallThermostatMode, "MANUAL") // Tried it also without this first command to set the Thermostat in MANUAL
			setTimer = createTimer(now.plusSeconds(5)) [|
				sendCommand(LivingWallThermostatSetTemp, 4.5)										
			] // Thermostat is switching back to AUTOMATIC
			
			manualTimer = createTimer(now.plusSeconds(10)) [|
				sendCommand(LivingWallThermostatMode, "MANUAL")														
			]
		}
		else 
		{
			logInfo("SummerModeLivingRoom", "Turn heating on")
			sendCommand(LivingWallThermostatMode, "AUTOMATIC")
		}
end
12

Marcel, would be great if you could check with OH1 (see my code in my previous reply)!
If I will find some spare time, I will check OH2, since I am curious anyway, however, have no running version on my Raspberry yet. Hopefully OH2 will be stable soon (unfortunately, I am not joining EclipseCon France this year).

Have a nice holiday in between!

13

The issue with the OH1 code binding is that the sending of the commands can interfere easily with the receiving of messages fom the cube.
Anytime both sending and receiving are running at the same time there is either an error or worse (like you describe, hanging)