How do I start a remote engine?

[Aldo Bleeker]

People have mentioned remote engines, engines running on remote computers. That sounded useful, so I decided to try to run picochess on my Raspberry Pi 5, but use an engine running on my Windows PC. It wasn't clear how to do this, but I found some hints here in this group.

If you want to run Stockfish 16 on a Windows PC, I think you have to do the following.

- Add a remote engine to /opt/picochess/engines/aarch64/engines.ini on the Pi. The name in engines.ini must start with [remote_. For instance [remote_stockfish].

- Place remote_stockfish.uci in the same folder. Use the same name.

- Place a copy of the Windows version of Stockfish 16 engine in a folder, for instance C:\picochess\remote_engines.  Use the same name again, so it has to be called remote_stockfish.exe.

- Edit picochess.ini on the PI, and enter the server, the engine folder, the username, and the password for the Windows PC.

- Start picochess on the Pi and select the remote engine.

But it isn't working. When I select the remote engine, I get Server Error and Engine Error.

The log shows error

2025-12-08 15:59:44.178   ERROR     engine - open_engine: OS error in starting engine /opt/picochess/engines/aarch64/remote_stockfish

and

FileNotFoundError: [Errno 2] No such file or directory: '/opt/picochess/engines/aarch64/remote_stockfish'

It looks like the remote engine isn't recognised.

I've also read here that the remote engine uses SSH, but it's installed on the Windows PC and I've created user pi with password picochess. I can even use this to SSH from the Pi to the Windows PC, start remote Stockfish, and for instance enter bench to run a benchmark.

Am I doing something wrong?

Aldo

/opt/picochess/engines/aarch64/engines.ini:

[remote_stockfish]
name = Remote Stockfish 16 64-bit
web = Remote Stockfish 16 64-bit
small = R SF
medium = R SF16
large = R Stockfish 16
elo = 3310
ccrl = 3541
levels = 21
ponder/brain = y
fischer chess960 support = y
comments: NNUE embedded and enabled.

/opt/picochess/engines/aarch64/remote_stockfish.uci:

[DEFAULT]
Hash = 192
Threads = 1
SyzygyPath = /opt/picochess/tablebases/syzygy
Slow Mover = 33
Move Overhead = 2000
Use NNUE = true
;EvalFile = nn-82215d0fd0df.nnue

[Elo@1350]
UCI_LimitStrength = true
UCI_Elo = 1350

...

[Elo@2850]
UCI_LimitStrength = false
UCI_Elo = 2850
Threads = 3

/opt/picochess/picochess.ini:

engine-remote-server = 192.168.178.21
engine-remote-home = C:\picochess\remote_engines
engine-remote-user = pi
engine-remote-pass = picochess

[Randy Reade]

What version of PicoChess are you using? I don't think it's been ported to v4.

Randy

--
You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/picochess/4ed5fe76-0980-4f52-aa37-ccc0edff149en%40googlegroups.com.

[Randy Reade]

Some discussion here:

https://github.com/JohanSjoblom/picochess/issues/8

On Mon, Dec 8, 2025, 11:27 a.m. Aldo Bleeker <aldo.b...@gmail.com> wrote:

--

[Aldo Bleeker]

Thanks, Randy, didn't know that! That probably it, I'm using 4.1.9. 

Aldo

[Francois Vannier]

That'd be great to have its priority reconsidered. it's a great feature to be able to play with Picochess against external chess engine, as it was possible with earlier V3, not to mention the possibility to have a stronger tutor/watcher.

Thanks in advance ;-)

Francois

To view this discussion visit https://groups.google.com/d/msgid/picochess/CAE5WdusEBcVTBB30i2XSAqqDzctob1VSuJ9YcS5a3gF91z_%3DYw%40mail.gmail.com.

[Johan Sjöblom]

Your timing is absolutely great!

I have just finished working on pgn_engine leftovers and the next thing on my to-do list is to support a remote engine :-) The new chess library uses another mechanism so I need to change the Python code in V4. The instructions given here should stay the same. I have created a branch named 8-remote-engine and in this branch I will try to support a remote engine. I will let you know when I have the first solution that can be tested there.

If the remote engine is a Windows I guess we do not need to have any security ssh keys? But if the remote engine is running on a Debian we might need to support some ssh keys? Does anyone know if V3 has support for ssh keys?

[Francois Vannier]

At least, picochess.ini referred to a SSH key (optional for Windows, if I remember well):

### =========================
### = Remote engine options =
### =========================

### Parameters for a remote engine (server)

