Home Automation Domotica Forum Europe, Bwired Forum

Hi all again,
i need some help understanding how to send commands to the cube.
It's not something concerning how to create the message, is just HOW to sent it. In details, every time i open a connection to the cube, it starts sending me standard response (H,M,C,L) and if i try to brutally write a s: command to the connection channel, it seems to have no effect.
So, is there something i am loosing?
Do you send commands on the same channel where you read informations?

I keep the connection open all the time. No problems..

I mistakenly send the a: command during testing. And I can confirm that it worked

I would advice against trying that yourself by the way

Perhaps your s: message has the wrong syntax and is therefore ignored by the cube? What happens when you send an l: message? The cube should then respond with the L: message. This is an easy test because there are no parameters: l:\r\n will suffice.

I gather that you are waiting until you have received the initial response messages before you send messages yourself?

yes, but now that i know that you keep the connection open i can work on it without loosing my time
i will not hesitate coming back to you

Edit: it was a blocking mode problem on the socket. Now i'm up and running Thanks again!

hello all again
now i can easily set the heating mode of every room/device with s: command.
But i can't figure out how to set the WEEKLY program of a room/device!
I saw some examples in the second page of this thread, but i can't understand them.
first: if the format of the message is the same inserted in the first post, how can the cube understand if i'm setting the heating mode or the weekly program? is that the third byte that (in hex) seems to be 10 instead of 40?
More than this, in the decoding (working!) section, a weekly program is 26bytes long for each week day. Examples in the second page are mush shorter than this!
Help

MarnixT wrote:thanks to Robert Hekkers code I got some responses from my cube. It seems the cube confirms the s: command with S:. Sorry if I missed it, but doesn't seem to be mentioned in this thread. What does it mean?

Code: Select all

> s:AARAAAAABjVGBGEAAAA= (temp=16,5)
< S:07,0,31

also got

Code: Select all

S:01,0,31

last time I tried

i think that the first piece (in your examples, 07 and then 01) is the % (in hex) of duty cycle used.
I think that the cube answers the new value for every command you send. You can read this value also in the H: response of the cube.

Massi wrote:

MarnixT wrote:thanks to Robert Hekkers code I got some responses from my cube. It seems the cube confirms the s: command with S:. Sorry if I missed it, but doesn't seem to be mentioned in this thread. What does it mean?

Code: Select all

> s:AARAAAAABjVGBGEAAAA= (temp=16,5)
< S:07,0,31

also got

Code: Select all

S:01,0,31

last time I tried

i think that the first piece (in your examples, 07 and then 01) is the % (in hex) of duty cycle used.
I think that the cube answers the new value for every command you send. You can read this value also in the H: response of the cube.

The first byte is indeed the duty cycle.
The second byte indicates whether the command has been discarded (0 = ok, 1 is discarded)
The third byte is the free memory slots.

Both duty cycle and free memory slots are indeed also returned in the H: repsonse.

pbrand wrote:The second byte indicates whether the command has been discarded (0 = ok, 1 is discarded)

And a new control point has born for my script
Thanks!

Hi All,

I started working on a decoder for the complete protocol. It is a windows app, written in C#.

I wanted to share my progress so far.
The source is shared through GitHub at: https://github.com/JinxNL/MaxDecoder

Let me know if you are interested in helping to complete all functions.

Thanks,

Erik

hello,
only decoder?
why don't you open a dedicated thread? i'm not able to code in c#, but i'd be happy to help (if i can..) in protocol decoding..
bye

I would say this ís the dedicated thread for decoding the MAX! protocol, so why open a new thread for it, Massi?

The language in which we want to use the decoded protocol, in my case for example C#, is not important for the decoding process itself

pbrand wrote:I would say this ís the dedicated thread for decoding the MAX! protocol, so why open a new thread for it, Massi?

i thought that a dedicated thread for a decoding app could work better, for example to talk about app features or coding problems..
But i know you are always right so for me it's ok even in this 3ed

Ant help for me for setting weekly program?

Massi wrote:i thought that a dedicated thread for a decoding app could work better, for example to talk about app features or coding problems..

You could be right about a thread dedicated to app features and so on. But let's keep the protocol part is this thread

Massi wrote:But i know you are always right <snap>

Please pass this belief on to my girfriend

Massi wrote: Ant help for me for setting weekly program?

I for one have done nothing yet with the s: message. I'm still coding my gateway for decoding of all info in the H:, M:, C: and L: messages.

When I come to the s: message, I shall try to answer youer question if I can.

pbrand wrote:Please pass this belief on to my girfriend

you know, women are out of human rules

Massi wrote:I for one have done nothing yet with the s: message. I'm still coding my gateway for decoding of all info in the H:, M:, C: and L: messages.

i'm checking your blog for this
i'm even trying to understand what the information about "free memory slots" can be used for.. (in H response)
maybe Clock Set could be something about DST?

Massi wrote: i'm even trying to understand what the information about "free memory slots" can be used for.. (in H response)
maybe Clock Set could be something about DST?

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