Fermentrack: Fermentation monitoring & BrewPi-www Replacement for Raspberry Pi

[100amps]

Ughh. So close. Next problem... When moving to the configure sensors/pins screen it throws an error saying it's unable to reach brewpi-script, try restarting it. Not sure how to check or restart the script.

When clicking the Control Temperature button on the dashboard, it says unable to connect to device. You can't have any pudding until you eat your meat! Wait, no.. You cannot update temperature settings for a device that cannot be contacted.

Fermentrack can see (and flash) the controller and the debug device connection tests succeed. Yep, tried all the resetting, restarting, rebooting. Calibration mallet is standing by in case that's needed.

 

[100amps]

If you want to, I'd say do it - but there's not really a need if you already have a working Uno. There are some features that only exist on the ESP8266 port (like WiFi connectivity!) but fundamentally it will control temperature just as well as your Uno does. If you want/need the new features, then go for it - otherwise, it's your call if you want the additional project.

Yeah, exactly. Uno is fine for my system now that I can see light at the end of the tunnel. In a moment of weakness I was beginning to doubt that I'd get the Uno controller working with Fermentrack and wondered if I should just cut my losses.

 

[LBussy]

No. Fermentrack will function with any BrewPi firmware that runs on an Arduino Uno - including the firmware you're currently running.

If you use the I2C Uno Firmware, you could even make a new diagram? cough

When moving to the configure sensors/pins screen it throws an error saying it's unable to reach brewpi-script, try restarting it. Not sure how to check or restart the script.

When clicking the Control Temperature button on the dashboard, it says unable to connect to device.

The workflow for Fermentrack expects there to be NOTHING plugged in when you start, and at some point, it will tell you to plug it in. Did you follow those instructions? If you do not, it will not "detect" your controller. I know I breezed past that a number of times when monkeying around with it.

 

[100amps]

If you use the I2C Uno Firmware, you could even make a new diagram? cough

I did actually! I don’t have an I2C display though. But might soon. Tell me what you need for a diagram. (If you did already, I apologize for forgetting). Give me napkin drawing or whatever. I see you guys have PCBs now too to simplify the assembly of a controller.

The workflow for Fermentrack expects there to be NOTHING plugged in when you start, and at some point, it will tell you to plug it in. Did you follow those instructions?

Yup. And that part worked great. Fermentrack lists the device it found. The error seems more related to Fermentrack talking to Brewpi-script.

 

[LBussy]

I did actually! I don’t have an I2C display though. But might soon. Tell me what you need for a diagram. (If you did already, I apologize for forgetting). Give me napkin drawing or whatever. I see you guys have PCBs now too to simplify the assembly of a controller.

I dropped you a note privately, thank you!

Yup. And that part worked great. Fermentrack lists the device it found. The error seems more related to Fermentrack talking to Brewpi-script.

Hm, well I'm out of ideas. I get to answer the really easy ones - @Thorrak or someone else gets to pick up the things requiring any real knowledge.

 

[maxspencer]

I am using a brewpi setup for monitoring/controlling the temperature in my keezer. It ran fine for years without touching it. This week I decided to update some of the software and put a new microsd card into it. After realizing the whole pi install of the brewpi is pretty much obsolete, I moved the pi over to fermentrack.

As a keezer it is better to have longer and deeper cycles than shorter. It runs in fridge constant mode. In the www-brewpi you could set parameters in the firmware such as min on and idle times for the compressor. I see these are also coded in the esp8266 firmware, but it seems they are not exposed to be changed. I want to move the default MIN_COOL_ON_TIME and MIN_COOL_OFF_TIME_FRIDGE_CONSTANT to values other than the defaults in the firmware. Is this not possible with fermentrack?

 

[LBussy]

After realizing the whole pi install of the brewpi is pretty much obsolete

Well, that was your first mistake. This is where I re-released it. It's improved since that post, but that was the announcement that got buried in the Mega Thread.

As a keezer it is better to have longer and deeper cycles than shorter.

Not following that logic, unless you mean for your compressor? The PID algorithm is going to maintain temperature and learn to anticipate the needs of the system no matter what box it's in.

I want to move the default MIN_COOL_ON_TIME and MIN_COOL_OFF_TIME_FRIDGE_CONSTANT to values other than the defaults in the firmware. Is this not possible with fermentrack?

Fermentrack is a web/script combo front end that replaces the classic BrewPi web UI and script backend. You can currently use either the Arduino Uno which uses the same firmware as BrewPi, or the ESP8266 which is pretty true to the original port. You can use both of these with either UI for that matter.

