Python plugin: ELV/EQ-3 MAX!

[Dynazap]

Hmm, i'm a total noob with scripts etc.
What is the best way to get this plugin / EQ3 connected to Domoticz running on a Synology NAS?

[mvzut]

Hmm, i'm a total noob with scripts etc.
What is the best way to get this plugin / EQ3 connected to Domoticz running on a Synology NAS?

1. Check if your image supports Python plugins. If not, install a Domoticz image which supports this (see e.g. http://www.jadahl.com)
2. Copy the plugin files from Github to a subfolder in ~/domoticz/plugins. The easiest is using an SSH terminal and using the git command as explained in this thread or in https://github.com/mvzut/maxcube-Domoti ... /README.md. But if git is not installed on your Synology (I believe this is not standard) you can also just download the files from Github and copy them to your Synology in another way
3. To activate and configure the plugin, follow the rest of the instructions from https://github.com/mvzut/maxcube-Domoti ... /README.md

P.S. I don't have a Synology myself, if others have better tips, please share

[l0gic]

Hi guys,
while I had some spare time I thought I'd swing over from the older LUA script to the new plugin.
I've hit an issue.
Error: (EQ-3) 'onHeartbeat' failed 'TypeError':'int() argument must be a string, a bytes-like object or a number, not 'NoneType''.
Error: (EQ-3) ----> Line 310 in /opt/domoticz/plugins/eq3max/plugin.py, function onHeartbeat
Error: (EQ-3) ----> Line 279 in /opt/domoticz/plugins/eq3max/plugin.py, function onHeartbeat
Error: (EQ-3) ----> Line 128 in /opt/domoticz/plugins/eq3max/plugin.py, function UpdateDevice

Code: Select all

2018-12-29 14:38:23.910 (EQ-3) Skipping heartbeat: 7
2018-12-29 14:38:53.934 (EQ-3) Skipping heartbeat: 8
2018-12-29 14:39:23.957 (EQ-3) Skipping heartbeat: 9
2018-12-29 14:39:53.931 (EQ-3) Reading e-Q3 MAX! devices from Cube...
2018-12-29 14:39:57.007 (EQ-3) Checking device 'Office Thermostat' in room 1
2018-12-29 14:39:57.007 (EQ-3) Checking device 'Office Radiator' in room 1
2018-12-29 14:39:57.007 (EQ-3) Checking device 'Main Bedroom Thermostat' in room 2
2018-12-29 14:39:57.007 (EQ-3) Checking device 'Main Bedroom Radiator' in room 2
2018-12-29 14:39:57.007 (EQ-3) Checking device 'En-Suite Radiator' in room 2
2018-12-29 14:39:57.007 (EQ-3) Checking device 'BathroomThermostat' in room 3
2018-12-29 14:39:57.007 (EQ-3) Temperature (EQ-3 - BathroomThermostat - Temperature)
2018-12-29 14:39:57.010 (EQ-3) Checking device 'Bathroom Radiator' in room 3
2018-12-29 14:39:57.010 (EQ-3) Valve (EQ-3 - Bathroom Radiator - Valve)
2018-12-29 14:39:57.014 (EQ-3) Checking device 'Bedroom 3 Thermostat' in room 4
2018-12-29 14:39:57.014 (EQ-3) Temperature (EQ-3 - Bedroom 3 Thermostat - Temperature)
2018-12-29 14:39:57.017 (EQ-3) Checking device 'Bedroom 3 Radiator' in room 4
2018-12-29 14:39:57.017 (EQ-3) Checking device 'Bedroom 2 Thermostat' in room 5
2018-12-29 14:39:57.017 (EQ-3) Checking device 'Bedroom 2 Radiator' in room 5
2018-12-29 14:39:57.017 (EQ-3) Checking device 'Dining Room Thermostat' in room 6
2018-12-29 14:39:57.017 (EQ-3) Temperature (EQ-3 - Dining Room Thermostat - Temperature)
2018-12-29 14:39:57.021 (EQ-3) Checking device 'Dining Room Radiator' in room 6
2018-12-29 14:39:57.021 (EQ-3) Checking device 'Front Room Thermostat' in room 7
2018-12-29 14:39:57.021 (EQ-3) Checking device 'Front Room Radiator 1' in room 7
2018-12-29 14:39:57.021 (EQ-3) Checking device 'Front Room Radiator 2' in room 7
2018-12-29 14:39:57.021 (EQ-3) Checking device 'Conservatory Thermostat' in room 8
2018-12-29 14:39:57.021 Error: (EQ-3) 'onHeartbeat' failed 'TypeError':'int() argument must be a string, a bytes-like object or a number, not 'NoneType''.
2018-12-29 14:39:57.021 Error: (EQ-3) ----> Line 310 in /opt/domoticz/plugins/eq3max/plugin.py, function onHeartbeat
2018-12-29 14:39:57.021 Error: (EQ-3) ----> Line 279 in /opt/domoticz/plugins/eq3max/plugin.py, function onHeartbeat
2018-12-29 14:39:57.021 Error: (EQ-3) ----> Line 128 in /opt/domoticz/plugins/eq3max/plugin.py, function UpdateDevice
2018-12-29 14:40:23.939 (EQ-3) Skipping heartbeat: 1

I have nine separate rooms and the code bombs at the start of room eight. So I end up with room 8 & 9 not being updated.
I have debug on and all options at default, i.e. Create all devices, update every 5 mins.

Dropping back to the lua script and all is well.

I have also fired up the Max! configuration application to check for any 'dodgy' settings. All looking good, no flat batteries or radio problems reported.

Running latest stable (4.9727) and git pulled a couple of days ago.

Line 310 calls _plugin.onHeartbeat() - Reads Cube at desired time
Line 279 calls self.UpdateDevice(EQ3device, "Thermostat")
Line 128 checks battery as a function of UpdateDevice

Possibly failing to get thermostat information for room 8 and failing thereafter?
Why room 8 (and possibly onwards) is there a hard limit or is there something odd with my room?
Each room has a thermostat and at least one radiator valve to a maximum of two.
Room 7 has one thermostat and two radiators if that helps (but so does room 2)
Room 8 has one thermostat and one radiator.

Has anyone hit this before? Searched the thread without finding anything obvious.

TIA

Kevin

[mvzut]

Hi guys,
while I had some spare time I thought I'd swing over from the older LUA script to the new plugin.
I've hit an issue.
Error: (EQ-3) 'onHeartbeat' failed 'TypeError':'int() argument must be a string, a bytes-like object or a number, not 'NoneType''.
Error: (EQ-3) ----> Line 310 in /opt/domoticz/plugins/eq3max/plugin.py, function onHeartbeat
Error: (EQ-3) ----> Line 279 in /opt/domoticz/plugins/eq3max/plugin.py, function onHeartbeat
Error: (EQ-3) ----> Line 128 in /opt/domoticz/plugins/eq3max/plugin.py, function UpdateDevice

...

Line 128 checks battery as a function of UpdateDevice

Possibly failing to get thermostat information for room 8 and failing thereafter?
Why room 8 (and possibly onwards) is there a hard limit or is there something odd with my room?

..

Hi Kevin,

I suspect that the API (which I didn't develop myself) did not find battery info for this device. It crashes because it cannot convert an empty value to an integer. Even though it is strange that the battery value is empty just for this device (it seems to go well for the other devices), the plugin obviously shouldn't crash if this happens. I have made a small adjustment to the code on Github to prevent this, please check it out!

Of course, it may be that the non-existing battery level is just a symptom of an underlying bigger issue. If that is the case, my fix may not help, and we have to dig deeper.

[l0gic]

Morning mvzut,

despite my checking of the cube configuration and it looking 'ok' I still had a gut feel that something was up.
So I renamed the Conservatory (room 8) to Old, created a new room and moved the thermostat and radiator valve into it. Then deleted the original room container.

I did that last night and since then the error has disappeared.

So I'm chalking it up to a configuration error of some type on the cube despite it not indicating anything amiss.

Many thanks for the prompt reaction and I will do a git pull later today to exercise your updated code.

All the best

Kevin

[l0gic]

As a side note the room numbers are no longer sequential, room 8 is missing and the new room is 10.
No problem with the code - nice one!

[janvangent2]

This plugin has now been running flawless for a few months, realy happy with the combination of this plugin, Max! hardware, an ESP8266 + relay for switching on/off the heater.

Next week I'm going to install the same setup for my father in law. 10 radiator valves, 2 room thermostat, and a sonoff basic relay (+ ESPeasy flash) for controlling the heater.

[DarkG]

The same, runs well without any problems. I use smart virtual thermostat too, because I think external temp sensors are better.

[Umberto]

Hi mvzut,

Back again.

I run into a strange issue: my configuration consists of 2 rooms:
- room 1 only has 1 radiator valve
- room 2 has 1 wall thermostat and 3 radiator valves (which are coupled by the MaxCube)

In the past I noticed some strange behaviour but I couldn't get hold of the exact issue. I have done some testing last couple of days and found the following testcase (see attached logging):
- install the plugin, set debug on: devices are found, room config seems to be ok, data is retrieved fine from the Cube
- setting a new setpoint for the wall thermostat (room 2) using Domoticz results in a change of only room 2 which is fine off course.
- setting a new setpoint for room 1 (only 1 radiator valve) using Domoticz now results in a change of all valves (and wall thermostat). I assume since the wall thermostat receives an update via Domoticz and then on its turn changes all the other settings also.
- manually changing setpoints for both room 1 and 2 doesn't change the other room and also results in an update in Domoticz without any issues.

I didn't log / test a change of the mode, but the behaviour is exactly the same as with the setpoints.

I did have a quick look at the code, but couldn't find a reason that quickly. Sorry.

Are you able to have a look at the code? Need some more info I could help with?

Best regards.

[mvzut]

I will have a look later this weekend. One thing maybe worth mentioning: I also had weird behavior once, setting a thermostat value for one room set another room as well. I found out that it also did this when using the ELV app, so I knew it had nothing to do with my plugin (or actually my Lua script at that time). I reconfigured everything in the Cube (did a complete reset) and it was solved.

[yakkz]

Hi all,

I have just started with Domoticz and Max.
I have installed the plugin and got it too connect to the cube.

All devices are created properly as well.

But I'm unable to figure out how to get the "Heat demand switch" working.

While testing I've set the Min valve pos for heat demand to 5
One of my radiators has a valve position of 25%, but the (automatically created) Heat demand switch never gets turned on.

If I look at the log it mentions that heat is required, but there's no entry about the switch.

2019-01-12 18:22:16.745 (Max Cube) Reading e-Q3 MAX! devices from Cube...
2019-01-12 18:22:19.467 (Max Cube) Checking device 'Rad1' in room 1
2019-01-12 18:22:19.468 (Max Cube) Valve (Rad1 - Valve)
2019-01-12 18:22:19.487 (Max Cube) Temperature (Rad1 - Temperature)
2019-01-12 18:22:19.505 (Max Cube) Checking device 'Rad2' in room 2
2019-01-12 18:22:19.506 (Max Cube) Checking device 'Rad3' in room 3
2019-01-12 18:22:19.506 (Max Cube) 1 valves require heat

What do I need to do to get the heat demand switch working?

[mvzut]

While testing I've set the Min valve pos for heat demand to 5
One of my radiators has a valve position of 25%, but the (automatically created) Heat demand switch never gets turned on.

If I look at the log it mentions that heat is required, but there's no entry about the switch.

2019-01-12 18:22:16.745 (Max Cube) Reading e-Q3 MAX! devices from Cube...
2019-01-12 18:22:19.467 (Max Cube) Checking device 'Rad1' in room 1
2019-01-12 18:22:19.468 (Max Cube) Valve (Rad1 - Valve)
2019-01-12 18:22:19.487 (Max Cube) Temperature (Rad1 - Temperature)
2019-01-12 18:22:19.505 (Max Cube) Checking device 'Rad2' in room 2
2019-01-12 18:22:19.506 (Max Cube) Checking device 'Rad3' in room 3
2019-01-12 18:22:19.506 (Max Cube) 1 valves require heat

What do I need to do to get the heat demand switch working?

Hmmm, that's strange. It works for me, and I believe others are using it with success too.
I think the plugin thinks your switch is already turned on. In debugging mode it will always report how many valves require heat, but it will only turn the switch on when it is off. Somehow it cannot properly read the state, it seems. Have you tried restarting Domoticz?

[yakkz]

I had tried to restart Domoticz but that didn't help.

Finally I added some debugging code to the plugin and found that the sValue of the switch returned an empty string instead of the expected "On" or "Off". In this situation manually toggling the switch from the Domoticz interface didn't work as well.

So finally I removed the switch. After it was recreated by the plugin it works.

Further testing revealed that the issue seems to be related to slave devices. I tried to set the heat demand switch as a slave device for the actual switch. After that it stopped working. (even after reverting the slave device setting)
But removing and recreating the switch resolves the issue.

[maks87]

Is it possible for the thermostat to report the set temperature all the time? Currently, if one change is at 8pm and the next one at 8am, there are no points between and a rounded line appears on the graph. It would be good if there were more between these points, with the value set at 8pm.
https://imgur.com/a/rQBbBVl

[mvzut]

Is it possible for the thermostat to report the set temperature all the time? Currently, if one change is at 8pm and the next one at 8am, there are no points between and a rounded line appears on the graph. It would be good if there were more between these points, with the value set at 8pm.
https://imgur.com/a/rQBbBVl

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?

How do the graphs of other users look like?

[mvzut]

Hi mvzut,

Back again.

I run into a strange issue: my configuration consists of 2 rooms:
- room 1 only has 1 radiator valve
- room 2 has 1 wall thermostat and 3 radiator valves (which are coupled by the MaxCube)

In the past I noticed some strange behaviour but I couldn't get hold of the exact issue. I have done some testing last couple of days and found the following testcase (see attached logging):
- install the plugin, set debug on: devices are found, room config seems to be ok, data is retrieved fine from the Cube
- setting a new setpoint for the wall thermostat (room 2) using Domoticz results in a change of only room 2 which is fine off course.
- setting a new setpoint for room 1 (only 1 radiator valve) using Domoticz now results in a change of all valves (and wall thermostat). I assume since the wall thermostat receives an update via Domoticz and then on its turn changes all the other settings also.
- manually changing setpoints for both room 1 and 2 doesn't change the other room and also results in an update in Domoticz without any issues.

I didn't log / test a change of the mode, but the behaviour is exactly the same as with the setpoints.

I did have a quick look at the code, but couldn't find a reason that quickly. Sorry.

Are you able to have a look at the code? Need some more info I could help with?

Best regards.

I cannot find anything strange in your logs. I am almost certain that his behavior originates from something outside the plugin. My best guess is that the Cube is somehow messing up rooms. As I said before, I have also had this (twice actually), directly after connecting new MAX stuff.

Have you tried changing a setpoint in the MAX software (either web-based or via their smartphone app), with the Python plugin temporarily disabled? If you see the same thing happening then, it has nothing to do with the plugin. Best thing to do then is a complete reset of the Cube and register all devices again. In your case this is not so dramatic, since you "only" have 5 devices... After reinstallation, the plugin should continue working with your existing Domoticz devices, so you don't lose any timers or history data.

[Umberto]

Hi mvzut,

My Pi crashed and I had to restore it. Luckely 'just 1 week' lost. I think I am going to rebuild it from scratch since the performance is very low (processor load is approx 20-25% but responses to the commandline are way too slow). Therefor I have concentrated yesterday and last saturday on automating the backup first. I found a solution which I am trying now (learned also that 32 GB sd cards aren't all equal, some are more equal others less ). That issue seems solved.

I hope that I can sort things out this week (including a new install of the Cube itself). Then I'll be back. Furtermore: I took your advise regarding the restarting of the cube and 'automated' a restart every week.

Best regards,

Umberto

[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.

[mvzut]

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?

[DarkG]

here is mine