[HowTo] USV: NUT Server auf SBC installieren

qqolli

Hallo,

ich hatte den Nut auf einem Raspi nach Deiner Anleitung installiert und das lief auch bis gerade eben super mit meiner APC USV. Nach einem Power off des Raspi und Restart bekomme ich nur noch diese Fehlermeldung:

nut.0	2020-12-02 13:19:43.873	error	(21087) Err while getting NUT values: DRIVER-NOT-CONNECTED
nut.0	2020-12-02 13:19:43.870	info	(21087) Start NUT update

Was könnte das sein, bzw. wie bekomme ich es wieder ans laufen?

Homoran

@qqolli sagte in [HowTo] USV: NUT Server auf SBC installieren:

Nach einem Power off

Stecker raus??

@qqolli sagte in [HowTo] USV: NUT Server auf SBC installieren:

Was könnte das sein

dann kann es von nicht gestartetem Prozess bis hin zu einem defekten Dateisystem alles sein

qqolli

@Homoran

Ja, das könnte wohl sein.

Was ich gemacht hatte war: Mit sudo poweroff den Produktiv-Raspi runtergefahren. Der Monteur setzt einen neuen Zähler und schaltet den Strom komplett ab. Die USV springt ein und der NUT-Serverraspi hängt ebenfalls an der USV. Strom wird wieder eingeschaltet und Produktiv-Raspi fährt wieder hoch. Danach kam die besagte Fehlermeldung.

Der NUT-Raspi scheint aber zu funktionieren, kann mich per SSH aufschalten.

Homoran

@qqolli sagte in [HowTo] USV: NUT Server auf SBC installieren:

der NUT-Serverraspi hängt ebenfalls an der USV.

der war also nicht komplett stromlos?

@qqolli sagte in [HowTo] USV: NUT Server auf SBC installieren:

Der NUT-Raspi scheint aber zu funktionieren, kann mich per SSH aufschalten.

dann mache mal einen reboot

qqolli

@Homoran

Ja, der NUT-Server war zu keinem Zeitpunkt stromlos, da an die USV angeschlossen und ich habe ihn auch schon neu gestartet.

Sollte ich vlt. den Produktiv-Raspi mit ioBroker drauf nochmal neu starten?

klassisch

@qqolli sagte in [HowTo] USV: NUT Server auf SBC installieren:

@Homoran

Ja, der NUT-Server war zu keinem Zeitpunkt stromlos, da an die USV angeschlossen und ich habe ihn auch schon neu gestartet.

Habe die Anleitung im Eingangspost upgedatet, weil @David-G bei seinem System Probleme mit der Rebootpersistenz hatte und @Thomas-Braun hilfreich zur Seite war. Bei neueren Systemen nutzt man hierfür systemd

Sollte ich vlt. den Produktiv-Raspi mit ioBroker drauf nochmal neu starten?

Eigentlich hast Du das schon gemacht. Was sagen denn die Adaptereinstellungen? Stimmen die noch oder haben die sich verändert?

Mein ioBroker Rechner (Laptop) hängt auch an der USV und läuft somit immer durch. So kann ich dann per FLOT hinterher sehen, was während der Blackoutzeit passiert ist. Sowas wäre jetzt hilfreich.
Du kannst aber jetzt den Adapter auf debug stellen. Dann sollte er im log etwas gesprächiger werden.

Dann hast Du jetzt auch eine Moderne Meßeinrichtung bekommen? Dann gleich PIN besorgen und smartmeter Adapter nutzen.

qqolli

@klassisch

anbei die aktuellen Adaptereinstellungen, mit denen es bisher funktionierte:

Die Debug-Ausgabe ist auch nicht besonders redefreudig:

nut.0	2020-12-02 15:32:33.127	debug	(26662) NUT Connection closed. Done.
nut.0	2020-12-02 15:32:33.125	error	(26662) Err while getting NUT values: DRIVER-NOT-CONNECTED
nut.0	2020-12-02 15:32:33.123	debug	(26662) NUT Connection ready
nut.0	2020-12-02 15:32:33.121	info	(26662) Start NUT update

Ja, habe heute den Ferraris-Zähler gegen eine mME getauscht bekommen, PIN habe ich bereits eingegeben.

Den smarten Adapter brauche ich nicht, da ich durch die PV-Anlage ein Smartmeter (Fronius) habe, das ich durch den Fronius-Adapter auch auslesen kann.

klassisch

@qqolli Die Adaptereinstellungen sehen aus wie meine.
Ich interpretiere das log so, daß zumindest mal die Verbindung zum NUT-Server aufgebaut wird.
Anscheinend scheint dort das Problem zu liegen. Vielleicht Findet er den USB Port Treiber nicht mehr?

qqolli

@klassisch

Witzigerweise findet er meine APC-USV über USB:

pi@NUT-Server:~ $ lsusb
Bus 001 Device 005: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 001 Device 004: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Broadcast message from nut@NUT-Server (somewhere) (Wed Dec  2 16:07:39 2020):

UPS ups@localhost is unavailable

Aber am Ende sagt er:

UPS ups@localhost is unavailable

obwohl die per USB-Kabel am NUT dran ist

Homoran

@qqolli sagte in [HowTo] USV: NUT Server auf SBC installieren:

die per USB-Kabel am NUT dran ist

hast du den USB-Port gewechselt?

qqolli

@Homoran

Nein, wirklich nichts geändert; außer wie oben beschrieben. USB-Port ist unverändert.

David G.

@qqolli

Hast du mal versucht einzustellen, dass der Dienst verzögert startet?

Habe gelesen, dass teilweise wenn der Dienst zu früh startet die USB Devices oder das Netzwerk noch nicht geladen sind.

Zu dem verzögerten Start steht auch was in der Anleitung.

qqolli

@Homoran @klassisch @David-G

Problem gelöst

sudo upsdrvctl start

Dann geht es wieder. Der wird nicht automatisch nach einem Reboot gestartet.

Thomas Braun

@David-G @qqolli
Deswegen ja auch die Zeile

ExecStartPre=/bin/sleep 30

beim Start über systemd. In den 30 Sekunden hat das System dann die Zeit die Interfaces hochzufahren. Könnte man auch anders machen, funktioniert aber.

Homoran

Hallo @klassisch und @all

Habe jetzt endlich meine zweite APC700 in finalen Betrieb genommen und den vorbereiteten Cubie als NUT-Server angeklemmt.

Leider bekomme ich beim Versuch diesen von ioBroker aus zu erreichen folgende Fehlermeldung:

nut.1	2020-12-04 19:10:09.370	error	(11393) Error happend: Error: getaddrinfo ENOTFOUND http://192.168.138.73 http://192.168.138.73:3493

nut.1 ist korrekt, ich habe für die zweite USV eine zweite Instanz angelegt.
Die IP und den Port habe ich jetzt x-mal geprüft.

User und Passwort sind die nach der Anleitung als ups-remote angelegt wurden (mit slave!?!?)

Lokal über putty bekomme ich mit sudo upsc ups@localhost eine brauchbare Ausgabe.

Ich bin jetzt mit meinem Latein am Ende und für jede Hilfe dankbar

EDIT:

habe noch einiges versucht, Schlussendlich war das Entfernen von http:// die Lösung.
Ich weiß gar nicht wo die herkam.

Homoran

Hallo @klassisch,

Ich könnte doch nochmal deine Hilfe gebrauchen. Vielleicht kann auch @Thomas-Braun die Frage beantworten.

Ich musste noch mehrmals den Cubietruck mit den nut Server herunterfahren und stelle soeben fest, dass seit dem ersten herunterfahren keine Daten mehr kamen.
Neustart der Instanz ergab ebenfalls ein connection refused, und ohne hier nochmal die letzten posts gelesen zu haben konnte ich such mit sudo upsdrvctl start das System wieder zum laufen bringen.

Im Eröffnungspost hast du die geänderte Autostart Anleitung beschrieben, danach noch die Alte, mit Hinweis, dass diese nicht zusätzlich existieren soll.
Aber genau das ist bei mir ja der Fall, da ich das System nach der alten Anleitung aufgebaut hatte.

Was mache ich damit, wenn ich auf die neu Version umsteigen will?

Thomas Braun

@Homoran
upsdrvctl start
ist das Verfahren über rc-Level? Und du willst das jetzt auf systemd umstellen?
(So tief hab ich mich damals ehrlich gesagt da gar nicht reingefräst...)

Homoran

@Thomas-Braun sagte in [HowTo] USV: NUT Server auf SBC installieren:

Und du willst das jetzt auf systemd umstellen?

Ja, weil das System nach Shutdown nicht von alleine hochfährt

Thomas Braun

@Homoran
Da sollte es dann irgendwo in /etc/rc.local einen Eintrag für upsdrvctl oder so ähnlich geben. Nimm die da mal weg. Dann wird die nicht beim Start ausgeführt. Und dann nach der Anleitung die targets nach systemd anlegen. Das hatten wir ja dann so ausgeknobelt.

Oder es gibt was in /etc/init.d
Keine Ahnung wie das angelegt wurde für den Dienst.

Homoran

@Thomas-Braun sagte in [HowTo] USV: NUT Server auf SBC installieren:

es dann irgendwo in /etc/rc.local einen Eintrag für upsdrvctl oder so ähnlich geben

Das sieht bei mir im Moment (ohne Kommentarzeilen) so aus:

# By default this script does nothing.

#additions  for nut server
upsdrvctl start
upsd
#end additions for nut server

exit 0

Diese hätte ich auskommentiert.

@Thomas-Braun sagte in [HowTo] USV: NUT Server auf SBC installieren:

Oder es gibt was in /etc/init.d

da gibt es ne ganze Menge u.a. eine Datei nut-server

#! /bin/sh
### BEGIN INIT INFO
# Provides:          nut-server upsd
# Required-Start:    $local_fs $syslog $network $remote_fs udev
# Required-Stop:     $local_fs $syslog $network $remote_fs udev
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Network UPS Tools initscript
# Description:       This script take care of starting and stopping the
#                    Network UPS Tools components. When needed, it also
#                    handle the UPS hardware shutdown.
### END INIT INFO

# Author: Arnaud Quette <aquette@debian.org>

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin

NAME=nut-server
DESC="NUT - power devices information server and drivers"
CONFIG=/etc/nut/nut.conf
pid_dir=/var/run/nut
upsd_pid=${pid_dir}/upsd.pid
upsd=/sbin/upsd
upsdrvctl=/sbin/upsdrvctl
log=">/dev/null 2>/dev/null"

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

# set upsd specific options. use "man upsd" for more info
# this parameter is now located in nut.conf, and not in /etc/default/nut anymore
# FIXME: retrieved from 'nut' script during update
UPSD_OPTIONS=""

# Exit if the package is not installed
[ -x "$upsd" ] || exit 0

# Include NUT nut.conf
[ -r $CONFIG ] && . $CONFIG

# Explicitly require the configuration to be done in /etc/nut/nut.conf
# redundant with nut-client
if [ "x$MODE" = "xnone" -o -z "$MODE" ] ; then
   log_action_msg "$NAME disabled, please adjust the configuration to your needs"
   log_action_msg "Then set MODE to a suitable value in $CONFIG to enable it"
   # exit success to avoid breaking the install process!
   exit 0
fi

# Check if /var/run/nut exists and has the correct perms
check_var_directory() {
 [ ! -d ${pid_dir} ] && mkdir -p ${pid_dir} \
   && chown root:nut ${pid_dir} \
   && chmod 770 ${pid_dir} \
   && [ -x /sbin/restorecon ] && /sbin/restorecon ${pid_dir}
}

# check if the right components are running
check_status() {
 case "$MODE" in
   standalone|netserver)
     status_of_proc -p $upsd_pid $upsd upsd
     # FIXME: need driver(s) status too!
     ;;
   none|netclient|*)
     # defered to nut-client
     #status_of_proc -p $upsmon_pid $upsmon upsmon
     ;;
 esac
}

start_stop_server () {
 case "$MODE" in
   standalone|netserver)
     case "$1" in
       start)
         # First, start driver(s)
         ! $upsdrvctl start >/dev/null 2>&1  &&  \
           log_progress_msg " (driver(s) failed)." || log_progress_msg " driver(s)."
         # Then, data server (upsd)
         start-stop-daemon -S -p $upsd_pid -x $upsd \
           -- $UPSD_OPTIONS >/dev/null 2>&1 &&
           log_progress_msg "upsd" || log_progress_msg "(upsd failed)"
         ;;
       stop)
         # FIXME: should stop nut-client first!
         # Reverse order for stop
         start-stop-daemon -K -o -p $upsd_pid -n upsd && #>/dev/null 2>&1 &&
           log_progress_msg "upsd" || log_progress_msg "(upsd failed)"
         ! /sbin/upsdrvctl stop >/dev/null 2>&1  &&  \
           log_progress_msg "(driver(s) failed)" || log_progress_msg "driver(s)"
         ;;
     esac
     ;;
   none|netclient|*)
     # now handled by nut-client
     return 1
     ;;
 esac
}

case "$1" in

 start)
   log_daemon_msg "Starting $DESC"
   check_var_directory
   start_stop_server start #&& log_progress_msg "upsd"
   #start_stop_client start && log_progress_msg "upsmon"
   log_end_msg 0
   ;;

 stop)
   log_daemon_msg "Stopping $DESC"
   start_stop_server stop #&& log_progress_msg "upsd"
   #start_stop_client stop && log_progress_msg "upsmon"
   log_end_msg 0
   ;;

 reload)
   $upsd   -c reload >/dev/null 2>&1
   #$upsmon -c reload >/dev/null 2>&1
   ;;

 restart|force-reload)
   log_daemon_msg "Restarting $DESC"
   #start_stop_client stop
   start_stop_server stop
   sleep 5
   check_var_directory
   start_stop_server start #&& log_progress_msg "upsd"
   #start_stop_client start && log_progress_msg "upsmon"
   log_end_msg 0
   ;;

 status)
   #log_daemon_msg "Checking status of $DESC"
   echo "Checking status of $DESC"
   check_status
   exit $?
   ;;

 poweroff)
   wait_delay=`sed -ne 's#^ *POWEROFF_WAIT= *\(.*\)$#\1#p' /etc/nut/nut.conf`
   # UPS poweroff action is actually done here.
   # But nut-monitor (Ie nut-client) does the check and call nut-server if needed!
   # This action MUST NOT be called directly, and thus is not exposed in 'Usage'
   case "$MODE" in
     standalone|netserver)
       log_daemon_msg "Shutting down the UPS ..."
       if $upsdrvctl shutdown ; then
         # FIXME (needed?): sleep 5
         log_progress_msg "Waiting for UPS to cut the power"
         log_end_msg 0
       else
         log_progress_msg "Shutdown failed."
         log_progress_msg "Waiting for UPS batteries to run down"
         log_end_msg 0
       fi
       if [ -n "$wait_delay" ] ; then
         log_daemon_msg " (will reboot after $wait_delay) ..."
         sleep "$wait_delay"
         invoke-rc.d reboot stop
       fi
       ;;
     none|netclient|*)
       # nothing to do
       ;;
   esac
   ;;

 *)
   N=/etc/init.d/$NAME
   echo "Usage: $N {start|stop|reload|restart|force-reload|status}" >&2
   exit 1
   ;;
esac

exit 0

NEWS

[HowTo] USV: NUT Server auf SBC installieren

Support us

952
Online

31.9k
Users

80.2k
Topics

1.3m
Posts

NEWS

[HowTo] USV: NUT Server auf SBC installieren

Support us

952Online

31.9kUsers

80.2kTopics

1.3mPosts

952
Online

31.9k
Users

80.2k
Topics

1.3m
Posts