Bump Bar for Kitchen display

Has anyone here ever configured the kitchen display to use a bump bar instead of a touch screen for selecting orders and changing the state as order ready to clear it from the kitchen display?

Something like this:


Or even if we could take just a simple number pad keypad and program the keys to it so that it can control the samba ticket lister widget. I know that right now i cannot use a keyboard to control the ticket lister widget so not sure if this is even possible.

Main reason is touch screen monitors are expensive and there is alot of grease and heat in the kitchen and your hands are usually dirty and would make the touch screen a mess… Regular monitors are much cheaper and a keypad or bumpbar would keep the screen from getting dirty with finger prints… it also would allow you to mount the monitor a little higher so you dont have to try to look over people shoulders to see whats on the screen if it is a big kitchen.


Id also like to know this. It’ll be good for the new system I have planned for install in the next few weeks.


While the Ticket Lister Widget does not accept keyboard input, there are some Widgets that do.

In particular for this case, you could try an Editor Widget on the same screen as the Ticket Lister and use automation to receive the editor input (via physical keyboard, or this device) and “do something” with that input.

You would have to show me some examples because im not too sure how i could even go about doing that… everything ive seen for the editor widget is to change the value of a item not to select and change the state of a ticket. Would it be hard for @emre to allow keyboard input on the ticket lister widget for this purpose? Or is there a command that we can emulate with some type of hotkey program so when keys are press the hotkey program enters the command.

Editor Widgets are simple. They allow input from an on-screen keyboard or physical keyboard.

To access a single Ticket within the lister, we use the Ticket Id, so the same would apply for the Editor Widget Automation. To know which Ticket to work on, we need to:

  • Show the Ticket ID in the Ticket Lister Widget, so we can see it to know which to select
  • Receive input of a Ticket Id from Editor Widget
  • Perform an Action (Ticket KitchenStatus State change)

:exclamation: This is simply Proof-of-Concept to show how the Editor Widget can be used to change a Ticket State so that the Ticket Lister Widget removes a Ticket from the display. There may be much more Automation required in the end for full working implementation, depending on your desired flow.

Editor widget at the top. We are going to change the KitchenStatus Ticket State of Ticket Id 3091 from NotReady to Ready

Entity Screen

TO Tickets Only [UNKNOWN] (Entity Screen)

Name: TO Tickets Only
Ticket Type: Ticket
View Mode: Custom
Search Value Replace Pattern:
Background Image:
Background Color: #00FFFFFF
Use State Display Format: unchecked
Column Count: 0
Row Count: 0
Button Height: 0
Page Count: 1
Font Size: 50
Header Button Font Size: 0
Entity List (0)
Entity Type: UNKNOWN
Display State:
State Filter:
Entities: (none)
Details Template (none)(none)
Mappings (1)
Terminal User Role Department Ticket Type Visibility

#Editor Widget Properties and Settings


##TO Receive Ticket ID [Automation Command Executed] (Rule)##

Rule Name: TO Receive Ticket ID
Event Name: Automation Command Executed
Rule Tags:
Custom Constraint List (1):
Execute Rule if: Matches All
Automation Command NameEqualsTO Receive Ticket ID

Actions (8):

TO Update Program Setting

Constraint: (none)

settingName: TOTicketId
settingValue: 0
updateType: Update
isLocal: True
TO Update Program Setting

Constraint: [=TN(‘[:CommandValue]’)] > 0

settingName: TOTicketId
settingValue: [:CommandValue]
updateType: Update
isLocal: True
TO Load Ticket

Constraint: [=TN(‘[:CommandValue]’)] > 0

ticketId: [:CommandValue]
TO Update Ticket State

Constraint: [=TN(‘[:CommandValue]’)] > 0

stateName: KitchenStatus
currentState: NotReady
newState: Ready
Close Ticket

Constraint: [=TN(‘[:CommandValue]’)] > 0

TO Update Program Setting

Constraint: (none)

settingName: TOTicketId
settingValue: 0
updateType: Update
isLocal: True
TO Set Widget Value

Constraint: (none)

widgetName: TO Editor
value: 0
TO Navigate

Constraint: [=TN(‘[:CommandValue]’)] > 0

moduleName: Entity
parm: TO Tickets Only
hideHeader: True


@emre, the only issue I am seeing with the above setup is that of giving the Editor Widget FOCUS when the Screen is displayed or refreshed.

Is there some way we can do this? Or do we need another “feature” added?

I tried this hoping it might be a hidden feature, but alas it does not work to give the FOCUS to go to the Editor Widget, which I named TO Editor:

The first time the screen is displayed, I can hit the TAB key 1 time to give the Editor FOCUS.

When the screen is refreshed via Navigate Action, I need to hit the TAB key exactly 22 times before the Editor receives FOCUS.

Doesn’t editor widget automatically got focus?

No it does not. I thought it would, but this is not the case… at least, it does not get focus when on the same screen as a Ticket Lister Widget.

EDIT: In fact, I have Editor Widgets on many screens with various other Widgets, and none of the Editors receive focus automatically. The only Widget I know of that does receive automatic-focus in the Entity Search Widget…

I tried messing with Z-index on both of the Widgets, and also the order in which the Widgets were added to the screen, but no changes…

Does the Ticket Lister Widget accept keyboard input?

OK. I added “Should Focus” setting for editor widget so when enabled it captures focus.

No it doesn’t. I think your solution is already great.

1 Like

We also have Task Editor that can accept input.

And in fact, that does work… and it gets FOCUS automatically.

You need to set up a Task Type (abitrary) …

And then add the Task Editor to the Screen with these Settings:

Using the same Actions and Rules as the previous post, we can use the Task Editor Widget in exactly the same way…

The only issue I see with this setup is that we are actually creating a Task everytime we do this, which is a bit useless, but anyway…

Yea it just sucks you can’t just use a arrow and select the ticket you are working on cause if you have more than 10,000 tickets i could see alot of typos happening… arrows to highlight/select a ticket and then being able to press a button to change it to ready just seems much simpler for a fast paced kitchen… those bump bars were designed specifically for that and have been around for years so they are proven solutions to get food orders out fast and easy to use.

Can you elaborate that? Sounds like a good idea but couldn’t fully get how it works.

I use AutoHotkey with a numeric pad to do that, I think that you can map a button of that bump bar

I used to work with one at an old restaurant it was really efficient. Ill make an in depth explanation a little later after work.

Can you show how you accomplished this with autohotkey?

The bump bar is basically just a programmable keyboard. It mounts somewhere easy to reach so that the kitchen staff can use it to select the order on the kitchen display and then change the order state to ready or even selecting an item and marking it as ready. It depends on the software but the main point for using one is its fast and easy to use because most kitchen display monitors are mounted higher up and out of reach. They are also water proof and approved to be used in a kitchen setting by the health department.

When I worked with a kitchen screen and bump bar, the screen was broken up in to 8 boxes. Each box had a corresponding number. When an order was ready in the 2 second box the cook would simply press the 2 button on the bump bar and that order would clear.

the orders would come in and be listed in sequential order. so box 1 had the oldest orders, box 2 is the second oldest, box three is the third oldes…and so on… After an order cleared the the 8th box was for recalling past orders and the arrows were used to cycle thru them.

1 Like

I’m wondering if we might be able to do this with Task Types.

Question: when an order is cleared, do the older orders scroll toward the lower-number box?

For example, if you clear Order 3 (box 3), does 4 move to 3, 5 move to 4, 6 move to 5, and 7 move to 6, while Order Boxes 1 and 2 remain unchanged?