## Path to the remote engine, if applicable.
## Please make sure that you also set 'engine-remote-home' accordingly
## IP address of server hosting the remote engine
#engine-remote-server = 192.168.xxx.yyy
## The home path (where the engines live) for the remote-engine-server
#engine-remote-home = C:\chess\remote_engines

## What remote user account to use to connect to the remote-engine server
#engine-remote-user = <username>
## What password for the remote-engine-server
#engine-remote-pass = <password>
## Your private key for the remote SSH server if using SSH key-based
## authentication. Server must already have your public key.

#engine-remote-key = your_private_key

Francois

To view this discussion visit https://groups.google.com/d/msgid/picochess/56d66796-cfa7-42c3-adc9-353ce9410394n%40googlegroups.com.

[Johan Sjöblom]

Ok. Now in branch 8-remote-engine there is a first solution !! I was able to play against a remote Stockfish16 (remember to set Use NNUE to false for Stockfish 16, for me it crashed with true) and a Stockfish 17.1 where I used "Use NNUE = true" and both Stockfish worked nicely. My remote test machine was just a Pi 4. Please test on Windows or any platform and let me know.

I used the same setup instructions as Aldo posted above

This version still does not have support for keys, so I took an extra manual ssh connection to my Pi4 so that the host keys got recognized and stored before testing... Not sure if it was necessary.

This branch requires you to get one more Python library, and here is how you can do it on the command line if. 

cd /opt/picochess
source venv/bin/activate
pip install -r requirements.txt

The new library name is asynchssh and the version I used was 2.16.0 as you can see in the requirements.txt when you checkout this branch. An alternative to the commands above could be that you checkout the branch and then run the sudo ./install-picochess.sh which should install that new library as part of the installation (if everything works as before).

I have added extra debugs to this branch code so that we can find out errors you might have. Please use log-level = debug in your picochess.ini for best result and if you have problems paste the log here or email it to me.

In my picochess.ini I used this setting to connect to a Stockfish on my remote Pi 4:

engine-remote-server = 192.168.1.49
engine-remote-home = /opt/picochess/remote_engines/NNUE

engine-remote-user = pi
engine-remote-pass = picochess

I was able to switch between testing Stockfish 16 and 17 by just having the NNUE at end of engine-remote-home or not. And as said with Stockfish 16 I got a crash when my remote_stockfish uci had the setting "Use NNUE = true". I recommend starting your testing with Use NNUE = false to avoid the extra hour I spent on troubleshooting why it did not work.

Happy Testing. Let me know if it works or not :-)

[Francois Vannier]

Great !

I tried using remotely with picochess the latest SF dev running on my PC under Windows 10 with a Elo based uci file & it's working as expected 🙂

Xmas list: 🎄

1) Using a remote engine as tutor/watcher engine failed. Looking at the logs, a local uci engine is expected. Could you please add the possibility to use a remote engine instead ?
2) If 1) is fixed/improved, is this possible to have an optional additional parameter in picochess.ini to identify the fallback local engine for the tutor if the tutor primary remote engine fails to connect (PC off -> use local engine) ?

Thanks !

Francois

To view this discussion visit https://groups.google.com/d/msgid/picochess/bdd5f7e3-df61-4da0-b955-48eaa831cdben%40googlegroups.com.

[Johan Sjöblom]

I will take a look at the remote tutor. Not sure if I need your picochess.log file but if you can, please post it.

I guess the name of the tutor engine must start with  "remote_". An example for my remote Pi4 could then be /opt/picochess/remote_engines/remote_stockfish

To view this discussion visit https://groups.google.com/d/msgid/picochess/CADa9EqWFRd3%3DDMGy0QPqouJYJry6jn3%2BDvOebqKPWJrTvci1Mg%40mail.gmail.com.

[Francois Vannier]

Hi Johan,

Here is attached the log. Looks like picochess is expecting an executable file named 'remote_stockfish'.

I put the remote_stockfish.uci in aarch64, so my picochess entry is: tutor-engine = /opt/picochess/engines/aarch64/remote_stockfish

Thanks

Francois

To view this discussion visit https://groups.google.com/d/msgid/picochess/CAEk%2BOSTMTpSqHUPPPgANopZbH_XmfJmw2NwwcnceJW2SEKQpLA%40mail.gmail.com.

[Aldo Bleeker]

I've tried playing against a remote engine again with this branch, and from what I've seen it's working flawlessly. Great job!

