Pre-requesties

Firstly, I’d like to introduce the way hoppers work in Minecraft and Kraftland server. In Kraftland, a default configurations is set which lets hopper-transfer happen every 8 ticks, of which exactly one item is transferred. This is a key to the control system, so bear that in mind 🧐.

Second, according to minecraft.wiki, a beehive is:

a craftable block that houses bees. They fill with honey as bees pollinate flowers and return to their homes and, when full, can either provide honeycomb when sheared or honey bottles when glass bottles are used on them.

Following with some features: when a comparator is attached to such block, it outputs the honey_level as redstone signal strength which has the maximum of 5. And it can also be harvested by a dispenser.

A no-latency redstone extension circuit can be achieved by connecting a sticky piston and a redstone block like below. Such architecture is better in terms of latency than that of the repeater equivalent.

Core Logic

In this machine we would like to precisely control the time between redstone pulses are sent because of the hopper transfer rate is roughly at 1 per 8 ticks, or 0.8 seconds per item. Increased latency may create instability as it can break the workflow.

Logic

The core logic is shown as follows:

Core Logic

The top-most hopper is used to feed bottles into the middle hopper because the middle one is locked, since we don’t want the dispenser to ingest multiple bottles and having to build an item separator, that will obviously be a huge mess. The middle hopper is responsible of feeding empty bottles into the dispenser, it is controlled via redstone to only feed 1 bottle into the dispenser when the beehive reaches a honey_level of 5. That specific bottle then gets filled by the dispenser facing towards the beehive. The bottom-most hopper is designed to be normally closed and only ingest anything after the dispenser does its job. Which in turn means that honey-filled bottles will be the only thing sucked out.

There it is, a complete flow of bottles. First being fed from the top-most hopper into the middle hopper, where it waits before beehive reaches its maximum honey level. When that happens and a tick has passed (due to the usage of repeaters to invert such signal), the lock on the middle hopper is released and one bottle drops into the dispenser. One tick later, the dispenser activates and honey is filled into the bottle. The redstone signal is then passed to the lower hopper inverted and with a one tick delay, making sure that the bottle is filled when pulled by the hopper. And that’s it, somewhat a simple design.

Implementation

At the very first, we need 2 hoppers on top of a beehive, the latter which is sealed with 3 bees and a dirt with flower on top. Then, connect the last hopper to finish the core, shown in Core Logic

Core Logic

After which, we need to place a comparator and determine whether the signal strength reaches a level of 5.

Output

Then we route the signal and invert it, and point the redstone signal towards it. That way the hopper is unlocked just one precise tick after the beehive is full.

Caution! When powering the hopper, only do weakly powering! Otherwise your upper hopper and dispenser will be powered too, leading to an infinitely stuck machine!

Hopper Control

With the latency requirement in mind, we now extend and reverse such signal with an added one tick delay pointing directly towards the dispenser, as this enables it to suck the honey out of a beehive.

Dispenser Signal

Lastly, with the previous caution in mind, we route such signal into the lower section of the machine and point a redstone torch to strongly charge the block beside the bottom hopper. With a normally enabled design, it prevents contents from being sucked out when the machine is collecting honey.

Lower Hopper Control

That’s it! You’ve successfully created a fully automatic honey machine.