Home Automation Domotica Forum Europe, Bwired Forum

Posted: **Mon Feb 10, 2014 10: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

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!

Posted: **Mon Feb 10, 2014 10:40 pm**

Good to see that my assumptions were correct, Massi

Posted: **Wed Feb 26, 2014 12:53 pm**

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

Posted: **Mon Jul 07, 2014 3: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..

Posted: **Thu Sep 18, 2014 9: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.

Posted: **Mon Sep 22, 2014 1: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!

Posted: **Mon Sep 22, 2014 2: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

Posted: **Mon Sep 22, 2014 3:01 pm**

wow, looking forward to your blog post

i was using only the 40 value..

Posted: **Mon Sep 22, 2014 5: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

Posted: **Tue Sep 23, 2014 9: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.

Posted: **Tue Sep 23, 2014 9: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?

Posted: **Tue Sep 23, 2014 10: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

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.

Posted: **Tue Sep 23, 2014 3:35 pm**

Ok so i'll wait for the blog post and the protocol description indeed

Posted: **Mon Nov 10, 2014 3: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

Posted: **Tue Nov 11, 2014 12:45 am**

Google "ELV MAX FHEM"

Home Automation Domotica Forum Europe, Bwired Forum

ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description

Re: ELV MAX! protocol description