I had to refresh my faulty memory and I am not sure this was exposed in BrewPi's UI either. The firmware code declares these as such in TempControl.h (in both the ESP8266 and the Uno Firmware):

// Set minimum off time to prevent short cycling the compressor in seconds
const uint16_t MIN_COOL_OFF_TIME = 300;
// Use a minimum off time for the heater as well, so it heats in cycles, not lots of short bursts
const uint16_t MIN_HEAT_OFF_TIME = 300;
// Minimum on time for the cooler.
const uint16_t MIN_COOL_ON_TIME = 180;
// Minimum on time for the heater.
const uint16_t MIN_HEAT_ON_TIME = 180;
// Use a large minimum off time in fridge constant mode. No need for very fast cycling.
const uint16_t MIN_COOL_OFF_TIME_FRIDGE_CONSTANT = 600;
// Set a minimum off time between switching between heating and cooling
const uint16_t MIN_SWITCH_TIME = 600;
// Time allowed for peak detection
const uint16_t COOL_PEAK_DETECT_TIME = 1800;
const uint16_t HEAT_PEAK_DETECT_TIME = 900;

Being constants, they are not going to be changed anywhere.

You can always change these values and recompile a custom version or yourself. If you are using the Uno, I have a new repo with it organized to work with PlatformIO (since @Thorrak talked me into it quite a ways back) instead of that wretched Arduino IDE. The ESP8266 firmware repo is here and is likewise organized around PlatformIO.

 

[Brewski_59]

I am using a brewpi setup for monitoring/controlling the temperature in my keezer. It ran fine for years without touching it. This week I decided to update some of the software and put a new microsd card into it. After realizing the whole pi install of the brewpi is pretty much obsolete, I moved the pi over to fermentrack.

As a keezer it is better to have longer and deeper cycles than shorter. It runs in fridge constant mode. In the www-brewpi you could set parameters in the firmware such as min on and idle times for the compressor. I see these are also coded in the esp8266 firmware, but it seems they are not exposed to be changed. I want to move the default MIN_COOL_ON_TIME and MIN_COOL_OFF_TIME_FRIDGE_CONSTANT to values other than the defaults in the firmware. Is this not possible with fermentrack?

Is your original micro SD card intact? Couldn't you clone your old card to the new card, then get back to running what was fine for years?

 

[Brewski_59]

I'm running a new install of Fermentrack, on a new install of Buster. I found that Tilt graphing tends to stop after a few hours. So I tried the debugging option I see this

Python is missing required capability flags!

Current flags:

I ran this

sudo setcap cap_net_raw,cap_net_admin+eip /usr/bin/python3.7

No response. Also no change in debugging screen, still missing python capability flags.
Today I ran this

curl -L "https://raw.githubusercontent.com/thorrak/fermentrack-too                 ls/master/fix-environment.sh" | sudo bash

I still get the message that python is missing required capability flags

 

[LBussy]

The dropout is likely not anything to do with the cap flags if it works then stops. I had the same issue for a while in BPR and had to implement some additional checks/rechecks/restarts. I think John was doing something along those lines, not sure how far he got.

 

[garzlok]

Though my evidence is anecdotal, I attributed my dropped Tilt Graphing to signal strength from the Tilt. (I ferment in Stainless, in a modified beverage cooler) Since I incorporated a signal repeater in my set-up, my Tilt readings have not dropped.

I ended up using the Tilt App to measure the Tilt signal strength near my TiltBridge device. Anytime my Fermentrack/TiltBridge dropped the Tilt reading, I was measuring anywhere from -85 to -95 dBm. The Tilt App on an iPhone 8 even struggled with updating the SG Value when investigating the signal strength.

Again, I’m not saying you’re experiencing the same issue as me, but maybe it’s something you would want to investigate.

 

[Brewski_59]

When I check signal I'm consistently seeing high 60's to low 70's That's not bad. Besides, I have never had a signal issue using the Tilt app to log to google sheets, or logging on my Brewpi install. No I think this is a limitation to the logging routine, Like its a full buffer or something along those lines.

 

[LBussy]

It’s the way aioblescan scan works. It is related to signal strength, the app can deal with occasional drop outs. The library cannot. That’s why stronger signal will help with that.

 

[MacDee]

I have access to my RPi running Fermentrack thru remot3.io. In the past I've recovered from lost connections to my esp8266's after power outages thru a reboot of using SSH into my Rpi. This time it didn't work.

