Modifying the Additional Ports


#1

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?


#2

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


#3

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.


#4

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.


#5

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.


#6

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.


#7

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,
                }
            };
            process.Start();
            string result = process.StandardOutput.ReadToEnd();
            process.WaitForExit();
            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).


#8

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();

#9

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


#10

Whoa. Never would have guess that.


#11

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.


#12

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