Python plugin: ELV/EQ-3 MAX!

[maks87]

For some reason, my graphs look different from yours (see below)! They are nice and straight, even though the values are only updated when they change value. No idea why you have this smoothing effect. Which version of Domoticz do you use?

My Domoticz is V4.9700.

I use the latest beta, not sure but this COULD explain the difference.
Can others maybe report on how their thermostat graphs look, sharp or smoothed, and what their version number is?

Hello again
I confirm that problem was with stable version. Now I installed the latest beta and charts is the same as yours.

[mvzut]

OK, so in fact I need to buy a thermostat+boiler, with either direct compatibility in domoticz, or with openthermgateway.
I guess I should be looking for a "dumb" thermostat, since I'll be "fooling" the thermostat anyway by altering the setpoint through domoticz. I won't need any of the "smart" functions of a NEST or similar thermostats (self-learning, geofencing,...).
Anyone has any ideas on which thermostat would work with modulating boilers, but is cheap and dumb?

Usually they offer packages with a thermostat included when you buy a new boiler. This is often a relatively basic thermostat, so in this way you don't pay too much. In my case, there was a special offer where the thermostat (Remeha iSense) was included for free with my Remeha Calenta boiler. From the OTGW website, I knew this thermostat was known to work, which made it an easy choice for me.

[waltervl]

