Not enough credit!

[mflammia1]

Hi there,

I know this subject is a very common one, and looked at all the posts I can find, although it is sometimes difficult for me to understand in the translate from German to English.

Currently in the process of trying to work out why I am getting messages of not enough credit and missing ack in my log files, as per below:

2016.10.31 10:42:53.883 2: CUL_MAX_SendQueueHandler: Missing ack from 0de0a2 for 0fbe04031234560de0a200101f0aaab2
2016.10.31 10:42:53.925 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 4, but we need 113. Waiting 109 seconds.
2016.10.31 10:44:42.935 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 112, but we need 113. Waiting 1 seconds.
2016.10.31 10:44:50.461 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 113. Waiting 106 seconds.
2016.10.31 10:46:36.467 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 112, but we need 113. Waiting 1 seconds.
2016.10.31 10:46:43.993 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 113. Waiting 106 seconds.
2016.10.31 10:48:30.011 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 112, but we need 113. Waiting 1 seconds.
2016.10.31 10:48:37.536 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 113. Waiting 106 seconds.
2016.10.31 10:50:23.549 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 112, but we need 113. Waiting 1 seconds.
2016.10.31 10:50:28.051 2: CUL_MAX_SendQueueHandler: Missing ack from 0f78a4 for 0f5e04031234560f78a400101f0ab298

In order to do that I've enable verbose 5, and the output now looks like the following:

2016.10.31 13:52:16.094 5: CUL_0 sending Zs0f6204031234560f78d800101f0db490
2016.10.31 13:52:16.095 5: SW: Zs0f6204031234560f78d800101f0db490
2016.10.31 13:52:19.591 2: CUL_MAX_SendQueueHandler: Missing ack from 0f78d8 for 0f6204031234560f78d800101f0db490
2016.10.31 13:52:19.604 5: SW: X
2016.10.31 13:52:19.616 5: CUL/RAW (ReadAnswer): 21  360

2016.10.31 13:52:19.626 5: CUL_0 sending Zs0f5c04031234560ddfde00101f0db493
2016.10.31 13:52:19.628 5: SW: Zs0f5c04031234560ddfde00101f0db493
2016.10.31 13:52:26.126 5: SW: X
2016.10.31 13:52:26.138 5: CUL/RAW (ReadAnswer): 21  253

2016.10.31 13:52:26.149 5: CUL_0 sending Zs0f5c04031234560ddfde00101f0db49a
2016.10.31 13:52:26.150 5: SW: Zs0f5c04031234560ddfde00101f0db49a
2016.10.31 13:52:32.498 5: SW: X
2016.10.31 13:52:32.510 5: CUL/RAW (ReadAnswer): 21  146

2016.10.31 13:52:32.527 5: CUL_0 sending Zs0f5c04031234560ddfde00101f0db4a0
2016.10.31 13:52:32.529 5: SW: Zs0f5c04031234560ddfde00101f0db4a0
2016.10.31 13:52:39.023 5: SW: X
2016.10.31 13:52:39.035 5: CUL/RAW (ReadAnswer): 21   40

2016.10.31 13:52:39.043 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 40, but we need 113. Waiting 73 seconds.
2016.10.31 13:52:44.500 5: CUL/RAW: /Z0C3F044
2016.10.31 13:52:44.504 5: CUL/RAW: Z0C3F044/20F79110DE0A2003
2016.10.31 13:52:44.507 5: CUL/RAW: Z0C3F04420F79110DE0A2003/0F219

2016.10.31 13:52:44.509 4: CUL_Parse: CUL_0 Z0C3F04420F79110DE0A20030F219 -61.5
2016.10.31 13:52:44.512 5: CUL_0 dispatch Z0C3F04420F79110DE0A20030F2
2016.10.31 13:52:44.515 5: CUL_MAX_Parse: len 12, msgcnt 3F, msgflag 04, msgTypeRaw WallThermostatControl, src 0f7911, dst 0de0a2, groupid 0, payload 30F2
2016.10.31 13:52:44.516 5: CUL_MAX_Parse: rssi: -61.5
2016.10.31 13:52:44.548 5: CUL/RAW: /Z0E3F020
2016.10.31 13:52:44.552 5: CUL/RAW: Z0E3F020/20DE0A20F7911000
2016.10.31 13:52:44.556 5: CUL/RAW: Z0E3F02020DE0A20F7911000/109003016

2016.10.31 13:52:44.557 4: CUL_Parse: CUL_0 Z0E3F02020DE0A20F7911000109003016 -63
2016.10.31 13:52:44.560 5: CUL_0 dispatch Z0E3F02020DE0A20F79110001090030
2016.10.31 13:52:44.563 5: CUL_MAX_Parse: len 14, msgcnt 3F, msgflag 02, msgTypeRaw Ack, src 0de0a2, dst 0f7911, groupid 0, payload 01090030
2016.10.31 13:52:44.564 5: CUL_MAX_Parse: rssi: -63
2016.10.31 13:53:15.449 5: CUL/RAW: /Z0C3F044
2016.10.31 13:53:15.453 5: CUL/RAW: Z0C3F044/20F79390DDFDE002
2016.10.31 13:53:15.457 5: CUL/RAW: Z0C3F04420F79390DDFDE002/2DD1B

2016.10.31 13:53:15.458 4: CUL_Parse: CUL_0 Z0C3F04420F79390DDFDE0022DD1B -60.5
2016.10.31 13:53:15.461 5: CUL_0 dispatch Z0C3F04420F79390DDFDE0022DD
2016.10.31 13:53:15.465 5: CUL_MAX_Parse: len 12, msgcnt 3F, msgflag 04, msgTypeRaw WallThermostatControl, src 0f7939, dst 0ddfde, groupid 0, payload 22DD
2016.10.31 13:53:15.466 5: CUL_MAX_Parse: rssi: -60.5
2016.10.31 13:53:15.498 5: CUL/RAW: /Z0E3F020
2016.10.31 13:53:15.501 5: CUL/RAW: Z0E3F020/20DDFDE0F7939000
2016.10.31 13:53:15.505 5: CUL/RAW: Z0E3F02020DDFDE0F7939000/10900221A

2016.10.31 13:53:15.507 4: CUL_Parse: CUL_0 Z0E3F02020DDFDE0F793900010900221A -61
2016.10.31 13:53:15.509 5: CUL_0 dispatch Z0E3F02020DDFDE0F79390001090022
2016.10.31 13:53:15.512 5: CUL_MAX_Parse: len 14, msgcnt 3F, msgflag 02, msgTypeRaw Ack, src 0ddfde, dst 0f7939, groupid 0, payload 01090022
2016.10.31 13:53:15.513 5: CUL_MAX_Parse: rssi: -61
2016.10.31 13:53:24.351 5: CUL/RAW: /Z0C42044
2016.10.31 13:53:24.354 5: CUL/RAW: Z0C42044/20F78EF0
2016.10.31 13:53:24.358 5: CUL/RAW: Z0C4204420F78EF0/DDFE1002AE141

2016.10.31 13:53:24.359 4: CUL_Parse: CUL_0 Z0C4204420F78EF0DDFE1002AE141 -41.5
2016.10.31 13:53:24.362 5: CUL_0 dispatch Z0C4204420F78EF0DDFE1002AE1
2016.10.31 13:53:24.365 5: CUL_MAX_Parse: len 12, msgcnt 42, msgflag 04, msgTypeRaw WallThermostatControl, src 0f78ef, dst 0ddfe1, groupid 0, payload 2AE1
2016.10.31 13:53:24.366 5: CUL_MAX_Parse: rssi: -41.5
2016.10.31 13:53:24.399 5: CUL/RAW: /Z0E42020
2016.10.31 13:53:24.403 5: CUL/RAW: Z0E42020/20DDFE10
2016.10.31 13:53:24.406 5: CUL/RAW: Z0E4202020DDFE10/F78EF000109002A4
2016.10.31 13:53:24.410 5: CUL/RAW: Z0E4202020DDFE10F78EF000109002A4/E

2016.10.31 13:53:24.411 4: CUL_Parse: CUL_0 Z0E4202020DDFE10F78EF000109002A4E -35
2016.10.31 13:53:24.414 5: CUL_0 dispatch Z0E4202020DDFE10F78EF000109002A
2016.10.31 13:53:24.417 5: CUL_MAX_Parse: len 14, msgcnt 42, msgflag 02, msgTypeRaw Ack, src 0ddfe1, dst 0f78ef, groupid 0, payload 0109002A
2016.10.31 13:53:24.418 5: CUL_MAX_Parse: rssi: -35
2016.10.31 13:53:52.026 5: SW: X
2016.10.31 13:53:52.038 5: CUL/RAW (ReadAnswer): 21  113

2016.10.31 13:53:52.048 5: CUL_0 sending Zs0f5c04031234560ddfde00101f0db5b4
2016.10.31 13:53:52.050 5: SW: Zs0f5c04031234560ddfde00101f0db5b4
2016.10.31 13:53:55.544 2: CUL_MAX_SendQueueHandler: Missing ack from 0ddfde for 0f5c04031234560ddfde00101f0db5b4

So now I have this information I'm struggling to workout what its telling me, for example a single entry that shows "Not enough credit! credit10ms". I can't see anything in the config that marry's up with any of those numbers?:

2016.10.31 13:52:39.043 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 40, but we need 113. Waiting 73 seconds.
2016.10.31 13:52:44.500 5: CUL/RAW: /Z0C3F044
2016.10.31 13:52:44.504 5: CUL/RAW: Z0C3F044/20F79110DE0A2003
2016.10.31 13:52:44.507 5: CUL/RAW: Z0C3F04420F79110DE0A2003/0F219

Or for an entry that show Missing Ack, other than I know its referring to "define MAX_Spare_Bedroom_TVR MAX HeatingThermostat 0ddfde". My assumption here is possibly a bad signal?

