Zwave JS UI Server Build and upgrade without docker

Well, no offense, but maybe you may want to reconsider your choice of installation method. You chose the only installation method that specifically targets people who are very familiar with how to manage a Linux system, build software from source themselves, etc. This can’t really be done by randomly copy and pasting code you find, as it depends a lot on your specific situation.

If you want to learn about all this, then great ! It’s a very deep and interesting rabbit hole. But then you must do it methodologically by reading up on Linux system administration basics first and work your way up, while understanding what you’re doing and where to look when things go wrong (logs !). Be aware there is a (rather steep) learning curve if you come from Windows. Setting up an experimental NodeJS server on Linux isn’t really the best approach to learning if you don’t know the basics yet.

If you just want to get your zwave-js up and running on HA, just use the Docker or Supervised installs.

this is what I use to get zwaveJS to start manually

pi@raspberry:~/zwavejs2mqtt $ ./zwavejs2mqtt

ARM and x86-64 does stuff different on making zwave-js work

Right, so the cwd item (current working directory) in the same block, changes the directory to /home/pi/zwave2mqtt. The app.js file (which I thought would launch the package) is located there, hence the relative ./app.js reference.

So thanks both you and Alex for that crucial tip. Looking for a script file without a script extension in a folder called bin. Reminds me of a the Beware of the Leopard passage from Hitchhiker’s :laughing:

Anyway, things are humming along nicely, OCD appeased!


And this is my working configuration file for pm2 which will start up zwavejs2mqtt

{
        "apps": [
                {
                        "name": "njsPC 6.1.1",
                        "script": "./dist/app.js",
                        "instances": 1,
                        "cwd": "/home/pi/controller.611"
                },
                {
                        "name": "njsPC Web 6.1.0",
                        "script": "./dist/Server.js",
                        "instances": 1,
                        "cwd": "/home/pi/webclient.610",
                        "env":  {
                                "NODE_ENV": "production node dist/Server.js"
                        }
                },
                {
                        "name": "ZwaveJS2MQTT",
                        "script": "bin/www",
                        "instances": 1,
                        "cwd": "/home/pi/zwavejs2mqtt"
                }

        ]
}

You gents may want to check out pm2 as it’s a really cool method of running multiple npm packages at once on most linux flavors, raspian included. It’s a heckuva lot more lightweight than docker and it supports pretty much any other kind of process; python, shell scripts, regular binaries etc. The command pm2 imonit gives you a nice realtime view of cpu+ram consumption


and pm2 logs tails the console output from any of these.

Well, I don’t blame you hesitating. This is my third time around the house removing climbing ladders, removing covers and excluding+including various devices.

Having fled the almost daily glitches of the SmartThings-Apple-Wannabe garden, where the walls were closing in on mad-hatter-tinkerers such as myself, I went with Webcore and Actiontiles on a Hubitat Elevation C7 hub. Life was good until 2/3rds through the migration, where it became painfully apparent that the HE hub subjectively has about as much CPU power as an 80’s era calculator watch…

So while HE is locally executing and dev friendly, their built-in rule engine IMHO is complete illogical garbage. And when only about 30 well designed webcore pistons were enough to slow it to a crawl, I had enough.

Enter HA; running in a HyperV VM with plenty of oomph. And once I discovered Node Red I was in love all over again and ready to put all my old webcore pistons to bed. As you pointed out, there’s fair amount of reading and studying that goes into this, but once things click into place, MAN that is rewarding! :wink:

okay finally got it to start as a service on a reboot

well the information of the x86-64 vs ARM did help out npm does not work very easy on x86-64 and the pkg as you stated does not work on ARM, that is what caused me the most issues so now I built two instructables to maybe help the next poor fool trying to load this up without docker