Support for external notification/control

[andrewn]

I'd like to implement more of the original Little Printer behaviour i.e.

• don't automatically print messages;
• show an indicator (an LED) when there are messages waiting;
• print waiting messages when a physical button is pressed.

I think it makes sense that this happens outside of sirius-client, so that this project doesn't prescribe what or how it's controlled.

I was thinking that having a port listening for (perhaps local-only) WebSocket connections would make sense. It's bi-directional so could send notifications for pending messages, and could be used to send control messages from other processes on the device.

Wanted to get your feedback before starting on an implementation.

[notjosh]

Yessss, I've been thinking a little bit about this along the way - how to support this kind of functionality, making it opt-in. Or, put another way, how to support making your setup as complex as you want without needing to.

(That sort of relates to a broader question: does this project aim to reproduce LPs faithfully, or does it lower the barrier as low as possible to DIY? So far, it's the latter, but this issue would bring us more toward the former. That's a good long-term goal.)

The biggest hesitation I've had in doing this kind of thing until now has mostly been around it introducing more state. Mostly around: where do the "not-yet-printed" images get stored? Is that centralised, is it per-printer?

I can think of two opt-in ways of this working on a per-printer basis:

1. create a "virtual printer" that wraps a Printer, which acts as a buffer for the actual printer, where the print queue + state can be stored (in memory, sqlite, whatever)
2. create a "controller" that exists as a property on a printer (with a default "always print immediately" controller), and that controller is kind of a proxy for instructing to hold queue + state

In either of those, we could have different ways of driving it (as you say, via websocket protocol etc), or reading/writing directly from gpio, etc. I don't have a good feeling yet of how configurable we'd want it vs just making it a playground to hack for yourself.

This is still pretty raw, but I could imagine configuration looking like this (and you can probably picture the implementation):

---
version: 1

printers:
  # option 1
  some_printer:
    driver: escpos                    # this is all the same as now, to configure a device
    parameters:
      transport:
        type: usb
        parameters:
          vid: 0x1234
          pid: 0x1234
    controller: gpio                  # <- added: the `controller` configuration
      buffer: sqlite
        path: /path/to/storage.sqlite
      indicator_pin: 14
      button_pin: 16

  # option 2
  some_other_printer:
    driver: gpio_controller           # this is now the printer driver itself
      buffer: sqlite
        path: /path/to/storage.sqlite
      indicator_pin: 14
      button_pint: 16
      wrapping: escpos                # the wrapped printer driver is defined here
      parameters:
        image:
          width: 384
        transport:
          type: usb
          parameters:
            vid: 0x1234
            pid: 0x1234

And then instead of gpio controller, we could have websocket controller and so on. And instead of sqlite, it could buffer to a folder, in memory, and so on.

I think the preference is more option 1, as it seems a little more flexible overall, but needs a little more thinking. Option 2 feels more hacky, and doesn't really fit the APIs we have so far.

---

Another slight tangent, but related feature is the "printer faces". Currently there's no printing of faces, and the printers don't persist the "custom face" feature. So I thiiiiink this could tie in nicely with adding functionality for each printer to (optionally) have a storage attached to it (again, "in memory" by default, with a folder or sqlite as options). The controller should be able to piggyback on the storage, so then it only really needs an interface into it, and then focus on gpio/websocket/etc.

(I'd probably just thinly wrap https://github.com/philippgille/gokv as its storage options are extensive!)

---

How customisable do you think you'd want this to be? Would it be "as LP as possible", so that a controller interface would only really have youve_got_mail_so_flash_leds() and button_pressed_so_print_queue() (+ connection status red LED, reset pin pressed, etc etc)? Or would you want more advanced things like, say, ability to show how many items are in the queue?

If it's the former, I think we could come up with a Controller interface, and then try hacking a GPIOController and WebSocketServerController and see how they feel?

Sorry, long response, I hope it mostly makes sense!

[andrewn]

Thanks for the detail, this is really useful...

That sort of relates to a broader question: does this project aim to reproduce LPs faithfully, or does it lower the barrier as low as possible to DIY?

I see your question as about how much of the LP protocol are we implementing in sirius and sirius-client? For me, much of the magic of the LP was publications and the distinction between timed deliveries (a crossword waiting for me at 9am every morning!) vs instant messages from friends. And of course faces 🙂.

Long-term, I'd love for this command set to be supported. This includes upstream work too, since sirius currently gives a server error if you send to an offline printer.

This does mean more state, but I think it's worth it.

I wonder whether storage is actually separate from the controller? Printers store incoming deliveries, and then notify controllers who can decide if that's displayed to the user somehow and also tell the printer to print something.

printers:
  # option 1
  some_printer:
    driver: escpos                    # this is all the same as now, to configure a device
    parameters:
      transport:
        type: usb
        parameters:
          vid: 0x1234
          pid: 0x1234
    buffer: sqlite
      path: /path/to/storage.sqlite
    controller: gpio                  # <- added: the `controller` configuration
      indicator_pin: 14
      button_pin: 16

The default controller just prints everything immediately - the same functionality as we have now, since most users of this project will probably be using an off-the-shelf thermal printer (paperang, etc).

How customisable do you think you'd want this to be? Would it be "as LP as possible", so that a controller interface would only really have youve_got_mail_so_flash_leds() and button_pressed_so_print_queue() (+ connection status red LED, reset pin pressed, etc etc)? Or would you want more advanced things like, say, ability to show how many items are in the queue?

From previous work on Radiodan, I'd keep it low-level and determine a set of events/commands that describe state (new delivery, 3 items in queue, new face) and let the controllers decide how to interpret the state. That allows people to integrate whatever creative ideas they have:

• releasing a marble whenever I have a message
• activates DJ Roomba
• plays a song on Spotify

One issue this raises is then how to allow people to load their own controller code without having to include it in this project. I'm a little hesitant about bundling a GPIO controller due to a lot of the npm GPIO libraries failing to install on non-raspbian environments. And maybe I want to use something like Johnny-Five instead, so how do I get my controller code running? Do we have a way to configure an npm package name to require which then provides the controller? This is a similar issue for the transports too.

Another slight tangent, but related feature is the "printer faces". Currently there's no printing of faces, and the printers don't persist the "custom face" feature.

How do faces work? Are they sent from sirius?