It's *always* something...

[FlaMike]

Where is Emily Littella when you need her?

Reconstructed successfully njsPC, dashPanel, & REM on a new Pi5 4GB running Bookworm & everything is finally coming together again... almost.

My Pi stack is Pi---SmartFan6+---MegaBas---Multi-relayBoard---EZO

Other than the new Pi this is the same stack that's been running for well over 2 years.

i2Cdectect shows all expected and no unexpected devices. Everything is configured except the SmartFan6+.

The fan shows up as exptected in REM's i2C-bus #1 devices tab at address 45 0x2d. When I try to configure the SmartFan, (tell REM it's active & a Smart Fan6+) and click Save Device, the screen dims and it attempts to save the device, but then REM crashes & restarts. The PM2 REM logs show the following:

michael@nixie:~ $ pm2 logs REM
[TAILING] Tailing last 15 lines for [REM] process (change the value with --lines option)
/home/michael/.pm2/logs/REM-error.log last 15 lines:
0|REM | free(): invalid pointer
0|REM | Aborted
0|REM | free(): invalid pointer
0|REM | Aborted
0|REM | free(): invalid pointer
0|REM | Aborted

/home/michael/.pm2/logs/REM-out.log last 15 lines:
0|REM | [12/04/2026, 11:27:43] info: Found I2C device Unknown at address: 45 - (0x2d)
0|REM | [12/04/2026, 11:27:43] info: Found I2C device Sequent MEGA-BAS at address: 72 - (0x48)
0|REM | [12/04/2026, 11:27:43] info: Found I2C device Atlas_EZO-ORP at address: 98 - (0x62)
0|REM | [12/04/2026, 11:27:43] info: Found I2C device Atlas_EZO-pH at address: 99 - (0x63)
0|REM | <Buffer 00 96 00 40 01>
0|REM | { baud: 38400, mode: 0, parity: 0, stopBits: 1, address: 1 }
0|REM | [12/04/2026, 11:27:43] info: Device Sequent MEGA-BAS initialized for i2c bus #1 address 72
0|REM | [12/04/2026, 11:27:43] info: Device Multi-Relay Board initialized for i2c bus #1 address 38
0|REM | [12/04/2026, 11:27:45] info: New socket client connected pEt5aqrWPpmiYLC3AAAB -- 192.168.1.130
0|REM | [12/04/2026, 11:27:46] info: Device Atlas EZO-ORP initialized for i2c bus #1 address 98
0|REM | [12/04/2026, 11:27:50] info: Device Atlas EZO-pH initialized for i2c bus #1 address 99
0|REM | [12/04/2026, 11:27:50] info: i2c Bus #1 Initialized
0|REM | [12/04/2026, 11:27:52] info: New socket client connected nQhq1ZwXoDU5xe6vAAAD -- 192.168.1.112
0|REM | [12/04/2026, 11:27:57] info: Setting device state {"type":"i2c","busId":1,"deviceId":2,"binding":"i2c:1:2:4","typeId":1,"id":2,"params":["4"]}
0|REM | setDeviceState

Is there a way to get the fan configured & functional again?

Thanks for your help!!!

[tagyoureit]

Pull the latest. Pushed up some changes to hopefully get it working. rstrouse/relayEquipmentManager@78b00f4

[FlaMike]

I did the pull & tested it this am on a clone of the production disk & it worked fine. When I replicated it on the production disk it failed. The discs are clones created using "clone disc" in Balena Etcher with verification turned on. I am flummoxed as to why the change did not work on the production disc, but I'm blown at the moment. Running without the smart fan & just using a case fan which is likely far more important.

I also re-installed Sequent's smart fan firmware to no avail. It found the board without any issues, but the invalid pointer error persists, at least in my production system. :-(

[FlaMike]

Did a bit more playing around & want to share what I learned with you. I've been building and running the system using "npm install" and "npm run build" so pm2 could use "run start:cached" formatted correctly, of course, & things start up quickly.

I pulled the REM fix you posted & did a fresh npm install & npm run build. Deleted REM from pm2 & started fresh there, too. No love with the fix. However, if I start REM manually using "node dist/app.js" from the relayEquipmentManager directory, everything is good, including configuring the SmartFan 6+.

