Artisan server/client

[rpaulo]

It would be interesting if we could separate the backend from the frontend. This would allow us to create an artisan server which could run on an RPI connected directly to the roaster and then run the frontend on a laptop. They could communicate over WiFi or Bluetooth.

[MAKOMO]

There are users running Artisan on their RPi operating it via an iPad connected via VNC to that RPi. Raspian now comes out of the box with an VNC server. One level deeper, Matplotlib has a Web backend thus I have no experience with that and do not know if it supports enough features for running Artisan that way. I don't know if Qt has a Web-based backend.

[rpaulo]

I see a couple of drawbacks with that approach.

• The RPI is not a fast computer so I suspect using Artisan on it is a bit slow. Artisan + VNC will probably make it even slower
• With a server/client architecture, we could run the Artisan server on even smaller computers. Imagine we define a protocol for Artisan to communicate with the backend. It could then implemented on an Arduino with an Ethernet shield.
• When we roast, we want to save the profiles somewhere. If Artisan is running on the RPI, we have to save the profiles to the RPI first and the maybe copy them to a laptop.

[MAKOMO]

You are right, that a cleaner architecture is to use custom protocol, thus this involves a lot more development efforts.

To my experience the RPi3 is fast enough for everything around Artisan, including a VNC over a local WiFi.

Still, a small backend just handling the communication with external devices and abstracting away the device specifics could lead to a modular architecture the whole project could benefit from as it would separate concerns.

Should we tag this 2.0?

[rpaulo]

The method I was thinking of how this should work would be:

1. Artisan client is setup to connect to the server
2. After connecting, server sends the capabilities of the roaster (drum control, heater control, fan control) and LCD config (need to think about this a bit more). Alarms/events can be configured on both sides.
3. Artisan client configures the UI and asks the server to start streaming data

We can implement the communication channel using JSON since it's something that can be readily used by small computers like the Arduino.

[MAKOMO]

Interesting, but how are the capabilities on the server configured. By a config file modified by the user? Yes, JSON via WebSockets might be the way to go (assuming the Arduino has a network connection). Still this sounds like a bigger project.

Note that Phidgets and Yoctopuce modules already support a remote access as well as the Arduino TC4 by just adding a $1 Bluetooth module to transfer its serial stream via BT. There is also an ESP32-based hardware module for Artisan with 2 TC input channels and 2 motor control channels that talks MODBUS TCP via its Wifi connection.

I have to think more about this all...

[PDWest]

Although it's not exactly what's asked for in the OP, but I have a simple modbus server that runs on a headless RPi zero. It's got a couple of max31856 digital thermocouple inputs wired to the SPI bus. For heater control I've got a Nodelynk I2C expansion bus with a 'slow' PWM for heater control plus a yet to be integrated with Artisan ambient temp/humidity sensor on it. This little RPi connects to my roaster, and Artisan connects to it via WiFi using the standard modbus interface. No refactoring of Artisan required.