The great thing about Remot3 is I can also use VNC and look back at my router and reboot it but the router still can't see any wireless 2.4 or 5 ghz devices (i only have esp8266s on the 2.4 band).

I'm trying to solve the loss of connectivity thing remotely only. Ideas?

 

[LBussy]

I suspect it's a timing thing - the ESP's come online faster than the router so they never connect. You could try putting smart plugs on the power supplies and restart them that way.

 

[MacDee]

Do the ESP's only try to connect once on power up?

 

[LBussy]

It depends on how John set it up.

 

[MacDee]

yeah once upon a time @Thorrak had a Beta flash for slow APs. I didn't see that Beta as an option last time I flashed so I figured he had just incorporated the provision for slow APs into all of the wifi flashes.

 

[Brewski_59]

It’s the way aioblescan scan works. It is related to signal strength, the app can deal with occasional drop outs. The library cannot. That’s why stronger signal will help with that.

The two will stop logging at the same time, although they report somewhat different signal strength.

 

[Thorrak]

I had to refresh my faulty memory and I am not sure this was exposed in BrewPi's UI either. The firmware code declares these as such in TempControl.h (in both the ESP8266 and the Uno Firmware):

// Set minimum off time to prevent short cycling the compressor in seconds
const uint16_t MIN_COOL_OFF_TIME = 300;
// Use a minimum off time for the heater as well, so it heats in cycles, not lots of short bursts
const uint16_t MIN_HEAT_OFF_TIME = 300;
// Minimum on time for the cooler.
const uint16_t MIN_COOL_ON_TIME = 180;
// Minimum on time for the heater.
const uint16_t MIN_HEAT_ON_TIME = 180;
// Use a large minimum off time in fridge constant mode. No need for very fast cycling.
const uint16_t MIN_COOL_OFF_TIME_FRIDGE_CONSTANT = 600;
// Set a minimum off time between switching between heating and cooling
const uint16_t MIN_SWITCH_TIME = 600;
// Time allowed for peak detection
const uint16_t COOL_PEAK_DETECT_TIME = 1800;
const uint16_t HEAT_PEAK_DETECT_TIME = 900;

Being constants, they are not going to be changed anywhere.

Yeah, I'm pretty sure those are constants in the "legacy" BrewPi firmware. They're configurable in the "modern" firmware (0.4.x and up) but that's not what the overwhelming majority of people on here are using. (If you built it yourself, it's almost certainly legacy)

As you noted - they could be changed by anyone willing to compile their own firmware, however.

I'm running a new install of Fermentrack, on a new install of Buster. I found that Tilt graphing tends to stop after a few hours. So I tried the debugging option I see this


I ran this

sudo setcap cap_net_raw,cap_net_admin+eip /usr/bin/python3.7

No response. Also no change in debugging screen, still missing python capability flags.
Today I ran this

curl -L "https://raw.githubusercontent.com/thorrak/fermentrack-too                 ls/master/fix-environment.sh" | sudo bash

I still get the message that python is missing required capability flags

That's really strange, as the installer should set that (especially on a new install). That said, if they aren't set, it generally just doesn't work rather than dropping out after any period of time.

The dropout is likely not anything to do with the cap flags if it works then stops. I had the same issue for a while in BPR and had to implement some additional checks/rechecks/restarts. I think John was doing something along those lines, not sure how far he got.

Not far enough - yet. The overwhelming majority of issues relating to Tilts relate to environmental problems. Thus far, the approach I've taken is to try to write as many environment test cases as I can (including the setcap ones @Brewski_59 mentioned above). The real solution - in my opinion - is containerization.

That said, my focus the past few weeks has been on getting the Docker port together and tested once I have that mostly together, I'm going to go back and add a lot of the same checks/restarts you have.

Do the ESP's only try to connect once on power up?

Sort of --

On power up, the ESP attempts to connect if it has WiFi credentials. If it can't connect (e.g. if your router is disconnected/out of range) then it spins up a configuration AP for 5 minutes. If it isn't configured during that 5 minutes it tears down the configuration AP and launches the standard "controller" processes.

That said, part of the loop while controlling temperature checks for a WiFi connection and should trigger an automatic reconnect if no connection is detected. Assuming that it has saved WiFi credentials, they should get used.

It's admittedly been a few months (years?) since I last looked at that code, though, so I could be remembering incorrectly.

 

[bscuderi]

Random question that doesn’t really affect the usability of the program but I wonder if there is any specific reason I can’t load my fermentrack webpage inside of an i frame. I can go to the website manually in my browser but I was just hoping to add it as a page in my home assistant dashboard. It would just put it with other smart tech and sensors in a centralized location.

 

[Thorrak]

Random question that doesn’t really affect the usability of the program but I wonder if there is any specific reason I can’t load my fermentrack webpage inside of an i frame. I can go to the website manually in my browser but I was just hoping to add it as a page in my home assistant dashboard. It would just put it with other smart tech and sensors in a centralized location.

There shouldn’t be, so long as everything is on the same network.

What happens when you try?

 

[100amps]

Ughh. So close. Next problem... When moving to the configure sensors/pins screen it throws an error saying it's unable to reach brewpi-script, try restarting it. Not sure how to check or restart the script.

When clicking the Control Temperature button on the dashboard, it says unable to connect to device. You can't have any pudding until you eat your meat! Wait, no.. You cannot update temperature settings for a device that cannot be contacted.

Fermentrack can see (and flash) the controller and the debug device connection tests succeed. Yep, tried all the resetting, restarting, rebooting. Calibration mallet is standing by in case that's needed.

Dang, I left my invisibility cloak on again.

@Thorrak, Do you have any suggestions for troubleshooting this seemingly contradicting issue?

 

[Brewski_59]

Dang, I left my invisibility cloak on again.

@Thorrak, Do you have any suggestions for troubleshooting this seemingly contradicting issue?

Are you using the arduino? How is the USB connection between the arduino and the raspberry pi? I did have a USB cable failure cause me all kinds of grief, if you have a different cable to try, try that.
Look at the output from the stderr log for clues
This is what I get under normal operation
Dec 09 2020 03:36:57 Connection type Serial selected. Opening serial port.
Dec 09 2020 03:36:57 Connected via serial to port /dev/ttyACM0
Dec 09 2020 03:36:57 Notification: Script started for beer 'Rye_IPA'
Dec 09 2020 03:37:07 Checking software version on controller...
Dec 09 2020 03:37:07 Found BrewPi v0.2.10 build unknown, running on an Arduino Uno with a revC shield on port /dev/ttyACM0


This when its FUBAR
Dec 08 2020 21:06:06 Error: controller is not responding to new data requests. Exiting.

 

[100amps]

Heya Brewski_59. Thanks for responding. Yeah, USB cable is good, tested, swapped out and back. As mentioned, the connection diagnostics all pass, and I've been able to flash the UNO with the BrewPiRemix FW through Fermentrack.
Here's STDERR (time is in UTC for some reason.)

 Dec 09 2020 06:06:04   Serial Error: [Errno 5] Input/output error)
 Dec 09 2020 06:06:04   Lost serial connection. Error: [Errno 19] could not open port /dev/ttyACM0: [Errno 19] No such device: '/dev/ttyACM0')
Terminating due to fatal serial error
 Dec 09 2020 06:06:06   Unable to locate device using USB serial number
 Dec 09 2020 06:06:06   Connection type Serial selected. Opening serial port.
 Dec 09 2020 06:06:16   Errors while opening serial port: 
[Errno 2] could not open port /dev/ttyACM0: [Errno 2] No such file or directory: '/dev/ttyACM0'

 Dec 09 2020 06:06:21   Unable to locate device using USB serial number
 Dec 09 2020 06:06:21   Connection type Serial selected. Opening serial port.
 Dec 09 2020 06:06:23   Connected via serial to port /dev/ttyACM0
 Dec 09 2020 06:06:23   Notification: Script started for beer 'Test1'
 Dec 09 2020 06:06:33   Checking software version on controller... 
 Dec 09 2020 06:06:44   Warning: Cannot receive version number from controller. Your controller is either not programmed or running a very old version of BrewPi. Please upload a new version of BrewPi to your controller.
 Dec 09 2020 06:06:46   Connection type Serial selected. Opening serial port.
 Dec 09 2020 06:06:46   Connected via serial to port /dev/ttyACM0
 Dec 09 2020 06:06:46   Notification: Script started for beer 'Test1'
 Dec 09 2020 06:06:56   Checking software version on controller... 
 Dec 09 2020 06:06:56   Found BrewPi v0.2.12 build 8d36524, running on an Arduino Uno with a I2C shield on port /dev/ttyACM0

 Dec 09 2020 06:06:56   BrewPi version received was 0.2.12 which this script supports in 'legacy' branch mode.
 Dec 09 2020 06:06:57   Installed devices received: []
 Dec 09 2020 06:06:57   Available devices received: [{"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 5, "x": 0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 6, "x": 0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 2, "x": 0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 10, "x": 0}]

And here's the debug connection results, which seem to contradict the error log here and there.

Connection Settings
Connection Type    serial
USB Serial Number    Arduino__www.arduino.cc__0043_7403530353035140A120
Locate port via USB Serial?    True
Last Located Serial Port    /dev/ttyACM0
Serial Alt Port (optional)    None
Tests Performed
Test    Parameter    Pass/Fail    Output
Device Status Test    active    Passed    Device active & managed by Circus
Udev Availability Test    Linux    Passed    pyudev is available & loaded
USB Serial Number (SN) Usage Test    True    Passed    Will look up port via USB serial number
USB SN Test        Passed    Arduino__www.arduino.cc__0043_7403530353035140A120
USB SN Availability Test    (USB SN)    Passed    /dev/ttyACM0
Udev Matches Cached Port Test    /dev/ttyACM0    Passed    /dev/ttyACM0

 

[peram]

Heya Brewski_59. Thanks for responding. Yeah, USB cable is good, tested, swapped out and back. As mentioned, the connection diagnostics all pass, and I've been able to flash the UNO with the BrewPiRemix FW through Fermentrack.
Here's STDERR (time is in UTC for some reason.)

Dec 09 2020 06:06:04   Serial Error: [Errno 5] Input/output error)
Dec 09 2020 06:06:04   Lost serial connection. Error: [Errno 19] could not open port /dev/ttyACM0: [Errno 19] No such device: '/dev/ttyACM0')
Terminating due to fatal serial error
Dec 09 2020 06:06:06   Unable to locate device using USB serial number
Dec 09 2020 06:06:06   Connection type Serial selected. Opening serial port.
Dec 09 2020 06:06:16   Errors while opening serial port:
[Errno 2] could not open port /dev/ttyACM0: [Errno 2] No such file or directory: '/dev/ttyACM0'

just a shot in the dark from a noob, but is it a "true" Uno or a clone ? I thing the devices-name are different for the clones... And what ls -l show on /dev/ttyACM0 to verify the accessrights on the device ?

peram

 

[100amps]

Thanks peram. Its a Sainsmart UNO. Decent quality. It’s been in constant use running Brewpi with no problems for 4-5 years now.

I did just change the fw on it to BrewPi Remix with I2C shield firmware.

And I’ll try ls -l on it tomorrow. I didn’t realize you could run that on a connection.

 

[peram]

Thanks peram. Its a Sainsmart UNO. Decent quality. It’s been in constant use running Brewpi with no problems for 4-5 years now.

I did just change the fw on it to BrewPi Remix with I2C shield firmware.

And I’ll try ls -l on it tomorrow. I didn’t realize you could run that on a connection.

As I said i'm a noob on this and dont have any fermentrak online now så my comments may be way off

the good thing about linux is at everything is a file so yes you can do ls -l /dev/ttyACM0 and it will show you what rights is has.

 

[LBussy]

I did just change the fw on it to BrewPi Remix with I2C shield firmware.

There's no reason for it not to work. You might try adding the user fermentrack to the dialout group:

sudo adduser fermentrack dialout

You could always go back to BPR which works (just testing to see if @Thorrak is paying attention ).

 

[Brewski_59]

Dec 09 2020 06:06:56 Checking software version on controller...
Dec 09 2020 06:06:56 Found BrewPi v0.2.12 build 8d36524, running on an Arduino Uno with a I2C shield on port /dev/ttyACM0