2016.10.31 13:53:52.048 5: CUL_0 sending Zs0f5c04031234560ddfde00101f0db5b4
2016.10.31 13:53:52.050 5: SW: Zs0f5c04031234560ddfde00101f0db5b4
2016.10.31 13:53:55.544 2: CUL_MAX_SendQueueHandler: Missing ack from 0ddfde for 0f5c04031234560ddfde00101f0db5b4

I'm also not aware that I have configured anything for FHEM to send anything, I'm basically just logging information at the moment. In fact what has led me to this is that I can't seem to send anything to my MAX! wall thermostats like desired temperature and schedule, and first trying to resolve the 'Not enough credit!" before moving forward.

It maybe possible that something is happening that I not aware of, but appreciate if anyone can decipher the messages for me.

Many thanks in advance

[fruit]

Wait for things to go quiet, it should in a while but don't send any more commands in the meantime.

If you really want to parse the commands look in the MAX and CUL modules sources as well as some of the early posts in https://forum.fhem.de/index.php?board=4.0 and others such as http://www.domoticaforum.eu/viewforum.php?f=66&sid=edcccb74dd9eec5d7e7d7f3d9dd94409. Perhaps this one too https://github.com/Bouni/max-cube-protocol/blob/master/protocol.md

[mflammia1]

Thanks for posting.

Part of the problem is there doesn't ever seem to be a quiet moment, these messages are continuous, getting messages around every 10 - 15 seconds or so which probably explains why I'm running out of credit.

Still, even though looking at the sites you have posted I can't work out what the verbose information is telling me, (although I believe you suggested those just for the parse commands) - any ideas?

With reference to sending parse commands, I believe it shouldn't be anymore difficult then say submitting the following:

set MAX_Bathroom_Thermostat desiredTempreture 22.0

Would that be right, perhaps for a TVR that you are familiar with, does that work?

So think I probably need to concentrate on fixing my credit issue first.

Sorry to be persistent but the Not Enough Credit issue has been challenging me for sometime and be really good to get to bottom of it or find an article that is really good at explaining / interpreting it and some examples of what I can do about it.

An explanation would be useful or I could tackle this by striping my config and putting it back piecemeal, but would be really nice to understand and diagnose what the verbose information is telling me.

Thanks.

[fruit]

A MAX system on it own will generate little traffic other than when valveposition or desiredTemperature changes.
It is commands that are sent to alter the stored autonomous weekProfile that generate traffic eg. increasing/decreasing desiredTemperature

If you are seeing lots of traffic something mut be sending commands eg. MaxScanner or similar
Just in case you have a rogue pairing command running somewhere save config then 'shutdown restart'

Code Auswählen Erweitern

set MAX_Bathroom_Thermostat desiredTempreture 22.0should be fine though all mine are aliased so I use device name eg.

Code Auswählen Erweitern

set MAX_075bdc ecoTemperature 15.0

Sorry to be persistent but the Not Enough Credit issue has been challenging me for sometime

I could send you pages of similar

would be really nice to understand and diagnose what the verbose information is telling me.

If you do not believe you are seeing queued command then see 14_CUL_MAX.pm sub
CUL_MAX_Parse($$), line 268 gives format. line 270 fields

[alangward]

Hi,
There is a hack to get round this:

https://blog.mjwconsult.co.uk/modifying-cul-firmware-to-increase-send-limit-for-eq3-max-heating-thermostats/

I have made this change to my CUNX system - which meant moving the changes to the (local) v2 branch of culfw.
It solved the problem.

Alan

[fruit]

That and similar hacks have been mentioned before. Whether it is a good idea to implement is a different matter.
I do not have an issue with the FW as is and only see credit warnings when updating some settings en masse or eg. weekProfiles. I plan updates accordingly

I seem to remember reading somewhere here a suggestion that the hack does not actually do what is hoped in the way expected but I cannot find that reference - perhaps I imagined it :\

[alangward]

Hi,
It works well for me.
Now when I press my 'Eco' switch all the devices get set very quickly and apparently reliably.

Alan

[chapelhill]

Can anyone point me to a web page to explain how to compile the firmware from source as I would like to have a go. I have read around, but virtually everything I find relates to compiling for the raspberry and not for other devices, or looks so complex that I suspect I would not successfully compile.

I had a quick look at the page for the hack, but I have the cube so I need to compile with the latest changes included.

I had a look at some of the changes from the hack and I would like to try differing variants with just a change to the clock routine to speed up process of getting back credits, but leave all other code unchanged as I suspect having some limits is going to be more reliable than having no limits.

I have had to reset three valves today and it takes hours before all the messages get through as I have around 18 radiators.

Thanks
Regards

[chapelhill]

I have done some tests with my cube and I think this is working but use at your own risk and comply with your local laws.
Rather than trying to stop the limits I have tried to return the credits back slightly faster depending on LED mode so we can adjust and could adjust dynamically using functions too.

NOTE You must set the led to off for normal operation and the cube boots with LED mode flashing which is 2. Use this in FHEM web
   Set culdevicename led 00

I could not find way to set mode to off for first boot.

