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.