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: -
After editing the flow, restart the service with:
Cause 2: The npm
package manager has been updated without the use of opkg
.
Check the eManager npm version with
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 |
24.04 | 3.0 | 10.2.4 |
Solution 2: Reinstall the expected version with
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:
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.
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:
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
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:
gyp ERR! stack Error: not found: make
Cause: Some Node-RED packages require the native compiler in the eManager, such as node-red-node-sqlite.
Solution: Install native compiler package:
Finally, restart the node-red service and try again to install the node in Node-RED:
TypeError accessing to a hardware module
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>
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:
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
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>
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:
And reinstall the package using:
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.
Solution: You can manage your Internet connection preferences through Webadmin as explained here.
Opkg database is corrupted
Cause: Some package in the opkg database has experimented a problem during its installation. That makes no longer possible the installation and uninstallation of other packages in your eManager.
Solution: It is necessary to verify if you opkg database is corrupted. To do so:
- Check for duplicated entries:
$ grep "Package: " /usr/lib/opkg/status | sort | wc
$ grep "Package: " /usr/lib/opkg/status | sort -u | wc
- Check that all packages
p
for which a file/usr/lib/opkg/info/$p.list
exists is listed in/usr/lib/opkg/status
:
for i in /usr/lib/opkg/info/*.list; do
p=$(echo $i | sed -e 's,.*/,,' -e 's,\..*,,')
grep "Package: $p" /usr/lib/opkg/status > /dev/null || echo opkg install $p
done
If no output is displayed, your opkg database is working properly.
If one of the above tests indicates that your opkg database is corrupted:
-
Remove from
/var/lib/opkg/status
the package entry that causes the error. The package entries follow this structure:2. Install the package that causes the error. In this case, execute:Package: python3-stringold Version: 3.8.11-r0.0 Depends: python3-core Status: install ok installed Architecture: cortexa7t2hf-neon Installed-Size: 31329 Installed-Time: 1666597826 Auto-Installed: yes
opkg install python3-asn1crypto --force-reinstall
.
Modem disconnects from peer without any apparent cause
You will identify this situation by checking the ppp logs. The following log appears:
Tip
To check the logs use journalctl -f -u ppp@provider -n 100
.
Cause: The available channel bandwidth (depending on coverage, environmental conditions, etc.) is very thin, leaving little space for the control messages of the ppp protocol itself.
Solution: Increase the following parameters in /etc/ppp/options-mobile
file:
-
lcp-echo-interval
: pppd will send an LCP echo-request frame to the peer every n seconds. Normally the peer should respond to the echo-request by sending an echo-reply. This option can be used with the lcp-echo-failure option to detect that the peer is no longer connected. Allowed range: 1 to 255 seconds. The default value is 5 seconds. -
lcp-echo-failure
: pppd will presume the peer to be dead if n LCP echo-requests are sent without receiving a valid LCP echo-reply.
We recommend to increase lcp-echo-interval
from 10
to 30
, and lcp-echo-failure
from 3
to 5
.
For more information regarding pppd
, please check here.