Unfortunately, I don't seem to be able to REM to run automatically on crash recovery/reboot after power failure using pm2. Although I have a whole house generator, there's a delay before it kicks in when we have an all-too-frequent outage. So the Pi and all need to be able to reboot & recover unattended to keep the pool running on its own.

The good news is that if I don't confgure the Smart Fan, everything is OK, so I do have a working system. Not sure how to proceeed from here, other than ignoring & evenutally removing the fan from the Pi stack.

[FlaMike]

I shall give it a shot, in addition to the suggestions in your other note.  Thanks!

…

On 4/17/26 11:49 AM, tagyoureit wrote: Pull the latest. Pushed up some changes to hopefully get it working. ***@***.*** <rstrouse/relayEquipmentManager@78b00f4> — Reply to this email directly, view it on GitHub <#1170?email_source=notifications&email_token=AJ3NIBB3HQCMGVRS6ELZZC34WJOCFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRWGA2TGNZZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-16605379>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ3NIBFHQLW7Q3WFM3TT4B34WJOCFAVCNFSM6AAAAACXWDK3L2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNRQGUZTOOI>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[johnny2678]

Hey FlaMike — I saw your post and thought it was worth chiming in because our setups look nearly identical. I'll admit upfront that I had Claude help me review your situation and compare it to mine, since we have a similar setup.

My stack: Pi, SmartFan (older type 1001), MEGA-BAS, Multi-Relay, EZO-ORP, EZO-pH — same core hardware as you, just the older fan board. Mine runs fine under PM2, which is why your crash caught my attention.

What I think is happening:

Your crash (free(): invalid pointer) happens under PM2 but not with node dist/app.js directly. The command being run should be identical since start:cached is just node dist/app.js — so the difference has to be in how PM2 is managing the process.

Two things worth trying from my setup:

1. Run node directly in PM2 instead of through npm

In your ecosystem.config.js, if you're using:

"script": "npm",
"args": ["start:cached"]

Try changing it to:

"script": "node",
"args": ["dist/app.js"]

When PM2 manages an npm process, node is actually a grandchild of PM2. When PM2 kills the process, the signal doesn't always propagate cleanly to the node child — especially if native i2c or GPIO code is mid-execution. Running node directly makes PM2 own the process cleanly, which more closely mirrors what you already know works.

2. Check your watch list for config/data directories

If your ecosystem.config.js is watching a config or data directory, saving device settings through the UI will trigger a PM2 restart at the same time REM is trying to initialize the SmartFan6+ native driver (GPIO pin setup + i2c reads). That race between PM2 killing the process and the native addon running is a likely candidate for the memory corruption. Try adding:

"ignore_watch": ["data", "*.json"]

or just temporarily remove "config" from the watch list and see if you can configure the fan without a crash.

3. One more thought on the Pi5

The SmartFan6+ code sets up GPIO pin 32 for fan power. Pi5 uses the new RP1 GPIO chip, and some GPIO libraries behave differently there — particularly when invoked as a subprocess of npm rather than directly as node. This might be why tagyoureit's fix worked on the clone (possibly a different PM2/npm configuration) but not production.

Hope one of those helps. Happy to share my full ecosystem.config.js if that would be useful for comparison.

[FlaMike]

Hi johnny2678,

Thank you so much for your thoughts, research, & suggestions!

My depth of knowledge in npm and pm2 is limited to what's been in the poolController wiki and the discussions folks have posted, so you explanation is very helpful. In the past I have tried using "script": "node", with "args": ["dist/app.js"] but I've been through so many variants of the ecosystem file, I can't say exactly why I went back to "node":... and "start": cached". I'm gonna blame a chatbot :-) I'm certainly willing to go back to "node" for the current challenge. Getting rid of a middleman certainly makes sense to me.

The current ecosystem variant I'm using with the latest fan patch does not use "watch", here is the REM exerpt. For better or worse, njsPC and dashPanel use the same approach, without REM_GPIO_BACKEND: "libgpiod-onoff"