credit10ms return is normal 1 credit per second with LED off
credit10ms return is 2 credits per second with LED ON
credit10ms return is 3 credit per second with LED flashing.

Based off version 1_23_02

Problem I have is with so many devices the backgound normal messaging uses most of the available credits so any updates can take a long time before being actioned. It does not require much extra to get to a reasonable level which is very similar to running two cubes side by side.

[malc_b]

Does anyone know the logic behind the 1% rule?  I would assume this is to allow multiple devices to use the same bandwidth, that is 1 device can only use 1% so there is space for up to 100 (in theory).  If all a house uses is max cube (or CUL) and max stats etc. does the 1% matter?  I suppose that some max slaves send messages off their own bat such as window open but if those messages are getting lost then you could make fhem/cube/cul scan devices and make it a simple 1 master, rest slaves situation where it would not matter if 100% BW was used by master.

[fruit]

Does anyone know the logic behind the 1% rule?  I would assume this is to allow multiple devices to use the same bandwidth

Pretty much that's it I think.
See https://www.ofcom.org.uk/__data/assets/pdf_file/0025/38095/final_report.pdf pp.14,15. I'm sure there will be many other references out there.

[malc_b]

Useful info.  So if I crowd the 868.3MHz what I need to worry about is wireless fire alarms (don't have one), car key fob, maybe, smart meters which I could live with.

[fruit]

No neighbours who you may upset?

[malc_b]

Good point.  My house is ~11m square and about 6m to nearest house.  I was thinking of putting cube central in the loft so it looked down through floors to the radiator heads.  Less brick to get in the way of the signal.  Path to next door would be through brick wall and then 6m of air (more really as 6m is horizontal distance), then their brick wall.  Signal should be reduced by the time it gets to them.  An alternative would be to metal clad a side wall and mount cube there.  Metal stops signal towards neighbours on one side and on the other they are even further away, plus the 11m of the house.  I think that sounds better.

[rubbertail]

If it is a question why this 1% rule is to be set: It's a legal issue as much as an interference one. In Germany at least, the 1% rule is written down in law. Of course, if noone is actually checking you might be fine, but if at some point one of the radio testers of the Bundesnetzagentur rings at your door and confiscates your equipment you probably have upset one of your neighbours.

Afaik these rules were generalized in Europe at least.

[malc_b]

Well I'm in UK so that's unlikely .

[rubbertail]

As i said - this sort of thing was generalized.... but i have no real idea on the situation elsewhere. It's just not very likely that the wavelength is completely free for everyone to use how he or she would like to.

[chapelhill]

Not sure if the 1% rule was properly thought out with two way communication as you would expect differing rule for cube than from radiator valves. I have been running single cube on the arm version of the cul software since it came out and using standard cube before that.

The cul firmware version wins hands down as it is reliable and you can see what the problem is.

Credits mainly becomes a problem when one of the devices gets some form of rf error which results in resending of data which consumes credit and this is perhaps why the rules were instigated.

Since the system stores the messages until there is credit availsble the messages should get through.

In dealing with rf error normally requires a factory reset of oroblem device and then resend schedule and any non standard settings. I think these rf errors are related to device associations but I need ro do some more experimentation to test now I have found way if tracking credit left more accurately.

I have a version of software which puts max credit to 3000 instead of 900 but still only starts with the default on boot 450 units so does not break 1% rule over an hour but just stores more up. If needed I can change speed of credit return based on led setting by factor of 2 or 3.

[malc_b]

I found the max cube original firmware would use up 1% and then wait 1 hour before sending any messages.  That is just usable.  Waiting 1hr to change the thermostat......

CUL fw looks to be better from what I can see as it adds back credits rather than waiting 1hr.

FYI as I live in the country then I don't see my going over the 1% limit as a problem (and I'm not sure if it is a legal limit in UK).  There is very little around I'm likely to interfere with, and as this is 1% per device then I could have multiple devices in my house and have the same effect.  Really the cube should be near unlimited and the radiator valves etc. have the 1% limit, or at least a 1% per device limit.  That's the same as having say 50 separate remote control devices.  Maybe culfw should have multiple rf ids so it can switch ids when it communicates with different max devices.  That would keep it "legal" at least as far as anyone monitoring could see .

[fruit]

If it is a question why this 1% rule is to be set: It's a legal issue as much as an interference one. In Germany at least, the 1% rule is written down in law. Of course, if noone is actually checking you might be fine, but if at some point one of the radio testers of the Bundesnetzagentur rings at your door and confiscates your equipment you probably have upset one of your neighbours.

Afaik these rules were generalized in Europe at least.

They do apply to the UK as well of course. I have come across the regs a coupe of times but they are nowhere where one would expect to find them from what I remember.

A long time a go in the days of the GPO (General Post Office, now Royal Mail and BT) there was a service affectionately known as 'Tinkerbell' who would trace and search out signals just like Bundesnetzagentur above I guess.
I am sure that service still exists in the UK but probably privatised - and with big fines to pay for it all!

[malc_b]

