ELV MAX! protocol description

Forum about the home automation suites by ELV etc

Moderator: jrkalf

Re: ELV MAX! protocol description

Postby Massi » Mon Feb 10, 2014 9:22 pm

pbrand wrote:I'm not sure about the free memory slots, but I think the Cube works similar to the older ELV devices in that is has a command queue in which all commands to be send are queued. It then processes the commands one by one. I guess the free memory slots is an indication of how full the queue is. If there are no slots available, the memory is full (the queue is full) and the cube will not accept any new commands and therefore discard them.
So we could (or should) keep an eye on the duty cycle to see if the cube has room for commands timeslot wise, and keep an eye on the free memory to see if the cube has room for commands memory (or queue) wise.
But that's only an educated guess 8)


mmmm it's not clear to me how free slots are counted..
i suppose it's a hex value, so i converted it to decimal and sent a list of commands (auto-manual-auto-manual) to the cube, with a sleep time of 2 seconds between each. this is the result
Code: Select all
Command sent. Duty cycle reached: 42%. Free memory slots: 49
Command sent. Duty cycle reached: 45%. Free memory slots: 49
Command sent. Duty cycle reached: 48%. Free memory slots: 46
Command sent. Duty cycle reached: 50%. Free memory slots: 47
Command sent. Duty cycle reached: 51%. Free memory slots: 49
Command sent. Duty cycle reached: 54%. Free memory slots: 45
Command sent. Duty cycle reached: 54%. Free memory slots: 47
Command sent. Duty cycle reached: 57%. Free memory slots: 49
Command sent. Duty cycle reached: 57%. Free memory slots: 48
Command sent. Duty cycle reached: 60%. Free memory slots: 47


cannot understand how slots jump from 49 to 46.. or from 49 to 46..

as expected, reaching full duty cycle, commands are accepted but slots go down..

Code: Select all
Command sent. Duty cycle reached: 99%. Free memory slots: 45
Command sent. Duty cycle reached: 99%. Free memory slots: 44
Command sent. Duty cycle reached: 99%. Free memory slots: 43
Command sent. Duty cycle reached: 99%. Free memory slots: 42
Command sent. Duty cycle reached: 99%. Free memory slots: 41
Command sent. Duty cycle reached: 99%. Free memory slots: 40
Command sent. Duty cycle reached: 99%. Free memory slots: 39
Command sent. Duty cycle reached: 99%. Free memory slots: 38
Command sent. Duty cycle reached: 99%. Free memory slots: 37
Command sent. Duty cycle reached: 99%. Free memory slots: 36


don't know if 99% is maximum value possible, or my command is bigger than 1% so is not executed :) my hex value returned is always 63..

mmm curious about return value when duty cycle is 100% and slots are over..

Code: Select all
S:63,0,05 Command sent. Duty cycle reached: 99%. Free memory slots: 5
S:63,0,04 Command sent. Duty cycle reached: 99%. Free memory slots: 4
S:63,0,03 Command sent. Duty cycle reached: 99%. Free memory slots: 3
S:63,0,02 Command sent. Duty cycle reached: 99%. Free memory slots: 2
S:63,0,01 Command sent. Duty cycle reached: 99%. Free memory slots: 1
S:63,0,00 Command sent. Duty cycle reached: 99%. Free memory slots: 0
S:63,1,00 Command sending failed - Command rejected.


so once duty cycle is used and slots are full, the cube rejects other commands.

Now my cube will go on all night switching my living room heating, but at least we know what to expect :)

bye!
Massi
Member
Member
 
Posts: 51
Joined: November 2013

Re: ELV MAX! protocol description

Postby pbrand » Mon Feb 10, 2014 9:40 pm

Good to see that my assumptions were correct, Massi :)
pbrand
Member
Member
 
Posts: 100
Joined: October 2008
Location: Netherlands

Re: ELV MAX! protocol description

Postby HMside » Wed Feb 26, 2014 11:53 am

Hello,

i'am working with an HomeMatic CCU2, the CuxD Addon and an CUL-Stick (Zr=Moritz-Mode).
Now i have put the MAX! Windows Shutter over the CuxD Addon in the CCU2.

Over the CuxD Terminal i get this lines when i open or close (the - separator are filled by me):
Code: Select all
closed
22:21:21 [ttyACM0] --> Z-0B-01-00-02000000006539000000
22:21:21 [ttyACM0] --> Z-0B-01-00-3000653900000000-00-FA <-- closed 00
open
22:21:59 [ttyACM0] --> Z-0B-02-00-02000000006539000000
22:21:59 [ttyACM0] --> Z-0B-02-00-3000653900000000-02-F8 <-- open 02


Over CuxD i create an Universal Remote (40). Than i put in the Codes for open/close over the CCU2 Device Config.

It looks like this:
Code: Select all
SWITCH|RCV_SHORT
???????300065390000000002??
SWITCH|RCV_LONG
???????300065390000000000??