I was playing with picochess local on the Raspberry Pi 5, and the remote engine was placed on my Debian desktop computer. I've configured the system the same as I've described earlier. Note that to login I only used the username and password, I've left the authentication key left out. As remote engine I've used a copy of a-stockf (named remote_stockfish), which is some version of Stockfish 16.

Emboldened by this success I've added Komodo Dragon 1.0 and Komodo 14.1, and these remote engines performed admirably too!

Now I'm going to try playing with remote engines on Windows.

Aldo

[Johan Sjöblom]

I will now design a solution where you should set the tutor-engine to only "remote-"-something, like "remote-stockfish". No path when you want a remote engine for your tutor. If your tutor engine name starts with "remote_" it will attempt to start it in the same directory as your engine-remote-home setting.

[Johan Sjöblom]

Done, 4-5 lines of code change!

take a git pull and you should receive a new picochess.py that can accept something like "remote_stockfish" as a tutor engine.

I have not tested it myself yet.

[Johan Sjöblom]

that solution would require you to copy the tutor uci file to /opt/picochess base directory, so I will change the solution so that we can give a full path to the tutor remote engine as I was thinking from the beginning:  tutor-engine = engines/x86_64/remote_stockfish or /opt/picochess/engines/x86_64/remote_stockfish

[Johan Sjöblom]

No changes needed. You can decide yourself how you want to do, but I do recommend a full path as that might make it possible to fulfil the other christmas wish :-) ...

tutor-engine = remote_stockfish (no path) --> looks for remote_stockfish.uci in the current working dir (typically /opt/picochess).
tutor-engine = /opt/picochess/engines/x86_64/remote_stockfish --> looks for /opt/picochess/engines/x86_64/remote_stockfish.uci

I would recommend the later second row... In any case its the one git pull you need.

[Johan Sjöblom]

Sorry for the multiple post. But yet one clarification. If you use the name "remote_" in front of your tutor engine it will always expect to find that engine in the engine-remote-home path on the remote machine. The previous post just explains where your local uci file for that remote tutor engine should be located.

And note that I am testing on a Debian machine so my paths are /x86_64/ but if you are on a Pi then its of course the /aarch64/

[Johan Sjöblom]

Tested remote tutor engine and I had to make one fix. I was filtering out the info messages from the remote engine as they caused problems with a remote engine, but from the tutor we do need all the info messages otherwise the tutor would not work.

So you need to do another git pull to get this fix. My remote tutor now works !

[Johan Sjöblom]

For the 2nd christmas point on the list we would need to make a design decision. If we want a fallback tutor for the case where we try a remote tutor first and the remote fails (like when the remote engine is not running at all)  I would propose the following design:

We always let the existing "tutor-engine" setting be a local tutor engine, as it is in most cases today. And then for an optional remote tutor we add another setting. If that is set it tries first to open a remote tutor, and failing that it would then open the "normal tutor".

Example settings for this proposal:

tutor-engine = /opt/picochess/engines/x86_64/a-stockf        # local fallback/ default, with .uci file
tutor-remote-engine = remote_stockfish                                     # optional remote tutor (uses engine-remote-home by default)

As you see in this design we no longer need a path for the remote tutor. The uci file would always be read from the tutor-engine folder.

[Francois Vannier]

First, if someone is familiar with Discord, maybe we'd like to move all our threads into a dedicated server to avoid clogging everyone's mailbox 🙂

Second, about the tutor latest improvement attempt for remote engines:

> At first sight, it is now working with a remote engine, but

> The uci parameters (default) of the remote engine, wherever the uci file is stored, do not seem to be taken into consideration (ex: threads). Testing the remote engine itself, the proper location seems to be 'aarch64'

> I got two instances of (cmd.exe & remote_stockfish) running in windows when starting fresh, maybe one at startup time & the other one when the feature is activated after the first move (guessing)

> Picotutor, normally activated by lifting & putting back a piece, does not seem to work (nothing happens)

Thanks

Francois

To view this discussion visit https://groups.google.com/d/msgid/picochess/d07912af-de6e-4fae-80ae-b0e693a0337an%40googlegroups.com.

[Johan Sjöblom]

Ah yes, of course!... the tutor engine is probably never using a uci file. Tutor settings all hard coded and set in picotutor_constants.py. and tutor always uses threads=1

The playing remote engine needs a uci file like in Aldos instruction example:  remote_stockfish.uci,... and its location is determined by what you write in your engines.ini. And those uci instructions should be used by the remote engine.