Dec 09 2020 06:06:56 BrewPi version received was 0.2.12 which this script supports in 'legacy' branch mode.
Dec 09 2020 06:06:57 Installed devices received: []
Dec 09 2020 06:06:57 Available devices received: [{"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 5, "x": 0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 6, "x": 0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 2, "x": 0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 10, "x": 0}]

Odd
This looks like its communicating at 6:06:56
Could be an intermittent connection.

This was the last entry from your err log. based on this I expect it should be working. Are there more instances of it failing after this? I'm still suspecting a cable if its intermittent.


What I don't see is this line Dec 08 2020 21:06:24 Bound to TCP socket on port XXXX, interface localhost

It was between the Brewpi version recieved, and installed devices received lines.

 

[calandryll]

I haven't brewed in a few months and just looked at my install of Fermentrack. It looks like the SD card is starting go on the associated Pi. Since I have an extra computer or two, what's the easiest way to migrate to a Docker install? I would like to copy over all of the data I've done so far with it.

 

[100amps]

There's no reason for it not to work. You might try adding the user fermentrack to the dialout group:

sudo adduser fermentrack dialout

Heya. Yeah, I assumed it should work. I will try that user change.

You could always go back to BPR which works (just testing to see if @Thorrak is paying attention ).

Actually, I've never ran BPRemix. I'd been running Elco's BrewPi until last week. I probably would have, but didn't really know what BPR was. Not paying enough attention to the world around me. But, (no offense intended) I think Fermentrack is the way forward for me -- if I can get past these hurdles.

 

[100amps]

Odd
This looks like its communicating at 6:06:56
Could be an intermittent connection.

This was the last entry from your err log. based on this I expect it should be working. Are there more instances of it failing after this? I'm still suspecting a cable if its intermittent.

What I don't see is this line Dec 08 2020 21:06:24 Bound to TCP socket on port XXXX, interface localhost
It was between the Brewpi version recieved, and installed devices received lines.

That log dump was consistent with a bunch of previous attempts to continue configuring the app. It doesn't seem intermittent to me. It was captured moments before I posted it. Not sure about that TCP socket message. I wouldn't expect TCP to be involved with UNO communications in this set-up, but I obviously don't know how it's supposed to work.

 

[Brewski_59]

That log dump was consistent with a bunch of previous attempts to continue configuring the app. It doesn't seem intermittent to me. It was captured moments before I posted it. Not sure about that TCP socket message. I wouldn't expect TCP to be involved with UNO communications in this set-up, but I obviously don't know how it's supposed to work.

Is the use inetsocket box checked under Connect Interface to Script on your configuration page? it is on mine, I suppose that explains the TCP socket message.

 

[100amps]

So, fermentrack user is already a member of dialout.
ls -l on the ttyACM0 device: crw-rw----+
inetsocket is not checked.

That help?

 

[Thorrak]

You could always go back to BPR which works (just testing to see if @Thorrak is paying attention ).

No comment.

I haven't brewed in a few months and just looked at my install of Fermentrack. It looks like the SD card is starting go on the associated Pi. Since I have an extra computer or two, what's the easiest way to migrate to a Docker install? I would like to copy over all of the data I've done so far with it.

I'll shoot you a PM. Copying over the data is the tough bit, though - not quite there yet unfortunately (though it's in the works).

So, fermentrack user is already a member of dialout.
ls -l on the ttyACM0 device: crw-rw----+
inetsocket is not checked.

That help?

Try using inetsockets. I did a bunch of editing this past weekend on a fork of the script - I recall seeing some potential bugs with the socket implementation - especially if you didn't explicitly change the socket names.

 

[100amps]

Try using inetsockets. I did a bunch of editing this past weekend on a fork of the script - I recall seeing some potential bugs with the socket implementation - especially if you didn't explicitly change the socket names.

After checking the inetsocks checkbox I could not save the config. It said a device with that name already exists. I ignored that rabbit hole and decided to cut my losses. I deleted the device and created a new one from scratch. The inetsocks checkbox was checked by default. Success! Everything seems to be working fine.

Now to drag it all out to the brewery (garage) and hook it up for reals... See what else I can break.

 

[Thorrak]

After checking the inetsocks checkbox I could not save the config. It said a device with that name already exists. I ignored that rabbit hole and decided to cut my losses. I deleted the device and created a new one from scratch. The inetsocks checkbox was checked by default. Success! Everything seems to be working fine.

Now to drag it all out to the brewery (garage) and hook it up for reals... See what else I can break.

That's (the error about the device with that name already existing) a bug. I have the fix ready to go - it's in queue to be merged whenever I merge docker support. Sorry about that.

The inability to use unix socket is also a bug. I think that's also in queue to be merged whenever I merge docker support, but I'll have to test that.

 

[100amps]

That's (the error about the device with that name already existing) a bug. I have the fix ready to go - it's in queue to be merged whenever I merge docker support. Sorry about that.

The inability to use unix socket is also a bug. I think that's also in queue to be merged whenever I merge docker support, but I'll have to test that.

Nothin to be sorry about, sir! I’m just happy you’ve done what you already have.

 

[100amps]

- it's in queue to be merged whenever I merge docker support.

Just curious, Thorrak, what’s the benefit you want from Dockerizing? Just better portability? Or does it simplify deployment? Or?