Now i want to understand what are this lines means. I have read this in an other forum but it was read whit an RFM22:
Code: Select all
0B 48 00 30 06 0F 1F 00 00 00 00 02 72 D5
Description:
byte(s)   description
0B   message length in bytes(without CRC)
48   message counter
00   flag??
30   type; 30=window contact
06 0F 1F   source address (ID of sensor)
00 00 00   destination address (0 = broadcast)
00   groupID??
02   payload (02=open, battery good, 00=closed)
72 D5   CRC


Can some help me to understand?

PS im from Germany, sorry for my bad english ;)
HMside
Starting Member
Starting Member
 
Posts: 1
Joined: February 2014

Re: ELV MAX! protocol description

Postby Massi » Mon Jul 07, 2014 2:33 pm

matthijskooijman wrote:I considered that, but I do not think there is any way to update the valve position directly. AFAIU you can only change the set temperature, which causes the thermostat to update the valve position appropriately. Since there is some kind of controller system (probably some kind of PID controller) that controls the valve position, it might not be wise to change the set temperature regularly, since I think that, even if you change it back right away, the internal state is probably influenced. Also, forcing the thermostat to do a valve position change every 30 minutes might be bad for battery life as well.

I'm thinking that the ELV Max! system is useful if you want to set temperatures and let the thermostats determine the valve positions from that, but if you want more control, the system is perhaps not so useful (not sure if there are useful alternatives, though).

For getting the actual temperatures in my house, I'm planning to buy a few wall thermostats and only use them in the two or three most important rooms for measurements. As an additional advantage, their temperature sensors are not attached to the radiator, which should make them more reliable anyway.


Just for reference:
for WALL thermostat, when the actual temp is higher than 25.5°, last byte of L response (12th) starts from 0 again and is added a bit 1 to the "target temp" byte (the 8th byte, added 1 as MSB). So reading, if not managed, get's wrong (target temp 64° too high and actual temp 25.5° too low)
Had to update my php script :)

For RADIATOR thermostat "target temp" doesn't change, and i can't see actual temp in the L response, but i'm not that interested indeed (i've all wall thermostat)

Has anyone found a good walkthrough for SENDING command? I can only send "temporary" command, but not weekly program..
Massi
Member
Member
 
Posts: 51
Joined: November 2013

Re: ELV MAX! protocol description

Postby pbrand » Thu Sep 18, 2014 8:55 pm

Massi wrote:Has anyone found a good walkthrough for SENDING command? I can only send "temporary" command, but not weekly program..


You can send a weekprogram with the S: command.

The data bytes are (values in hex here):

Code: Select all
        /// 00:  00                                  ; always 00
        /// 01:  00 or 04                            ; 04 if a roomid is used, otherwise 00
        ///                                                When a roomid is used, the command is executed for all
        ///                                                thermostat devices in that room.
        ///                                                When a roomid of 0 is used, the command is executed for all
        ///                                                thermostat devices connected to the cube.
        /// 02:  command                             ; 10 = week profile configuration
        /// 03:  000000                              ; always 000000
        /// 06:  address                             ; 03f25d address of thermostat
        /// 09:  roomid                              ; id of the room; 00 when not used
        /// 0A:  day + index                         ; day of week for profile + index of profile (first 7 or
        ///                                            remaining 6 set points)
        ///                                               Bit 5 contains the index. 0 is the first seven days
        ///                                               1 is the remaining six days.
        ///                                               4 LSB bits contain the day. 00 is Saturday
        ///                                                through 06 is friday.
        /// 0B:  Week Program                        ; Schedule for day
        ///                                               Each schedule consists of 7 + 6 words (2 bytes) e.g. set points
        ///                                               1 set point consist of
        ///                                                    7 MSB bits is temperature set point (in degrees * 2)
        ///                                                    9 LSB bits is time (in minutes / 5)
        ///                                               First 7 set points are sent when index == 00
        ///                                               Remaining 6 set points are sent when index == 01


I hope to have some time soon to post a new blog on my site about the S: command.
pbrand
Member
Member
 
Posts: 100
Joined: October 2008
Location: Netherlands

Re: ELV MAX! protocol description

Postby Massi » Mon Sep 22, 2014 12:45 pm

yeeeeeee i was missing this!!

Code: Select all
02:  command                             ; 10 = week profile configuration


so this is 10 for week and 40 for working mode.
Now i'm expecting at least another code to send device configuration..
It seems to me that for week profile configuration the rf address of devices is useless..

Thanks a lot!
Massi
Member
Member
 
Posts: 51
Joined: November 2013

Re: ELV MAX! protocol description

Postby pbrand » Mon Sep 22, 2014 1:54 pm

Hi Massi,

I know of (and have implemented in my Max gateway) the following commands:

0x10 Thermostat Week Program
0x11 Configure Thermostat (eco temperature, maximum setpoint temperature, minimum setpoint temperature, temperature offset, window open temperature, window open duration)
0x12 Configure Valve (Boost, Decalcification, Max Valve Setting, Valve Offset)
0x40 Set Temperature (and Mode)
0x43 Set To Comfort Temperature
0x44 Set To Eco Temperature
0x82 Set Display Actual Temperature (wall thermostat only)

