Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proper permissions to start REM with pm2? #1

Closed
johnny2678 opened this issue Feb 23, 2021 · 3 comments
Closed

proper permissions to start REM with pm2? #1

johnny2678 opened this issue Feb 23, 2021 · 3 comments

Comments

@johnny2678
Copy link

I can run REM as pi using npm start and everything works fine (i2c, etc)

When I run with pm2 (as pi), it gets caught in a loop:

3|relayEquipmentManager  | > [email protected] start /home/pi/relayEquipmentManager
3|relayEquipmentManager  | > npm run build && node dist/app.js
3|relayEquipmentManager  | > [email protected] build /home/pi/relayEquipmentManager
3|relayEquipmentManager  | > tsc
3|relayEquipmentManager  | linux
3|relayEquipmentManager  | info: Connecting mqtt to mqtt://192.168.5.140:1883
3|relayEquipmentManager  | info: Initializing GPIO Pins 1
3|relayEquipmentManager  | info: Configuring Pin #36 Gpio #16:out on Header 1.
3|relayEquipmentManager  | info: Pin #36 Gpio #16:out on Header 1 Configured.
3|relayEquipmentManager  | info: Initializing SPI Bus #0
3|relayEquipmentManager  | info: SPI Bus #0 Initialized
3|relayEquipmentManager  | info: Initializing SPI Bus #1
3|relayEquipmentManager  | info: SPI Bus #1 Initialized
3|relayEquipmentManager  | info: Initializing i2c Interface
3|relayEquipmentManager  | info: Detecting i2c Buses
3|relayEquipmentManager  | info: Detecting i2c Buses /sys/class/i2c-dev/i2c-1
3|relayEquipmentManager  | info: Initializing i2c Bus #1
3|relayEquipmentManager  | info: Server is now listening on 0.0.0.0:8085
3|relayEquipmentManager  | info: Connected to njspc-15620 : http://192.168.5.205:4200
3|relayEquipmentManager  | info: Scanning i2c Bus #1
3|relayEquipmentManager  | info: Found I2C device Atlas_EZO-ORP at address: 0x62
3|relayEquipmentManager  | info: Found I2C device Atlas_EZO-pH at address: 0x63
3|relayEquipmentManager  | warn: Atlas_EZO-ORP Suspend Polling 3
3|relayEquipmentManager  | info: Device Atlas EZO-ORP initialized for i2c bus #1 address 98
3|relayEquipmentManager  | info: New socket client connected RpewmNvFknuFdwhtAAAA -- 192.168.5.205
3|relayEquipmentManager  | warn: Atlas_EZO-pH - Device not ready re-trying the command L,? again: Retries 0.
3|relayEquipmentManager  | error: Atlas_EZO-pH 99 Slope,?. No I2c data to send
3|relayEquipmentManager  | info: Device Atlas EZO-pH initialized for i2c bus #1 address 99
3|relayEquipmentManager  | info: i2c Bus #1 Initialized
3|relayEquipmentManager  | info: New socket client connected 78V4RAsegw8D1nYYAAAB -- 192.168.5.138
**3|relayEquipmentManager  | Shutting down Relay Equipment Manager**
3|relayEquipmentManager  | info: Closing 2 devices.
3|relayEquipmentManager  | info: Stopped I2c Atlas_EZO-ORP
3|relayEquipmentManager  | info: Stopped I2c Atlas_EZO-pH
3|relayEquipmentManager  | info: Closed i2c Bus #1
3|relayEquipmentManager  | info: Stopping GPIO Controller
3|relayEquipmentManager  | > [email protected] start /home/pi/relayEquipmentManager
3|relayEquipmentManager  | > npm run build && node dist/app.js
3|relayEquipmentManager  | > [email protected] build /home/pi/relayEquipmentManager
3|relayEquipmentManager  | > tsc

Not a lot there to tell me what's going on. Here's my pm2 ecosystem js file:

module.exports = {
 apps: [
         {
             "name": "relayEquipmentManager",
             "script": "npm",
             "args": [
                 "start"
             ],
             "cwd": "/home/pi/relayEquipmentManager",
             "autorestart": false,
             "restart_delay": 10000,
             "env": {
                 "NODE_ENV": ""
             },
             "watch": true,
             "ignore_watch": ["node_modules", "config.json", "src", "dist", ".cache"]
         }
     ],
   deploy : {
     production : {
       user : 'SSH_USERNAME',
       host : 'SSH_HOSTMACHINE',
       ref  : 'origin/master',
       repo : 'GIT_REPOSITORY',
       path : 'DESTINATION_PATH',
       'pre-deploy-local': '',
       'post-deploy' : 'npm install && pm2 reload ecosystem.config.js --env production',
       'pre-setup': ''
     }
   }
};

See anything obvious that would cause a loop? Any way to increase logging on REM to give more details about why it's shutting down?

Not a big deal as I can run directly using npm start but would be better process mgmt if I could get it to work using pm2.

@johnny2678
Copy link
Author

johnny2678 commented Feb 23, 2021

also just a comment... on my pi, i had to run REM as root (sudo su -) when I set up the i2c connection.

Otherwise it couldn't find the probes. Once I set up the i2c connection and configured the probes, REM works just fine running as pi

a bit odd since I can query probe values via an i2c python script I wrote running as pi. Originally setup i2c permissions using something like this.

Not a big deal in the end. Just need to get pm2 working and environment will be pretty steady.

BTW, I completely shut down my acid dosing nodered flow. Today's acid dosing has been entirely controlled by REM:

image

I've configured the dosing/mixing exactly like i had in nodered so there are no differences between today's graph and any other day prior to today, except REM is running the dosing automation. Great job!

edit: wording

@johnny2678
Copy link
Author

omg... rooking mistake on my part. I had pm2 watch set to true so it kept restarting when the REM folder contents changed. Sorry to bother!

@DrJeff
Copy link

DrJeff commented Mar 13, 2021

@johnny2678
How do you get the values into njspc via a script to mqtt I have sensors external but want to feed to njspc? Next item on list to do PH ORP with SWG IC60

rstrouse pushed a commit that referenced this issue Jun 1, 2024
This PR adds support for Sequent Systems Smart Fan v6, along with support for Raspi OS Bookworm on a 4B.

The v6 Smart Fan uses a different GPIO pin from previous generations, and also lacks the capabilities drop from v4 onward. As I don't have an older device to test with, I opted to create a new module for this generation instead of sharing the existing one. This new module only contains the capabilities of the v4 and onward, and supports the changed GPIO pin in v6 (?). Some other general fixes as well.

Raspberry Pi Bookworm changes how GPIO pins are addressed. Per @rstrouse in #61 (comment)

I have found why your GPIO numbers seem so strange. The pi engineers are now identifying gpios by touple which includes the chip id (2) in the gpio. Honestly, this is the same approach as other boards such as the orange pi and probably what raspberry should have been doing all along. Perhaps there is a future for multiple gpio headers on the same board. For now the problem is that the pi 5 does not have the gpio chip embedded (chip id 0). It is external to the cpu on chip id (2).

To address this, I have included a new pinout profile that I have tested with the Raspberry 4B. I am almost certain the 5 will need a different pinout, but unsure of other 4 variants and earlier.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants