MAX! BC-RT-TRX-CyG-3 and ACTUAL_TEMPERATURE

English Forums Devices
#1

Hello all,

I am using 3 valve drivers from MAX! connected to my system through SPI/ti-cc1101. It’s working well, when I send commands they are immediately received byt the devices, but the reading of ACTUAL_TEMPERATURE is weird.

What is happening is that the value I read from the valves remain fixed for a long time (e.g. a couple of hours at night) and then suddendly changes a lot (like 2 deegrees C). The updated values is returned sometimes after sending a command, and sometimes all by itself.

I would like to know whether this is normal because the devices go into some kind of “energy saving” mode, or perhaps it’s homegear which is caching this data (I am using openhab with rrd4j persistence on top of homegear).

Kind regards,
Daniele

Max! über CUL - SET-Temperature wird nur sporadisch an HomeGear übertragen?
#2

Hello Daniele,

the problem is, that the BC-RT-TRX-CyG-3 doesn’t send cyclic status packets by itself. It only does that in combination with the wall thermostat. Currently what you can do is set a value on the thermostat in regular intervals for example with a timed event [1] (not too often as that will drain your batteries).
I will add the possibility to poll MAX! devices automatically in one of the next Homegear releases.

Cheers,

Sathya

[1] https://www.homegear.eu/index.php/AddEvent

#3

Has anybody had any luck getting these valves to report ACTUAL_TEMPERATURE? I was hoping to control my boiler based on whether individual radiators need heat, though sometimes it can go for hours without the new temperature being reported. I read somewhere else that the valves only send the temperature when the valve position changes?

Sathya: Do the thermostats regularly report the temperature? I only bought the valves so far.

#4

Hey @richy,

No, they don’t by themselves. They report the current temperature only on changes of the setpoint temperature or the mode. If you need values more often, you need to buy the wall thermostat. Then you get a new value every few minutes.

Cheers,

Sathya

#5

Thanks. I’ve found some time to pick this project up after a few months.

It looks like they will report their current temperature if any of the config values are changed (or just set to the same value). I’ve got some hacky code that sets DECALCIFICATION_DAY to 0 (despite the fact it’s already 0). It appears that the valve is ACK’ing that request and also including “oh, by the way, ACTUAL_TEMPERATURE is x now”. Agreed, not too often to avoid hammering the batteries - though it’s this hack or abandon the project entirely.

Thanks!

1 Like
#6

Exactly the problem I’m facing. I also reached the same conclusion and will implement the same ‘hack’. For others, the link to addEvent documentation has changed and is now https://ref.homegear.eu/rpc.html#addEvent.

Quick question, I’m not familiar at all with PHP and don’t understand how to pass eventDescription structure parameter to the command. I’m trying to use this command

rc $hg->addEvent(...structure example on one line...)

but only manage to get this error back:

PHP Fatal error:  Uncaught Homegear\HomegearException: Type error. in 
/var/lib/homegear/scripts/inline.php:7
Stack trace:
#0 /var/lib/homegear/scripts/inline.php(7): Homegear\Homegear->__call('addEvent', Array)
#1 {main}

Can you help? Thanks

1 Like
#7

Hi @renmarq,

the example is not specific for a programming language and won’t work in PHP as it is. You need to rewrite it as a PHP array:

homegear -e rc '$hg->addEvent(array("TYPE" => 0, "ID" => "My event", "PEERID" => 71, <...>));'

The event engine is depracated though, you can use Node-BLUE now.

Cheers,

Sathya

#8

Hi @sathya,

I had a look at Node-BLUE. Much better than the old event engine indeed.

Also I noticed that devices would send message (e.g. new temperature) on their own, sometimes quite regularly, then stop for a couple of hours and start again, etc.

So I’m thinking now about a solution where I should check age of last known state in homegear and only send a “refresh update” if too old. But I couldn’t find timestamp of last communication in Node-BLUE, can you let me know if it’s available? Even through python code if necessary.

Thank you.

#9

After some additional testing it seems the ack doesn’t contain the ACTUAL_TEMPERATURE anymore.

Going further I realised that the configuration of packets with id ACK_STATUS (which is the one received after any command sent to the valve) never contained ACTUAL_TEMPERATURE since initial commit, so how come you were able to receive it before?

I only found ACTUAL_TEMPERATURE in INFO_LEVEL packet which is sent ‘randomly’ by the valve.

I’ve been able to validate this by checking homegear.log.

Would anyone have an idea on how to force the valve to send ACTUAL_TEMPERATURE on request? Thank you.

#10

Yeah. I found that trying to find out the actual temperature is unreliable at best.

In the end I stuffed all of my valves on eBay and shelled out for Honeywell Evohome :frowning:

#11

Thanks for your answer. Hard option for me as I need 14 valves in total.

I would tend to think there is a way to get that information on demand since the wall thermostat is apparently capable of getting it from the valve?

#12

After a bit of investigations the valves are not sending ACTUAL_TEMPERATURE randomly but immediately after having moved the internal motor to control the radiator. It might be useful for someone else.

2 Likes
#13

Some automation systems implements a logic that periodically shift setup temperature 0.5 °C up and down to force transmission of data; not too often to save battery…