It is ofcom that regulates this.  I would imagine that the department tasked with radio interference investigation has larger concerns than SRDs in the licence free band.  The EU regulation is ESTI EN 300 220 which does say 1% limit.  However, Ofcom IR_2030 (IR2030/1/16 2010/0168/UK Oct 2010) says

"Techniques to access spectrum and mitigate interference that provide at least equivalent performance to the techniques described in harmonised standards adopted under Directive 1999/5/EC must be used. Alternatively a duty cycle limit of 1 % may be used."

Which is a more practical approach and more relaxed than EN 300 220.  I would argue that I could easily take steps to mitigate any interference, but that's specific to my location.  However, since there would be no difference between one cube running at say 3% and 3 cubes running at 1% then the one 3% cube meets the "equivalent performance" requirement.  That's especially when implemented as a x3 credit return which would give a 1% burst followed by another 1% followed by another 1% burst, in a 1 hour period.  That's the same as 3 cubes and synchronized to give even gaps too which is less interfering that 3 separate cubes which might generate a 3% burst.

[alangward]

I was interested to read above that there is an ARM version of the CUL software that can be flashed to a CUBE.
Can someone point me at where I might find this.

Thanks
Alan

[malc_b]

The thread is here

https://forum.fhem.de/index.php/topic,38404.0.html

it's mostly in german so you need google translate if you don't speak german.  I find chrome with the translate addin works best, the you can just right click and select translate to english if it doesn't happen automatically.  The first post has the main details but it is a bit sparse.  Post #28 has a docx with some helpful info in the post and especially in the attached docx.  Note that the latest (1.23.05) precompiled binaries on mediafire does NOT have the bootloader in it.  You need to look back through the older versions to find that (I think latest is 1.20.08).  The directory you want is CUBe of course.

NOTE not all Cubes have the right hardware and flashing is a one way street.  You can't restore the max firmware.

[medolino2009]

I have done some tests with my cube and I think this is working but use at your own risk and comply with your local laws.
Rather than trying to stop the limits I have tried to return the credits back slightly faster depending on LED mode so we can adjust and could adjust dynamically using functions too.

NOTE You must set the led to off for normal operation and the cube boots with LED mode flashing which is 2. Use this in FHEM web
   Set culdevicename led 00

I could not find way to set mode to off for first boot.

credit10ms return is normal 1 credit per second with LED off
credit10ms return is 2 credits per second with LED ON
credit10ms return is 3 credit per second with LED flashing.

Based off version 1_23_02

Problem I have is with so many devices the backgound normal messaging uses most of the available credits so any updates can take a long time before being actioned. It does not require much extra to get to a reasonable level which is very similar to running two cubes side by side.

Hallo,

first of thank you very much for this firmware...i flashed it on my Cube and it is working together with Pimatic... My question is about credits... My Power LED flash every second... what this means with credits ? I have 6 thermostats and credits are very very annoying... Is it possible to remove credits completely or make highest credits per hour possible ... would you be kind to make binary firmware for Cube with this possibility please ?

Thank you in advance

Best regards

Miki (NL)

[alangward]

Hi Malc_b
By looking around I had found some of the stuff on updating the Cube to a 'CUL'.
But I couldn't find the bootloader so you post has been very helpful.

Thanks,
Alan

[chapelhill]

Hallo,

first of thank you very much for this firmware...i flashed it on my Cube and it is working together with Pimatic... My question is about credits... My Power LED flash every second... what this means with credits ? I have 6 thermostats and credits are very very annoying... Is it possible to remove credits completely or make highest credits per hour possible ... would you be kind to make binary firmware for Cube with this possibility please ?

Thank you in advance

Best regards

Miki (NL)

Hi When led is off credits return at a rate of 1 per second, when led is on all the time credits return at 2 per second, when led is flashing credits return at 3 per second.

The formula I have is credits return at 1 + (led setting*2).
This could be changed to any number so that credits return faster than can be consumed but personally I would have thought a setting of a factor  of 10 would be the maximum given that we should have some limits in place.

I found that credits is usually a problem when there is a device with a problem causing retransmissions.

I prefer to run with 3000 credit limit and leave credit return at 1 per second. I can put all radiators (approx. 20) into eco mode without running out of credits and vice versa.If I want to change schedules for many radiators then that would be an instance of setting led to flashing so that credit returns faster just whilst I am doing it and set it back to standard once complete.

I don't have access to my code this week, but could send you another version with higher factor if you want at the weekend.

[medolino2009]

Hi When led is off credits return at a rate of 1 per second, when led is on all the time credits return at 2 per second, when led is flashing credits return at 3 per second.

The formula I have is credits return at 1 + (led setting*2).
This could be changed to any number so that credits return faster than can be consumed but personally I would have thought a setting of a factor  of 10 would be the maximum given that we should have some limits in place.

I found that credits is usually a problem when there is a device with a problem causing retransmissions.

I prefer to run with 3000 credit limit and leave credit return at 1 per second. I can put all radiators (approx. 20) into eco mode without running out of credits and vice versa.If I want to change schedules for many radiators then that would be an instance of setting led to flashing so that credit returns faster just whilst I am doing it and set it back to standard once complete.

