NSPManager
Bug Report: Failed to connect to MQTTManager
*Description NspanelManager is failing to establish a connection with MQTTManager. The console displays a recurring error message indicating that the connection attempt has failed and that the system is continuously retrying to connect.
*Steps to Reproduce
Start NspanelManager Observe the console output
*Expected Behavior NspanelManager should successfully connect to MQTTManager without any error messages.
*Actual Behavior The console repeatedly displays the following error message: CopyFailed to connect to MQTTManager. Retrying... This message appears to loop, indicating that the connection attempts are consistently failing.
*Logs I get this issue on docker logs
*** Operational MODE: preforking ***
Did not find a running MQTTManager, starting MQTTManager...
/MQTTManager/build/nspm_mqttmanager: error while loading shared libraries: /MQTTManager/build/libMQTTManager_WebHelper.so: unexpected reloc type 0x03
*Environment OS: Hassio + Supervisor + nspanelmanager (1.0.1)
Environment info (please complete the following information):
- Home Assistant
- NSPanelManager version [Web UI lower left corner]
Hm, strange. What hardware are you running on? Specifically processor architecture.
hello, i'm on a raspberry 4 : "Raspbian GNU/Linux 10 (buster)" Many thanks
~ $ cat /sys/firmware/devicetree/base/model
Raspberry Pi 4 Model B Rev 1.4
~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
Hm, could you verify what arch of the container hass downloaded? To to the system cli and run docker ps
hello,
here is
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c91fdfed400f nspanelmanager/nspanelmanager-armv7:1.0.1 "/bin/bash ./run_uws…" 12 hours ago Up 12 hours 0.0.0.0:8000->8000/tcp, :::8000->8000/tcp addon_a5d2b728_nspanelmanager
Could you send over the total output of dpkg-architecture? It should look something like the following:
DEB_BUILD_ARCH=arm64
DEB_BUILD_ARCH_ABI=base
DEB_BUILD_ARCH_BITS=64
DEB_BUILD_ARCH_CPU=arm64
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_ARCH_LIBC=gnu
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_GNU_CPU=aarch64
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=aarch64-linux-gnu
DEB_BUILD_MULTIARCH=aarch64-linux-gnu
DEB_HOST_ARCH=arm64
DEB_HOST_ARCH_ABI=base
DEB_HOST_ARCH_BITS=64
DEB_HOST_ARCH_CPU=arm64
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_ARCH_LIBC=gnu
DEB_HOST_ARCH_OS=linux
DEB_HOST_GNU_CPU=aarch64
DEB_HOST_GNU_SYSTEM=linux-gnu
DEB_HOST_GNU_TYPE=aarch64-linux-gnu
DEB_HOST_MULTIARCH=aarch64-linux-gnu
DEB_TARGET_ARCH=arm64
DEB_TARGET_ARCH_ABI=base
DEB_TARGET_ARCH_BITS=64
DEB_TARGET_ARCH_CPU=arm64
DEB_TARGET_ARCH_ENDIAN=little
DEB_TARGET_ARCH_LIBC=gnu
DEB_TARGET_ARCH_OS=linux
DEB_TARGET_GNU_CPU=aarch64
DEB_TARGET_GNU_SYSTEM=linux-gnu
DEB_TARGET_GNU_TYPE=aarch64-linux-gnu
DEB_TARGET_MULTIARCH=aarch64-linux-gnu
The full output of the command uname -a would also be helpful.
Me and @cablesandcoffee have done some testing and he is running a Raspberry PI 4 as well and it works for him without issues. Though, he is using a newer version of raspbian. We had issues when older versions of raspbian which we couldn't figure out beacuse the older versions of raspbian pretends to be 64 bit but they are actually 32 bit and this causes problems with unknown arm instructions when trying to run code build for 64-bit architectures.
Sorry for my late answer, I was not at home here is the command return
`pi@raspberrypi:~ $ dpkg-architecture DEB_BUILD_ARCH=armhf DEB_BUILD_ARCH_ABI=eabihf DEB_BUILD_ARCH_BITS=32 DEB_BUILD_ARCH_CPU=arm DEB_BUILD_ARCH_ENDIAN=little DEB_BUILD_ARCH_LIBC=gnu DEB_BUILD_ARCH_OS=linux DEB_BUILD_GNU_CPU=arm DEB_BUILD_GNU_SYSTEM=linux-gnueabihf DEB_BUILD_GNU_TYPE=arm-linux-gnueabihf DEB_BUILD_MULTIARCH=arm-linux-gnueabihf DEB_HOST_ARCH=armhf DEB_HOST_ARCH_ABI=eabihf DEB_HOST_ARCH_BITS=32 DEB_HOST_ARCH_CPU=arm DEB_HOST_ARCH_ENDIAN=little DEB_HOST_ARCH_LIBC=gnu DEB_HOST_ARCH_OS=linux DEB_HOST_GNU_CPU=arm DEB_HOST_GNU_SYSTEM=linux-gnueabihf DEB_HOST_GNU_TYPE=arm-linux-gnueabihf DEB_HOST_MULTIARCH=arm-linux-gnueabihf DEB_TARGET_ARCH=armhf DEB_TARGET_ARCH_ABI=eabihf DEB_TARGET_ARCH_BITS=32 DEB_TARGET_ARCH_CPU=arm DEB_TARGET_ARCH_ENDIAN=little DEB_TARGET_ARCH_LIBC=gnu DEB_TARGET_ARCH_OS=linux DEB_TARGET_GNU_CPU=arm DEB_TARGET_GNU_SYSTEM=linux-gnueabihf DEB_TARGET_GNU_TYPE=arm-linux-gnueabihf DEB_TARGET_MULTIARCH=arm-linux-gnueabihf pi@raspberrypi:~ $ uname -a Linux raspberrypi 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux
` Thanks for the feedback, i will try to upgrade
Thanks. Unfortunately it looks like you've ran into the same issue which we couldn't really work around last time. This is not an issue in newer raspbian versions.
We might be able to solve this by statically building the binary but I'm not sure. Anyway I've begun work to have that be the default when issuing a release.
Curious, I am facing the same prolem
pi@living:~ $ uname -a
Linux living 6.1.21-v7+ #1642 SMP Mon Apr 3 17:20:52 BST 2023 armv7l GNU/Linux
same problem here for me, would love to help in resolving this issue :-)
uname -a Linux starknet 6.6.51+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08) aarch64 GNU/Linux
Thanks. Unfortunately it looks like you've ran into the same issue which we couldn't really work around last time. This is not an issue in newer raspbian versions.
We might be able to solve this by statically building the binary but I'm not sure. Anyway I've begun work to have that be the default when issuing a release.
I am running the latest Raspbian (12) version and this still happens....
This should be fixed as of latest beta as that is statically linked and not dynamically.