Max! valve not reporting state changes

English Forums Devices
#1

I have successfully changed my Max! system to a Max! Cube CUL and I am running Homegear. I have paired my valves successfully some of which are linked to wall thermostats through a channel 1 (wall Thermostat source) - channel 3 (Valve target) link.

Everything works perfctly with the valves linked to wall thermostats. I get regular actual temperature and valve state updates through MQTT.

BUT I get nothing from the stand-alone valves. They are communicating with homegear OK. I can get and put paramsets and I can change the set temperature and if I do, I get an MQTT message of the new variable values including the new valve state and the actual temperature.

But when the valves are running their own schedule and the set temperature changes or the actual temperature causes the valves to move, I get nothing, no MQTT notification and no notification of the valve setting when it changes.

This is a major problem as a vital part of my setup is to control my boiler depending on how many radiatiors are calling for heat. Currently I cannot tell when the radiator valves close either when the schedule changes to a lower set temperature or because the room is warm enough and so I don’t know to turn off the boiler.

I understood that the valves reported their new state (and the current temperature) every time the valves moved (and only then). They certainly did when I was running the Max! software and they don’t need to be linked to a wall thermostat to do that. I don’t have wall thermostats in every room.

Is Homegear missing something or am I?

I have the same problem with both BC-RT-TRX-CyN and BC-RT-TRX-CyG-3 valves

I’d be very grateful for some help here.

#2

Hey Simon,

that’s odd… Did not have any problems with Max! and a Max!Cube CUL when I had them running.

Could you tell which version of homegear you are running and show your mqtt.conf?

Cheers,
Patrik

#3

Hi Patrik, thanks for the quick reply

I’m running homegear 0.7.45-3101. I run openHAB for the rest of my automation. Homegear is the version that comes built into openHAB and runs on the same RPi. The MQTT broker is the Mosquitto broker that comes with the openHAB build, which I’ve been following using MQTT.fx

mqtt.conf is below. Everything else I’ve not reproduced is commented out.

MQTT works for the other valves with thermostats and, on the valves without thermostats, I do get MQTT messages from Homegear (new set temperature, new actual temperature, new valve state and other things) when I update a set temperature. I just don’t get anything when they’re minding their own business and change valve positions on their own because of either schedule or actual temperature changes.

I have checked; the valves do change their set temperature according to the schedule (sent to Homegear and acknowledged over MQTT). They just don’t report anything back to Homegear when it happens (or Homegear isn’t telling me about it over MQTT).

Puzzling!

# mqtt.conf
#
# MQTT settings.
#

# Set this to "true" to enable MQTT.
# Default: false
enabled = true

# Hostname or IP address of your MQTT message broker.
brokerHostname = localhost

# Port of your MQTT message broker.
brokerPort = 1883

# Name of this client.
clientName = Homegear

# The prefix to use. Every topic starts with this prefix.
# Default: homegear
prefix = homegear

# Unique ID of this Homegear instance. Change this, have you have multiple
# Homegear installations.
# This is not used for IBM Bluemix Watson IOT platform
homegearId = 1

# Tells the MQTT server to retain received MQTT messages. New clients will then
# receive the last value of a topic on connection.
# Variables of type "Action" are not retained.
retain = true

# When authentication by username and password is enabled, uncomment the following two lines and fill in your username
# and password.
username = xxxxxxxxx
password = xxxxxxxxx

# The number of parallel processing threads.
processingThreadCount = 5

### Topic payload encodings ###

# Enable topic: homegear/HOMEGEAR_ID/plain/PEERID/CHANNEL/VARIABLE_NAME
# Contains the value as is. E. g.: 43.7.
plainTopic = true

# Enable topic: homegear/HOMEGEAR_ID/json/PEERID/CHANNEL/VARIABLE_NAME
# Puts the value in a JSON array to be JSON-compliant: [43.7].
jsonTopic = true

# Enable topic: homegear/HOMEGEAR_ID/jsonobj/PEERID/CHANNEL/VARIABLE_NAME
# Puts the value into a JSON object. The key is value: { "value": 43.7 }.
jsonobjTopic = true


