Additional Software Packages
johannes-777 opened this issue · comments
Please add htop to chirpstack os.
Node-red! I would like to have a an extended version with node-red. The new version of node-red has login pages, that is basic websecurity, a modified UI module that can be used for simple kiosk-displays of sensor values with graphs etc, as well as the traditional drag and drop programming for smart logic and dataflows between sensors and actuators. Since node-red uses mqtt it is very easy to interface with and work with on the raspberry together with gateway-os.
It would require node.js, most likely a C-compiler as some node modules, like modbus, compiles.
I did this as an ugly hack almost a year ago and it does work well once the build system is configured correctly.
Oh, I think Multitech offers this on their gateways, but I can't find it as open source. https://nodered.org/users/multitech/
https://layers.openembedded.org/layerindex/recipe/126006/
- add meta-iot as layer
- add node-red to the image
- build
- figure out what config you want to change
Rather long rant, but I think node-red should not run on the gatewayos as I suggested earlier. Let's save it for RaspiOS.
--some trials and background to my change of mind--
I have tried to implement node-red on the latest versions ( the one available late summer/early autumn of 2020 ) and run into some problems that I could not solve, so I do not think it should be included in this distribution. I had it running with the versions that was available a year ago ( november 2019 ), but that version of gatewayos would not boot sometimes due to timingproblems with SD-cards ( this has been fixed in the later versions of gatewayos ).
It does work now, but Yocto/OpenembeddedLinux is not maintained in a really good way, and since Intel was one of the main driving force behind it and they have dropped our of the embedded world the maintenance and interest might drop even more.
Anyway the Node-red version in openembedded is not the latest release of Node-red from this summer. The summer release of node-red fixed a lot of small but very useful things. Like support for different user priviliges, improvements to the editor, etc. I could probably live without that, but for education use etc, the new version is definitely an improvement...
I also needed modbus-communication in node-red and relied on a package that implemented serial ports in Yocto/Openembedded. But these guys doing the serial-support in a rather unreleated openembedded package have removed support from their package as they do not need it anymore and the older packages are not compatible with the latest Openembedded stuff... Thus I could not set up serial port support from within node-red and run the modbus-packages.
After having spent about two weeks and having the GatewayOS up and running in the latest version, I simply had to drop it since I could not find support in some other needed packages to run what I needed in node-red. Openembedded/Yocto is also terrible to work with if you end up needing changing in the field. And you do...
I have now instead used RaspiOS and followed the setups for setting up the complete Chripstack with node-red, serial ports, Wireguard VPN, Monit etc. just like Gatewayos has and it works like a charm. RaspiOS also supports OverlayFS out of the box through Raspi-Config and thus there are no writes to the SD-cards anymore. It simply reverts once the power is removed and reapplied.
Thus my conclusion is that Node-red applications and the complete chirpstack is best run on RaspiOS. I use the Raspberry 3 with a lorawan concentrator board for this and with 1Gb of RAM, the RAM disk is about 40% full. The CPU is loaded to about 0-5%.
My setup might work on a Raspberry 0 today (0.5 gb of RAM), but I have not tested it, and when Raspberry decides to build a Raspberry 4 based Raspberry 0 W (1gb ram + wifi ) it will definitely be my choice for smart edge-gateways.
Thank's a lot for your experience. I went to RaspiOS too and use an RPI3 because it requires a lot less power than the RPI4. I too believe that this is the better way, even GatewayOS has NodeRed integrated now, but the problem you described (where you required a special NodeRed plugin) sounds very familiar.
I have 10 gateways running since 2019 and no problem with SD-wear out so far. I just reduced logging, except for the test gateways. I use Sandisk Extreme Pro. However, I might switch to OverlayFS. What keeps me from this is that I would hate losing all my logs at a crash or at power-down.
Just a note about logging - I insert a USB memory stick into the raspberry and I let node red write sensor data to that usb drive as a backup. If named correctly, the usb drive will be located at a fixed path among devices.
I think the system logs are still written to the RAM disk, but heavily rotated and compressed to limit their size. We usually have no need for these logs.
Another thing - Node red does not scale well after 4 sensors. 10 sensors, decoders etc. and we had always problems with reconfiguring it for new devices/gateways. You would always forget to change something. You could probably work around it, but the documentation was hard.
Moving to pure node.js with a full programming language it was a much easier task to handle 20 or more sensors.
We usually have no need for these logs.
We neither, normally our systems don't crash ;-)
Just some more experience on logging:
We once had logging to a dedicated drive too and for some reason believed, that this would make the system more stable. In our case, it was not: When the USB-Stick broke, the pipes for stdout filled up and the system halted. The advantage, however, was a quick system recovery: Just plug in a new USB Stick.
In general I found out, that logging was a significant cause of error: Too many times we had a process, that would not clean up logfiles and after a year or two the diskspace would be consumed, which has similar effects as a dying battery in a Renault: Instead of informing the user of the obvious, all kinds of brown-out effects are print to display like "engine control unit failure", "parking break broken", or "general error - immediately go to service center".
Concerning node red, we also moved on to a full programming language, python. However, we still use node red as the line graph visualization for our timeseries data. It was scheduled end of life 1 year ago and be succeeded by grafana, but our customers like the node-red visualization. And I have to say that it really runs smooth.
With the migration to OpenWrt, you can install additional packages.