{
  name: "REM",
  cwd: "/home/michael/relayEquipmentManager",
  script: "npm",
  args: "run start:cached",
  env: {
    NODE_ENV: "production",
    REM_GPIO_BACKEND: "libgpiod-onoff"
  },
autorestart: true,
restart_delay: 5000
},

The "REM_GPIO_BACKEND: "libgpiod-onoff" was suggested by chatgpt to try to address the Pi 4's gpio library issues. I probably should switch to claude for code chats. Offhand, I don't know if the Pi4 & 5 have similar GPIO chips. I think they're both different than the 3b+.

I'm also wondering it I should just go back to a Pi3B+ to get past the smartfan challenges or just remove it from the stack. I have a case fan & don't know how much the smartfan really matters. It does get toasty here in the summer. Fortunately, the equipment pad faces east, so the blazing afternoon sun is shaded by the house. I don't believe things get warm enough for the Pi to throttle itself due to heat. It's certainly not too hot currently--the CPU is < 120, that's when the case fan turns on. The air temp is 83, so we'll get another 10+/- degrees in July/August.

I'm running 64 bit bookworm in my various experiments. My daliances with Trixie were problematic, so I downgraded the OS & made some progress.

Thanks again for your time, thoughts, & help!! I'll let you know how things go.

[tagyoureit]

You really should be using the ignore_watch. We write files to the directory and every time we write a file PM2 will restart the app if it isn't told to ignore the directory.

[FlaMike]

I can put it back in. Can I just add what's in the example ecosystem.config.js from the Wiki after the "env" section as in the snippet above? AI chats told me to take it out. I have no expertise with PM2 other than using it for this project, so I blindy do what's suggested.

[tagyoureit]

There are full examples in the PM2 wiki. I prefer the watch because you are just limiting it to a smaller number of directories. But the exclusion of the files that get changed is the important part.

[FlaMike]

Would this work or will it hose things up? I can go back to the exact Wiki file, but with start:cached if that's the better option.

{
name: "REM",
cwd: "/home/michael/relayEquipmentManager",
script: "npm",
args: "run start:cached",
env: {
NODE_ENV: "production",
REM_GPIO_BACKEND: "libgpiod-onoff"
},
"watch": [
"boards",
"config",
"connections",
"devices",
"gpio",
"i2c-bus",
"logger",
"pages",
"pinouts",
"spi-adc",
"web",
"package.json"
],
"watch_delay": 5000,
"kill_timeout": 15000
autorestart: true,
restart_delay: 5000
},

[FlaMike]

@johnny2678 Would you mind posting your ecosystem.config.js file? I've not had an opportinity to play with the system since your post last week, but any & all suggestions are welcome. Thanks in advance!

[johnny2678]

Hey FlaMike! I don't use PM2 at all except for this project, but this config has been working well for me:

module.exports = {
  apps : [
    {
      "name": "REM",
      "script": "npm",
      "args": [
        "start"
      ],
      "cwd": "/home/john/relayEquipmentManager",
      "restart_delay": 10000,
      "watch": [
        "boards",
        "config",
        "connections",
        "devices",
        "gpio",
        "i2c-bus",
        "logger",
        "pages",
        "pinouts",
        "spi-adc",
        "web",
        "package.json"
      ],
      "watch_delay": 5000,
      "kill_timeout": 15000
    },
    {
      "name": "dashPanel",
      "script": "npm",
      "args": [
        "start"
      ],
      "cwd": "/home/john/nodejs-poolController-dashPanel",
      "restart_delay": 10000,
      "watch": [
        "pages",
        "scripts",
        "server",
        "package.json"
      ],
      "watch_delay": 5000,
      "kill_timeout": 15000
    },
    {
      "name": "njsPC",
      "script": "npm",
      "args": [
        "start"
      ],
      "cwd": "/home/john/nodejs-poolController",
      "restart_delay": 10000,
      "watch": [
        "config",
        "controller",
        "logger",
        "web",
        "package.json"
      ],
      "watch_delay": 5000,
      "kill_timeout": 15000
    }
  ]
};

[FlaMike]

Thank you! It looks pretty close to the Wiki model other than the home directory, which makes sense to me. I'll probably give it a shot with the change you suggested last week & hope that does the trick:

"script": "node",
"args": ["dist/app.js"]