Modifying the Additional Ports


Is there a way to modify the additional ports setting of OctoPi from the linux environment while it's running? Also, where is the file that stores that information? If I modify it on the file system will OctoPrint automatically reload it?


The file is called config.yaml as described in the link. You should make a backup of this file before working on it; one wrong slip and your OctoPrint won't boot.

The section you're interested in is serial.

I'm not sure if it requires a restart in order to read your changes. But this is something you could test as easily as I could so I'll delegate this one if you don't mind. ha

nano ~/.octoprint/config.yaml


I tried it. Messed up the config. Broke Octoprint. Fixed the config. Backed it up. Tested if the setting shows up after modification. It does not. It requires a reboot.

Also, what is that when I modify the config file it says that there is a new version available? Is it checking the last modified time of the config? If so is there a flag so I can disable this? I just want it to go offline and then come back online without the user needing to refresh (preferably). My current strategy for my firmware is to:

  • create a virtual serial link with socat
  • update config.yaml with one of the pairs of ports (e.g. /dev/pts/2)
  • start octoprint as a process not a daemon

This way I can optionally monitor what octoprint is doing by parsing it's outputs.


When you say "parsing its outputs" do you mean the contents of the ~/.octoprint/logs/octoprint.log? Because this is what usually goes to STDOUT/STDERR anyway. Or do you mean the integer return code when it's exiting?

Hmm... I don't see a Logging mixin available (which would have allowed you to hook into anything that gets logged). I don't see a hook. I don't see an event. Any of those would have been useful here. There is something here though that looks like it might be a mixin: AsyncLogHandlerMixin(). Maybe there's a way of adding an attribute to your plugin's class to identify that you want to voyeur all logging events.


Oh context needed. My firmware is a process running on the same OS as OctoPrint. So yes, I'l be parsing the output from STDOUT/STDERR.


Every day of my life I sit here and watch the output from octoprint serve and read that output in realtime for each iteration of my code. If you're spawning octoprint from a bash script or from C or from Python I'm sure there's a way of tee'ing or otherwise just parsing both outputs. It all depends upon which one you run it from. Or you could just tail -f the log as another thread, to be honest.

I assume you know about /etc/init.d/octoprint on a standard OctoPi-imaged install which directly responds to commands like sudo service octoprint verb.


Really @OutsourcedGuru, everyday!

My setup won't have /etc/init.d/octoprint on it. From what i've read:

public static string Bash(this string cmd)
            var escapedArgs = cmd.Replace("\"", "\\\"");
            var process = new Process()
                StartInfo = new ProcessStartInfo
                    FileName = "/bin/bash",
                    Arguments = $"-c \"{escapedArgs}\"",
                    RedirectStandardOutput = true,
                    UseShellExecute = false,
                    CreateNoWindow = true,
            string result = process.StandardOutput.ReadToEnd();
            return result;

will allow me to just read the output of octoprint serve. Except I'll be using read lines on the process.StandardOutput instead of trying to read to the end (I hope).


Don't forget STDERR which seems to be heavily used in the softwareupdate functionality.

This is looking a bit like Microsoft C#. If it is, be careful with slashes/backslashes in paths. Or is it mono?

RedirectStandardOutput = true;
RedirectStandardError = true;
string resultOut = process.StandardOutput.ReadToEnd();
string resultErr = process.StandardError.ReadToEnd();


It's dot net core 2.2.1 c# running on BBB's Debian.


Whoa. Never would have guess that.


Well, it turns out that socat can alias the virtual ports so I don't have to do anything to OctoPrint on a per startup basis. Configure once and run away. So I did it. I'm sending Octoprint crazy data from a process on the OS.


/tmp/OctoPrint, for the win. :+1: