ELV MAX! protocol description
Moderator: jrkalf
Re: ELV MAX! protocol description
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".
Taken from here: http://www.fhemwiki.de/wiki/MAX, see chapter 6.1 "IST-Temperaturwerte".
Re: ELV MAX! protocol description
How did you find the firmware version of the 'stat?blb wrote:I have Radiator Thermostats Firmware version 14, It does work on mine.
Re: ELV MAX! protocol description
Firmware Radiator Thermostats: see http://www.domoticaforum.eu/viewtopic.p ... are#p58766
Bernard
Re: ELV MAX! protocol description
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.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".
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
Is there a definite opinion on where the temperature of the valve is stored in the L response to the Cube?
Tx
Tx
-
- Member
- Posts: 62
- Joined: Tue Oct 18, 2011 10:07 am
Re: ELV MAX! protocol description
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.
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.
Last edited by matthijskooijman on Fri Feb 01, 2013 12:25 am, edited 1 time in total.
-
- Member
- Posts: 62
- Joined: Tue Oct 18, 2011 10:07 am
Re: ELV MAX! protocol description
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?
-
- Member
- Posts: 62
- Joined: Tue Oct 18, 2011 10:07 am
Re: ELV MAX! protocol description
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
HI matthijskooijmanmatthijskooijman 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?
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
-
- Member
- Posts: 62
- Joined: Tue Oct 18, 2011 10:07 am
Re: ELV MAX! protocol description
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 :-)
-
- Starting Member
- Posts: 1
- Joined: Fri Sep 14, 2012 11:53 pm
Re: ELV MAX! protocol description
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
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
Have a look at this post: domoticaforum.eu/viewtopic.php?f=66& ... =30#p55255peterhintze 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.
There are the device IDs mentioned.
-
- Starting Member
- Posts: 1
- Joined: Thu Apr 04, 2013 8:08 pm
Re: ELV MAX! protocol description
Does someone know if the current room temperature value (not the set temperature) of each thermostat is available in the protocol?
Thanks,
Gianluca.
Thanks,
Gianluca.
Re: ELV MAX! protocol description
look at http://www.maxbuddy.de/ maybe they have the protocol available as they can read teh current temperatur. not live but its usable
-
- Member
- Posts: 62
- Joined: Tue Oct 18, 2011 10:07 am
Re: ELV MAX! protocol description
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)
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