Max - transmission bps, message sizes?

Begonnen von malc_b, 29 Januar 2016, 09:30:43

Vorheriges Thema - Nächstes Thema

malc_b

Hi,

Does anyone know the bps of max cube transmissions?  Searching on the net I found info on the message bytes so if I knew the bps I could know the message time and hence what fraction of 1% a message was.  Of course I could also do with knowing message overhead, crc, stops bits, but I could assume that's small and ignore it.

I've tried Max Support email who "helpfully" pointed out that 36s per hour is 1%, yes I could have worked that out, thanks.  When pushed by my pointing out that message = 1ms, or message  = 1s make a vast difference they said message length varies depending on component (I knew that too) but message will be < 1s (I could have guessed as 36 messages per hour limit hardly makes a workable system).

The reason for this is that I'm playing around with tablet ui.  I've put buttons on the thermostat but this results in a message for every 0.5C change.  I think I need to throttle this.  Unless of course MAXLAN.pm or 00_MAX.pm  already has a throttle built in?  I guess it might be easier to throttle in fhem rather than tablet-ui as I haven't worked out how the thermostat works in tablet-ui.

What I'm thinking of is forwarding all messages through say something called TMAX.  TMAX would store messages and overwrite the same type, i.e. temperature change, that way only the last button push would be captured.  Then after say 2s of no activity it would forward the messages on to MAX.
But does MAX/MAXLAN already do that?

fruit

Zitat von: malc_b am 29 Januar 2016, 09:30:43Does anyone know the bps of max cube transmissions?
Are you asking about messages to/from fhem/MAX software?
If so you can monitor traffic with wireshark or similar, that may give you some idea.

Other than that there is a lot of MAX info in the archive section of the forum. Another useful source is http://www.domoticaforum.eu/viewforum.php?f=66&sid=9273afd49c61c49ac7022564f0a22693
Feel free to follow up in German if you prefer

rudolfkoenig

Although I am not a MAX expert, i guess a message is about 30ms: 4preamble+4sync+30content+cs = 40Bytes. 40Bytes @ 10kBaud = 32ms. Note that each message gets ACKed (which is about half the size), and if the ACK is not received, the message is resent (up to three times in total).
For details take a look at culfw/clib/rf_moritz.c, which is easier to read if you also have the CC1101.pdf at hand.

malc_b

Thanks fruit and rudolfkoenig

Wireshark is a good idea.  That will tell me if max on fhem is throttling.  And the links looks useful too.

So 36s/hr is roughly 1000 msg/hr but message + ack is ~ 1.5 msg so 667 msg/hr or ~ 10 per minute.  Throttle is a must as tapping up/down buttons would easily exceed that.

fruit

Dutycycle (amount of 1% rule used) is reported in fhem and also available from the messages - somewhere
You may be able to get some idea of what is going on by sending different length messages, weekprofiles perhaps, whilst watching dutycycle level

John of MaxScanner may know more on this as his module monitors dutycycle/credits I believe. If you are lucky he may see this thread :)
Feel free to follow up in German if you prefer

malc_b

I've found the duty cycle.  I had set poll interval to 10s that gives a duty cycle of 3 (%?).  If I hit it with a lot of thermostat changes the duty cycle hits 29.  It's very slow to drop back so maybe that is over an hour.  I've set maxlan back to default polling (60s?).  I'll have to play with this and see what I can deduce.

Does anyone know is dutycycle in % and what does freememoryslot relate to?

fruit

I'm sure I have seen mention of timescales but may not be for MAX.
The standard is available somewhere online but not easy to find and probably irrelevant for your purposes.
https://en.wikipedia.org/wiki/Short_Range_Devices For some information

No idea on how dutcycle is extracted but the module may give you some hints or the domotica link above or another link from https://github.com/Bouni/max-cube-protocol/blob/master/protocol.md
See the module too for freememoryslot, perhaps what can be queued in the Cube?
Feel free to follow up in German if you prefer

malc_b

How many devices can the cube pair with?  No messages sent by cube for ages as I've been out.  Still says 49 free memory slots.  I have one paired device so if cube can pair with 50 devices that would make sense.

Duty cycle still said 29 even after refreshing the page, so I sent a change temperature command.  Duty cycle dropped to 0.  So it looks like you have to do something for the duty cycle to update, at least in fhem.

fruit

