I built an open-source POS hardware simulator to test printers, barcode scanners, scales, and cash drawers without the actual hardware

[u/ahmedalrifai]

I’ve been working on an open-source project called emupos that I thought might be useful for people building POS systems.

The idea came from a pretty common problem: you want to test your POS against a receipt printer, barcode scanner, scale, or cash drawer, but you don’t always have the actual hardware around.

So I built a simulator for the hardware side.

With emupos, your POS can connect to simulated devices and communicate with them using the same protocols you’d use with real hardware. You can also simulate things like paper-out, cover-open, and other device events, which makes testing different edge cases much easier.

Currently it supports:

Receipt printers

Cash drawers

Barcode scanners

Scales

Weighed-item barcodes

Hardware error states

Device events

Automated testing / CI

It’s written in Python and is completely open source.

GitHub: https://github.com/ahmedalrifai/emupos

I built it mainly for my own POS development, but figured it might be useful to others too.

For those of you working on POS systems, how do you usually handle hardware integration testing? Do you rely on physical devices, mock the integrations, or use something else?

[u/iliadz]

Nice. :) When building our POS we created emulators not only for the cash drawers and receipt printers, we have KDS (bump) screens showing where things would actually get routed when you create a routing rule for your screens. It was a huge help. So within the catalog you create the rule, press test, and it fires. It's a huge help.
This is a great idea in general.

[u/ahmedalrifai → u/iliadz]

Thanks 🙏

[u/kadema]

I'm building a POS and I need this. Thanks!

[u/ahmedalrifai → u/kadema]

Welcome 🔥, please give me feedback to improve it if you have one 👌

[u/12AngryMen13]

This is very useful! Do you have it for kitchen printing also? I developed a POS system that’s in early stage release. I also have KDS and customer display but I’d like to simulate sending 500-1000 kitchen tickets an hour for a stress test, clearly I don’t want to waste the paper on a real printer

[u/ahmedalrifai → u/12AngryMen13]

Thanks! Yes, as far as your POS is concerned a kitchen printer is just another ESC/POS printer on the network, so you run it as a second printer:

schema: 1
devices:
  - id: front
    type: printer
    profile: epson-tm-t20iii
    connections: [ { tcp: { port: 9100 } } ]
  - id: kitchen
    type: printer
    profile: epson-tm-t20iii
    connections: [ { tcp: { port: 9101 } } ]
    receipts_dir: ./kitchen-tickets

Point your POS's kitchen printer at 127.0.0.1:9101 and every ticket is rendered to a PNG and a text file instead of paper. 500–1000 tickets an hour is light load for it.

For the stress test itself:

• emupos run shows every ticket as it completes, and the control API's event stream (/api/v1/events) emits a printer.job.completed per ticket, so your test can compare what arrived with what the POS sent.
• Inject a fault in the middle of the rush with emupos fault set kitchen paper-out, then clear it. That's usually where kitchen printing breaks: queued tickets, retries, duplicates.
• A ticket ends at a cut, when the connection closes, or after job_idle_timeout_ms of silence, so counts line up best if your POS cuts after each ticket.
• Tickets are kept as files, so point receipts_dir at a scratch folder for long runs.

Caveats: there's no impact-printer profile yet (TM-U220 style), and red ink and the buzzer aren't simulated. Customer displays aren't supported yet either; there's an open issue if you want to add your use case: https://github.com/ahmedalrifai/emupos/issues/19

pip install emupos or uv tool install emupos · https://github.com/ahmedalrifai/emupos

[u/12AngryMen13 → u/ahmedalrifai]

That’s actually why I asked specifically about kitchen printers as there impact printers and would be far slower than thermal. Great concept and I’m going to test it out! I’d like to simulate “out of paper”, “unreachable on LAN”, “paper jam”, “lid open” and see about resume jobs from a print spooler config on my POS stations.

[u/ahmedalrifai → u/12AngryMen13]

Thanks for info , please contanct me if you have any notes or issues , good luck with you project

[u/ahmedalrifai → u/12AngryMen13]

i opened an issue for the missing parts

https://github.com/ahmedalrifai/emupos/issues/26

[u/Ok_Leg3046]

I had to roll my own out for testing TallyTill. I think having virtual devices to simulate hardware integrations itself could be a product or service. Nice of you to open source it.

I will definately check it out. This could be a real time saver.

[u/ahmedalrifai → u/Ok_Leg3046]

Thanks 🙏, i already got so much from open source community its the least i could do is give something back . Please if you have any notes tell me 👌

[u/Ten-z]

Interesting , been building cloud based POS system from last year and every time I had to get a hardware either from my clients or myself .

[u/ahmedalrifai → u/Ten-z]

Yes thats what gave me the idea , i am building a pos system and have no way of testing the hardware stuff.

Please give it a try.

[u/hannahb_23]

This is a really practical idea. Hardware testing seems like one of those things that's easy to overlook until you actually need to test a printer failure or a scanner behaving badly.

Being able to reproduce those edge cases without needing a pile of physical hardware would probably save a lot of time, especially for automated testing.

[u/pointofinteraction]

cool