{"_id":"@baroldgene/node-red-contrib-victron","_rev":"2-8fcc44b301c56b9485d31a7c4cacec9a","name":"@baroldgene/node-red-contrib-victron","dist-tags":{"latest":"1.5.17"},"versions":{"1.5.16":{"name":"@baroldgene/node-red-contrib-victron","description":"Custom Node-RED Nodes for Victron Energy","version":"1.5.16","dependencies":{"dbus-native":"^0.4.0","debug":"^4.3.4","lodash":"^4.17.21","promise-retry":"^2.0.1","standard":"^17.1.0"},"node-red":{"nodes":{"victron-client":"./src/nodes/config-client.js","victron-nodes":"./src/nodes/victron-nodes.js"},"version":">=3.0.2"},"devDependencies":{"@babel/eslint-parser":"^7.23.10","csv-parse":"^5.5.5","eslint":"^8.57.0","eslint-config-google":"^0.14.0","gar":"^1.0.4"},"keywords":["node-red"],"scripts":{"test":"standard --fix src/ scripts/","codespell":"codespell src/ scripts/","release":"git tag -d v$npm_package_version; git tag v$npm_package_version && git push --tags && git push && npm run create-release"},"repository":{"type":"git","url":"git+https://github.com/baroldgene/node-red-contrib-victron.git"},"engines":{"node":">=14.17.4"},"license":"MIT","_id":"@baroldgene/node-red-contrib-victron@1.5.16","gitHead":"ec216c758769cece51835e0261d11dbf59f7f0ed","bugs":{"url":"https://github.com/baroldgene/node-red-contrib-victron/issues"},"homepage":"https://github.com/baroldgene/node-red-contrib-victron#readme","_nodeVersion":"20.5.1","_npmVersion":"9.8.0","dist":{"integrity":"sha512-oTWkMLaPE95olnXq1LoE79hYlX5WXBNZjvaj/Slz5ZgVQ5V5fAVBvRwnvx+Y52/x81R/YPPLFeKQaNjz3G927g==","shasum":"367c6699ebe87b92163c7678c68b418e48d62c38","tarball":"https://registry.npmjs.org/@baroldgene/node-red-contrib-victron/-/node-red-contrib-victron-1.5.16.tgz","fileCount":65,"unpackedSize":1799109,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCH2RxSrIuULg5OIWkNV7VRQiN3hWR9H44Qyy/EG5CcBgCIQCCj1DmFVvt2ZKbiWvR4fgHc9fME5ACp0+h536sGY4BDQ=="}]},"_npmUser":{"name":"baroldgene","email":"brinkley.17@gmail.com"},"directories":{},"maintainers":[{"name":"baroldgene","email":"brinkley.17@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/node-red-contrib-victron_1.5.16_1712338098799_0.11766149485435418"},"_hasShrinkwrap":false,"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info."},"1.5.17":{"name":"@baroldgene/node-red-contrib-victron","description":"A fork of the Victron nodes to test a bug fix.","version":"1.5.17","dependencies":{"dbus-native":"^0.4.0","debug":"^4.3.4","lodash":"^4.17.21","promise-retry":"^2.0.1","standard":"^17.1.0"},"node-red":{"nodes":{"victron-client":"./src/nodes/config-client.js","victron-nodes":"./src/nodes/victron-nodes.js"},"version":">=3.0.2"},"devDependencies":{"@babel/eslint-parser":"^7.23.10","csv-parse":"^5.5.5","eslint":"^8.57.0","eslint-config-google":"^0.14.0","gar":"^1.0.4"},"keywords":["node-red"],"scripts":{"test":"standard --fix src/ scripts/","codespell":"codespell src/ scripts/","release":"git tag -d v$npm_package_version; git tag v$npm_package_version && git push --tags && git push && npm run create-release"},"repository":{"type":"git","url":"git+https://github.com/baroldgene/node-red-contrib-victron.git"},"engines":{"node":">=14.17.4"},"license":"MIT","_id":"@baroldgene/node-red-contrib-victron@1.5.17","gitHead":"a9e8d918ea810edbd89d1a63ab2a763e5418ba6c","bugs":{"url":"https://github.com/baroldgene/node-red-contrib-victron/issues"},"homepage":"https://github.com/baroldgene/node-red-contrib-victron#readme","_nodeVersion":"20.5.1","_npmVersion":"9.8.0","dist":{"integrity":"sha512-iKTahxJUEraPjYv+laP+GONOhZzzEYN/1owGSAokQUu0o8s6AcsfsixkCtlHLxephAv5UocF6MckPULjiwMD0w==","shasum":"e09f99e3b7e2708af57d9bfd70827132abe06cb7","tarball":"https://registry.npmjs.org/@baroldgene/node-red-contrib-victron/-/node-red-contrib-victron-1.5.17.tgz","fileCount":65,"unpackedSize":1799256,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIEzxOcLv/Xj3WvQeJSLy99x1p7CCWBUJIBm4fVULdq0iAiBNqUqIEaaU0AfBeXd1gQVwQYShxWoCVjhwY7H4crsCNA=="}]},"_npmUser":{"name":"baroldgene","email":"brinkley.17@gmail.com"},"directories":{},"maintainers":[{"name":"baroldgene","email":"brinkley.17@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/node-red-contrib-victron_1.5.17_1712341848873_0.4781173740142961"},"_hasShrinkwrap":false,"deprecated":"Package no longer supported. Contact Support at https://www.npmjs.com/support for more info."}},"time":{"created":"2024-04-05T17:28:18.699Z","1.5.16":"2024-04-05T17:28:19.038Z","modified":"2024-04-05T19:13:56.008Z","1.5.17":"2024-04-05T18:30:49.138Z"},"maintainers":[{"name":"baroldgene","email":"brinkley.17@gmail.com"}],"description":"A fork of the Victron nodes to test a bug fix.","homepage":"https://github.com/baroldgene/node-red-contrib-victron#readme","keywords":["node-red"],"repository":{"type":"git","url":"git+https://github.com/baroldgene/node-red-contrib-victron.git"},"bugs":{"url":"https://github.com/baroldgene/node-red-contrib-victron/issues"},"license":"MIT","readme":"# Custom Victron Energy nodes for Node-RED\n\nThis library provides custom Node-RED nodes for some of the most commonly used Victron Energy products. The aim is to make it easier and faster for users to create automations for and around a Victron system, without actually having to touch any of the devices' internals.\n\nThis library is usually used as part of [Venus OS Large](https://www.victronenergy.com/live/venus-os:large) where it comes preinstalled, together with Node-RED itself.\n\nIt is also possible to use this library when running Node-RED on a separate host.\n\nThis library is not officially supported by Victron Energy: don't call our dealers or other support channels for help.\n\nFor any questions or help, please turn to [community.victronenergy.com](https://community.victronenergy.com). Pull-requests are willingly encouraged!\n\n## Requirements when self-installing this node palette\n- A Victron system that includes a GX device (note that for trial & development you could use the demo mode in Venus OS, Settings -> General)\n- D-Bus configuration on Venus OS to be modified to bind to TCP\n\nMore details in the [instructions](#Installation-and-Usage).\n\n## Usage and examples\n\nWhen Node-RED is started, a Victron Energy configuration node is automatically created, connecting to the dbus in the GX device. All the node services and measurements can be found on [services.json](/src/services/services.json) and on the [wiki](https://github.com/victronenergy/node-red-contrib-victron/wiki/Available-nodes) -- however only those services and measurements that are available in the system are shown in the node edit panel.\n\n![Architecture](documentation/images/node-palette.png)\n\n*Node-palette - Input nodes on the top, output nodes below,*\n\nHere's an example on a functional flow with the Victron Nodes. More in-depth examples and use cases can be found in [wiki/Example-Flows](https://github.com/victronenergy/node-red-contrib-victron/wiki/Example-Flows).\n\n![Architecture](documentation/images/example-nighttime-rates.png)\n\n### Input Nodes\n\nThe input nodes have two selectable inputs: the devices select and measurement select. The available options are dynamically updated based on what sort data is actually available on the Venus device dbus.\n\n```\nDevice Select       - lists all available devices\nMeasurement Select  - lists all available device-specific measurements\nNode label Input    - sets a custom label for the node\n```\n\nThe measurement unit type is shown in the measurement label in brackets, e.g. Battery voltage (V).\nIn case the data type is enumerated, an approppriate enum legend is shown below the selected option.\n\n![Architecture](documentation/images/edit-vebus-input.png)\n\nIf in the configuration node, the _Context store_ checkbox has been set, the received values will also\nbe stored in the (global) context.\n\n\n\n### Output Nodes\n\nInput Nodes have the same options available, but the selectable 'measurement' only lists writable services. Additionally, the user can set an initial value to the service, which is sent whenever the flow is deployed.\n\nAll output nodes should have the control value set in its incoming message's `msg.payload` property.\n\n```\nDevice Select       - lists all available devices\nMeasurement Select  - lists all available device-specific measurements\nInitial value Input - initializes the device when the flow is deployed\nNode label Input    - sets a custom label for the node\n```\n\n### Custom Nodes\n\nThere are 2 custom nodes. An input and an output node. The input node allow to read from and the output node allows to  write to all found dbus services and paths. This obviously comes with a risk, as not all services and paths are supposed to be written to. So only use the custom output node if you have read the documentation and know what you are doing. Also note that used services and paths might change, so there is no guarantee\nthat a node will remain functional after a Venus firmware update.\n\n![Architecture](documentation/images/edit-relay-output.png)\n\n### Example Flows\n\nPlease head to [wiki/Example-Flows](https://github.com/victronenergy/node-red-contrib-victron/wiki/Example-Flows) for example flows implemented with the Victron Energy nodes.\n\n## Architecture\n\n### Plugin Behavior\n\nAll the individual nodes (inputs / outputs) will use a singleton instance of a Victron Config Node to access the system dbus in a Venus device. The nodes will provide an easy-to-use interface for accessing various measurements and writing data to the system.\n\nThe following graph demonstrates the architecture of this plugin.\n\n1. Upon initialization, the Victron Config Node initializes a VictronClient and SystemConfiguration instances. VictronClient connects to the Venus D-Bus and starts maintaining a cache of available services.\n\n2. When a user modifies a node (e.g. battery node), the node fetches the available dbus services from the local SystemConfiguration cache and renders relevant inputs to the edit view.\n\n3. When a node is deployed, they either subscribe a message handler to the VictronClient or start publishing data to a desired D-Bus path.\n\n\n![Architecture](documentation/images/architecture.png)\n\n### Directory Structure\n```\n.\n├── documentation\n├── scripts\n│   ├── csv                         | input CSV files for the parser script\n│   ├── parse-services.js           | parses the services.json used by nodes\n│   └── service-whitelist.js        | dbus service/path whitelist for the parser\n└── src\n    ├── nodes\n    │   ├── icons\n    │   │   └── victronenergy.svg\n    │   ├── config-client.html\n    │   ├── config-client.js\n    │   ├── victron-nodes.html\n    │   └── victron-nodes.js\n    └── services\n        ├── services.json           | used for node config generation\n        ├── utils.js\n        ├── dbus-listener.js\n        ├── victron-client.js       | Victron Energy dbus-client\n        └── victron-system.js       | DBus service cache\n```\n\n## Installation and Usage\n\nNOTE: these instructions are about how to install and make this node pallette working on your own Node-RED installation. Make sure that is what you want and need. The more common solution is to [use Node-RED already pre-installed inside Venus OS](https://www.victronenergy.com/live/venus-os:large).\n\nWARNINGS: (A) Only do this on a trusted network. Exposing D-Bus to TCP is not secured - anyone on the same network can do\nanything he/she wants after enabling this setting. (B) If you do below change incorrectly, the GX Device will no longer\nboot correctly and will also not enable SSH nor Remote Console anymore. Also the GUI won't work; nor will anything else.\nBasically its rendered unusable, until either debugged via the serial console using a\n[serial console cable](https://www.adafruit.com/product/954); or reinstalled using an factory installation image on an\nsdcard. Note that after factory installation, certain files must be put back in order for, for example, the wifi to\nwork again. There is no complete documentation about how to restore those, but the information on older revisions of this page will at least help:\n[Venus OS Extended manual - Repart. appendix](https://www.victronenergy.com/live/venus-os:extended#appendix_a_-_repartitioning_venus_gx_flash_memory).\n(C) below modifications are on ones own risk. We'll help where possible; but there are only a few\npeople available within Victron that can help; and they won't be standby all the time to help with issues like this:\nonly do this when you (I) are not in a rush when it goes wrong and (II) are technical and know what you are doing. To\nget help, you could try the issues, as well as the\n[Modifications section on Community](https://community.victronenergy.com/spaces/31/index.html). (D) Remember that a \nfirmware update of the GX device will override below advised (and any other) changes to the rootfs.\n\nTo make above this change, you'll need [root access to the GX device](https://www.victronenergy.com/live/ccgx:root_access).\n\nWith all those (important!) warnings out of the way, here are the steps to locally install Node-REDand this\nplug-in. As well as the step to Open up the GX device, so that it can be communicated with remotely by this\nnode-red plugin:\n\n1. install node-red on your system\n2. cd to the node-red user directory, typically `~/.node-red`\n3. install node-red-contrib-victron locally, `npm install @victronenergy/node-red-contrib-victron`\n4. enable d-bus over tcp in your Venus device **if you want to use dbus over TCP**, otherwise skip this step.\n\nSet the dbus service `com.victronenergy.settings`, path: `/Settings/Services/InsecureDbusOverTcp` to\n`1`:\n`dbus -y com.victronenergy.settings /Settings/Services/InsecureDbusOverTcp SetValue 1` and reboot\nthe Cerbo (the dbus needs to be restarted)\n\nThe old way was to edit `/etc/dbus-1/system.conf` and add the following directly above `<policy context=\"default\">`:\n\n```\n  <listen>tcp:host=0.0.0.0,port=78</listen>\n  <auth>ANONYMOUS</auth>\n  <allow_anonymous/>\n```\n\n5. the client can connect to dbus either using tcp or directly via system socket.\n  - the client defaults to a socket connection systembus, with a socket 'unix:path=/var/run/dbus/system_bus_socket'. This should directly work with a Venus device.\n  - (You can  `DBUS_SYSTEM_BUS_ADDRESS` to change the systembus socket path or alternatively set `DBUS_SESSION_BUS_ADDRESS` to use sessionbus via socket)\n  - set the environment variable `NODE_RED_DBUS_ADDRESS` to connect via TCP. The variable should be a string with an ip and port separated by a colon, e.g. `export NODE_RED_DBUS_ADDRESS=192.168.1.1:78`\n\n6. you can optionally run the plugin with a DEBUG=* environment variable set, to see additional debug information printed on the shell. E.g. `export DEBUG=node-red-contrib-victron*`\n\n## Generating the node specification file (developers)\n\nAll the nodes use a manually generated [services.json](/src/services/services.json) file to figure out what dbus services and paths to expose to the end-user. This file is used to e.g. render the labels to the 'Select measurement' dropdowns in node-RED's edit view. Please note, that this file is not a full representation of all available dbus paths -- rather, a subset of services and paths that the node-red nodes actually use.\n\nThis `services.json` file is generated using the `parse-services.js` script in `./scripts` directory. The script uses two CSV files, `dataAttributes.csv` and `dataAttributeEnums.csv`, as its primary source to generate an up-to-date listing of available dbus services and dbus paths for Victron Energy's devices.\n\n(Unfortunately, the CSV files are not committed to the repo for now -- if you need to update the services.json, please ask for the CSVs from Victron Staff or run the parse-services script with the `--append` switch).\n\nThe parsed services and paths are filtered against a whitelist (`service-whitelist.js`) before saving the file in order to get rid of undesired or deprecated dbus paths and only reveal the paths actually relevant to the VE nodes.\n\n![Parser Script Architecture](documentation/images/parser-script-architecture.png)\n\n1. Before running the script, please ensure that you have valid data csv's (`dataAttributes.csv`, `dataAttributeEnums.csv`) in the `./scrip/csv` directory. Edit the `service-whitelist.js` to control all the available fields to the nodes. (Alternatively use `--append`, see below)\n2. Run the script `node run parse-services.js`\n3. If some of the whitelisted services or paths are not found on the CSV files, the script will print out all the missing dbus paths. The script will also generate a `missingpaths.template.json` file, which can be manually populated and added as an extra input to the script.\n4. Copy, rename and populate the `missingpaths.template.json` and run the script again, this time with an extra argument: `node parse-services.js ./missingpaths.json`. This extra input file can also be used to overwrite parsed CSV rows, for example.\n5. You are done! The new fields in `services.json` can be verified using a your favorite diff tool (`git diff`, for example).\n\n## Adding new nodes (developers)\n\nA few modifications to the code are needed in order to add new nodes (or new paths to existing ones). Here's an example on how to add a new input node `victron-test`. It uses the dbus service `com.victronenergy.settings` and has one option for a path `/Settings/TestDbusPath`.\n\n1. Add the nodetype to scripts/service-whitelist.js\n```\n    \"input-test\": {\n        \"settings\": [\n            \"/Settings/TestDbusPath\",\n        ]\n    }\n```\n\n2. Run `node parse-services.js ./missingpaths.json` to generate a new `services.json`, which is used to render the node options. If some of the whitelisted path definitions are missing from the given input CSV's (or missingpaths.json), a missingpaths.template.json is generated with pre-filled objects for the path definitions. You should fill in the missing data, and copy-paste the new json objects to missingpaths.json file. Run the script again until no more missing paths are printed to the console.\n\nYou can use the `--append` switch to completely bypass the whitelist, missingpaths.json and csv parsing. This is useful if you don't have access to the CSV files. This will simply merge the given input json file with the existing services.json: `node parse-services.json ./additionalPaths.json --append`.\n\n3. Add the following rows to given files:  \n```\n// The following function defines what services are shown in\n// /victron/services/ API endpoint.\n// src/services/victron-system.js - listAvailableServices()\n\"input-test\": this.getNodeServices(\"input-test\"),\n\n// Creates a new node-definition for node-red backend API\n// src/nodes/victron-nodes.js\nRED.nodes.registerType('victron-input-test', BaseInputNode);\n\n// Creates a new node-definition for node-red frontend API\n// src/nodes/victron-nodes.html\nregisterInputNode('victron-input-test', 'Test', 'input-test');\n```\n\n4. Make sure to update the documentation. The script for this is in the `scripts/` directory and called `service2doc.js`. It adds the generated context after the first html comment match in the file and uses `sponge` (part of moreutils) not to overwrite the original contents:  \n```\n( sed '/^<!--/q' ../src/nodes/config-client.html && node service2doc.js -s ../src/services/services.json -r ../src/nodes/victron-nodes.html -t nodered ) | sponge ../src/nodes/config-client.html\n```\n\nBesides that it is also important to update the wiki:\n\n```\nnode scripts/service2doc.js -s src/services/services.json -r src/nodes/victron-nodes.html -t md >\\\n  ~/git/node-red-contrib-victron.wiki/Available-nodes.md\n```\n\nAssuming you have the wiki cloned as well in `~/git/` directory. Review and commit those changes too.\n\n5. Restart Node-RED and test the new node. It should be visible under Victron Energy nodes. If the path `/Settings/TestDbusPath` is present in dbus under `com.victronenergy.settings`, the node will show the path as an option in its edit panel settings (otherwise it will be hidden and you will probably see a disclaimer text on missing services). Make sure also to check the documentation.\n\n\n## Releasing a new version (developers)\n\n### 1. Updating dependencies\n\nRegularly, you'll need to check if its time to update dependencies. A crude way is\nto remove all version locking files, and also remove the node_modules folder\nitselves as npm install will not touch any already installed dependencies, and then\nrun npm install. In other words, do this:\n```\nrm ./package-lock.json ./npm-shrinkwrap.json ./yarn.lock\nrm -rf ./node_modules\nnpm install --omit=dev\n```\n\nNow, all dependencies are installed as per latest version that is allowed by\n`package.json`. And also a new `package-lock.json` with all their version numbers\nand sha-sums is generated as well.\n\nSince `package-lock.json` is in git, commit it.\n\nNote that above only updates the depedencies as allowed per rules definied in `package.json`.\nTo really update them, ie. check for newer, possibly breaking versions, something else\nis needed. That can for example easily be checked with\n[npm-check-updates](https://www.npmjs.com/package/npm-check-updates). Here is\nan example output:\n```\n$ ncu\nChecking /home/matthijs/dev/node-red-contrib-victron/package.json\n[====================] 10/10 100%\n\n @babel/eslint-parser             ^7.17.0  →   ^7.21.3\n @signalk/github-create-release    ^1.2.0  →    ^1.2.1\n csv-parse                         ^4.4.6  →    ^5.3.6\n debug                             ^4.1.0  →    ^4.3.4\n eslint                           ^8.12.0  →   ^8.36.0\n eslint-config-google             ^0.11.0  →   ^0.14.0\n lodash                          ^4.17.11  →  ^4.17.21\n promise-retry                     ^1.1.1  →    ^2.0.1\n\nRun ncu -u to upgrade package.json\n```\n\n### 2. Testing\n\nNow, run a full test and make sure the package, including the now locked dependencies\nfunctions correctly.\n\n### 3. Releasing and publishing\n\n1. Run `npm version [major|minor|patch]`, this bumps the version in package.json, as well\n   as package-lock.json, and, if present, npm-shrinkwrap.json\n2. Run `npm run release`, this will create a Github Release (on Github!)\n3. Run `npm publish`, this will publishes the package to the npm registry\n\n### 4. Making a new npm-shrinkwrap.json\n\nFirst a bit of background:\n\nThe purpose of package-lock.json is mainly to make developers all work on the same\nsituation.\n\nnpm-shrinkwrap.json is exactly the same file, with same effect, but a different purpose:\nthe recommended use-case for npm-shrinkwrap.json is applications deployed through the\npublishing process on the registry: for example, daemons and command-line tools intended\nas global installs. More about that here:\nhttps://docs.npmjs.com/cli/v9/configuring-npm/npm-shrinkwrap-json\n\nIn Venus OS, we use npm-shrinkwrap.json as well, purpose there is to have 100% reproducible\nbuilds. The shrinkwrap file is kept in the meta repos, ie meta-victronenergy.\n\nNote that some repos/packages have a package-lock.json in their repo, and others do not.\nFor node-red-contrib-victron for example we do keep that. But Node-RED and signalk-server\ndon't have that, and they don't publish a npm-shrinkwrap.json to the NPM registry either.\nNeither do we for node-red-contrib-victron by the way.\n\nSo, with all that explained, here is how to make the shrinkwrap file:\n```\nnpm shrinkwrap\n```\n\nCareful, that must be done on a repo having a package-lock.json. Which for signalk-server\nand Node-RED means you need to run `npm install --only=prod` before you can make a\nmeaningful npm-shrinkwrap.json.\n\nCopy the resulting file into the meta-victronenergy repo.\n","readmeFilename":"README.md"}