I don't have access to my code this week, but could send you another version with higher factor if you want at the weekend.

Thank you so much for your answer... you are greatest...

I have 6 radiators... i have rules for getting real temperature from them... this cost many credits as you know... thats why i need higher limit... and yes...i have one radiator thermostat that don't get data sometimes...not sure why is that...when i reset pimatic (or max cube) it is ok again... but when it is not ok, and when it is not responding...i am getting transmission error....this cost also credits....

Flashing LED you mean Power LED right ? (Battery LED is always ON here)... This seeting i can't change trough Pimatic i think right ? (i shuld have FHEM there for or i didn't understand right ?)

I really look forward to get from you firmware with much higher credit limit (3000 as you say shuld be ok i think)...  (Shuld i send you my email adres in Private message so you can send it this way, or you going to post it in here )

Thank you so much...

Best regards

Miki (NL)

[malc_b]

The led mode can be set in fhem.  Just look at the set ... dropdown for the cube device.

Actually I think the led_mode variable can be set to any single hex digit, not just 0,1,2.  So I think set led 15 in fhem cube device would return 16 credits per second.

[chapelhill]

The led mode can be set in fhem.  Just look at the set ... dropdown for the cube device.

Actually I think the led_mode variable can be set to any single hex digit, not just 0,1,2.  So I think set led 15 in fhem cube device would return 16 credits per second.

Very good suggestion, although I am not sure what led would do, but it probably would not flash, would have to modify the code to deal with greater or equal to 2 rather than equal to 2 for flashing mode.

[medolino2009]

The led mode can be set in fhem.  Just look at the set ... dropdown for the cube device.

Actually I think the led_mode variable can be set to any single hex digit, not just 0,1,2.  So I think set led 15 in fhem cube device would return 16 credits per second.

Hallo

Thank you for suggestion, but i don use fhem....i use Pimatic and maxcul plugin... i don´t think it is possible to do this with this plugin...
Best solution for me would be what Chapelhill suggested in last post... to put credit limit always very high up in firmware (to 3000 or more per hour)... in dit case i don´t need to ¨look at it every couple hours¨ ... at this moment in my system biggest drawback is Max Cube because of this Credit problems... i bought 4 more thermostats, but can´t use them because of this...

So i am patiently waiting for another firmware from Chapelhill 

Best regards

Miki (NL)

[malc_b]

You could access the cube via telnet.  See here http://culfw.de/commandref.html .  I think the led setting is stored in eeprom so it might stick between reboots, otherwise you'd need to manually set it everytime you powered off.  In anycase it is something you could try now.

chapelhill - I checked the led code before I made that suggestion.  FYI it just tests the bits , with &1 and &2 so top bits are ignored.  If lsb is 0 led is off, if 1 led is on.  That is done once, then bit lsb+1 is checked each clock and the led toggled if it is set.  So as long as you are a bit flexible on the count you can have flashing or on or off as you wish.  The led flashing wasn't something I thought was important though as my cube will be out of sight. 

[medolino2009]

You could access the cube via telnet.  See here http://culfw.de/commandref.html .  I think the led setting is stored in eeprom so it might stick between reboots, otherwise you'd need to manually set it everytime you powered off.  In anycase it is something you could try now.

chapelhill - I checked the led code before I made that suggestion.  FYI it just tests the bits , with &1 and &2 so top bits are ignored.  If lsb is 0 led is off, if 1 led is on.  That is done once, then bit lsb+1 is checked each clock and the led toggled if it is set.  So as long as you are a bit flexible on the count you can have flashing or on or off as you wish.  The led flashing wasn't something I thought was important though as my cube will be out of sight.

So this means ethernet connection on Max Cube is still working (When i flashed CUL i connected Max Cube to  Raspberry Pi trough USB, my ethernet connection is not in use at a moment... will try this when i get home)

Thanx for suggestion

Best regards

Miki (NL)

[malc_b]

I've modded my cube if anyone wants the binary.  As I can't see a need for the led I've used all of that as it turns out that the led can be sent a byte and stores a byte in eeprom.  Indeed fhem complains if you don't send 01 rather than 1.  In this binary, based on a-culfw 1.23.05 the led byte top 2 bits are the credit10ms maximum multiplier, 900 x1- x4, and the bottom 6 bits are the credit10ms added per second, 1-64 so:

led = 00 would be max = 900, 1 credit/s, i.e. standard CUL
led = C0 would be max = 3600, 1 credit/s, i.e. like max cube
led = 0A would be max = 900, 10 credit/s, i.e. simulate 10 CULs

If anyone is interested this is the code I've added in clock.c, line 201, in place of the standard credit10ms increment

Code Auswählen Erweitern


{
    uint16_t max = MAX_CREDIT*(1+(led_mode >> 6));

    if (credit_10ms < max )
      credit_10ms += (1 + (led_mode & 0x3F));
    if (credit_10ms > max)
      credit_10ms = max;  //test > max always in case limit is changed
   
  }