Zitat von: malc_b am 29 Januar 2016, 17:38:25How many devices can the cube pair with?
50 according to the FAQ I have here - if more then dutycycle issues/delays may occur
Zitatsays 49 free memory slots.
Mine too - with 9 or 10 devices :)
ZitatDuty cycle still said 29
Mine is 1% at present.
My guess is that if nothing else has been updated since then you won't get to see any changes in dutycycle
Add a Filelog to the Cube and it will log dutycycle for you

The FAQ may give you a bit more info on the things you are looking for. I don't have a link but search for FAQ_1784_MAX_FAQs_20120810.pdf and you should at least find something
Feel free to follow up in German if you prefer

malc_b

DOH, 50 -1 device = 49 was so attractive too.

If I do nothing for a while when I look dutycycle is zero.  Send 1 message and it jumps to 3.  If I click like mad to send lots of messages I can get it to hit 100 and then freememoryslot is zero.  I think dutycycle means % of 1%, i.e. 100% = 1%.  It won't go above 100%.  It's now stuck at 100% and freememoryslots is 0 (I'm doing set reconnect to trigger an update of cube status).  I can only think that it will now wait an hour, then send the queued messages.  I'll have to test that when I have a free hour to watch it  ::) 

fruit

Zitat von: malc_b am 29 Januar 2016, 19:24:51I think dutycycle means % of 1%
I'm sure it does
ZitatI can only think that it will now wait an hour
Have a read of that FAQ, it seems to suggest the unit may be a minute - but that may be poor translation - and I'm not sure a minute complies with the standard.

I suspect longest sent message will be something like
set MAX_075bb2 weekProfile Fri 15.5,01:00,16,02:00,16.5,04:00,17,06:00,19,08:00,19,10:00,18.5,12:00,19,14:00,20,16:00,20,18:00,19,20:00,18,22:00,16
one day with maximum switches (I think), change the device to yours and day of the week, send one for each day and see how you get on :)
Feel free to follow up in German if you prefer

ggaljoen

#11
Zitat von: malc_b am 29 Januar 2016, 09:30:43
Does anyone know the bps of max cube transmissions?

The CC1101 uses the spi control protocol, the clock frequency is 2 MHz by the original communication. (see attachment)

Zitat von: malc_b am 29 Januar 2016, 09:30:43
Searching on the net I found info on the message bytes so if I knew the bps I could know the message time and hence what fraction of 1% a message was.  Of course I could also do with knowing message overhead, crc, stops bits, but I could assume that's small and ignore it.

I found a lot of information overhere:
Erwan's Blog - Arduino : use a Texas CC1101
Daniel Berenguer - panStamp project
Matthijs Kooijman - ELV Max! Arduino sketch
Rudolf Koenig - culfw
Bjoern Hempel - a-culfw

Zitat von: malc_b am 29 Januar 2016, 09:30:43
The reason for this is that I'm playing around with tablet ui.  I've put buttons on the thermostat but this results in a message for every 0.5C change.  I think I need to throttle this.  Unless of course MAXLAN.pm or 00_MAX.pm  already has a throttle built in?

I think it is a good idea to handle a delayed-send event for this use, not needless using up credits.

Zitat von: malc_b am 29 Januar 2016, 09:30:43
What I'm thinking of is forwarding all messages through say something called TMAX.  TMAX would store messages and overwrite the same type, i.e. temperature change, that way only the last button push would be captured.  Then after say 2s of no activity it would forward the messages on to MAX.
But does MAX/MAXLAN already do that?

I am not that far with my project but it is on my wishlist.
Gg.

malc_b

I think I probably don't need to know the actual speed as I have the answer to main question.

I need throttle and not send unnecessary messages

I can tell the % used of the 1% allowed from maxlan in fhem.  When that hits 100% it stops sending messages.  One set temperature message is 3%.  This 3% dutycycle stays for over 45mins.  I'd guess it hit the hour.

ggaljoen

Zitat von: malc_b am 30 Januar 2016, 13:32:20
I need throttle and not send unnecessary messages

I can tell the % used of the 1% allowed from maxlan in fhem.  When that hits 100% it stops sending messages.  One set temperature message is 3%.  This 3% dutycycle stays for over 45mins.  I'd guess it hit the hour.

What RF device do you use?
If it really gets critical, you can adjust the credits (firmware dependent) in your benefit  ;)

malc_b

Max cube.  But what are credits I haven't able to find the answer to that.  Or alternately what does adjusting the credits do?