Just saying thanks to mvzut for creating this plugin!!
I am running 7 radiator thermostats now since 2 weeks. The only thing I would like to be added in the plugin is the more frequent update of the measured temperatures.
I now programmed the dzVents script below for doing this. The lua script did not work for me. Also I set the time between the mode switch of 3 minutes (the same as the inventors of this scan function proposed in LINK. Also made this script run every 30 minutes. As I understand communication is very limited I set switch every 30 minutes. It is doing the trick for me, see screenshot.

I am running stable Domoticz. I see only flowing lines in the graphs when the time between measurements is larger dan several hours.

Temperature update script:

Code: Select all

return {
	on = {
		-- timer riggers
		timer = {
			-- timer triggers.. if one matches with the current time then the script is executed
			'every 30 minutes',
		},
	},
	execute = function(domoticz, timer)
	    -- domoticz.log('Maxcube The rule that triggered the event was: ' .. timer.trigger')
		local myValves = {58, 60, 62, 64, 66, 68, 70}
		domoticz.log('Maxcube -- Time based event update RadTherms to switch mode')
          for n, Valve in pairs(myValves) do
            local ThModeSetting = domoticz.devices(Valve).level
            if ThModeSetting == 0 then tempsetting = 10 else tempsetting = 0 end
            domoticz.devices(Valve).switchSelector(tempsetting)
            domoticz.devices(Valve).switchSelector(ThModeSetting).afterMin(3)
          end
	end
}

screenshot_temp.JPG (18.25 KiB) Viewed 3287 times

[DarkG]

The Cube will crash when you connect too often.

[waltervl]

The Cube will crash when you connect too often.

But what is too often?
I read people have it switch off every day by switching off power to the Cube. So it resets and keep on running. Is that still necessary?
I have an old fashioned clock switch lying around somewhere (just moved .. so I will have to dig in some boxes )

[mvzut]

The Cube will crash when you connect too often.

But what is too often?
I read people have it switch off every day by switching off power to the Cube. So it resets and keep on running. Is that still necessary?
I have an old fashioned clock switch lying around somewhere (just moved .. so I will have to dig in some boxes )

I restart it once a week, before I did that, my Cube would "forget" all its setting every few weeks or months.

I poll my Cube every 5 minutes (plus of course when I change a thermostat setpoint). In combination with my weekly reset, this seems to work fine. I don't think polling a couple of times extra per hour (for the temperature logging trick) should be a problem.

By the way, if you intend to use an old fashioned clock switch, be aware that they can normally only be set to switch per quarter of an hour or so (at least the analog ones). So that means your Cube will be "dead" for 15 minutes per day... If you have the opportunity to use a 433 MHz/Zigbee/Z-Wave/WiFi switch, I would always use that, since you are much more flexible that way.

[mvzut]

Just saying thanks to mvzut for creating this plugin!!
I am running 7 radiator thermostats now since 2 weeks. The only thing I would like to be added in the plugin is the more frequent update of the measured temperatures.

You're welcome.

The mode switching seems to work with the timings you suggest, the graph indeed looks nice! I will look into a way to implement this in the plugin. However, I will need to remove another setting if we want to make it an optional feature. Moreover, I still believe it is bit of an "ugly" solution: Your thermostat mode logs will be flooded with mode switches, and it might also drain the batteries faster.

[waltervl]

Thanks, I use ZigBee (ZiGate), I will check one out probably IKEA Tradfri switch.

[janvangent2]

The Cube will crash when you connect too often.

But what is too often?
I read people have it switch off every day by switching off power to the Cube. So it resets and keep on running. Is that still necessary?
I have an old fashioned clock switch lying around somewhere (just moved .. so I will have to dig in some boxes )

I restart it once a week, before I did that, my Cube would "forget" all its setting every few weeks or months.

I poll my Cube every 5 minutes (plus of course when I change a thermostat setpoint). In combination with my weekly reset, this seems to work fine. I don't think polling a couple of times extra per hour (for the temperature logging trick) should be a problem.

By the way, if you intend to use an old fashioned clock switch, be aware that they can normally only be set to switch per quarter of an hour or so (at least the analog ones). So that means your Cube will be "dead" for 15 minutes per day... If you have the opportunity to use a 433 MHz/Zigbee/Z-Wave/WiFi switch, I would always use that, since you are much more flexible that way.

I have been running the plugin for a couple of months now, without resetting the cube. So I don't think it's required for this plugin anymore.

[acefx]

Hi !
I began using the plugin and would like to thank you for your work.
I was working with the Openhab Binding Max!cube

They figure out the implementation of many cool feature:
- Reboot cube function
Could program a cube reboot automaticaly....

- Duty cycle remaining ( in %) so the user / plugin know if he can send some orders This channel indicates the duty cycle (due to regelatory reasons the cube is allowed only to send for a limited time. Duty cycle indicates how much of the available time is consumed )

- Free memory of the cube (This channel indicates the free available memory on the cube to hold send commands.)
I think the cube hold in memory all the command that has not been sent due to duty cycle consumed.

Maybe i could resolve the " setting lost " problems that occurs when both dutycycle & free memory are saturated

Also the best feature EVER could be to integrate the MAX!CUL device.
MAX!CUL device is a firmware modded MAX!cube with a unlimited duty cycle. also it's compatible with some other 868 protocols.

Here's the openhab binding GIT , maybe you could peek an eye to see how they manage to get the reboot/dutycycle/free memory and integrate it in the plugin

Cheers

[acefx]

Hi again,
Digging a bit further in the MAX!cube protocol
https://github.com/Bouni/max-cube-protocol


shows :
------------------------------
the duty cycle command
-----------------------------

Code: Select all

The S Message
The incoming 'S' message response looks like this:

S:00,0,31
This can be decoded as following

Description        Length      Example Value
=====================================================================
Duty Cycle          2           00 
Command Result      1           0
Free Memory Slots   2           31
Duty Cycle
868MHz radio comms is limited to 1% transmission, i.e. 36 seconds in each hour. The cube monitors this, and returns the hex representation of the permitted duty cycle as a percentage. When this percentage reaches 100% it will queue S commands in memory or reject additional commands.

Command Result
0:	command processed
1:	command discarded

[mvzut]

I know that the protocol was reverse engineered to go beyond simple command sending and retrieving device status. However, I am using an existing Python API (https://github.com/hackercowboy/python-maxcube-api) for my plugin. I believe the functions you mention are not implemented there. Adding them to the Python API myself, i.e. interpreting the raw code, is slightly above my programming skills I'm afraid. If somebody is willing to help there: very welcome! It would indeed be nice if we could reduce the chance of Cube resets by obeying its rules for communication better. Although I do not get a whole lot of complaints about this, so I don't know how big this problem really is.

[Gonetolunch]

Since tonight this MAX! Plugin works no more. Instead, I regularly receive only these error messages:

Code: Select all

2019-07-22 08:58:17.694 Error: (MAX1) 'onHeartbeat' failed 'TypeError':'unsupported operand type(s) for *: 'NoneType' and 'int''.
2019-07-22 08:58:17.694 Error: (MAX1) ----> Line 318 in '/home/pi/domoticz/plugins/MaxCube/plugin.py', function onHeartbeat
2019-07-22 08:58:17.694 Error: (MAX1) ----> Line 289 in '/home/pi/domoticz/plugins/MaxCube/plugin.py', function onHeartbeat
2019-07-22 08:58:17.694 Error: (MAX1) ----> Line 135 in '/home/pi/domoticz/plugins/MaxCube/plugin.py', function UpdateDevice 

A restart of Domoticz and the MAX!Cube did not change anything. I already have the MAX! Plugin deleted and reinstalled, but still the same error.

If I start the program belonging to the MAX! Cube instead, it will work as well as all the thermostats. In this respect, I exclude a hardware error.

How can I fix this error?

[janvangent2]

I'm still running this plugin, and it just runs as a charm.

Now I'm planning to get rid of my old oil burner, and have a new gas condensation burner, with opentherm or ebus (modulating) control.
So now I'm wondering what would be the best option, still run it with a simple relay and on/off control based on the heat demand by the individual valves.
OR the following:
-Install an opentherm thermostat in the living room. Use OpenThermGateway to alter the temperature setpoint of this thermostat in case if there is heat demand by one of the smart radiator valves.
-In this case I would be using the more smart regulating algorithm of the heater/thermostat instead of on/off
-However, I'm not sure if it will work properly. The PID control will not teach itself properly I'm afraid.
-Normal case: there will be heat requested in living room (by smart radiator valves) --> so setpoint of thermostat increased --> heat requested by thermostat --> heat deliverd to living room. In this way the thermostat is supposed to be working, and teach-in the PID control properly
-Other situation: however, with the smart radiator valves, sometimes there will be heat requested in another room, for example the bathroom. Temperature setpoint of opetherm thermostat in living room is increased to start up the heat demand to the boiler. However, the smart valves on the radiators in the living room are NOT open in this case, since no heat request in living room. This case will get the whole PID control system upset I'm afraid... Since it will not see a temperature rise in the room, whilst heat demand is on, so it will increase and increase it's heat demand, until suddenly the setpoint is lowered because there is no need anymore for heat in the bathroom.

So I think I have the option between a simple control, based on ON/OFF, which is probably not ideal.
OR go for the "smart" solution, but I'm afraid the control system will not work properly in this case.

What do you guys think?

[mvzut]

I use the second option already for a few years now, it works fine. In theory you are probably right, it is not perfect. The Opentherm thermostat in the living room may get confused when you give it a high setpoint that it will never be able to reach since there are no radiators on in the living room. But in practice it works just fine for me.

[tarootrangi]

nice

[mvzut]

Since tonight this MAX! Plugin works no more. Instead, I regularly receive only these error messages:

Code: Select all

2019-07-22 08:58:17.694 Error: (MAX1) 'onHeartbeat' failed 'TypeError':'unsupported operand type(s) for *: 'NoneType' and 'int''.
2019-07-22 08:58:17.694 Error: (MAX1) ----> Line 318 in '/home/pi/domoticz/plugins/MaxCube/plugin.py', function onHeartbeat
2019-07-22 08:58:17.694 Error: (MAX1) ----> Line 289 in '/home/pi/domoticz/plugins/MaxCube/plugin.py', function onHeartbeat
2019-07-22 08:58:17.694 Error: (MAX1) ----> Line 135 in '/home/pi/domoticz/plugins/MaxCube/plugin.py', function UpdateDevice 

A restart of Domoticz and the MAX!Cube did not change anything. I already have the MAX! Plugin deleted and reinstalled, but still the same error.

If I start the program belonging to the MAX! Cube instead, it will work as well as all the thermostats. In this respect, I exclude a hardware error.

How can I fix this error?

I just noticed your post, have you solved this issue already? It seems others (including myself) are still using the plugin without any issues, so I suspect it must be something that changed on your system?

[janvangent2]

I use the second option already for a few years now, it works fine. In theory you are probably right, it is not perfect. The Opentherm thermostat in the living room may get confused when you give it a high setpoint that it will never be able to reach since there are no radiators on in the living room. But in practice it works just fine for me.

Thanks for your reply!

I'm sure it will work, but a simple on/off control will work as well...

Just wondering what would be most efficient (from an energy consumption perspective), a simple on/off control
or a more "smart" control which is actually continuously being fooled, which will most likely screw up the PID control loop

[fiskuss]

I want to say that i have also your script running on a Synology NAS! Important is to have a Domoticz version with Python from www.jadahl.com

Code: Select all

/usr/local/domoticz/var/plugins

If you are there with SSH you can give the following comands:

Code: Select all

wget https://github.com/mvzut/maxcube-Domoticz-plugin/archive/master.zip
7z x master.zip
cd maxcube-Domoticz-plugin-master/
cp -R * ../
cd ..
chmod +x plugin.py

You need to restart your NAS or only Domoticz before the plugin should be found.

Hello,

i have SYN 918+ running Domoticz plugin domoticz_apolloloake - 6.2_4.0.10717-8. I have installed python plugin according your guide, but MAX! devices are not recognized in Domoticz. MAX!Devices are imported via backup, like others. All others devices are working.
Not info about python nor E-max! cube issue in Domoticz log.
I have also Domoticz VM in Proxmox and also in RPI and there python plugin is working w/o problems.
Could you or somebody help with this please? I'm total noob in Synology.

Thank you!

[haajee]

I want to say that i have also your script running on a Synology NAS! Important is to have a Domoticz version with Python from www.jadahl.com

Code: Select all

/usr/local/domoticz/var/plugins

If you are there with SSH you can give the following comands:

Code: Select all

wget https://github.com/mvzut/maxcube-Domoticz-plugin/archive/master.zip
7z x master.zip
cd maxcube-Domoticz-plugin-master/
cp -R * ../
cd ..
chmod +x plugin.py

You need to restart your NAS or only Domoticz before the plugin should be found.

Hello,

i have SYN 918+ running Domoticz plugin domoticz_apolloloake - 6.2_4.0.10717-8. I have installed python plugin according your guide, but MAX! devices are not recognized in Domoticz. MAX!Devices are imported via backup, like others. All others devices are working.
Not info about python nor E-max! cube issue in Domoticz log.
I have also Domoticz VM in Proxmox and also in RPI and there python plugin is working w/o problems.
Could you or somebody help with this please? I'm total noob in Synology.

Thank you!

But do you see something in the log of Domoticz. Like: 2019-10-12 13:07:45.621 Status: PluginSystem: Started, Python version '3.6.8'. ? And if you install the plugin from 0 and added the devices do you see also something in the log?