I've not bothered to change any of the initialization code so max will start at 900 and ramp up to the new limit.

[medolino2009]

I've modded my cube if anyone wants the binary.  As I can't see a need for the led I've used all of that as it turns out that the led can be sent a byte and stores a byte in eeprom.  Indeed fhem complains if you don't send 01 rather than 1.  In this binary, based on a-culfw 1.23.05 the led byte top 2 bits are the credit10ms maximum multiplier, 900 x1- x4, and the bottom 6 bits are the credit10ms added per second, 1-64 so:

led = 00 would be max = 900, 1 credit/s, i.e. standard CUL
led = C0 would be max = 3600, 1 credit/s, i.e. like max cube
led = 0A would be max = 900, 10 credit/s, i.e. simulate 10 CULs

If anyone is interested this is the code I've added in clock.c, line 201, in place of the standard credit10ms increment

Code Auswählen Erweitern


{
    uint16_t max = MAX_CREDIT*(1+(led_mode >> 6));

    if (credit_10ms < max )
      credit_10ms += (1 + (led_mode & 0x3F));
    if (credit_10ms > max)
      credit_10ms = max;  //test > max always in case limit is changed
   
  }


I've not bothered to change any of the initialization code so max will start at 900 and ramp up to the new limit.

Wow this is great... will try this when i get home again... If i understand good... with this, we have 900 credits per hour limit...standard Max Cube has 33 or something like that, right ?

Thank you very much for sharing...

By the way...i tried telnet with my cube...it is not working... i was doing something wrong probably... but doesn't matter if this firmware make possible use of 900 credits standard at startup...i think this will be ok....

But just to be sure.... if i want to change to 3600 , i need to use fhem right ?

Thank you

Best regards

Miki (NL)

[medolino2009]

i have one more question...

Do i need to flash bootloader everytime i wanna flash firmware or not ? if not...how to come in bootloader to flash new firmware without reseting everything with J1 on Max Cube

Thanx in advance

Best regards

Miki (NL)

[malc_b]

Standard Max/cul is 1% duty cycle.  1 hour is 60x60=3600 s so 1% of that is 3600 x 10ms.  Max firmware starts with 3600 credit_10ms (36s) but when you use all of those it is an hour before you can send any more data.  CUL firmware starts with 900 credit_10ms (9s) and restores these at 1/s so it is 15min before it is back to 900.  So CUL firmware stops when 9s of messages have been sent and restarts when it has enough for the next message in the queue.

With this firmware you can change the 900 limit to 1800, 2700, or 3600 and the rate of restoring the credits from 1/s to 64/s but I wouldn't go higher than you need on the rate and certainly not more than the number of radiator valves, wall stats etc..

Bootloader need only be install once.  The 1st time cube will go into firmware flash mode automatically when you plug in the usb/power lead (because the main firmware is blank).  Subsequent times you need to hold down the reset button on the underside of the cube as you plug in the usb/power lead.  That tells it to go into bootloader rather than run main firmware.  You can then use teraterm or similar to send the new firmware via xmodem.  Wait until the file is all sent and then give it a minute to finish flashing, then power off and back on.

I think you can access the cube via telnet or usb.  Same commands work for both and you can set led via either.  So you should be able to set the led after you have finished flashing and have powered off/on.  You can test this by setting it flashing/off/on and powering on/off to check it remembers the setting.  I would assume that pimatic uses the same method to control the cube so maybe that is why you can't get telnet to work.  Fhem I assume uses telnet and telnet supports multiple sessions usually.

[medolino2009]

Standard Max/cul is 1% duty cycle.  1 hour is 60x60=3600 s so 1% of that is 3600 x 10ms.  Max firmware starts with 3600 credit_10ms (36s) but when you use all of those it is an hour before you can send any more data.  CUL firmware starts with 900 credit_10ms (9s) and restores these at 1/s so it is 15min before it is back to 900.  So CUL firmware stops when 9s of messages have been sent and restarts when it has enough for the next message in the queue.

With this firmware you can change the 900 limit to 1800, 2700, or 3600 and the rate of restoring the credits from 1/s to 64/s but I wouldn't go higher than you need on the rate and certainly not more than the number of radiator valves, wall stats etc..

Bootloader need only be install once.  The 1st time cube will go into firmware flash mode automatically when you plug in the usb/power lead (because the main firmware is blank).  Subsequent times you need to hold down the reset button on the underside of the cube as you plug in the usb/power lead.  That tells it to go into bootloader rather than run main firmware.  You can then use teraterm or similar to send the new firmware via xmodem.  Wait until the file is all sent and then give it a minute to finish flashing, then power off and back on.

I think you can access the cube via telnet or usb.  Same commands work for both and you can set led via either.  So you should be able to set the led after you have finished flashing and have powered off/on.  You can test this by setting it flashing/off/on and powering on/off to check it remembers the setting.  I would assume that pimatic uses the same method to control the cube so maybe that is why you can't get telnet to work.  Fhem I assume uses telnet and telnet supports multiple sessions usually.