### TLS options ###

# Set to "true" to enable SSL encryption for MQTT.
enableSSL = false
#4

Hmm… I’m not sure, but if I remember correctly they did that in my installation.

Do you get a message from the Thermostats to Homegear when you manually change the temperature with the dial on the thermostat?

Your config looks good, though.

Keep in mind, the thermostats try to save energy. So it can take time for actually sending out data packets.

#5

No, if I change the dial so that the valve would need to change (e.g. the valve is closed and I set the target temperature to 30, I get nothing from Homegear.
The only time I get a response is if I send a variable change message over MQTT to change the set_temperature or if I change the mode from Auto to Manual or vice versa.

I’ve just tested it now. The valve was set to Auto and I changed the set_temperature to 30.5, which opened the valve up to 100, and which I was notified about over MQTT. I had already sent a schedule that changed the set_temperature back to 18.5 about 20 minutes later.

I’ve just checked the valve and it is reading 18.5 on the display but I have had no MQTT messages for over an hour since the valve went to 100 and I had complete set of set_temperature (30.5), actual_temperature (20) and valve_state (100) messages. So anything relying on MQTT would still think the valve is still open.

#6

Ok. That totally worked for me.
What firmware did you use on the cube?

#7

Ooh that’s a good point.

I used this version witht the credit restrictions removed

Cube firmware

Maybe I’ll try a different version. It would be odd if the firmware had just broken one aspect of MQTT for one type of valve. That’s a job for a spare evening; not right now!

Do you have a similar setup? Which firmware are you using?

#8

Well, you have a point. Could you check the homegear.log with debuglevel 5 what if there are any packets received when you manually change the temperature at the thermostats?

You can change the debuglevel at runtime via the homegear console:

sudo homegear -r
dl 5

Not any more. Used it last 2 years ago.

#9

Not any more. Used it last 2 years ago.

Interesting - what are you using now?

I looked at the logs. There didn’t seem to be any packets arriving from a valve when the values changed under the valve’s own schedule control.

So presumably homegear is OK (why would it not be?) and presumably my problem is with the CUL itself. I’ll try changing the firmware over the weekend and rebuilding the setup slowly adding one valve and seeing if it works OK.

Thanks for your thoughts so far.

#10

Still using homegear but not Max! anymore. Using 24V valves together with a Beckhoff BK9000.
See my blog article here: https://allgeek.de/2020/01/05/aktorik-sensorik-mit-dem-beckhoff-feldbus-und-homegear/ (german)

That’s odd… maybe @sathya can have a look into this?

I hope that helps… maybe my wild guess can solve this.

#11

Well,

I’m not sure whether I’ve got to the bottom of this but I have a working solution.

I changed the firmware on the MAX! Cube CUL and that did not seem to have any effect.

So I set up a new Homegear installation on a new RPi running standard Raspbian Buster. And that worked! A far as I can see the configuration of the new Homegear on the new Pi is exactly the same as it was on the old version running on the openHAB Pi. I did however, because it was a new version, change the Homegear ID in max.conf, which meant that I had to factory reset all my devices to get them to pair. Perhaps that cured the problem.

So, the interesting question is does the version of Homegear that comes with openHAB contain some form of bug that prevents it from picking up the messages from stand alone valves?.. or did I indavertently cure the problem some other way by factory resetting the devices on the way to the new setup?

I might never find out because Pis are so cheap that I don’t particularly mind using my spare Pi just for a Homegear installation separate from openHAB. And I’m not sure I want to go through the hassle of changing it all back to having both openHAB and homegear on one unit. I’ll just buy another spare.

1 Like
#12

Simon, when in AUTO, as soon as the next schedule point is reached, the Thermostat (valve) will send the SET_TEMPERATURE to the MAX! Cube CUL. See https://ref.homegear.eu/device.html?directory=MAX!&file=BC-TC-C-WM-4.xml&familyLink=max&name=BC-TC-C-WM-4#affixSubsubsection1_0_14

For homegear installation, if I remember correctly, I use one recent nightly build which was stable enough for me on the Pi.