Page 5 of 11

Re: ELV MAX! protocol description

PostPosted: Mon Jan 14, 2013 1:16 pm
by Kingsammy
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".

Re: ELV MAX! protocol description

PostPosted: Thu Jan 17, 2013 10:27 am
by ceemjay
blb wrote:I have Radiator Thermostats Firmware version 14, It does work on mine.


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

Re: ELV MAX! protocol description

PostPosted: Fri Jan 18, 2013 12:18 pm
by blb

Re: ELV MAX! protocol description

PostPosted: Fri Jan 18, 2013 10:45 pm
by marki
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.

Re: ELV MAX! protocol description

PostPosted: Thu Jan 24, 2013 9:39 am
by ceemjay
Is there a definite opinion on where the temperature of the valve is stored in the L response to the Cube?

Tx

Re: ELV MAX! protocol description

PostPosted: Thu Jan 31, 2013 8:50 pm
by matthijskooijman
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.

Re: ELV MAX! protocol description

PostPosted: Thu Jan 31, 2013 11:23 pm
by matthijskooijman
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?

Re: ELV MAX! protocol description

PostPosted: Thu Jan 31, 2013 11:28 pm
by matthijskooijman
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 :-)

Re: ELV MAX! protocol description

PostPosted: Fri Feb 01, 2013 10:20 am
by ceemjay
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

Re: ELV MAX! protocol description

PostPosted: Fri Feb 01, 2013 2:00 pm
by matthijskooijman
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 :-)

Re: ELV MAX! protocol description

PostPosted: Thu Feb 14, 2013 12:47 am
by peterhintze
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

Re: ELV MAX! protocol description

PostPosted: Fri Feb 15, 2013 2:39 pm
by Kingsammy
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.

Re: ELV MAX! protocol description

PostPosted: Thu Apr 04, 2013 7:14 pm
by gianluca105
Does someone know if the current room temperature value (not the set temperature) of each thermostat is available in the protocol?

Thanks,
Gianluca.

Re: ELV MAX! protocol description

PostPosted: Tue Apr 09, 2013 12:40 pm
by jorishp
look at http://www.maxbuddy.de/ maybe they have the protocol available as they can read teh current temperatur. not live but its usable

Re: ELV MAX! protocol description

PostPosted: Tue Apr 09, 2013 4:27 pm
by matthijskooijman
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.
Code: Select all
$ echo DAKY5QkSGAQmAAAAvQsBMbQJEhgcJADUAAsEyN0JEhgnJgAAAA== | base64 -d | hd
00000000  0c 02 98 e5 09 12 18 04  26 00 00 00 bd 0b 01 31  |........&......1|
00000010  b4 09 12 18 1c 24 00 d4  00 0b 04 c8 dd 09 12 18  |.....$..........|
00000020  27 26 00 00 00                                    |'&...|
00000025

Sequence num:   AC
Flags:          04
Packet type:    42 (WallThermostatState)
Packet from:    0298E5
Packet to:      04C8DD
Group id:       00
SeReceived 15 bytes
F3 4D 19 D8 EF 1D D6 20 22 A7 D2 1F CD A1 5F       .M..... "....._

Dewhitened:
0C AC 04 42 02 98 E5 04 C8 DD 00 26 BD 36 08       ...B.......&.6.

Sequence num:   AC
Flags:          04
Packet type:    42 (WallThermostatState)
Packet from:    0298E5
Packet to:      04C8DD
Group id:       00
Set temp:       19.0
Actual temp:    18.9
t temp:       19.0
Actual temp:    18.9


Dewhitened:
0F 00 04 60 01 31 B4 00 00 00 00 18 1C 24 00 D4    ...`.1.......$..
DF 19                                              ..

Sequence num:   00
Flags:          04
Packet type:    60 (ThermostatState)
Packet from:    0131B4
Packet to:      000000
Group id:       00
Mode:           auto
Adjust to DST:  0
Locked:         0
Battery Low:    0
Valve position: 28%
Set temp:       18.0
Actual temp:    21.2




This lists a wall thermostat (length 0c) and two radiator thermostats (length 0b)