To view this discussion visit https://groups.google.com/d/msgid/picochess/CADa9EqVWG87nB9yj%3DwB9aYSDk23ZQwXPJNJXwKXUvpwKu%2B_MVg%40mail.gmail.com.

[Aldo Bleeker]

Playing against remote engines on Debian as well as Windows was working well, but then I wanted to pause the game, but noticed that the menu buttons didn't respond anymore. The interface hasn't frozen, the clock's still running, I can move pieces, and for instance change the colour of the board, but I can't select menu items, the options aren't working.

I don't think it happens every time, but I haven't found out yet when or why it happens. I've attached a log of a session where it did happen.

Aldo

[Johan Sjöblom]

First to complete the Christmas list from Francois :-) ... the new remote tutor configuration is to be done like this:

tutor-engine = /opt/picochess/engines/aarch64/a-stockf        # your existing local tutor (used as fallback if remote not given or does not start)

tutor-remote-engine = remote_stockfish                                     # optional remote tutor (uses engine-remote-home directory)

To get an optional remote tutor, just add the tutor-remote-engine line. You can let your current tutor-line be unchanged.

The configuration of the remote engine is still the same as in Aldos instructions..

Not sure if I will find a solution to the pause game during this week... but lets see... 

[Johan Sjöblom]

Aldo, your log does not show any PAUSE_EVENT button 2. It only shows that the Chesslink was trying to reconnect and that picochess was killed. Maybe the menu had problems so you chose shutdown or restart without seeing it? You do have a kill signal in the log...

2025-12-09 20:01:23.322   DEBUG  picochess - exit_sigterm: Received kill signal, shutting down

[Johan Sjöblom]

Aldo, I checked the Chesslink reconnect code. If the Chesslink reconnect fails the main loop will be frozen and the menu will not work. I think that is what happened here. I am guessing, but its the only explanation I have at the moment.

[Aldo Bleeker]

I've tried again. This what I've done.

- I've set up picochess on the Pi 5 to play remote against Windows Stockfish 16 and cleared picochess.log.

  When I started this session, picochess wasn't running on the Pi because I had stopped it earlier with sudo systemctl stop picochess.

- Start picochess.service with sudo systemctl start picochess. Hit F5 to start picochess.

- Open the menu, and select Engines > Modern Engines > Remote Stockfish 16.

- Play a few moves, 20 ply or so.

- Hit Pause in the menu.

- The menu responds with the animation, but the clock doesn't halt, but keeps on running.

-  Stop picochess.service with sudo systemctl stop picochess.

- Save picochess.log.

And you're right, in the log there's no Pause event, but there's a kill event. I don't know where that's coming from, I'm pretty sure I didn't do anything to kill the connection or picochess. Anyway, picochess hadn't been killed because I could move pieces and picochess responded. But it seems the engine was cancelled because a kill signal had been sent.

Then I've restarted picochess, but played against the local Stockfish 16. This time I could pause the game.

I've no idea what's going on here.

Aldo

[Aldo Bleeker]

I had another go, and this time the log complained about the connection. Odd, I haven't had issues with bluetooth before. Or would it locally just reconnect, so I hadn't noticed? I can retry cabled over USB.

Aldo

[Johan Sjöblom]

I have now merged this branch to master, so testing can continue in master branch.

To get back to master do this (happy path):

cd /opt/picochess
sudo systemctl stop picochess
git fetch origin
git checkout master
git pull --ff-only origin master
sudo systemctl start picochess

If you are "stuck" and need to force your /opt/picochess into exactly same as latest master code:

cd /opt/picochess
sudo systemctl stop picochess
git fetch origin
git checkout master
git reset --hard origin/master
sudo systemctl start picochess

The reset --hard will always give you the latest master code and overwrite any local code changes you have.

When I have time I could look at the Chesslink retry-connection code and make it a separate async background task so that the menu will not be stuck while Chesslink is reconnecting...

[Johan Sjöblom]

Also fixed so that tutor-coach = lift in ANALYSIS mode also works. I also tested Normal playing mode and in master branch the king lifting now works.

[Johan Sjöblom]

And... Upgraded to the latest version of all python libraries in requirements.txt, including the latest asyncssh library. Hope that stabilizes the remote connections as well.

[Francois Vannier]

Thank you very much Johan !

I am wondering if the below values from picotutor_constants.py would need to be tweaked ( and how), depending on the HW + engine used for tutor:

