printing from a webserver to a thermal printer with no intermediary
I have been looking into this question for almost a month now. It seems I am being pushed in all different directions. I hope someone can help me with an answer.
to give a brief model of what I am looking for:
I have a webserver that has information I need to get to a thermal printer through the internet to be printed. I DO NOT want a computer to be the intermediary. I have no problem doing the necessary programming to make this happen. My problem has come through finding the devices that I will be able to program. the first problem I came accross was finding a thermal receipt printer that has a built in webserver that I could program to poll my server for information to print. There are no printers currently available for this purpose. I have talked to Zebra, Epson, Brother, etc. Most have a solution for printing if both devices are on the same network such as a mobile phone printer to a printer on the same network the mobile phone is connected to and most have SDK's to do it. I need the printer to be able to poll my webserver. So I went looking for an alternative. Maybe I could attach a wireless USB mini web server to the printer to reach my end goal. I thought this would be a simple task but its not. My question for the users here at stackoverflow.com is has anyone come accross as similar problem and know a solution? again I have spoken to the different manufacturers and none of them are able to help. I think most of them are not even able to understand what I am talking about. I hope those that program here my understand my problem.
Below is a homegrown roundabout solution for what I am trying to do.
http://proto-pic.co.uk/internet-connected-thermal-printer-kit/
again this solution above requires me to build it from the ground up. The berg cloud is another option but they do not allow me to control my web server and everything runs through them. Please feel free to ask questions as I do not expect a quick answer to this problem. I hope there are programmers who came across a similar problem.
Also to reference the tag I chose for this question, I was thinking maybe I could attach a device(Web server micro controller setup) to the thermal printer that maybe has a JVM running a webserver that I could then have communicate through USB to printer. I know Java is much worse than C for a microcontroller but its what I know. would love to hear any alternative solution.
Answer
I strongly suggest you re-consider the Zebra websocket solution at this point.
The best solution still might be the mini web server solution.
My experience with a Zebra websocket solution: Background:
I initially tried creating a node.js solution (I had read in several places that any server is doable). But after a few failed connection attempts even after getting Zebra signed certs - and the printer/server going through a successful handshake process - it still failed with a cryptic error, that when looked into is related to the printer trying to verify that a particular Tomcat version/server is being used!!!???
I did get a response from a Zebra developer who is developing a .Net solution but is also unable to get it working and is waiting on further information from the Zebra 'engineers' before they could complete the solution. They said they would send through the information when they had it and hoped to get it within a week (more than a week - no luck yet).
So - I decided to put together a Tomcat server - the only example Zebra has working... I got the example servlet running but started getting new cert problems (as I had changed servers/domains etc.) This got me thinking about the whole clunky process - and recognised the 1 deal breaker - the very restrictive ssl authentication and signing process is just too risky.
E.g. Lets say you have 100+ customers relying on this solution. If you EVER have problems with the cert (e.g. domain name change, server setup change or cert invalidation/expiry) - then ALL 100+ customers are without their printer. But you can't just fix it yourself - To fix/generate a new cert etc. re-sign process is slow and reliant on external resources! (this is a manual Zebra process btw - you send via an email and you are then left waiting considerable time before a Zebra employee responds with a signed cert).
This will mean that all 100+ customers are without printer services for considerable time but you have NO OPTION but to have Zebra sign your cert. To me this is an unacceptable risk - (the websocket solution should NOT be reliant on a Zebra signed cert - after all you are installing YOUR(or YOUR clients) printer you then configure the printer to specify an EXACT domain name/address for it to connect to).
With your mini server solution - if a client has a problem - it will only affect that single customer and you are NOT relying on an external company to sign certs to fix the problem.
Here are the identified problems and their associated risks.
PROBLEM 1) Very poorly implemented - I cannot (and they also cannot) get it to connect to a standard server other than a VERY specific Tomcat setup!!! RISK LEVEL: LOW - i.e. it's an initial cost and time burden - but once working the ongoing risk of this problem causing further issue is minimal. RISKS: a) Restricts the development to very specific servers and technologies. b) Increased time and costs to initial development/testing.
PROBLEM 2) Poorly documented - I have identified (and Zebra have verified) several mistakes in documentation - documentation is also scattered with important information thrown into a hard to find readme.txt file separate to the rest of the documentation. RISK LEVEL: LOW - i.e. it's an initial cost and time burden - but once working the ongoing risk of this problem causing further issue is minimal. RISKS: a) Slows initial development. b) Increased time and costs to initial setup/development.
PROBLEM 3) Printer security / ssl authentication is poorly planned and implemented. It involved multiple steps - is extremely restrictive and involves a slow zebra signing process that creates an ongoing risk. RISK LEVEL: HIGH - i.e. This is the reason we cannot work with this solution. RISKS: a) Restricts the development to very specific servers and technologies. b) Slows initial development. c) Increased time and costs to initial setup/development. d) Creates an ongoing HIGH LEVEL risk to the project as follows: ---> The idea is that a company would rely on this printer connection solution - therefore any potential downtime would cause MAJOR BUSINESS DISRUPTION. ---> ANY of the following scenarios would mean ALL customers relying on this websocket solution would be without printer services for several days while new Zebra signed certs are organised: ---> 1) Cert expires, 2) Cert is invalidated, 3) Server is moved, 4) domain details change, 5) Tomcat server setup is modified (due to the way the printer verifies certain Tomcat/server settings) ---> Also, the above 5 scenarios are only known based on my testing so far - there could be other possible restrictions that could mean cert failures that I have not come across yet.
Summary: IMO Problem 3 poses an unacceptable risk and the following 2 things need to happen before I would re-consider Zebra websockets. 1) They need proper documentation on how the websockets connect to a server as it is hidden and even the Zebra employees are currently in the dark. 2) They need to remove some of the authentication restrictions - so that you can fix any problem without a time consuming Zebra interaction.