So theoretically with your firmware i will much faster get transfer errors (LOVF) , because i will be sending same amount of data...but error will go away after 15 minutes , and before was that 1 hour

Would you please be so kind to make one firmware where everything is at max...64/s 3600 etc... so i wouldn't have LOVF error constantly... i am getting data from all thermostats with actual temp... thats why i need this much higher...

Thanx in advance

Best regards

Miki (NL)

[malc_b]

No, you can have either standard CUL firmware mode of 900 or standard Max firmware of 3600 or in between.  That is the total size of one message of set of messages before you get an error.  The restore rate is 1/s (standard for CUL) to 64/s.  So if you set say 900 and 10/s then you can send 9s worth of messages and recover from that in 90s.

[medolino2009]

No, you can have either standard CUL firmware mode of 900 or standard Max firmware of 3600 or in between.  That is the total size of one message of set of messages before you get an error.  The restore rate is 1/s (standard for CUL) to 64/s.  So if you set say 900 and 10/s then you can send 9s worth of messages and recover from that in 90s.

Ok, i understand now... but i am not that good with coding 

Would you please be so kind to make one firmware where everything is at max...64/s 3600 etc... (standard at start up of cube, as i can't change values within Pimatic), so i wouldn't have LOVF error constantly... i am getting data from all thermostats with actual temp... thats why i need this much higher...

Thank you in advance

Best regards

[malc_b]

How many max devices do you have all told?  You really want to set as a max the most number of cubes you can have, if money was no object.  That would be the maximum number of max devices you could pair, one to each cube.

[medolino2009]

How many max devices do you have all told?  You really want to set as a max the most number of cubes you can have, if money was no object.  That would be the maximum number of max devices you could pair, one to each cube.

i have total of 15 devices, but some devices have bad connection or something like that...so i have more blank transmits before i get replay... thats why i get LOVF all the time... but this aside... i wanna be sure i can use my system as i like...that means, get temp from rooms , open or close stuff as i want...i don´t wanna be blocked by some credit rules.... it is stupid.... i payed around 500 euro for this installation... it was not cheap...so i wan´t to be able to do with it what i like...

so i probably wouldn´t use all credits...but don´t wanna think about it you know...

[malc_b]

OK, here are 2 versions with 3600 as maximum credits and credit return rates of 15/s and 30/s.  Note that 15/s is the only one that you could justify using if you get a visit for interference.  As you have 15 max valves then you could pair each one with a max cube and thus have the same traffic as the 36s-15 version.  The 36s-30 is twice as much traffic of course.

I haven't tested this versions.

[medolino2009]

OK, here are 2 versions with 3600 as maximum credits and credit return rates of 15/s and 30/s.  Note that 15/s is the only one that you could justify using if you get a visit for interference.  As you have 15 max valves then you could pair each one with a max cube and thus have the same traffic as the 36s-15 version.  The 36s-30 is twice as much traffic of course.

I haven't tested this versions.

Hallo,

It works i think...wil test it for couple of days....

You are greatest. Thank you very much for your help

Best regards

Miki (NL)

[medolino2009]

It is working now just perfect...we will see in couple of days if it stays this way

Thank you ones again

Best regards

Miki (NL)

[medolino2009]

just update.... It still works great... no LOVF's any more.... great job malc_b

Does anyone know why am i getting transfer errors sometimes ? (thermostats are not that far away from Cube... max 15 meter ... ) , would bigger antenna make differences ?

Thank you

Best ergards

Miki (NL)

[fruit]

Thermostats too close to Cube/CUL can cause issues too as well as any other kind of interference (not necessarily the same frequency or even radio inteference), two or more devices trying to tramsmit at the same time etc.

[malc_b]

You can't just increase the antenna length as that can give worse results.  See

http://www.mike-stirling.com/2013/03/antenna-measurements-part-1/
https://github.com/OpenHR20/OpenHR20/wiki/2.)--Fundamental-Antenna-Design-Information

There are some values you can adjust in the CUL, at least in fhem.  The help says

Use it with care, it may destroy your hardware and it even may be illegal to do so. Note: The parameters used for RFR transmission are not affected.
freq sets both the reception and transmission frequency. Note: Although the CC1101 can be set to frequencies between 315 and 915 MHz, the antenna interface and the antenna of the CUL is tuned for exactly one frequency. Default is 868.3 MHz (or 433 MHz)
bWidth can be set to values between 58 kHz and 812 kHz. Large values are susceptible to interference, but make possible to receive inaccurately calibrated transmitters. It affects tranmission too. Default is 325 kHz.
rAmpl is receiver amplification, with values between 24 and 42 dB. Bigger values allow reception of weak signals. Default is 42.
sens is the decision boundary between the on and off values, and it is 4, 8, 12 or 16 dB. Smaller values allow reception of less clear signals. Default is 4 dB.

The other thing to look at is the positioning of the cube.  Solid wall are hard to get rf through.  Stud walls are easy as are floors and ceilings as long as the don't use silver backed plasterboard.

[medolino2009]

Thanx a lot for informations...

Will try to place my Cube at different spot...

Best regards

Miki (NL)