Regards,
Peter
pbrand
Member
Member
 
Posts: 100
Joined: October 2008
Location: Netherlands

Re: ELV MAX! protocol description

Postby Massi » Mon Sep 22, 2014 2:01 pm

wow, looking forward to your blog post :)
i was using only the 40 value..
Massi
Member
Member
 
Posts: 51
Joined: November 2013

Re: ELV MAX! protocol description

Postby labtec » Mon Sep 22, 2014 4:24 pm

Hi

When I read this topic, I don't get it at all :) I also have a ELV Max cube with a room thermostat and two radiator valves.

Is there list of commands available for using in HS2/HS3 for controlling the cube?

I don't know anything about programming :)

I.e. set the temperature, boost, etc

Thanks
labtec
Member
Member
 
Posts: 243
Joined: October 2010

Re: ELV MAX! protocol description

Postby pbrand » Tue Sep 23, 2014 8:15 am

Sorry can't help you there. I don't use Homeseer.

I have written a MAX! gateway myself (as a windows service) which acts on MQTT messages and translates them to commands which are then sent to the MAX! cube.

In that way I can choose any domotica controlling software I like without the necessity to change the MAX! control software when switching to a new domotica tool. The domotica software then only has to be able to send and receive MQTT messages.

But I'm sure there are users here who use homeseer. In fact I believe there's a separate topic that has a homeseer script to control the MAX!

Use the search and I'm sure you'll find it.
pbrand
Member
Member
 
Posts: 100
Joined: October 2008
Location: Netherlands

Re: ELV MAX! protocol description

Postby Massi » Tue Sep 23, 2014 8:56 am

pbrand wrote:I have written a MAX! gateway myself (as a windows service) which acts on MQTT messages and translates them to commands which are then sent to the MAX! cube.


ahahaha so i'm not the only one in the world using MQTT for domotica projects :)
i'm using it on my Raspberry for other things.. i'm managing my MAX devices through a PHP Class, but at the moment it just reads values (or set fixed temp), it does not manage the full system..

Are you planning to release your software open source? do you think a porting to linux could be done? :)
Massi
Member
Member
 
Posts: 51
Joined: November 2013

Re: ELV MAX! protocol description

Postby pbrand » Tue Sep 23, 2014 9:18 am

Massi wrote:Are you planning to release your software open source? do you think a porting to linux could be done? :)


Hi Massi,

I am not a developer who wants to hide his software, so when it's stable anyone who wants it can have it. It's written in C#.NET so in theory it should be portable to linux using mono. However, since I have much to do yet in my home automation it has a very low priority as I don't have the time to look in to that on a short or medium long term :mrgreen:

My original plan was to write it for the raspberry in Mono, but developing for the rasperbery, if your are a dot net developer, is not so straight forward. Also the performance of the raspberry lacks in peformance for some heavier services.

So I decided to use the raspberry for my Razberry only (which also has a web interface I can use) and use a windows server to host my home automation components.

My MAX! Gateway supports all the messages I mentioned in my previous reply and it also sends temperatures etc on a regular basis. All through MQTT.

It is combined with a service which publishes a google calendar to MQTT (the calendar contains my heating schedule) and a separate service which reads the calendar and MAX! MQTT messages to control the MAX! based on the temperatures in my google calendar.
pbrand
Member
Member
 
Posts: 100
Joined: October 2008
Location: Netherlands

Re: ELV MAX! protocol description

Postby Massi » Tue Sep 23, 2014 2:35 pm

Ok so i'll wait for the blog post and the protocol description indeed :)
Massi
Member
Member
 
Posts: 51
Joined: November 2013

Re: ELV MAX! protocol description

Postby Error323 » Mon Nov 10, 2014 2:10 pm

Hi All,

For my attempt in home automation I want to bypass the cube completely and control the valves directly via a 868 MHz transceiver. Does anybody here know the internal protocol between cube and valve components? I can't seem to find it anywhere, is it FHT based or completely different?

My plan is to control my boiler and all radiator valves via an arduino (control) and a raspberrypi (user interface). In my attempt to achieve this I've ordered the following hardware.
  • The eq-3 MAX! wireless valves
  • wifi module RFM12B
  • Arduino
  • realtime clock, the DS3231
  • Raspberrypi
  • HDMI display with touchscreen

Cheers,
Error323
Error323
Starting Member
Starting Member
 
Posts: 5
Joined: November 2014

Re: ELV MAX! protocol description

Postby Digit » Mon Nov 10, 2014 11:45 pm

Google "ELV MAX FHEM"
User avatar
Digit
Global Moderator
Global Moderator
 
Posts: 3388
Joined: March 2006
Location: Netherlands

PreviousNext

Return to Homematic, FS20, FHT, ESA and ELV

Who is online

Users browsing this forum: No registered users and 1 guest