Troubleshooting

opkg commands fail

It could be one of the following causes:

Cause 1: The eManager is not connected to the Internet.

Solution 1: Connect the eManager to a Router/WiFi through a Ethernet cable.

Cause 2: eManager has weak Internet connection.

Solution 2: We recommend upgrading the eManager packages using the perform-opkg-upgrade tool.

Node-RED gets stucked

Node-RED is unreachable or the service is restarting all the time.

Cause 1: it is possible that the flow contains some troublesome node that makes Node-RED to get stucked.

Solution 1: use the console to edit active Node-RED flows.

Edit the flows.json file.

Node-RED active flows are stored as a .json file in /var/lib/node-red/flows.json. You can edit it with:
```
nano /var/lib/node-red/flows.json
```
After editing the flow, restart the service with:
```
systemctl restart node-red
```

Cause 2: The npm package manager has been updated without the use of opkg.

Check the eManager npm version with

npm --version

Depending on the eManager image release the expected npm version is

Image release	Distro	npm version
21.02	1.1	6.13.4
21.08	1.2	6.13.4
22.01	2.0	6.14.15
22.10	2.1	6.14.15

Solution 2: Reinstall the expected version with

opkg install nodejs-npm --force-reinstall

I cannot access to the NodeRED application

It could be one of the following causes:

Cause 1: Wrong configuration in the Node-RED flow, which causes the Node-RED to crash.

Solution: Execute the following command in order to check the logs for the error causing the crash:

journalctl -f -u node-red -n100

Cause 2: Node-RED watchdog timeout is too low. It could happen if many components have been installed on the Node-RED palette, causing it to take a long time to load, until the Node-RED watchdog ends up restarting the service.

troubleshooting_q1

Solution 2: Execute the following steps in order to change the time of actuation of the watchdog:

Access the file /lib/systemd/system/node-red.service.
Modify the parameter WatchdogSec with the desired time of actuation of the watchdog.
Execute the following commands to reload the systemd daemon and restart the Node-RED service:
```
systemctl daemon-reload
systemctl restart node-red
```

For further information about the watchdog, please check here.

Cause 3: There is some process that monopolizes the CPU.

Solution 3: Review the processes that are running using the top command in the shell.

Sometimes Node-RED restarts for no reason

troubleshooting_q2

Cause: Node-RED stucked due to incorrect configuration or programming in the Node-RED flow.

Solution: Execute the following command in order to know what is actually causing this:

journalctl -f -u node-red -n100

npm WARN: npm does not support Node.js v8.17.0

troubleshooting_q3

Cause: npm has been updated to a new version, and it no longer supports the node.js version of the system.

Solution: Reinstall original version of npm:

opkg install nodejs-npm --force-reinstall

gyp ERR! stack Error: not found: make

troubleshooting_q4

Cause: Some Node-RED packages require the native compiler in the eManager, such as node-red-node-sqlite.

Solution: Install native compiler package:

opkg install packagegroup-core-buildessential

Finally, restart the node-red service and try again to install the node in Node-RED:

systemctl restart node-red

TypeError accessing to a hardware module

troubleshooting_q5

Common error messages are:

Error getting analog input...
Error getting digital input...
Error activating relays...

Cause: More than one hardware module request message ocurred at a time, and therefore a collision has occurred.

Collisions can occur when at the same time, on the one hand, a request is made to a hardware module, while another module generates an event from an input.

Solution: If possible, decrease the frequency of polling requests, to minimize collisions.

Missing node modules: `<node-red-node-name>` `<version>`

Troubleshooting_q6

Cause: Node-RED community has published a new version of a package that is no longer compatible with Node-RED version that eManager incorporates. In this example, <node-red-node-name> corresponds to <node-red-node-dashboard> and the <version> in the title corresponds to 3.1.3.

When you try to update the version of one of the Node-RED nodes in the list below and the version is higher than the one supported, the error message shown in the capture is displayed.

Solution: Reinstall the previous version. To do so you need to execute the following commands:

cd /var/lib/node-red
npm install <node-red-node-name>@<version>
systemctl restart node-red

In this example, to reinstall the previous version <node_red_node_name> is node-red-node-dashboard and the <version> is 2.30.0.

List of last versions compatible with Node-RED 0.20.8

node-red-dashboard@2.30.0
node-red-node-serialport@0.14.1

npm ERR! code EAI_AGAIN

Troubleshooting_q7

Cause: There are some new version the Node-RED community has published for some nodes that are not compatible with the Node-RED version the eManager incorporates. When you try to install some package with a higher version that the one supported, this error occurs.

Solution: Manually, install the packet with the last version compatible with the Node-RED version the eManager incorporates. To do so you can follow the instructions detailed here.

If you want to know the last versions compatible with Node-RED 0.20.8, please check here.

Nothing provides requested `<package_name>`

Troubleshooting_q8

Cause: If you try to install a specific package and the Internet connection is broken during this process, it could happen that some parts of the package are already installed while others are not. In this case, an error similar to the one shown in the image may appear.

Solution: Clean the files cache using:

opkg clean

And reinstall the package using:

opkg install <package_name> --force-reinstall

In this example <package_name> is python-pkgutil.

Lack of Internet connection when Wi-Fi is working

Cause: The eManager can be connected to Internet via an Ethernet cable and via Wi-Fi. By default, it prioritizes Ethernet, that is, auto-generated Internet routes through the Ethernet interface will take preference over those through the Wi-Fi interface.

This network configuration may lead to a loss of Internet connection if the Ethernet connection temporarily fails to reach the Internet, even when Wi-Fi maintains a stable connection. This is because eManager does not set IP routes dynamically by default.

Solution (new in image release 22.10): NetworkManager has a built-in option for this use case: the connectivity check functionality.

Note

This solution is only valid if the modem is not used as a medium to connect to the Internet. If you need the data to be sent by modem, you must configure the minor metric for that interface, as specified here.

Create a file

nano /usr/lib/NetworkManager/conf.d/20-connectivity.conf

with content

[connectivity]
uri=http://nmcheck.gnome.org/check_network_status.txt

and restart the service

systemctl restart NetworkManager