Is there a way to read the content of a chest using the circuit network. I tried to connect a red wire but i did not manage it ?. I want to make a belt balancer

No, circuit connection is not supported by the game for such "link-container" type.
Actually I am surprised the game has taken out this functionality as well. I also wanted that to read chest contents for some lamp colour as indicator too.

BTW, what is your use of red wire for constructing belt balancer?
Using this autolinked chest, wiring is NOT needed for belt balancer. Just connect every input and output loaders/inserters to the line of autolinked chests, then they will be balanced by themselves.

Thanks for your response

I have tried a simple build using four linked chest, four output line using deadlock's loader and two input lines (one full and one with only one lane). The ouput belts are not balanced, one lane had an ouput of 15 item/s and another of 18 item /s.

My idea was to add an hysterisis system, block output until the content of the chesh reaches an upper threshold and then unblock output until it reaches the lower threshold.

I see now the ability to read contents can be helpful to you. Unfortunately, it is currently unavailable (1.1.6).

I am thinking of an alternate solution for your use case. Instead of reading chest contents, can try read "density" of the output belts.

The flow in this figure is from left to right.
In the output belts, the first (left) row is just reading the contents.
They are connected to the constant combinator, which is used to control the on/off of second row. (Note it has negative value, so to sum up with measured values.)
The second (right) row is on/off belt, they are enabled only when the first row is full.
You can see the output belts on the right have more-or-less the same pattern, thus output balanced.

PS1: For four output belts, the combined "density" can never reach 32. So 31 is the max density you can get.
PS2: If may omit the constanat combinator, and just set value of 31 directly to the second row.

Below is my second solution:

It involves additional normal chests for "read chest contents" to work, so there is no need to fine tune the optimal density value of 31 (or whatever).
The value "-200" is arbitrary, just to ensure there are some items within.
The advantage of this setup is no need to fine tune the density value.
The disadvantage is extra loaders/inserters, chests (and thus space) is needed.

Thanks for your reply
I prefer the first solution.
I just make another test to see the UPS impact. I set two different builds with 16x16 belt balancers (i build12 balancers)

• one using the linked chest
• one using regular belt components

Surprisingly, the second build has the lowest execution time.
It seems that linked chest is not a viable option to build balancer in megabase

Would you mind posting the values, if you have them? I would also like to know about your results.

And can you test one more thing: the storage size of autolinked chest? Heard about storage size of a chest will have UPS impact.
(I have seen some analysis that some modded super-size chest is not good for UPS. So I guess tuning down the storage size of my autolinked chest may improve the results in some way?)

Always heard about splitters (as they are used a lot in belt balancers) has UPS impact. I do not have more than 8 belts to balance, so I cannot verify by myself. So this mod serves as an alternate way to deal with these.

Anyway, devs are continuously working on optimization on different parts of the game. They worked on belts, then pipes, and recently on multi-threading. So I am sure that results may improve in the future. (E.g., current belts are a lot smoother than belts of old times, say 0.15.)

Here my figures (for 12 clones of a 16x16 belt balancer)

linked-chess version (i have limited the storage size to one stack)
Transport lines: 0.3ms
Entity update: 0.22ms
Circuit networks: 0.090ms

regular belt balancer
Transport line (roughly evaluated, keep on changing) 0.230ms
Entity update: 0.135ms

I have the feeling that the native loaders performs particurlaly bad compared to the regular belts

Thanks for your data. So it is 67% more time on the linked chest.

My findings agree with your conclusion, where loaders can be the main cause.
Read from some discussions, they said the transport lines and inserters are constantly being worked on.
The loaders never get such kind of improvements (I doubt if any) for a long time, since 0.14 or so...

I have made another test.
I have a iron smelting facility (12 full blue belt). I have tried to replace the input belt with linked chess.
It worked very well. Besides, the "Entity update" time dropped from 0.135ms to 0.090ms.
Loading from a chest is faster than loading from a belt.
It would be nice if we can have different class of chest (here one for input, one for output).
The chess of the same class can link each other but not with the ones of the other class (with the link tool).
For a more complex factory, i like to have one class of chest for each input/ouput.
I like to replace the output lines on my smelting facility, too (and see the impact on UPS)

Nice find that it can be better in some aspects.

When I write the code, I have reserved the expansion ability that there can be multiple "tiers" of autolinked chests. (Though I intended them as different storage sizes.)
Yet I have not implemented that as they could be redundant for many users. I want to see if there is any real need for them.

I am worrying about if having too much different "classes" though, as I wonder how it can be done nicely. Users may expect graphical differences to make them instantly distinguishable, but I am no way an computer graphics artist.

Anyway, your request could be done with current version. There are two ways to achieve this:
1/ Turn off "Link chests on built". So you can just link chest with different link IDs (as different clusters) into what you want.
2/ Place any items into the chest first, which will lock its link ID. Then you can have two (or multiple) chest clusters that are next to each other.

I have replaced my output belt by autolinked chess. It was a bit tedious because sometimes the grouping changed the link id.

But the result is impressive: 0.070 ms of "Entity update" timing and ... nothing else.

You have the ultimate solution for megabase building and UPS saving.

I have replaced my output belt by autolinked chess. It was a bit tedious because sometimes the grouping changed the link id.

Do you mean the link ID is changed, when the inventory is empty or filled?
If it happens to filled inventory, it would be a bug as it would cause item lost.
If it happens to empty inventory, it is normal, as there is no way to tell which link ID you "prefer" when merging multiple clusters. It does not sound nice if the current automatic (on built) or one-step (on hotkey/shortcut) process has to take additional steps, in order to specify the new link ID.

But the result is impressive: 0.070 ms of "Entity update" timing and ... nothing else.

You have the ultimate solution for megabase building and UPS saving.

Glad this would be helpful to you.