Home Automation Domotica Forum Europe, Bwired Forum

It seems that the radiator thermostates only send the actual temperature if there is a change in the valve position or your send a new temperature to the Cube.
Taken from here: http://www.fhemwiki.de/wiki/MAX, see chapter 6.1 "IST-Temperaturwerte".

blb wrote:I have Radiator Thermostats Firmware version 14, It does work on mine.

How did you find the firmware version of the 'stat?

Firmware Radiator Thermostats: see http://www.domoticaforum.eu/viewtopic.p ... are#p58766

Kingsammy wrote:It seems that the radiator thermostates only send the actual temperature if there is a change in the valve position or your send a new temperature to the Cube.
Taken from here: http://www.fhemwiki.de/wiki/MAX, see chapter 6.1 "IST-Temperaturwerte".

Yes, I can confirm this. The temperature is on position of the "Date Until" - it probably use 9 bits (LSB). I saw it in the 15 and 16 fw version.

Unfortunatelly, the temperature is not updated properly and only sometimes present. Seems the temperature is not adjusted with the offset value.

As I know in the RF protocol, the payload from the radiator termostat contains the current temperature always together with the valve position, staus flags and the set temperature.

Is there a definite opinion on where the temperature of the valve is stored in the L response to the Cube?

Tx

In more recent firmwares the TCP port number has changed from 80 to 62910. Could you document this in the first post?

Also, I looked around the source a bit (and you probably found this already), but the commands sent by the application to the cube are created (and their replies parsed) by the classes in de\eq3\max\il\local\commands\ in MaxLocalBackend-1.3.6.jar. The L:, C:, M: and H: messages are parsed by the CubeConnection class in that same file.

The actual parsing of the content of the C: message happens in DeviceConfigurationSerializer. From that code, the "0114FF" that is still missing in your description is three separate bytes, group address (room number, I think), firmware version and test result (?).

The DeviceStateSerializer and MetaDataSerializer classes (in de.eq3.max.al.core.cubestate.convert) contain similar parsing code for the L: and C: response. It seems the application doesn't parse more info from the H: response than already documented.

One more thing: From looking more closely at this protocol spec, it seems you are unable to tell when a thermostat is switched on or off at a given time? I was under the impression that the cube would send out unsolicited updates when the valve position of a thermostat changed, but it seems that doesn't happen. Also, it seems the valve position isn't actually visible anywhere either (there is the valve position offset, but it seems that's always at 00 for my thermostat). Does anyone know of a way to get at this info from the cube, or should I really start sniffing the wireless transmissions instead of using the cube?

And one more thing: I found that the cube really only accepts commands that end with a \r\n, just \n isn't enough. Might be useful to explicitly state that somewhere, for anyone trying some things with netcat like me :-)

matthijskooijman wrote:One more thing: From looking more closely at this protocol spec, it seems you are unable to tell when a thermostat is switched on or off at a given time? I was under the impression that the cube would send out unsolicited updates when the valve position of a thermostat changed, but it seems that doesn't happen. Also, it seems the valve position isn't actually visible anywhere either (there is the valve position offset, but it seems that's always at 00 for my thermostat). Does anyone know of a way to get at this info from the cube, or should I really start sniffing the wireless transmissions instead of using the cube?

HI matthijskooijman

Maybe I am misunderstanding you but the L: response shows the valve position. Some people also state it contains the tempertature of the valve but no-one has specified where.

I am using Wireshark to capture the TCP packets between the Cube and the Max! software and then interpreting the L: response but I cant find the temperature. An L: packet is sent to the Cube every 7 or 8 seconds

This week an English version of MaxBuddy on maxbuddy.de was released (hooray!!) and in the log it shows the valve temperature every 10 minutes. However it must be magic as I can see no packets in Wireshark at the exact time the temperature was sent!! It's obviously me doing something wrong -- can anyone put me right?

Clive

Ah, you're right! I didn't see the scrollbar in the L packet description in the first post, I must have been tired. Thanks for pointing it out to me :-)

Some days ago ELV added "MAX! Elektronischer Heizkörper-Thermostat+" to the list of MAX! devices. In contrast to the non + Thermostat the new should work without a central cube but just a "Wandthermostat WT+". Of cause it does work with a central MAX! Cube, too.

Cause one of my non + Thermostat motors died, I decided to buy the new + to replace the broken one. The interesting thing is this new Termostat+ does show up with a new deviceid. While the old ones have deviceid 1 the new + has deviceid 2.

To my observation it is totally backwards compatible and can be configured with the known commands. Just be sure to treat both deviceid=1 and deviceid=2 as thermostat.

best

peterhintze wrote: To my observation it is totally backwards compatible and can be configured with the known commands. Just be sure to treat both deviceid=1 and deviceid=2 as thermostat.

Have a look at this post: domoticaforum.eu/viewtopic.php?f=66& ... =30#p55255

There are the device IDs mentioned.

Does someone know if the current room temperature value (not the set temperature) of each thermostat is available in the protocol?

Thanks,
Gianluca.

look at http://www.maxbuddy.de/ maybe they have the protocol available as they can read teh current temperatur. not live but its usable

It looks like the current temperature is listed in the L-response. However, as stated before, it is usually outdated for the radiator thermostats, since they only send it over when their valve position changes. For the Wall thermostats, the value is accurate, since those send updates every couple of minutes. Additionally, it seems that for radiator thermostats connected to a wall thermostat, the radiator thermostat doesn't send out its own measured value, but just forwards whatever the wall thermostat has sent them (but again, only when changing valve position).

For wall thermostats, the lower 8 bits of the actual temperature are sent as the last byte (position C) in the L-response (one extra byte compared to the radiator thermostats). There should be a 9th MSB (for temperatures >25.5°), but I'm not sure where that one is yet. For radiator thermostats, these bytes are in position A, the middle date/time byte. This suggests that when a radiator thermostat is in temporary/vacation mode, the actual temperature is not present (this is the case with the RF packets as well).

For reference, below is the L-response sent out by my cube shortly after I sniffed the below two RF packets. Note that the third device in the L-response has 00 00 00 as its last bytes (so no actual temperature there), presumably because the cube hasn't been powered on for long and the thermostat hasn't sent over its status yet. This lists a wall thermostat (length 0c) and two radiator thermostats (length 0b)