tresf
commented
3 months ago There are many layers of complexity in this idea...
- In short, QZ Tray does plan on eventually having a cloud-queue feature, but this hasn't been started. #825
- A cloud queue doesn't solve all problems, since, as you've mentioned, the device is expected to be setup without any advanced configuration from the end-user's perspective. For example, any network attached device must be hard-wired or go through an initial network configuration. This may be manageable through Bluetooth or some alternative discovery, but a smart app would likely need to be built for this (this is how many IoT devices are configured, such as Refrigerators, Washing Machines, Thermostats, etc).
- Configuring the print-server to know how to communicate with printers is tricky. For example, most printer drivers are best supported on Windows however most IoT devices do not run Windows, or if they can be manipulated to run Windows, the version will not have the device drivers available.
- Certificates (e.g. self-signed SSL) are a concern if the browser is expected to talk directly to the IoT device. If an intermediary queue is used instead, they are not as important.
I don't think there's an off-the-shelf solution to what you are seeking. I believe it is technically feasible but will require a lot of tooling. Some of these ideas are discussed regularly at QZ, however building the apps, interfaces and infrastructure to support the ideas on scale is a daunting task so it's one we have not yet started.
can the QZ server just not want to boot or have other odd errors that would make it hard to support?
It's not unheard of for people to leverage a small SoC device (such as a Raspberry Pi) for something very similar to what you're describing (e.g. run one app and do so rather blindly). Furthemore, QZ is known to be able to run on this type of hardware. But to your point/question.... supporting it (e.g. headless, limited connectivity, no graphical interface) certainly poses support challenges. e.g. Opening the device up for pre-configured remote control comes with security consequences, not doing so requires on-site technical knowledge.
If QZ ever leverages a hardware solution similar as described, it will spend most of the time sorting the bullet points above. At time of writing this, we do have some creative ideas to tackle some things (e.g. SSL certificates), but nothing -- not even a proof of concept -- has been created (by QZ, at least) at this time.
Wanted to know if anyone had some insight. Not a developer, just a guy with an idea. Issue I am trying to solve is end users always have a really hard time setting up local label printers. Whether it's USB or Ethernet. Then it's even a harder challenge printing from the app to the printer itself. My idea: I want to make a small, cheap, stand-alone QZ print server hardware running off Raspberry Pi Zero or something even more simple. I want to preconfigure the print server to the printer at my place, then bind that instance with a user on my site. So when they log in to print, it knows to send it to that print server and it just prints. So end user does not need to do any config. They plug into print server. Print server plugs into network, talks to internet, and gets data from website. I know Zebra has some web socket feature, but I think it's a paid feature and you have to pay per print. 2nd idea: Can this be embedded onto a label printer itself as a middle layer? Or is there another approach to solving my problem of I just want the end user to plug in and the printer gets the print job. Also, from what I read, a cert needs to be installed. How would that work if I preconfigure before I ship? Do I just install for for the end user For most installs, I just want the customer to plug in and use it. Assuming they are getting an IP from the internet network and able to get to the internet, can the QZ server just not want to boot or have other odd errors that would make it hard to support?