LOW_DEPTH = 5  # for 'obvious moves' calculation
LOW_TIME = 0.2  # time limit for 'obvious moves' and first analysis
DEEP_DEPTH = 17  # limit picotutor deep analysis (also used as analysis engine)
LOW_NUM_THREADS = 1  # parallel threads for low
NUM_THREADS = 1  # threads for deep - 1 to save CPU, 2 to have faster analysis
# VALID_ROOT_MOVES must be high enough to find also some bad moves
# but not so high that depth on PI 4 is as low as 5 or LOW_DEPTH
VALID_ROOT_MOVES = 30  # number of multipv best moves
LOW_ROOT_MOVES = 30  # number of obvious multipv root moves

& also I do not understand the comment on VALID_ROOT_MOVES  "# but not so high that depth on PI 4 is as low as 5 or LOW_DEPTH".

I guess this is legacy code, so question to whomever is familiar with this code.

Francois

To view this discussion visit https://groups.google.com/d/msgid/picochess/e1923098-52be-4f1c-915c-7bd7af6c0d7en%40googlegroups.com.

[Johan Sjöblom]

I know exactly what these means :-) But can I explain them well, maybe? I can try!  The text "but not so high that depth on PI 4 is as low as 5 or LOW_DEPTH" is my not so well formulated text! Let me try to explain better :-)

It means: If you make the VALID_ROOT_MOVES too high the analysis on Pi4 will be so slow that the Depth will not be deep enough and the tutor will therefore not work so well. Example: Deep tutor might not reach the DEEP_DEPTH of 17. The VALID_ROOT_MOVES is how many parallel variations the engine should calculate, also known as MultiPV. With this setting the tutor will calculate 30 "top moves". The tutor will only work with full accuracy if the move chosen by the user is listed within those 30 moves. You can use a higher number for the LOW_ROOT_MOVES and lower for VALID_ROOT_MOVES. The user chosen move has to be found within both lists.

The "deep" tutor will stop when it has 30 variations with depth 17. But its not so absolute. I force it to stop when the best line (=first) has reached the limit depth of 17, but the chess engine may decide to stop sooner, maybe some engines stop when one of the 30 variations reach 17. When I have looked at the debugs its seems we always get depth 17 on the first variation.

The V3 runs VALID_ROOT_MOVES = 200. In my testing I have seen that in that case the DEPTH is never 17 on a Pi4 if you play a Blitz game. I would think that the optimal value is somewhere in 10-50. I would say that with Stockfish 17.1 the optimum would be VALID_ROOT_MOVES = 20, and LOW_ROOT_MOVES = 30 (the low only goes to depth=5 so the number of variations does not matter so much). If you think that you will always as a user chose one of the 10 best moves you can set the VALID_ROOT_MOVES = 10. Let the LOW be a large number.

But now as you can use a remote tutor which has a lot more CPU you could raise both these values to 50... But will it give you any better result?. Maybe more importantly you can give the deep tutor engine more threads with NUM_THREADS. Depending on what kind of CPU you have you could give it as many threads as you like, which will make the deep tutor much faster.

The reason the tutor threads are kept low is that on a Pi4:

- On user turn both tutors run, taking at least 1 thread each = 2 threads.

- On user turn most modern engines keep pondering as you cannot control the ponder thinking which consumes as many threads as you have put in the uci file... which might be 1-3.

- Picochess V4 uses exactly 1 thread as its now fully Async... but it does depend on the Python engine

But as said above, if you have a strong CPU doing remote tutor and remote engine, you can give it a lot more CPU.

I have studied the Cambridge algorithm that this is based on and I do have a comparison note somewhere that shows the difference between V3 and V4 and how the formulas are calculated.

[Johan Sjöblom]

A year ago I made this... At that point I still had 50 variations, not 30 as now. This was my quick analysis on the Cambridge idea. Notice that in the new chess library everything is centipawns so I had to factor in 100x for the new values. Thresholds are still exactly the same. I believe I have it working the same way as in V3.

[Johan Sjöblom]

We can make a simple solution and say that when a remote tutor is in use we would always give it 2, 3 or 4 threads instead of one. Best would be to add a new variable so that we can change it when we want... We could invent a setting like "REMOTE_THREADS" and give that to the remote tutor if one is started. In some cases where you know you have 16 threads or more you could then assign it a value of 16.

[RandyR]

Note that you will need to run the following commands in the /opt/picochess folder prior to starting picochess after pulling the changes in order to get the new python modules:

source venv/bin/activate

pip3 install --upgrade pip

pip3 install --upgrade -r requirements.txt

deactivate

Then you can run:

sudo systemctl start picochess

(Another option is to re-run the installation script "./install-picochess.sh pico"

Randy