FHEM Forum

Die Network UPS Tools (www.networkupstools.org (http://www.networkupstools.org)) dienen dazu, Unterbrechungsfreie Stromversorgungen und ähnliches abzufragen und zu steuern. Unter anderem können sie dafür sorgen, dass ein Rechner ordentlich herunterfährt, wenn der Strom ausgefallen ist und die Batterie der USV zur Neige geht.

Damit das auch mit mehreren Rechnern an einer USV funktioniert, ist NUT (wie der Name schon sagt) netzwerkgestützt.

Da moderne USVs auch einiges an Meßwerten bieten (angefangen an Restlaufzeit über Eingangsspannung bis hin zu Umgebungsparametern wie Temperatur und Luftfeuchte), bieten sich für FHEM nette Szenarios an. Das fängt bei einem Hilferuf an, wenn der Strom ausfällt, geht mit der Dokumentation der verschiedenen Meßwerte weiter und kann z.B. auch das Abschalten verschiedener Verbraucher beinhalten, die an einer USV hängen, wenn der Strom ausfällt.

Deshalb bin ich gerade dabei, ein neues Modul zu entwickeln: 34_NUT.pm

Bisher kann es eine USV, die an einem NUT-Server hängt, abfragen und stellt ein paar Readings zur Verfügung.

Nur fehlen mir jetzt noch ein paar Informationen, wie es weitergeht:

• Ich habe nichts gefunden, welche Mindestansprüche an Fähigkeiten und Doku ein Modul haben muß, damit es aufgenommen werden muß.
• Vermutlich brauche ich einen Entwicklerzugang (werd ich einfach mal beantragen).
• Natürlich brauche ich Ideen und Anregungen, was das Modul noch so alles können soll.  ;)

Klingt interessant...

Hier http://www.fhemwiki.de/wiki/Kategorie:Development (http://www.fhemwiki.de/wiki/Kategorie:Development) findest du schon einiges zum Thema Modul-Entwicklung.

lg, ici

So. Das Modul ist eingecheckt.

Klasse Idee. Bisher habe ich zwar an meiner USV sowohl NAS, als auch Fritzbox und RasPi hängen, aber das Daten-Kabel der USV geht ins NAS. Mal sehen, ob das NAS NUT-fähig ist.  ::)

Also gleich mal meine ersten Versuch auf dem RasPi gemacht.

Ich habe ein Thecus NAS N5200XXX im Einsatz, daran hängt eine APC Back UPS ES 700. Laut Community ist NUT in der Firmware und läuft als Client und Server.

Das wollte ich doch mal sehen.

Schritt 1: Auf den RasPi NUT installieren. Ich will nur den Client.
# NUT für USV
sudo apt-get install nut-client

Schritt 2: rausbekommen, wie meine USV am NAS heißt. In der WebGui sieht man das nicht.
upsc -l ThecusNAS

Antwort:
usbhid-ups

Schritt 4: Prüfen, ob die USV angesprochen werden kann.
upsc usbhid-ups@ThecusNAS

Antwort:
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.date: not set
battery.mfr.date: 2012/03/09
battery.runtime: 937
battery.runtime.low: 120
battery.type: PbAc
battery.voltage: 13.6
battery.voltage.nominal: 12.0
device.mfr: APC
device.model: Back-UPS ES 700G
device.serial: 5B1210T09384
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.4.3
driver.version.data: APC HID 0.95
driver.version.internal: 0.34
input.sensitivity: medium
input.transfer.high: 266
input.transfer.low: 180
input.voltage: 236.0
input.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.firmware: 871.O2 .I
ups.firmware.aux: O2
ups.load: 39
ups.mfr: APC
ups.mfr.date: 2012/03/09
ups.model: Back-UPS ES 700G
ups.productid: 0002
ups.serial: 5B1210T09384
ups.status: OL
ups.timer.reboot: 0
ups.timer.shutdown: -1
ups.vendorid: 051d

Das sieht doch schon mal toll aus. Jetzt habe ich alle Daten, um das Modul zu konfigurieren.

Teil 2 folgt demnächst.  :)

Gruß,
Veit

Gerade habe ich Teil 2 versucht.
define UPS NUT usbhid-ups ThecusNAS

Wurde ohne Fehlermeldung im Log angelegt, allerdings bekomme ich keine Readings.

Ich habe jetzt sicherheitshalber auf IP umgestellt.

Einzige Info im Log:
2014.09.23 09:32:28 3: Opening UPS device 192.168.2.254:3493
2014.09.23 09:32:28 3: UPS device opened

Ideen? Gibt es noch weitere Installationsvoraussetzungen?

Gruß
Veit

Mit dem Attribut asReadings kann man einstellen, welche USV-Werte als Readings verwendet werden. Allerdings sollte dieses Attribut bereits vorbelegt sein.

Kannst du mal das Ergebnis von
list usbhid-ups
posten?

Hallo,

"nut-server" läuft bei mir auf einem NAS, dort ist auch die USV angeschlossen. Auf dem NAS selbst kann ich z.Bsp. die Werte der USV per

Zitat
upsc -l
apc

upsc apc
battery.alarm.threshold: T
battery.charge: 100.0
battery.charge.restart: 00
battery.date: 09/03/93
...

auslesen.

Von meinem FHEM-Server geht das nicht:

Zitat
upsc -l nas1
Error: Connection failure: Connection refused

Ich habe schon einige Seiten im Netz durchgelesen, aber keine Erklärung gefunden, wie man von "remote" die Werte für eine USV abfragt. Kann mir hier jemand helfen?

Gruß
Blueberry63

Zitat von: blueberry63 am 23 September 2014, 14:18:37

Von meinem FHEM-Server geht das nicht:
Ich habe schon einige Seiten im Netz durchgelesen, aber keine Erklärung gefunden, wie man von "remote" die Werte für eine USV abfragt. Kann mir hier jemand helfen?

Hallo blueberry63,

vielleicht ist NUT so konfiguriert, dass es nur auf localhost lauscht. Schau mal auf dem NAS in die Datei
/etc/nut/upsd.conf (oder wo auch immer die Datei auf dem NAS ist). Darin hat es vermutlich irgendwo die Zeile LISTEN 127.0.0.1
Die ergänzt du durch LISTEN 192.168.x.y
wobei das die IP des NAS ist. Nach einem Neustart des NUT-Servers lauscht er auch auf Anfragen von außen.

Um die USV von außen abzufragen, sollte jetzt folgendes gehen:
upsc apc@nas1

Die Konfiguration war so schon eingestellt. Muss eigentlich auf der "Remote-Seite" noch etwas für "nut-Client" konfiguriert werden?

Gruß
Blueberry63

Das ist jetzt natürlich sehr schwer zu beantworten, da ich nicht weiß, was für ein NAS das ist... und mich natürlich auch nicht mit allen auskenne.

Wichtig ist, dass der NUT-Server nach der Umstellung wirklich neu gestartet wird (reload reicht nicht).

Hängen die Geräte im gleichen Netz oder könnte da noch eine Firewall dazwischen sein? Könnte es sein, dass das NAS selbst eine Firewall aktiv hat?

Bei mir wird der FHEM-Server nach kurzer Zeit jeweils instabil und hängt sich auf. Der Load geht hoch.
Wenn ich den Server abschieße und das NUT-Device auf disabled 1 setze, läuft es normal.

Beim Absturz habe ich gesehen, dass sich im Feld Buffer dann doch größere Datenmengen angesammelt haben. Screenshot hängt dran.

Beim Wiederanfahren gab es noch eine Fehlermeldung auf der Kommandozeile:
Use of uninitialized value in string ne at ./FHEM/34_NUT.pm line 295.

Zitat von: volschin am 23 September 2014, 17:48:51
Bei mir wird der FHEM-Server nach kurzer Zeit jeweils instabil und hängt sich auf. Der Load geht hoch.
Wenn ich den Server abschieße und das NUT-Device auf disabled 1 setze, läuft es normal.

Beim Absturz habe ich gesehen, dass sich im Feld Buffer dann doch größere Datenmengen angesammelt haben. Screenshot hängt dran.

Beim Wiederanfahren gab es noch eine Fehlermeldung auf der Kommandozeile:

Code Auswählen Erweitern

Use of uninitialized value in string ne at ./FHEM/34_NUT.pm line 295.

#
Huaaa.

Die Fehlermeldung ist noch recht harmlos; da hab ich eine Vermutung.
Aber der NUT-Server scheint sich laufend selbst zu unterbrechen; und das ist was, das ich nicht verstehe. Ich werde mal eine Notbremse einbauen, wenn der buffer zu groß wird.

Auf was läuft NUT? Wie sind FHEM und NUT verbunden? (Na gut, so langsam kann die Verbindung eigentlich gar nicht sein...) Wie sind pollState und pollVal eingestellt?

Du kannst mir glauben, dass die Verbindung schnell genug ist. Wie aus meinen Versuchen oben erkennbar, gibt es auch keinerlei Probleme mit upsc auf OS Ebene.

Die Poll-Parameter habe ich nicht angepasst.

Seltsam, sehr seltsam... bin gerade dabei, die Auswertung umzubauen, damit sie robuster wird. Morgen teste ich, dann kommt eine neue Version.

Neue Version von 34_NUT ist im SVN. Sie sollte jetzt wesentlich robuster sein; ein unkontrolliertes Anwachsen des Buffers ist nicht mehr möglich.
Probiers damit mal aus. Woher der eigentliche Fehler kommt (unvollständiger Empfang der Daten von NUT), weiß ich nämlich noch nicht; aber so kannst du testen, ohne dass FHEM abstürzt.

Vielleicht kannst du dann mal die Ausgabe von
fhem.pl 7072 "list UPS"
posten. Mit
attr UPS verbose 5
kannst du auch die Laberhaftigkeit von NUT im fhem-log hochsetzen.

hab dein modul gerade installiert und es schaut schon sehr gut aus. danke !

einen wunsch habe ich aber: es wäre besser (und es ist mehr oder weniger fhem standard) wenn die readings keine einheiten haben. das macht das weiterverarbeiten und plotten einfacher und konsistent mit anderen (aktuellen) modulen.

gruss
  andre

und noch etwas: wenn du in deine attribut liste $readingFnAttributes mit aufnimmst kann dein modul automatisch event-on-change, event-min-interval & co. und die geloggte datenmenge lässt sich deutlich reduzieren.

gruss
  andre

Zitat von: justme1968 am 24 September 2014, 15:33:37
und noch etwas: wenn du in deine attribut liste $readingFnAttributes mit aufnimmst kann dein modul automatisch event-on-change, event-min-interval & co. und die geloggte datenmenge lässt sich deutlich reduzieren.

Geht das automatisch, wenn die Attribute aufnehme? Ich dachte, ich müßte das selbst implementieren, deshalb hab ich sie im Moment noch draußen.

Und das mit den Einheiten... ja, ich weiß, dass es unüblich ist... dafür gibt es ja die interface-Definitionen, aber die passen für eine USV hinten und vorne nicht.
Aber ich könnte es ja einfach per Attribut schaltbar machen.

jd. du musst nur "  $readingFnAttributes" an deine AttrList anhängen. alles andere geht automatisch.

die interface definitionen aus dem wiki sind im prinzip tot. es wird hoffentlich etwas neues geben. bis dahin ist die überwiegende meinung einheiten in den readings weg zu lassen. in STATE kann man sie sich ja mit stateFormat einfach selber konfigurieren.

gruss
  andre

Zitat von: justme1968 am 24 September 2014, 16:34:14
jd. du musst nur "  $readingFnAttributes" an deine AttrList anhängen. alles andere geht automatisch.

Hübsch. Gibt es da noch mehr Attributes, die automatisch funktionieren?

Zitat
die interface definitionen aus dem wiki sind im prinzip tot. es wird hoffentlich etwas neues geben. bis dahin ist die überwiegende meinung einheiten in den readings weg zu lassen. in STATE kann man sie sich ja mit stateFormat einfach selber konfigurieren.

Tja... damit würde man den tatsächlichen Geräten auch nur hinterherlaufen. Na ja, jetzt mach ichs mal per Schalter.

Neue Version kommt demnächst.

mit $readingFnAttributes bekommst du event-on-change-reading, event-on-update-reading, event-min-interval und stateFormat.

in dieser art gibt es dann nur noch die SetExtensions die du in (d)einer SetFn verwenden kannst und mit denen du automatisch on-for-timer, off-for-timer, on-til, off-til, blink und intervals bekommst wenn dein modul on und off kann. ob das für eine usv sinnvoll ist glaube ich aber nicht.

gruss
  andre

Zitat von: justme1968 am 24 September 2014, 16:50:00
in dieser art gibt es dann nur noch die SetExtensions die du in (d)einer SetFn verwenden kannst und mit denen du automatisch on-for-timer, off-for-timer, on-til, off-til, blink und intervals bekommst wenn dein modul on und off kann. ob das für eine usv sinnvoll ist glaube ich aber nicht.

Hihi... eine blinkende USV hätte ja schon was... Abschalten geht ja durchaus (wenn es auch noch nicht implementiert ist), aber Einschalten dürfte ferngesteuert eher selten gehen.

Ich habe die Version aus dem svn eingespielt, disable auf 0 gesetzt und das List gemacht.

Internals:
   DEF        usbhid-ups 192.168.2.254
   DeviceName 192.168.2.254:3493
   FD         106
   NAME       UPS
   NR         384
   PARTIAL
   STATE      opened
   TYPE       NUT
   UpsName    usbhid-ups
   buffer
   lastStatus
   pollValState 20
   Readings:
   Helper:
Attributes:
   asReadings battery.charge battery.runtime input.voltage ups.load ups.power ups.realpower
   disable    0
   model      1
   pollState  5
   pollVal    60
   room       _Test
   serNo      1

Jetzt hängt er wieder. Hätte mal zuerst das Attribut setzen sollen. Naja, beim nächsten Versuch.

Anbei das Log.

Hast du an das
reload 34_NUT
gedacht? Die Meldung Anzahl Readings von... gibt es in der aktuellen Version nicht mehr.

Hast du model und serNo von Hand gesetzt? Er setzt die eigentlich automatisch, aber nur, wenn sie nicht existieren.

Nach dem Log zu urteilen, hat er einige Minuten ganz normal eingelesen. Ich verstehe nicht, wieso dann keinerlei Einträge zumindest im Helper sind.

Reload habe ich gemacht. Spätestens für das Log hat das nach dem Absturz auch keine Rolle mehr gespielt.
Mit Model und Serno habe ich nicht manuell gemacht.

Neue Version steht im SVN.
Bitte prüfen, ob im Kopf der Datei tatsächlich die Id mit Rev 6616 steht.

Achtung:Die Definition des Attributes asReadings hat sich geändert: Die Readings werden jetzt nicht mehr mit Leerzeichen, sondern mit Kommata getrennt. Das Attribut muß also geändert werden, damit die Readings weiter geholt werden.
Die Änderung soll das Verhalten an die readingFnAttributes anpassen, die das auch so machen. Ich hoffe, ich zerschieße damit niemand allzu viel.

Ansonsten habe ich die Erzeugung der Einheiten ganz rausgeworfen, weil ich selbst damit Probleme bekommen habe.  ;) Immerhin bin ich damit regelkonform.

Die readingFnAttributes werden jetzt auch unterstützt.

@volschin: Versuch es bitte nochmal mit dieser Version (6616). model und serNo solltest du mal löschen, damit sie wieder richtig gesetzt werden. Falls es weiter nicht funktioniert, bitte nochmal Logfile (natürlich mit verbose 5  ;)) und Ausgabe von list.

Ich habe hier leider nur über update eine Datei bekommen, deren Id-Tag leer ist. Nichtdestotrotz funktioniert es jetzt.

Zitat von: volschin am 25 September 2014, 15:49:17
Ich habe hier leider nur über update eine Datei bekommen, deren Id-Tag leer ist. Nichtdestotrotz funktioniert es jetzt.

Sehr schön. Pass beim nächsten Update auf, da wird sich dann das Attribut asReadings anders verhalten (siehe oben). Ich weiß nicht genau, wann die Updates per update verteilt werden, nachdem sie im SVN eingecheckt sind; es kann sein, dass das erst am nächsten Tag funktioniert.

Irgendwie kann FHEM immer mehr, als man denkt.

Jetzt hab ich extra ein paar Berechnungen in das NUT-Modul eingebaut, um ups.realpower zu berechnen, weil dieser Wert nicht geliefert wird. Und ich habe mir Gedanken gemacht, wie man das über ein Attribut universeller gestalten könnte.

Dann lese ich mir (endlich) mal durch, wie userReadings funktioniert und muß feststellen, dass das doch schon alles geht.

Also gibt es am morgen wieder eine neue Version von 34_NUT, bei der ich diese überflüssigen Berechnungen rausgeworfen habe. Stattdessen habe ich bei mir jetzt asReadings um ups.realpower.nominal ergänzt und dafür ups.realpower, das bei meiner USV eh nicht vorhanden ist, rausgeworfen:
attr USV asReadings battery.charge,battery.runtime,input.voltage,ups.load,ups.realpower.nominal
Und damit kann ich mein gewünschtes ups.realpower einfach berechnen lassen:
attr USV userReadings upsRealpower {ReadingsVal("USV","ups.realpower.nominal",0)*ReadingsVal("USV","ups.load",0)/100}
Und siehe da - ups.realpower ist da, ganz ohne Zutun des Moduls.  ;D

[UPDATE] Soweit die Theorie. Geht aber nicht. Muß ich noch rausfinden, wieso.
[2. UPDATE] Weil userReadings im Moment keine Punkte im Namen verträgt. Codebeispiel oben entsprechend geändert.

Hallo Creideiki,
ich habe gerade mit deiner neuen komma-separierten Liste erste Erfahrungen gemacht. Du solltest das bitte so implementieren, dass es egal ist, ob am Anfang oder Ende ein Leerzeichen steht (trim).

Aktuell:
battery.charge,battery.runtime -> funktioniert
battery.charge, battery.runtime -> funktioniert nicht für zweiten Wert
battery.charge ,battery.runtime -> funktioniert nicht für ersten Wert

Sonst macht das jetzt schon einen sehr stabilen Eindruck. Danke für das Modul.  :)

Bzgl. der FHEM-Statistik bin ich mir noch nicht sicher, ob ich es so toll finde, dass da jetzt mein genauer UPS Typ übertragen wird. Was bringt diese Information?

Gruß,
Veit

Zitat von: volschin am 26 September 2014, 10:23:55
Hallo Creideiki,
ich habe gerade mit deiner neuen komma-separierten Liste erste Erfahrungen gemacht. Du solltest das bitte so implementieren, dass es egal ist, ob am Anfang oder Ende ein Leerzeichen steht (trim).

Danke. Wird implementiert.

Zitat
Bzgl. der FHEM-Statistik bin ich mir noch nicht sicher, ob ich es so toll finde, dass da jetzt mein genauer UPS Typ übertragen wird. Was bringt diese Information?

Hm. An sich dient es dazu, sicher zu sein, dass man die richtige USV in der Mache hat; ich könnte mir vostellen, dass es übersichtlicher ist, wenn man mehrere USVs verwendet. Ich hab das eigentlich aus dem HMLAN-Modul übernommen; da werden ja auch Typ und Seriennummer aller Geräte in Attributen angelegt.

Gibt es da einen üblichen Modus Operandi? Gibt es Argumente dafür, das zu tun oder zu lassen?

'normalerweise' sind attribute dinge die der anwender einstellt. readings sind messwerte die sich ändern und geloggt werden sollen und internals sind device spezifische informationen die sich (meist) nicht während der laufzeit ändern.

typ, software version und solche dinge kommen typischweise in die internals (also z.b. $hash->{model}).

martin steckt das vor allem deshalb in attribute statt internals weil es als attribut gespeichert wird und beim neustart zur verfügung steht ohne das ein device per funk abgefragt werden muss was funklast erzeugt und eventuell gar nicht geht weil das device schläft. bei allem was per kabel angebunden ist sollte das nicht relevant sein.

gruss
  andre

OK, das kann ich so nachvollziehen. Dann werf ich das raus.

Neue Version 6620

• Das Timing mit pollState und pollVar ist so überarbeitet, dass er zum einen mit dem Lesen aller Werte anfängt und zum anderen sich auch an die mit pollVar eingestellte Zeit hält.
• Die automatische Erzeugung von Werten wie ups.power ist rausgeflogen. Das funktioniert besser mit userReadings. Achtung: Mit userReadings erstellte Readings dürfen im Moment keinen Punkt enthalten, sonst klappt das nicht.
• Die automatische Erzeugung der Attribute model und serNo ist rausgeflogen. Es ist nicht wirklich notwendig, kann einfach erzeugt werden (z.B. mit userReadings) und ist u.U. störend.
• Die Liste der Readings (asReadings) darf jetzt auch Leerzeichen zwischen Komma und Reading enthalten.

Ich kriegs einfach nicht hin vielleicht hat noch wer einen tipp für mich

pi@Agent-Schlafzimmer ~ $ sudo apt-get install nut-client
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libupsclient1
The following NEW packages will be installed:
  libupsclient1 nut-client
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 297 kB of archives.
After this operation, 542 kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Err http://mirrordirector.raspbian.org/raspbian/ wheezy/main libupsclient1 armhf 2.6.4-2.3
  404  Not Found
Err http://mirrordirector.raspbian.org/raspbian/ wheezy/main nut-client armhf 2.6.4-2.3
  404  Not Found
Failed to fetch http://mirrordirector.raspbian.org/raspbian/pool/main/n/nut/libupsclient1_2.6.4-2.3_armhf.deb  404  Not Found
Failed to fetch http://mirrordirector.raspbian.org/raspbian/pool/main/n/nut/nut-client_2.6.4-2.3_armhf.deb  404  Not Found
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
pi@Agent-Schlafzimmer ~ $


am zweiten raspi klappt es noch weniger, da friert die Konsole einfach ein und nichts geht mehr
pi@Agent-Kuche ~ $ sudo apt-get install nut-client nut-server
pi@Agent-Kuche ~ $ ts... 5%




Bitte nicht Schlagen ich weis wirklich nicht was jetzt noch Fehlt...
Gruß Markus

404 not found klingt so als wäre etwas mit der erwarteten Downloadquelle nicht in Ordnung, sprich die erwarteten Pakete sind Online nicht verfügbar, dass kann an alten Paketinformationen liegen!

Hast du denn mal wie vom Programm vorgeschlagen

Zitatapt-get update

ausgeführt?

Greetz
Eldrik

Ich kann da natürlich nur raten, aber das sieht mir eher nach Netzwerkproblem aus... entweder bei dir oder bei raspbian.org oder zwischendrin. Versuch es doch einfach später nochmal, vielleicht erledigt sich das auch von selbst.

Hallo,

Ich bin gerade auf diesen Threat gestoßen weil ich mir eine USV gekauft habe die ich an den Raspberry , auf dem Fhem läuft, anschließen möchte .

Erst mal besten Dank an Creideiki für das 34_NUT.pm Modul welches sehr gut funktioniert !!

Ich habe jetzt zwei USV's .

Eine USV für die Heizung , den Fhem Raspi und der zweiten Fritzbox im EG .
Eine USV auf dem Boden für den NAS Server und die Haupt Fritzbox im OG .

Der NAS ist eine Synology DS412+ auf der tatsächlich ein NUT-Server läuft, der so wie im 4. Beitrag erklärt, ausgelesen werden kann . Die USV im NAS heist einfach "ups" . Also ein upsc ups@192.168.0.120 liest die USV aus .

Das erst mal nur kurz, der Vollständigkeit halber, vorweg  ;)

Die zweite USV wollte ich an den Fhem - Raspi anschließen, weil sonst kein PC in der nähe ist . Also muss ich auf dem Raspberry den NUT Server installieren . Ich möchte später auch mal eine Email oder Push Nachricht bekommen wenn Stromausfall ist .

Ich habe mich anhand dieses Blog Eintrages orientiert : http://abakalidis.blogspot.de/2013/04/using-raspberry-pi-as-ups-server-with.html (http://abakalidis.blogspot.de/2013/04/using-raspberry-pi-as-ups-server-with.html)

Hier nur mal eine kleine kurze und knappe Doku wie ich den Server bei mir eingerichtet habe :

Den NUT-Server + Client installieren


sudo apt-get install nut-client nut-server


USB-Utils installieren falls die nicht schon vorhanden sind .



sudo apt-get install usbutils


jetzt die USV am Raspi anstecken und mit dem Befehl lsusb kontrollieren ob die USV erkannt wird


pi@fhempi ~ $ lsusb

Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 008: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 006: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

Die USV wurde erkannt .

Nun kann der Server konfiguriert werden :

die Datei mit folgendem Befehl sudo nano /etc/nut/ups.conf aufrufen, editieren und die USV eintragen . Der Name den sie im NUT Server später hat steht in den eckigen klammern .

[apc550VA]
driver = usbhid-ups
        port = auto
        desc = "APC Back-UPS RS 550VA BR550GI"




jetzt die folgenden drei Befehle eingeben um die korrekten Rechte für den Ordner zu vergeben :


pi@fhempi ~ $ sudo mkdir /var/run/nut
pi@fhempi ~ $ sudo chown root.nut /var/run/nut/
pi@fhempi ~ $ sudo chmod 770 /var/run/nut/

Nun kann der USB Treiber getestet werden :



pi@fhempi ~ $ sudo upsdrvctl start
Network UPS Tools - UPS driver controller 2.6.4
Network UPS Tools - Generic HID driver 0.37 (2.6.4)
USB communication driver 0.32
Using subdriver: APC HID 0.95



Das sieht schon mal ganz gut aus .

Nun noch die Datei sudo nano /etc/nut/upsd.conf ändern damit der Server auch im Netzwerk angesprochen werden kann :

folgende Zeilen einfügen :
LISTEN 127.0.0.1 3493
LISTEN 192.168.0.22 3493

wobei die IP in der zweiten Zeile die IP des Rasperry ist auf dem der Server läuft .

dann mit


sudo service nut-server start



den Server starten und eventuell mit sudo update-rc.d -f nut-server defaultsden Server Dienst beim booten des Raspberry starten lassen .

folgender Befehl sollte den gestarteten Dienst anzeigen :

pi@fhempi ~ $ ps -ef | grep ups

nut       2210     1  0 10:48 ?        00:00:00 /sbin/upsd
nut       2609     1  0 10:53 ?        00:00:00 /lib/nut/usbhid-ups -a apc550VA
pi        2944  2488  0 11:02 pts/0    00:00:00 grep --color=auto ups

mit dem folgenden Befehl bekommt man dann alles was die USV so an Daten liefert angezeigt .

pi@fhempi ~ $ upsc apc550VA@192.168.0.22
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.date: 2001/09/25
battery.mfr.date: 2014/09/11
battery.runtime: 840
battery.runtime.low: 120
battery.type: PbAc
battery.voltage: 14.2
battery.voltage.nominal: 12.0
device.mfr: American Power Conversion
device.model: Back-UPS RS 550G
device.serial: 3B1437X13447
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.4
driver.version.data: APC HID 0.95
driver.version.internal: 0.37
input.sensitivity: medium
input.transfer.high: 282
input.transfer.low: 176
input.transfer.reason: input voltage out of range
input.voltage: 237.0
input.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.firmware: 857.L4 .I
ups.firmware.aux: L4
ups.load: 38
ups.mfr: American Power Conversion
ups.mfr.date: 2014/09/11
ups.model: Back-UPS RS 550G
ups.productid: 0002
ups.realpower.nominal: 330
ups.serial: 3B1437X13447
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: 0
ups.timer.shutdown: -1
ups.vendorid: 051d

Der Server läuft und man kann Fhem konfigurieren wie hier im Threat beschrieben .

Vielleicht hilft dem einen oder anderen diese kleine Doku zum einrichten den NUT-Servers auf einem Raspberry Pi .
Wenn jemand Fehler entdeckt bitte melden, dann korrigiere ich das .

Gruß Martin

Vielen Dank für die ausführliche Beschreibung Martin! Hat geklappt!

Wie kann ich einfach überprüfen ob die USV Strom bekommt oder nicht?

Übrigens ein kleiner Hinweis von mir zum Versenden von E-Mails oder Push-Nachrichten bei Stromausfall. Ich habe vor kurzem bei einem 45 Minuten Ausfall festgestellt, dass zwar meine Fritzboxen und der Raspi am Leben waren, jedoch die Internet-Verbindung tot. Ich habe einen T-Entertain Anschluss und vermutlich war auch irgendwelche Zwischenverteiler-Technik der Telekom davon betroffen. Also davon ausgehen, dass das Senden bei Stromausfall fehlschlägt.

Stimmt. Deshalb hab ich mir einen kleinen GSM-Stick zugelegt mit einer billigen SIM drin, die der RasPi per gammu ansteuert. Damit kann der RasPi auch nach Hilfe rufen, wenn das Internet tot ist. Vorausgesetzt, der zuständige GSM-Mast ist nicht auch tot...  :P

Hallo Creideiki,

erst mal vielen Dank für das Modul. Ich hatte es seit Monaten absolut stabil im Einatz.

Seit ein paar Tagen habe ich jedoch ganz komische Fehler. Es wurde eigentlich weder an der HW noch an der SW etwas verändert.

Bei mir hängt die USV am NAS (ojbnas) und von dort werden alle Infos geholt.

Wenn ich upsc ups@ojbnas auf der FHEM-Maschine eingebe kommen auch immer die gewünschten Daten.

Starte ich FHEM, bekomme ich jetzt allerdings:

2015.05.18 14:09:53 3: Opening usv device ojbnas:3493
2015.05.18 14:10:03 3: NUT antwortet nicht
2015.05.18 14:10:03 3: Opening usv device ojbnas:3493
2015.05.18 14:10:13 3: NUT antwortet nicht


Und jetzt wird es interessant. Wenn ich in FHEM direkt auf das Device gehe, dann im Define ojbnas auf ojbnas1 ändere, was es nicht gibt, und wieder zurück auf ojbnas und anschliessend disable auf 0 und dann wieder auf 1, dann geht es wieder.

Was kann das sein?

Um jede Hilfe dankbar.

Liebe Grüße
Oli

Sorry, dass es so lange gedauert hat; ich komme zur Zeit kaum noch an den Rechner.

Ich hab mir den Code nochmal angeschaut. Anscheinend lief er auf einen Timeout. Ich hab zwar was eingebaut, dass er dann automatisch die Verbindung wieder aufbaut, aber das geht so wohl nicht. Ich versuche das mal zu klären.

Im Moment ist es definitiv so, dass er die Verbindung nicht mehr aktiv kriegt.

Läuft er bei dir nach der Umbenennungsaktion wieder?

Habe heute seit sehr langer Zeit wieder mal ein Update gemacht, wo auch NUT geupdatet wurde.
Seither habe ich das selbe Problem wie obj.

Dürfte aber nicht direkt im NUT-Modul liegen, da ich auch nach zurückspielen des "alten" NUT nach wie vor das selbe Problem habe.
Auf meinem Testcubie, wo NUT lokal läuft, ist (ohne Update) kein Problem.

lg, Ici

PS: Hmm, ich sehe grad, dass NUT gar kein Update hatte. Muss also irgendwo anders liegen

PPS: Das Problem liegt in der DevIo......Sobald ich die Update, bekommt NUT keine Verbindung mehr zum service

ich habe auch das Problem mit dem disconnect  :(

gibt's da mittlerweile eine Lösung?

Und was hat's mit der DevIO auf sich?

LG
Arne

Hallo allerseits,

eigentlich habe ich das Modul entsprechend umgebaut. Ich komme bloß gerade nicht zum Testen, und ungetestet will ich es nicht einchecken. Ich habe es mal hier drangehängt; wer will, kann es mal testen und mir Rückmeldung geben. Es kann aber eben sein, dass es schlechter läuft also vorher - ist ja ungetestet.  ;)

DevIo ist ein Modul, das den ganzen Aufwand des Gerät (USB, Netz, Socket...) übernimmt, die Daten einliest und an das eigene Modul weitergibt usw. Es vereinfacht den Aufwand dafür wesentlich (es geht ja z.B. nicht, dass ein Modul auf Daten wartet und damit das ganze FHEM blockiert), aber es ist bisher nur wenig dokumentiert.

Habe grade das 34_NUT durch dein hier angehängtes ersetzt, hat sich aber nichts geändert (trotz reload 34_NUT und auch späterem komplett-Reset des Cubie's)

Liegt/lag wohl daran, dass ich nicht im selben Zug die DevIo geupdatet hatte.
Diese ist jetzt auch am neuesten Stand und seither läufts wieder.

Ich lass das mal über nacht und probiers dann morgen auf meinem Produktiv-System ebenfalls.

lg, Ici

Hm, das klingt... tja...

Gut finde ich, dass 34_NUT nicht gleich einen Syntaxfehler ausspuckt.  ;D

Schlecht finde ich, dass die Funktion/Nicht-Funktion von der Version von DevIo abhängt. Mit der hab ich nämlich nichts zu tun und ich habe auch noch keinen Changelog von ihr gefunden. Wenn sich da was ändert, wäre das gut, wenn man das mitkriegt...

Ich bin jedenfalls neugierig, wie es jetzt läuft.

Hallo Creideike,

habe eben die modifizierte 34_NUT eingespielt.

Bekomme folgebde Fehlermeldungen im fhem.log:

2015.06.08 00:01:57 1: PERL WARNING: Deep recursion on subroutine "main::NUT_ListVar" at ./FHEM/34_NUT.pm line 137.
2015.06.08 00:01:57 1: PERL WARNING: Deep recursion on subroutine "main::DevIo_OpenDev" at ./FHEM/34_NUT.pm line 181.

und FHEM hängt ....

Liebe Grüße und Danke trotzdem für die Mühen
Oli

So, auf meinem Testsystem läuft 34_NUT seit gestern abend ohne Fehler.
Vor ca. 30 Minuten hab ich die NUT auf mein Produktiv rüberkopiert.

Läuft soweit, ABER:
Beim ersten Start hing FHEM komplett und hat mir das Log zugemüllt:
2015.06.08 05:44:44 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.08 05:44:44 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.08 05:44:44 3: NUT antwortet nicht
2015.06.08 05:44:44 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.08 05:44:44 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.08 05:44:44 3: NUT antwortet nicht
2015.06.08 05:44:44 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.08 05:44:44 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.08 05:44:44 3: NUT antwortet nicht
2015.06.08 05:44:44 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.08 05:44:44 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.08 05:44:44 3: NUT antwortet nicht
2015.06.08 05:44:44 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.08 05:44:45 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.08 05:44:45 3: NUT antwortet nicht
2015.06.08 05:44:45 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.08 05:44:45 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.08 05:44:45 3: NUT antwortet nicht
2015.06.08 05:44:45 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.08 05:44:45 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.08 05:44:45 3: NUT antwortet nicht
2015.06.08 05:44:45 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.08 05:44:45 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.08 05:44:45 3: NUT antwortet nicht
2015.06.08 05:44:45 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.08 05:44:45 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.08 05:44:45 3: NUT antwortet nicht
2015.06.08 05:44:45 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.08 05:44:45 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.08 05:44:45 3: NUT antwortet nicht
2015.06.08 05:44:45 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.08 05:44:45 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.08 05:44:45 3: NUT antwortet nicht
2015.06.08 05:44:45 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.08 05:44:45 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.08 05:44:45 3: NUT antwortet nicht
2015.06.08 05:44:45 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.08 05:44:45 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.08 05:44:45 3: NUT antwortet nicht

Habe dann FHEM gestoppt (service fhem stop), dann direkt in der config das NUT auf "disable 1" gesetzt.
Danach ließ FHEM sich einwandfrei starten.
Nachdem ich dann das disable gelöscht habe, läuft es jetzt ohne Fehler.....

Hatte nur einen Fehler im Log:
2015.06.08 05:53:23 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/34_NUT.pm line 172.

lg, Ici

OK, da kann ich reinschauen, das sollte sich beides beheben lassen. Wird aber heute nichts mehr, meine Tochter hat Geburtstag. :-)

Hi,

ist das Problem evtl. schon gefunden? Seit dem letzten Update wird mein Log auch vollgeschrieben :-\

Greetz
Eldrik

Nicht wirklich, habe NUT vorläufig deaktiviert, nachdem es nach einem Reset wieder begonnen hatte, mein Log zu spammen.

Keine Ahnung, wo da der Hund begraben liegt.

Sorry für die späte Antwort, aber diese Woche war komplett dicht.

Ich denke, ich habe beide Fehler gefunden; anbei die neue Version.
Genaugenommen waren es eigentlich drei Fehler; zwei davon haben dafür gesorgt, dass er nach einem Neustart in diese Endlosschleife gekommen ist. Das sollte jetzt weg sein.

Supi, werd ich gleich mal testen.......


PS: Sieht nach den ersten Minuten und einem Restart gut aus :)

Zitat von: Icinger am 14 Juni 2015, 09:20:30
Supi, werd ich gleich mal testen.......


PS: Sieht nach den ersten Minuten und einem Restart gut aus :)

Dito!

Greetz
Eldrik

Hallo,

bei mir hängt FHEM:

2015.06.15 22:25:03 1: PERL WARNING: Deep recursion on subroutine "main::NUT_ListVar" at ./FHEM/34_NUT.pm line 137.
2015.06.15 22:25:03 1: PERL WARNING: Deep recursion on subroutine "main::DevIo_OpenDev" at ./FHEM/34_NUT.pm line 181.

Liebe Grüße
Oli

Kannst du mir sagen, unter welchen Umständen das angefangen hat? Gibt es da noch andere Fehlermeldungen am Anfang? Ist das die Version, die ich weiter oben (14.6.) angehängt habe?

Hallo Creideiki,

nachdem es nicht zu erklären ist, warum nur ich den Fehler habe, habe ich jetzt 34_NUT.pm erneut heruntergeladen und eingespielt.

Ergebnis: Es funktioniert und ich habe keine Fehlermeldungen.

Komisch. Ich denke gestern Abend habe ich auch alles richtig gemacht, würde aber einen Fehler meinerseits nicht ausschliessen.

Ich berichte weiter. Wie gesagt, im Moment alles super.

Danke für Dein Engagement.

Liebe Grüße
Oli

Bei mir läuft die neue Version jetzt seit 2 Tagen ohne irgendwelche Macken....

Auch 3 Restarts hats ohne Fehler überlebt (zu Testzwecken).

Ich hatte zwar heute morgen einen FHEM-Reset, hat aber glaube ich nichts mit 34_NUT.pm zu tun ...

Jun 17 07:47:52 kernel: [121514.369642] init: fhem main process (4165) terminated with status 9
Jun 17 07:47:52 kernel: [121514.369694] init: fhem main process ended, respawning

34_NUT.pm läuft fehlerfrei ...

Sehr schön. Ich hab's bei mir jetzt auch produktiv laufen. Wenn's keine Probleme mehr gibt, werde ich diese Version demnächst einchecken.

Bei mir läuft's jetzt auch wieder  :)
Nur kein Update machen, bevor's nicht eingechecked ist  ;)

Da muss ich auch aufpassen, da Samstag bei mir immer automatisch Update läuft.


Sent from my iPhone using Tapatalk

Zitat von: volschin am 18 Juni 2015, 18:09:31
Da muss ich auch aufpassen, da Samstag bei mir immer automatisch Update läuft.


Sent from my iPhone using Tapatalk

Automatische FHEM Updates sind in einer Produktivumgebung keine gute Idee.

Finde ich aber schon und hat mir bisher kaum Probleme gemacht. Auch meine RasPis machen ihre OS-Updates automatisch. Lediglich ein paar Ausnahmen fahre ich manuell, z.B. Kernel.

Ach übrigens, für ein Update bis die Änderung eingecheckt ist, einfach folgenden Eintrag machen:
attr global exclude_from_update 34_NUT.pm

Natürlich später nicht vergessen, es wieder rauszunehmen.  ;)

Ist die neue NUT immer noch nicht eingecheckt?
Hab grad ein Update gemacht, und nu gehts wieder los:

2015.06.23 21:04:15 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:15 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:15 3: NUT antwortet nicht
2015.06.23 21:04:15 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:15 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:15 3: NUT antwortet nicht
2015.06.23 21:04:15 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:15 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:15 3: NUT antwortet nicht
2015.06.23 21:04:15 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:15 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:15 3: NUT antwortet nicht
2015.06.23 21:04:15 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:15 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:15 3: NUT antwortet nicht
2015.06.23 21:04:15 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:15 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:15 3: NUT antwortet nicht
2015.06.23 21:04:15 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:15 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:15 3: NUT antwortet nicht
2015.06.23 21:04:15 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:15 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:15 3: NUT antwortet nicht
2015.06.23 21:04:15 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:15 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:15 3: NUT antwortet nicht
2015.06.23 21:04:15 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:16 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:16 3: NUT antwortet nicht
2015.06.23 21:04:16 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:17 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:17 3: NUT antwortet nicht
2015.06.23 21:04:17 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:17 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:17 3: NUT antwortet nicht
2015.06.23 21:04:17 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:17 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:17 3: NUT antwortet nicht
2015.06.23 21:04:17 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:17 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:17 3: NUT antwortet nicht
2015.06.23 21:04:17 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)
2015.06.23 21:04:17 1: 192.168.1.23:3493 reappeared (APC_UPS)
2015.06.23 21:04:17 3: NUT antwortet nicht
2015.06.23 21:04:17 1: 192.168.1.23:3493 disconnected, waiting to reappear (APC_UPS)

lg, Ici

Nein, noch nicht.

Ja, ja, ich mach ja...

Eingecheckt ist es, müßte also bald als Update verfügbar sein.

Ich habe festgestellt, dass wenn ich disable auf 1 setze und das Modul eigentlich schweigen müsste, das Log mit Einträgen zugespammt wird:

2015.07.20 13:06:18 1: 192.168.2.254:3493 disconnected, waiting to reappear (UPS)
2015.07.20 13:06:18 1: 192.168.2.254:3493 reappeared (UPS)

Das tritt minütlich auf und entspricht damit dem bei mir eingestellten Wert pollVal 60

Im angeschalteten Zustand (disable = 0) gibt es die Probleme nicht.

'Tschuldigung für die späte Antwort, ich komme im Moment nicht allzu oft an den Rechner.

Zitat von: volschin am 20 Juli 2015, 13:16:47
Ich habe festgestellt, dass wenn ich disable auf 1 setze und das Modul eigentlich schweigen müsste, das Log mit Einträgen zugespammt wird:

Code Auswählen Erweitern

2015.07.20 13:06:18 1: 192.168.2.254:3493 disconnected, waiting to reappear (UPS)
2015.07.20 13:06:18 1: 192.168.2.254:3493 reappeared (UPS)

Das tritt minütlich auf und entspricht damit dem bei mir eingestellten Wert pollVal 60

Im angeschalteten Zustand (disable = 0) gibt es die Probleme nicht.

Hm, seltsam. Ich hab da jetzt nichts gefunden, was das auslösen könnte. Zumal die Meldungen nicht vom Modul, sondern von DevIo kommen müßten.

Ist das immer noch so? Hat das Problem noch jemand anderes?

Wenn ich in die Subroutine
sub NUT_ListVar($) {
ab Zeile 163 reinschaue, startest Du immer erst einen Initialisierungsprozess und dann beginnt ab zeile 176 das "if" für das disabled.

Ich denke die Schleife müsste früher beginnen. Disabled heißt ja, es soll kein Connect auf den NUT-Server erfolgen. 

Das heißt, du hast NUT disabled, weil der NUT-Server nicht da ist?

Hm, ja, macht irgendwie Sinn. Das wäre eine sinnvolle Anwendung von disabled.

Ich verhindere im Moment tatsächlich nur das Polling. Ich schau, dass ich das demnächst umbaue.

Der Sinn von Disable ist eigentlich, dass das Modul gar nichts tut. Man ist damit nicht gezwungen etwas gleich aus der Konfiguration zu löschen, nur um es mal nicht zu nutzen. Und ja, mein NUT läuft auf dem NAS, dass ich nachts und bei Abwesenheit abschalte.

So, neue Version ist eingecheckt und sollte demnächst im Update erscheinen. Der Verbindungsaufbau wird jetzt durch disable=1 ebenfalls verhindert.

Super, danke. Ich werde testen und berichten.

Wollte nur Bescheid geben dass es mit meiner Eaton3S700DIN und meinem Raspberry mit FHEM und diesem Modul auch klappt. Vielen Dank dafür!

Hallo. Bei mir lief es sehr sehr lange ohne Probleme. Seit gestern bekam ich immer folgende Meldung:

2015.09.13 11:22:31 2: NUT Error: DRIVER-NOT-CONNECTED

Ich hatte alles probiert. Reboot FHEM, Disable an/aus. Hat nichts geholfen. Nur ein Löschen des UPS in fhem.cfg und wieder neu eintragen hat geholfen.

Komisch.

Hm... ich muß zugeben, ich bin verwirrt. Ich weiß nämlich nicht, wo diese Fehlermeldung herkommt. Anscheinend nicht von FHEM; da habe ich sie nirgens gefunden.

Aber ich muß wohl das Handling von disabled nochmal verbessern. Das hätte den Fehler beheben sollen, wenn Löschen und Wiederanlegen funktioniert.

Seit ich FHEM damals geupdated hatte kam der Fehler auch nicht mehr. Nur ab und an kommt jetzt:

DATA-STALE

zu finden dann im - lastError: DATA-STALE

Sollte aber kein grosses Ding sein. Geht ohne Probleme gleich danach wieder.

Siehe:
http://www.networkupstools.org/docs/FAQ.html#_what_8217_s_this_about_emphasis_data_stale_emphasis

Hallo!

Habe probiert eine APC USV mit einem Raspberry und FHEM in Betrieb zu nehmen und diesen Thread genutzt die USV zu betreiben.
Leider klappt das nicht wirklich bei mir.

Die USV ist via USB am Raspberry angeschlossen.
Welche Schritte muß ich hierfür ausführen.
Gibt es irgendwo eine Anleitung Schritt für Schritt um eine USV via USB am Raspberry zu betreiben?

So.
Lange hat es gedauert.
Habe aber immer noch ein Problem mit dem automatsichen Start des NUT-Servers am Raspberry beim Boot des Raspberry.

Mit dem Eintrag

Zitatsudo update-rc.d -f nut-server defaults

startet der Dienst nicht.
Ich muss diesen immer manuell starten mit

Zitatsudo service nut-server start

damit der Server Dienst läuft.

Firmware und Updates auf dem Raspberry sind aber aktuell!

Gibt es für die nut-Dienste etwas spezielles beim Raspberry damit diese laufen?

Hm... ich weiß natürlich mal wieder nicht genau, wie ich es dort zum Laufen gekriegt habe.

Existiert ein Link in /etc/rc2.d auf nut-server.sh?

Laut manpages auf meinem RasPi gehört das -f nicht zu dieser Anwendung von update-rc.d. Was sagt denn
sudo update-rc.d nut-server defaults?

Hast du zwischen update-rc.d und service ... start rebooted?

Mit

Zitatsudo update-rc.d nut-server defaults

wird unter /etc/rc2.d das File S03nut-server angelegt.
Bei einem Neustart wird aber dennoch der Service nicht gestartet!

Bei dir heist das File nut-server.sh anscheinend in diesem Verzeichnis.

Was meinst du mit

ZitatHast du zwischen update-rc.d und service ... start rebooted?

Sicherlich habe ich nach dem update-rc.d einen Neustart ausgeführt weil ich ja wissen will ob der Dienst gestartet wird.

Nachdem es aber nicht funktioniert muß ich den Service manuell starten.

Zitat von: Burny4600 am 19 Dezember 2015, 18:37:12
Mit  wird unter /etc/rc2.d das File S03nut-server angelegt.
Bei einem Neustart wird aber dennoch der Service nicht gestartet!

Gut. Wenn das File da ist, sollte er beim Booten zumindest versuchen, NUT zu starten. Dann geht dabei vermutlich etwas schief. Theoretisch sollte da in ingendeinem Logfile etwas auftauchen; in /etc/init.d/nut-server ist aber eine Variable log, die das wohl abklemmt. Versuch mal, da eine sinnvolle Datei einzutragen; vielleicht gibt es dann erhellende Ausgaben.

ZitatBei dir heist das File nut-server.sh anscheinend in diesem Verzeichnis.

Äh - nein, es heißt nut-server. Fehler meinerseits.

ZitatWas meinst du mit Sicherlich habe ich nach dem update-rc.d einen Neustart ausgeführt weil ich ja wissen will ob der Dienst gestartet wird.
Nachdem es aber nicht funktioniert muß ich den Service manuell starten.

Ich wollte nur sichergehen. Oft sind es die Kleinigkeiten, die einem den Tag vermasseln.

Also das was in dem nut-server File drinnen steht ist mir ein bischen zu steil.
Habe es angehängt, damit mir vielleicht du hier weiter helfen kannst.

Wenn ich mir das nut-server File so ansehe, kommt es mir vor als ob hier einige Angaben anders sind als wie die die ich aus Anleitungen her habe nach denen ich die Installation ausgeführt habe.
Nur weiß ich natürlich nicht was wirklich notwendig ist.

Mir kommt nur der Eintrag pid_dir=/var/run/nut
upsd_pid=${pid_dir}/upsd.pid
nicht ganz logisch vor, den dann müsste es ja auch die passende Datei dazu geben, ausser diese wird nicht benötigt oder später bei einem Ereigniss angelegt.

Könntest du mir deine Dateien aus dem Verzeichnis /etc/nut/ zum Vergleichen zukommen lassen?
Was mir auch noch auffällt ist, dass bei installiertem NUT das FHEM auch nicht mehr funktioniert.

I have similar problems with nut-server.

I have fhem on a Cubietruck, nut-server on a Pi

I have recently changed the Pi from wheezy to jessie and nut-server will  no longer start at boot - it is fine if started manually

The NUT module is OK but sometimes seems to lock up - that is not the problem, it worked OK before

I think nut-server is trying to start too early under jessie but cannot be sure and I have no idea where to look :(

@fruit

Und wie hilft mir das weiter?

Gibt es sonst ein Möglichkeit eine USB mit dem Raspberry und FHEM zu betreiben?

Hallo Zusammen,

sehr interessant das Thema!!

Ich würde gerne folgendes machen und fragen ob das so funktioniert:

USV hängt an Synology NAS, dort läuft der NUT Server.
Nun möchte ich, dass FHEM auf einen Stromausfall reagiert und noch ein paar Dinge einstellt (z.B. Temp auf bestimmten Wert) und dann den Server (auf dem FHEM läuft, ein Ubuntu Server) runter fährt.

Geht das so?
Was brauche ich noch auf meinen Ubuntu-Server? NUT Client?
Wer fährt den Server runter, FHEM oder NUT-Client?

Vielen Dank!

@Burny4600

I am not sure it helps much at all - except that starting nut-server under raspbian jessie seems to be broken

It was working very well under wheezy, with the Cubietruck as a nut-client and it would shutdown along with fhem as expected.


The script you posted seems to be the sysvinit script from /etc/init.d

I believe this is now replaced by systemd - unless you are still running wheezy or have disabled systemd - I am not sure what raspbian version you have

@Mitch
Soweit ich das beurteilen kann ist FHEM nur ein Monitor und weniger als ein NUT-Client.

Aber man kann mit diesen aufgenommenen Ereignissen trotzdem andere Komponeten bedienen, nur halt nicht die USV selbst über den NUT-Server.
Auf dem Server brauchst du eigentlich nichts mehr, denn da hast du ja den NUT-Server der die USV und den Server ja herunterfährt wenn es notwenig ist.

@fruit
Ich verwende die Version 2015-11-21-raspbian-jessie auf meinen Raspberry

Zudem ist es ärgerlich, sowie der NUT-Server fertig eingerichtet wurde funktioniert der FHEM Service auch nicht mehr.

Danke Chris.

Also würde ich folgendes machen:
- NUT Server auf Synology aktivieren (mahr braucht es da nicht)
- im FHEM einen notify auf ein passendes Reading (z.B. Strom weg), welcher die Temp einstellt
- im NUT Client (auf FHEM Server) den Shutdown durchführen lassen

Kann die Fritte auch NUT Client spielen?

In my hurry I had missed setting my static IP address in /etc/dhcpcd.conf on the new Pi2

nut-server would not start because it was waiting for IPs to come up with dhcp :(
All is good now

The fhem NUT module is working here - except if I reboot the Pi the module seems to be blocking and I have to restart
The nut-client on Cubietruck does reconnect with no problem.

I am sure it was OK before so perhaps another config issue here.

Wo genau wurde die Änderungen für DHCP bzw. der IP Adresse durchgeführt.


# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU.
# Some interface drivers reset when changing the MTU so disabled by default.
#option interface_mtu

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private

# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname


In wheezy IP address was set in /etc/network/nterfaces.
For jessie it should be set in /etc/dhcpsd.conf

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
#etc
#etc
# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname

interface eth0
static ip_address=192.168.1.35
static routers=192.168.1.33
static domain_name_servers=192.168.1.33

## interface wlan0
## static ip_address=192.168.1.201/24
## static routers=192.168.1.1
## static domain_name_servers=192.168.1.1
I only have eth0, uncomment/edot wlan0 if you have wlan

Das war es noch nicht.
Nach wie vor das gleiche.

Habe in der interfaces Datei noch folgendes entdeckt wo ich aber nicht weiß wo ich die Einstellungen vornehmen kann.
Nähmlich wo ich "man dhcpcd.conf" finde.
# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

iface eth0 inet manual

allow-hotplug wlan0
iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

allow-hotplug wlan1
iface wlan1 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Ohne diese Änderung habe ich den NUT-Server jetzt zumindest zum Laufen gebracht.
Unter raspi-config => 3 Wait for Network Boot => muß folgendes eingestellt werden damit der NUT-Server es mitbekommt.
Slow Wait for Network connection befor completing boot.
Das verhält sich anscheinend ähnlich wie der Start ohne DHCP, da der Raspy wartet bis er die vollständigen Netzwerk Informationen erhalten hat.
Jetzt besteht leider nur noch das Problem das die NUT-Installation den FHEM Dienst killt.
Die NUT Dienste sind es jedenfalls nicht, da wenn ich alle NUT-Dienste deaktiviere und einen Reboot ausführe der FHEM Dienst zwar läuft aber ich keinen Zugriff auf FHEM habe.

I have exactly the same /etc/network/interfaces as yours

Google is not helping :(

I think you are asking for 'man dhcpcd. conf' as you posted /etc/dhcpcd.conf earlier

apropos dhcpcd
apropos is useful :)
man dhcpcd.conf
Posting all of /var/log/syslog at boot is a lot so I will try and list important lines to show the order in which they happen here

Dec 21 10:35:33 rpi systemd[1]: Starting Internet superserver...
Dec 21 10:35:33 rpi systemd[1]: Started Internet superserver.
Dec 21 10:35:33 rpi systemd[1]: Starting dhcpcd on all interfaces...
..
Dec 21 10:35:33 rpi dhcpcd[493]: DUID 00:01:00:01:1d:96:d4:2c:b8:27:eb:90:f1:c5
Dec 21 10:35:33 rpi dhcpcd[493]: eth0: IAID eb:69:1b:86
Dec 21 10:35:33 rpi CRON[515]: (root) CMD (/bin/sleep 900; /usr/bin/touch /opt/fhem/log/fhem.save; /etc/init.d/watchdog start)
Dec 21 10:35:33 rpi CRON[516]: (logcheck) CMD (   if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck -R; fi)
Dec 21 10:35:33 rpi dhcpcd[493]: eth0: soliciting an IPv6 router
Dec 21 10:35:33 rpi dhcpcd[493]: eth0: using static address 192.87.182.35/8
Dec 21 10:35:33 rpi dhcpcd[493]: eth0: adding route to 192.0.0.0/8
Dec 21 10:35:33 rpi dhcpcd[493]: eth0: adding default route via 192.87.182.33
..
Dec 21 10:35:33 rpi systemd[1]: Starting Network.
Dec 21 10:35:33 rpi systemd[1]: Reached target Network.
..
Dec 21 10:35:33 rpi avahi-daemon[437]: New relevant interface eth0.IPv6 for mDNS.
Dec 21 10:35:33 rpi avahi-daemon[437]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.87.182.35.
Dec 21 10:35:33 rpi avahi-daemon[437]: New relevant interface eth0.IPv4 for mDNS.
Dec 21 10:35:33 rpi avahi-daemon[437]: Network interface enumeration completed.
Dec 21 10:35:33 rpi avahi-daemon[437]: Registering new address record for 2001:8b0:111b:0:ba27:ebff:fe69:1b86 on eth0.*.
Dec 21 10:35:33 rpi avahi-daemon[437]: Registering new address record for 192.87.182.35 on eth0.IPv4.
..
Dec 21 10:35:33 rpi systemd[1]: Starting /etc/rc.local Compatibility...
Dec 21 10:35:33 rpi systemd[1]: Starting Network is Online.
..
Dec 21 10:35:33 rpi upsdrvctl[559]: Using subdriver: APC HID 0.95
Dec 21 10:35:33 rpi upsdrvctl[559]: Network UPS Tools - Generic HID driver 0.38 (2.7.2)
Dec 21 10:35:33 rpi upsdrvctl[559]: USB communication driver 0.32
..
Dec 21 10:35:33 rpi upsdrvctl[559]: Network UPS Tools - UPS driver controller 2.7.2
Dec 21 10:35:33 rpi systemd[1]: Started Network UPS Tools - power device driver controller.
Dec 21 10:35:33 rpi systemd[1]: Starting Network UPS Tools - power devices information server...
Dec 21 10:35:33 rpi upsd[738]: fopen /var/run/nut/upsd.pid: No such file or directory
Dec 21 10:35:33 rpi upsd[738]: listening on 192.87.182.35 port 3493
Dec 21 10:35:33 rpi upsd[738]: listening on 192.87.182.35 port 3493
Dec 21 10:35:33 rpi upsd[738]: listening on 127.0.0.1 port 3493
Dec 21 10:35:33 rpi upsd[738]: Connected to UPS [Smart-UPS750]: usbhid-ups-Smart-UPS750
Dec 21 10:35:33 rpi upsd[738]: listening on 127.0.0.1 port 3493
Dec 21 10:35:33 rpi upsd[738]: Connected to UPS [Smart-UPS750]: usbhid-ups-Smart-UPS750
Dec 21 10:35:34 rpi upsd[749]: Startup successful

It is possible the Wait for Network Boot is causing problems but I believe it should pause boot until hhe network is up

Habe jetzt beide Fehler gefunden.  :P

Folgende Erkenntnisse:
Bei der NUT Installation ist darauf zu achten das folgender Eintrag in der fhem.cfg deaktiviert werden muß.
# define initialUsbCheck notify global:INITIALIZED usb create
Wenn dieser Eintrag aktiv ist stört das die USV die local am USB Anschluß angeschlossen ist.
Hat man den Watchdog auch noch aktiviert funktioniert der FHEM Dienst nicht mehr.

Damit die locale USV überwacht werden kann und der Watchdog funktioniert ist lediglich auf diesen Eintrag zu achten.

Boot Problem mit NUT und Raspberry:
Damit der NUT-Server Dienst wirklich startet ist entweder die Netzwerkadresse manuell einzugeben, oder was ich für das sinnvollste halte folgenden Eintrag zu ändern.
Unter raspi-config => 3 Wait for Network Boot => muß folgendes eingestellt werden damit der NUT-Server es mitbekommt.
=> Slow Wait for Network connection befor completing boot.

Somit laufen jetzt bei mir der NUT-Server und FHEM nach einem reboot.  ;)

Schwere Geburt, aber ich wieder ein Stückchen geschafft. :D

@fruit
Danke für deinen Tipp.
Ohne diesen Tipp hätte ich wahrscheinlich noch lange gesucht.

I am pleased you have it running
It is always the small things that are most difficult to find :(

Nächstes Problem:
FHEM NUT will mit der angeschlossen USV nicht arbeiten.

Habe folgende Einträge im LOG:
2015.12.21 18:47:41 3: Opening USV device 192.168.17.233:3493
2015.12.21 18:47:41 3: USV device opened
2015.12.21 18:47:41 1: Including /opt/fhem/log/fhem.save
2015.12.21 18:47:41 0: Featurelevel: 5.7
2015.12.21 18:47:41 0: Server started with 10 defined entities (fhem.pl:10208/2015-12-19 perl:5.020002 os:linux user:fhem pid:1174)
2015.12.21 18:47:41 5: NUT RX: ERR UNKNOWN-UPS
2015.12.21 18:47:41 2: NUT Error: UNKNOWN-UPS
2015.12.21 18:47:51 5: NUT polling disabled.
2015.12.21 18:48:01 5: NUT polling disabled.
2015.12.21 18:48:11 5: NUT polling disabled.
2015.12.21 18:48:21 5: NUT polling disabled.
2015.12.21 18:48:31 5: NUT polling disabled.
2015.12.21 18:48:41 5: NUT polling disabled.
2015.12.21 18:48:42 1: 192.168.17.233:3493 disconnected, waiting to reappear (USV)
2015.12.21 18:48:47 1: 192.168.17.233:3493 reappeared (USV)
2015.12.21 18:48:47 5: NUT polling disabled.
2015.12.21 18:48:57 5: NUT polling disabled.
2015.12.21 18:49:07 5: NUT polling disabled.
2015.12.21 18:49:17 5: NUT polling disabled.
2015.12.21 18:49:27 5: NUT polling disabled.
2015.12.21 18:49:37 5: NUT polling disabled.
2015.12.21 18:49:47 5: NUT polling disabled.
2015.12.21 18:49:49 1: 192.168.17.233:3493 disconnected, waiting to reappear (USV)
2015.12.21 18:49:54 1: 192.168.17.233:3493 reappeared (USV)
2015.12.21 18:49:54 5: NUT polling disabled.
2015.12.21 18:50:04 5: NUT polling disabled.


upsc apc1500va spuckt folgendes für die angeschlossene USV aus.

Init SSL without certificate database
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2010/08/20
battery.runtime: 20100
battery.runtime.low: 120
battery.temperature: 2493.9
battery.type: PbAc
battery.voltage: 122.1
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1500
device.serial: AS0349330598
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.7.2
driver.version.data: APC HID 0.95
driver.version.internal: 0.38
input.sensitivity: high
input.transfer.high: 253
input.transfer.low: 208
input.voltage: 234.7
output.frequency: 50.0
output.voltage: 233.2
output.voltage.nominal: 230.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 601.3.I
ups.firmware.aux: 1.5
ups.load: 0.0
ups.mfr: American Power Conversion
ups.mfr.date: 2003/12/03
ups.model: Smart-UPS 1500
ups.productid: 0002
ups.serial: AS0349330598
ups.status: OL RB
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.timer.start: -1
ups.vendorid: 051d


Definition im fhem.cfg sieht so aus.
define USV NUT usbhid-ups 192.168.17.233
attr USV asReadings battery.charge,battery.runtime,input.voltage,ups.load
attr USV disable 1
attr USV pollState 10
attr USV pollVal 60
attr USV verbose 5


Die USV ist lokal am Raspberry angeschlossen wo auch das FHEM läuft.
Ist für diesen Fall noch ein zusätzliche Änderung notwendig?

attr USV disable 1
=
NUT polling disabled.

Try with

attr USV disable 0

unless I have missed a reason for you setting disabled.

Polling geändert.

Aber die USV wird nicht erkannt?

Alles ist aber aktuell. Mit heutigem Datum nochmals alles aktualisiert.

What do you have in /etc/nut/ups.conf ?
Mine is
# To find out if your driver supports any extra settings, start it with
# the -h option and/or read the driver's documentation.

[Smart-UPS750]
        driver = usbhid-ups
        port = auto
        desc = "APC Smart-UPS 750"

and my Readings are

device.model    Smart-UPS 750
device.serial    AS0816143277
driver.name     usbhid-ups

Edit:
A long shot... but does re-enabling USB autocreate improve things at all?
(I realise that you said earlier that it was part of your problem - and that is why you disabled it)

Das ist mein Eintrag in der ups.conf für die lokale USV:
[apc1500VA]
        driver = usbhid-ups
        port = auto
        desc = "APC SMART-UPS 1500 SUA1500"


Und das der fhem.cfg für die USV
define USV NUT usbhid-ups localhost
attr USV asReadings device.model,device.serial,battery.charge,battery.runtime,input.voltage,ups.load
attr USV disable 0
attr USV pollState 10
attr USV pollVal 60
attr USV room _RXTX,USV
attr USV userReadings upsRealpower {ReadingsVal("USV","ups.realpower.nominal",0)*ReadingsVal("USV","ups.load",0)/100}
attr USV verbose 5

Port beim Server und FHEM ist 3493.

Benötigt FHEM um NUT zu nutzen noch spezielle Zugriffrechte?

Da ist was verrutscht:

Zitat von: Burny4600 am 22 Dezember 2015, 12:25:56
Das ist mein Eintrag in der ups.conf für die lokale USV:

Code Auswählen Erweitern

[apc1500VA]
        driver = usbhid-ups
        port = auto
        desc = "APC SMART-UPS 1500 SUA1500"


Die USV heißt also apc1500VA und verwendet den Treiber usbhid-ups.

Zitat
Und das der fhem.cfg für die USV

Code Auswählen Erweitern

define USV NUT usbhid-ups localhost
attr USV asReadings device.model,device.serial,battery.charge,battery.runtime,input.voltage,ups.load
attr USV disable 0
attr USV pollState 10
attr USV pollVal 60
attr USV room _RXTX,USV
attr USV userReadings upsRealpower {ReadingsVal("USV","ups.realpower.nominal",0)*ReadingsVal("USV","ups.load",0)/100}
attr USV verbose 5

Im define muß der Name der USV rein (also apc1500VA), nicht der Treibername. Sonst sucht er nach einer USB namens usbhid-ups, und die gibt es nicht.

@Creideiki

Danke für den Tipp.
Jetzt funktioniert es.

@Creideiki - and any others
This is a very useful module but I have one issue with it - it may be my configuration of course.

I have nut-server on a Pi.
fhem runs on a Cubietruck.
Cubietruck is a nut-client.
The NUT mdule uses the address of the Pi/nut-server

If I reboot the Pi then nut-client on Cubietruck will pick up and reconnect to nut-server shortly after but 34_NUT.pm does not reconnect and causes fhem to hang/block
The only way out seems to be to restart fhem

Any ideas please?

Are there any relevant log entries?

No, nothing from a quick look.

I will do some tests over the next few days and see if I can get anything from higher logging levels.

Perhaps it is/was an issue here as there do not seem to be any other similar reports - I think I am not alone in running nut-server on a different machine.
I am sure it was all OK before changing from wheezy Pi to jessie Pi2

Thanks for the reply

I have tried again this morning, lots of logs now but nothing to indicate NUT is at fault.

I think the blocking is actually caused by a PRESENCE definition that does not pick up that the Pi is back online
I knew there was was a very good reason I had disabled that some time ago :(
A pity I forgotten when I re-enabled it.
Now deleted so I don't do it again!

Sorry for the false alarm
Have a good Christmas and New Year

@Creideiki

Hat hier jemand auch schon das Steuern einer USV via FHEM realisiert?

Ich hatte es mir überlegt... aber da ich selbst keine Anwendung dafür habe, ist es nie über dieses Stadium herausgekommen. Es sollte aber nicht allzu schwer sein, das einzubauen.

Schwierig könnte es nur sein, die USV abzuschalten, an der FHEM hängt. Das gibt ein Timing-Problem.  ;D

Bekomme Fehlermeldungen von Pearl verursacht von NUT.
Wie kann ich herausfinden wo ich den Fehler suchen muss.
Fehlermeldung:
2016.03.13 12:55:33 1: Including /media/hdd/fhem/zeitplaene/zeitplaene.cfg
2016.03.13 12:55:33 1: Including /media/hdd/fhem/mycfg/USV/USV02.cfg
2016.03.13 12:55:34 3: Opening USV1 device localhost:3493
2016.03.13 12:55:34 3: USV1 device opened
2016.03.13 12:55:34 1: PERL WARNING: Use of uninitialized value $VALUE in sprintf at (eval 13) line 1.
2016.03.13 12:55:34 1: PERL WARNING: Use of uninitialized value $VALUE in sprintf at (eval 14) line 1.
2016.03.13 12:55:34 1: PERL WARNING: Use of uninitialized value $VALUE in sprintf at (eval 15) line 1.
2016.03.13 12:55:34 0: Featurelevel: 5.7

Config der USV:
#####################################
###    USV Gerätekonfiguration    ###
#####################################
define USV1 NUT apc1500VA
attr USV1 alias APC Smart-UPS 1500VA
attr USV1 asReadings battery.charge,battery.charge.low,battery.charge.warning,battery.runtime,battery.runtime.low,battery.temperature,input.voltage,ups.model,ups.delay.shutdown,ups.delay.start,ups.load
attr USV1 devStateIcon OL:measure_battery_100@green (DATA-STALE|UNKNOWN-UPS|opened|disconnected):measure_battery_100@red CHRG:measure_battery_100@yellow
attr USV1 disable 0
attr USV1 event-on-change-reading battery.(charge|charge.low|charge.warning|runtime|runtime.low|temperature),input.voltage,ups.(model|delay.shutdown|delay.start|load),Real(battery.runtime|ups.load|power)
attr USV1 pollState 10
attr USV1 pollVal 60
attr USV1 room _RxTx
attr USV1 userReadings Realbattery.runtime:input.voltage {ReadingsVal("USV1","battery.runtime",0)/60}, Realups.load:input.voltage {(ReadingsVal("USV1","ups.load",0)/(20+(1/3)+(1/15))+(17/100))},Realpower:input.voltage {(ReadingsVal("USV1","input.voltage",0))*(ReadingsVal("USV1","Realups.load",0))}
attr USV1 verbose 1

# -----------------------------------------------------------------------------------------------

#####################################
###     USV Anzeigenwerte für     ###
###     Floorplan definieren      ###
#####################################
define USV1_bc readingsProxy USV1:battery.charge
attr USV1_bc alias Batterie Ladung
attr USV1_bc group APC Smart-UPS 1500VA
attr USV1_bc icon measure_battery_100
attr USV1_bc room USV
attr USV1_bc stateFormat state %

define USV1_bcl readingsProxy USV1:battery.charge.low
attr USV1_bcl alias Batterie Ladung - 2. Warnung Begrenzung minimum
attr USV1_bcl group APC Smart-UPS 1500VA
attr USV1_bcl icon measure_battery_25@red
attr USV1_bcl room USV
attr USV1_bcl stateFormat state %

define USV1_bcw readingsProxy USV1:battery.charge.warning
attr USV1_bcw alias Batterie Ladung - 1. Warnung
attr USV1_bcw group APC Smart-UPS 1500VA
attr USV1_bcw icon measure_battery_50@yellow
attr USV1_bcw room USV
attr USV1_bcw stateFormat state %

define USV1_br readingsProxy USV1:battery.runtime
attr USV1_br alias Batterie Laufzeit
attr USV1_br icon time_clock
attr USV1_br room Unsorted
attr USV1_br stateFormat state Sec

define USV1_rbr readingsProxy USV1:Realbattery.runtime
attr USV1_rbr alias Batterie Laufzeit bei Shutdown
attr USV1_rbr group APC Smart-UPS 1500VA,APC Smart-UPS 1500VA
attr USV1_rbr icon time_timer@green
attr USV1_rbr room USV
attr USV1_rbr stateFormat state Min
attr USV1_rbr valueFn {sprintf("%.1f", $VALUE)}

define USV1_brl readingsProxy USV1:battery.runtime.low
attr USV1_brl alias Batterie Laufzeit bei Begrenzung Minimum
attr USV1_brl group APC Smart-UPS 1500VA
attr USV1_brl icon time_timer@red
attr USV1_brl room USV
attr USV1_brl stateFormat state Sec

define USV1_bt readingsProxy USV1:battery.temperature
attr USV1_bt alias Batterie Temperatur
attr USV1_bt group APC Smart-UPS 1500VA
attr USV1_bt icon temp_temperature
attr USV1_bt room USV
attr USV1_bt stateFormat state °C

define USV1_udsh readingsProxy USV1:ups.delay.shutdown
attr USV1_udsh alias Zeit bis zum Shutdown
attr USV1_udsh group APC Smart-UPS 1500VA
attr USV1_udsh icon general_aus_fuer_zeit
attr USV1_udsh room USV
attr USV1_udsh stateFormat state Min

define USV1_udst readingsProxy USV1:ups.delay.start
attr USV1_udst alias Zeit bis zum Wiedereinschalten
attr USV1_udst group APC Smart-UPS 1500VA
attr USV1_udst icon general_an_fuer_zeit
attr USV1_udst room USV
attr USV1_udst stateFormat state Min

define USV1_iv readingsProxy USV1:input.voltage
attr USV1_iv alias Spannung
attr USV1_iv group APC Smart-UPS 1500VA - Netzversorgung
attr USV1_iv icon measure_voltage
attr USV1_iv room USV
attr USV1_iv stateFormat state V

define USV1_ul readingsProxy USV1:ups.load
attr USV1_ul alias Stromaufnahme
attr USV1_ul icon measure_current
attr USV1_ul room Unsorted
attr USV1_ul stateFormat state A

define USV1_rul readingsProxy USV1:Realups.load
attr USV1_rul alias Stromaufnahme
attr USV1_rul group APC Smart-UPS 1500VA - Netzversorgung
attr USV1_rul icon measure_current
attr USV1_rul room USV
attr USV1_rul stateFormat state A
attr USV1_rul valueFn {sprintf("%.2f", $VALUE)}

define USV1_rp readingsProxy USV1:Realpower
attr USV1_rp alias Leistungsaufnahme
attr USV1_rp group APC Smart-UPS 1500VA - Netzversorgung
attr USV1_rp icon measure_power
attr USV1_rp room USV
attr USV1_rp stateFormat state W
attr USV1_rp valueFn {sprintf("%.1f", $VALUE)}


Zitat von: Burny4600 am 13 März 2016, 13:00:20
Bekomme Fehlermeldungen von Pearl verursacht von NUT.
Wie kann ich herausfinden wo ich den Fehler suchen muss.
Fehlermeldung:

Code Auswählen Erweitern


2016.03.13 12:55:34 1: PERL WARNING: Use of uninitialized value $VALUE in sprintf at (eval 13) line 1.


Config der USV:

Code Auswählen Erweitern

...
define USV1_rul readingsProxy USV1:Realups.load
attr USV1_rul valueFn {sprintf("%.2f", $VALUE)}
...


Glücklicherweise sind es nur Warnungen, keine Fehlermeldungen. Trotzdem ist das natürlich unschön.

Die Config ist ja gewaltig... da passiert eine Menge, das mit NUT nicht mehr viel zu tun hat. Ich habe oben mal eine der Zeilen rausgeholt, die ich verdächtig finde: Da kommt nämlich ein $VALUE in einer sprintf vor. Warum es aber vorkommen kann, dass $VALUE hier undefiniert ist, sollte vielleicht jemand beantworten, der sich mit valueFn besser auskennt.

Hallo,

Das NUT Modul funktioniert bei mir einwandfrei auf einem Pi mit per USB angebundener EATON3S. Ich habe aber ein kleines Problem mit einem Benarchrichtigungs-DOIF, vielleicht kann mir jemand auf die Sprünge helfen.



definde di_usv DOIF

([usv_eaton3s] =~ "OB")
({ DebianMail('me@mail.com','FHEM USV Alarm','USV auf Batteriebetrieb.');; })
DOELSEIF
([usv_eaton3s] =~ "OL")
({ DebianMail('me@mail.com','FHEM USV Alarm - OK','USV auf Normalbetrieb.');; })
DOELSEIF
([usv_eaton3s] =~ "disconnected")
({ DebianMail('me@mail.com','FHEM USV Alarm - keine Verbindung','USV Kommunikationsproblem.');; })

attr di_usv initialize cmd_2
attr di_usv wait 0:10:10



Das funktioniert im Normalbetrieb soweit prima, allerdings bekomme ich bei jedem FHEM Neustart eine Mail "USV auf Normalbetrieb" weil beim Start der Status von NUT beim Initialisieren erst kurze Zeit später auf OL CHRG wechselt (wenn die Kommunikation hergestellt ist). Dadurch erzeugt das DOIF einen Statuswechsel.

Ich hatte an irgendwas mit einer zusätzlichen Bedingung wie  ([sysmon:fhemuptime] > 60 gedacht aber ich hab da irgendwie grad einen gedanklichen Knoten im Hirn. Wie habt ihr das gelöst ?


Grüße, gadget

Hallo,

ist jetzt nur indirekt eine Frage zum Modul .... aber ich habe jetzt alles soweit am laufen nur mag
er mir die input.voltage nicht ausgeben. Aber upsc liefert die schon nicht

pi@raspberrypi:/etc/nut $ sudo upsc apc750@127.0.0.1:3493
Init SSL without certificate database
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.runtime: 9420
battery.runtime.low: 120
battery.type: PbAc
battery.voltage: 27.3
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 750
device.serial: AS1241224396
device.type: ups
driver.flag.pollonly: enabled
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 0003
driver.version: 2.7.2
driver.version.data: APC HID 0.95
driver.version.internal: 0.38
ups.beeper.status: disabled
ups.delay.shutdown: 20
ups.firmware: UPS 08.3 / ID=18
ups.mfr: American Power Conversion
ups.mfr.date: 2012/10/12
ups.model: Smart-UPS 750
ups.productid: 0003
ups.serial: AS1241224396
ups.status: OL
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.vendorid: 051d


Hat jemand eine SMT750I am laufen und bekommt diese Readings?

Oder überseh ich was grobes ;-)


Danke für jeden Tipp

LG
Timo

Meine USV hängt per USB an der Synology, die IP dort ist u.a. auch für den RasPi freigegeben.

Die Sachen am RasPi sind installiert, ich bekomme auch folgende Werte:

upsc ups@192.168.1.11
Init SSL without certificate database
battery.charge: 90
battery.charge.low: 20
battery.runtime: 1558
battery.type: PbAc
device.mfr: EATON
device.model: Eaton 3S 550
device.serial: 000000000
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 5
driver.parameter.port: auto
driver.version: DSM6-1-14872-161104
driver.version.data: MGE HID 1.33
driver.version.internal: 0.38
input.transfer.high: 264
input.transfer.low: 184
outlet.1.desc: PowerShare Outlet 1
outlet.1.id: 2
outlet.1.status: on
outlet.1.switchable: yes
outlet.2.desc: PowerShare Outlet 2
outlet.2.id: 3
outlet.2.status: off
outlet.2.switchable: yes
outlet.desc: Main Outlet
outlet.id: 1
outlet.switchable: no
output.frequency.nominal: 50
output.voltage: 230.0
output.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 02
ups.load: 12
ups.mfr: EATON
ups.model: Eaton 3S 550
ups.power.nominal: 550
ups.productid: ffff
ups.serial: 000000000
ups.status: OL CHRG
ups.timer.shutdown: 0
ups.timer.start: 0
ups.vendorid: 0463

Wenn ich die jetzt mit
define USV NUT usbhid-ups localhost einbinden will findet fhem sie nicht, muß ich nicht die IP eingeben?

du musst die ip der synology angeben. nicht localhost.

Also "DEF        usbhid-ups 192.168.1.11"? Kommt immer noch disconnected.
Oder statt USB... was anderes?

den namen den du der ups gegeben hast. im upsc kommando ist es ups. also auch im define:define USV NUT ups 192.168.1.11

Klappt, super, danke.

Gibts einen sauberen Weg um FHEM aus sich heraus zu beenden?
Oder sollte man daß direkt über NUT auf dem System machen lassen?

Also so nach dem Motto "wenn noch 120 Sekunden Akku da sind, bitte runterfahren".

Wenn dein Start/Stop Script sauber implementiert ist, brauchst Du Dir darum keine Gedanken zu machen.


Gesendet von iPhone mit Tapatalk

Hallo. :)

Danke für das tolle Modul. Eingerichtet und geht auf Anhieb.

Ich habe eine Frage:
Ich habe bereits ein userreading, welches mir die verbleibenden Sekunden in Minuten umrechnet (damit es in einer ReadingGroup und später in FTUI besser aussieht):

ZitatuserReadings Akkulaufzeit_Minuten {ReadingsVal($name,"battery.runtime","0")/60}

Das folgende ist mir nicht ganz klar, wie ich das erreiche. Das Readinig "state" wirft über den Status der USV folgendes aus:
state:OL
state:OB DISCHRG
state:OL CHRG

Was wäre der einfachste Weg, das in Abhängigkeit des Readings "state" ein anderer Text erscheint (z.B. in einem anderem Reading)?
state:OL = "USV ist voll geladen"
state:OB DISCHRG = "Stromausfall"
state:OL CHRG = "USV wird aufgeladen"


• Über "valueFormat" denke ich nicht das es klappt
• Vielleicht über "Userreadings"? Ich habe bei dem Device aber schon ein "Userreadings" im Einsatz, den kann man aber nur einmal setzten
• Oder ein Dummy-Gerät anlegen, und mit einem "if" bei einem bestimmten Wert von state das entsprechende Reading im Dummy schreiben?

Ich brauch keine fertige Lösung, nur den "best practice"-Weg als Anregung. :) Hab mich mit dem Suchen der Lösung ein wenig verrannt...., und um den WAF zu steigern, brauch ich Texte die auch meine Frau versteht. ;)

Eine Möglichkeit ist die Umdefinition über das Attribut structure_map.

KORREKTUR: Obiges wirkt nur in einer Structure. Versuch mal EventMap (https://wiki.fhem.de/wiki/EventMap)

ZitatVielleicht über "Userreadings"? Ich habe bei dem Device aber schon ein "Userreadings" im Einsatz, den kann man aber nur einmal setzten

Du kannst zwar nur einmal das userreadings-Attribut belegen, dafür aber dieses eine mit mehreren UserReadings.

Siehe commandref:

ZitatuserReadings
Komma getrennte Liste von benutzerdefinierten Readings.

lg, Stefan

Zitat von: volschin am 22 August 2017, 18:55:31
Versuch mal EventMap (https://wiki.fhem.de/wiki/EventMap)

Danke, ja das geht. Allerdings manipuliere ich damit den "STATE" und nicht das Reading.
@Icinger: danke, das wusste ich noch gar nicht. :)
OK, das werde ich noch mal genauer verfolgen, wenn ich Zeit habe. Danke für die Anregungen.


Nun aber mal eine Frage direkt zum Modul:
Was ist genau der Unterschied ziwschen den Attributes "pollState" und "pollVal"
"pollVal": "Dieser Wert wird auf ein Vielfaches von pollState gerundet" -> Warum?

Spricht was dagegen beide Werte z.B. auf 5 Sekunden zu setzten, um eine schnellere Aktualisierung zu bekommen? Und warum ist im default der Wert für pollState so groß (60 Sekunden)?

PollState fragt nur den Status der USV ab, während PollVal alle Werte ausliest und damit deutlich kostenintensiver ist.

Hallo Zusammen,

ich war grad ein wenig am Umbauen und mein NAS war darum ein wenig Offline. Kann es sein, das ein nicht erreichbares NAS FHEM zu blockieren bringt?

Folgendes ist die letzte Meldung im Log:

2018.02.03 11:10:55 3: NUT antwortet nicht
2018.02.03 11:10:55 1: 192.168.92.22:3493 disconnected, waiting to reappear (USV)

Hallo,

danke für das Modul! Funktioniert super.

Aber... Wie prüft ihr, ob es einen Stromausfall gibt?
Ist der State dann immer "OB DISCHRG" oder kann es auch noch andere bedenkliche Status geben?
Gibt es irgendwo eine Liste, was es alles geben kann und was die einzelnen Status bedeuten?

Gruß

Carsten

Hallo Carsten,

ich werte 3 States bei mir aus:
"OL" USV ist wieder voll aufgeladen
"OB.DISCHRG" USV hat in Akkumodus gewechselt. Stromausfall
"OL.CHRG" USV hat wieder in Power-Modus gewechselt. Stromversorgung ist wieder vorhanden

Ich lasse mir alle 3 States mit einem notify per Pushover zuschicken, somit weiß ich immer was passiert:

USV:OL set Pushover_Mike msg "USV-Status: USV ist wieder voll aufgeladen"
USV:OB.DISCHRG set Pushover_Mike msg "USV-Status: USV hat in Akkumodus gewechselt. Stromausfall?"
USV:OL.CHRG set Pushover_Mike msg "USV-Status: USV hat wieder in Power-Modus gewechselt. Stromversorgung ist wieder vorhanden"

Perfekt! Vielen Dank!

Hallo zusammen,

meine NUT-Abfrage benötigt einen Usernamen und Passwort, da der NUT-Server gesichert ist.
Wie kann ich denn in FHEM für den NUT-Zugriff Benutzername und Passwort mit eintragen?

Grüße
Der Tom

Eine kleine Ergänzung der Vollständigkeit halber

Meine APC BackUps UPS BX 700VA scheint sich bei >20 sekunden ohne USB-Kommunikation von USB zu verabschieden.

Meistens läuft es gut, aber hin und wieder kommen Fehler
In FHEM zeigt dann es "Data Stale" und/oder "WAIT" an.
Behoben werden kann es bisher nur, durch ziehen und wiedereinstecken des USB-Steckers oder reboot des Raspberry PI 3
Auch ein Neustart des NUT-Servers oder so hilft nicht.

Eine Lösung soll es wohl sein, folgenden eintrag mit "pollinvertall" in der ups.conf zu ergänzen:

[cyber1]
        driver = "usbhid-ups"
        port = "auto"
        desc = "CyberPower CP900EPFCLCD"
        pollinterval = 15

Quelle: https://nmaggioni.xyz/2017/03/14/NUT-CyberPower-UPS/

Der Fix läuft bei mir im Test.
Vielleicht hat ja jemand mal ein ähnliches Problem... der Rest lief nämlich fast problemlos bei mir seit n paar Monaten. :-)

Im Prinzip hat das Modul gleich funktioniert.
Jedoch dokumentiert das  Log minütlich folgender Eintrag:

2018.12.06 16:41:12 1: localhost:3493 disconnected, waiting to reappear (USV)
2018.12.06 16:41:12 1: localhost:3493 reappeared (USV)

Ein ändern der Attribute pollState und pollVal bewirkt keine Änderung des Abfragezyklus.

Das gleiche Problem wird in auch unter folgendem Thema berichtet.
Thema: Meine "USV" wird ständig getrennt und neu gefunden  (Gelesen 321 mal)
https://forum.fhem.de/index.php/topic,87660.msg801736.html#msg801736 (https://forum.fhem.de/index.php/topic,87660.msg801736.html#msg801736)

Hallo zusammen,

ich habe vorgestern endlich meine Eaton 3S 850VA bekommen. Nach einigem hin- und her bekam ich NUT-Tools zum laufen. Am Raspi mit FHEM läuft der nut-server, nut-client. Die Synology ist nicht immer aktiv, daher als Slave, funktioniert soweit so gut. Die Synology "frisst" den NUT-Server.

ABER:
1. Wenn ich den Raspi neustarte starten ALLE an der USV hängenden Geräte ebenfalls, was ich schon mal sehr seltsam finde.
2. Das Listing des NUT-Moduls sieht irgendwie auch unvollständig aus:

Internals:
   DEF        ups enterprise.fritz.box:3493
   DeviceName enterprise.fritz.box:3493
   FD         37
   FUUID      5ebb0568-f33f-6c8f-4695-a2bddcd29e94f304
   NAME       USV
   NR         354
   PARTIAL   
   STATE      opened
   TYPE       NUT
   UpsName    ups
   buffer     
   lastStatus OL
   pollValState 20
   READINGS:
     2020-05-14 21:56:08   battery.charge  100
     2020-05-14 21:56:08   battery.runtime 3216
     2020-05-14 21:12:02   state           opened
     2020-05-14 21:56:08   ups.load        7
   helper:
     battery.charge 100
     battery.charge.low 20
     battery.runtime 3216
     battery.type PbAc
     device.mfr EATON
     device.model unknown 850
     device.serial Blank
     device.type ups
     driver.name usbhid-ups
     driver.parameter.pollfreq 30
     driver.parameter.pollinterval 2
     driver.parameter.port auto
     driver.parameter.synchronous no
     driver.version 2.7.4
     driver.version.data MGE HID 1.39
     driver.version.internal 0.41
     input.transfer.high 264
     input.transfer.low 184
     outlet.1.desc PowerShare Outlet 1
     outlet.1.id 1
     outlet.1.status on
     outlet.1.switchable no
     outlet.desc Main Outlet
     outlet.id  0
     outlet.switchable yes
     output.frequency.nominal 50
     output.voltage 230.0
     output.voltage.nominal 230
     ups.beeper.status enabled
     ups.delay.shutdown 20
     ups.delay.start 30
     ups.firmware 02.04.0007
     ups.load   7
     ups.mfr    EATON
     ups.model  unknown 850
     ups.power.nominal 850
     ups.productid ffff
     ups.serial Blank
     ups.status OL
     ups.timer.shutdown -1
     ups.timer.start -1
     ups.type   offline / line interactive
     ups.vendorid 0463
Attributes:
   DbLogExclude .*
   asReadings battery.charge,battery.runtime,input.voltage,ups.load,ups.power,ups.realpower
   devStateIcon OL:10px-kreis-gruen.png
   disable    0
   event-on-change-reading battery.charge, state, ups.load
   event-on-update-reading battery.charge, battery.runtime, ups.load, state
   eventMap   state:OL = "USV Voll"
state:OB DISCHRG = "Stromausfall"
state:OL CHRG = "USV wird aufgeladen"
   group      03_Status
   icon       charge_battery
   pollState  10
   pollVal    60
   room       01_Dashboard
   sortby     16
   timestamp-on-change-reading state
   userReadings userReadings runtime.minutes {ReadingsVal($Name,"battery.runtime","0")/60}

Ausgelesen wird ja scheinbar so einiges, als Readings tauchen allerdings nur 4 auf. Der State wird auch mit opened anstatt OL o.ä. angezeigt. Die zusätzlichen Readings aus den vorigen Postings hätte ich auch schon versucht - sie werden einfach nicht angezeigt.

Any ideas?

lg aus Wien,
Shamal

Hi Shamal,

das sind genau die vier Readings, die Du über die "event-on-xxx" Attribute beeinflusst.
Verändere die entsprechend und es könnte nach Deinen Wünschen funktionieren.

Gruß
Danny

Hallo Moskito,

DANKE! - das wars... jetzt kommen die readings richtig an.

lg aus Wien,
Shamal

Hallo zusammen,

neues Problem mit der USV: Bis vor 10 Minuten lief alles gut, dann hatte ich die glorreiche Idee meine Synology mit SYSSTAT und SNMP auslesen zu wollen - das hat auch gut funktioniert - nur "darf" FHEM nicht mehr mit NUT sprechen, "connection-refused"

Habt ihr eine Idee, was die Verbindung plötzlich "stört"?

lg Shamal

Schon mal nachgeschaut, ob die "Freigabe/Zugelassene Diskstation Geräte" unter den USV Einstellungen auf der Synology noch vorhanden ist?

Gruß
Danny

Hallo Leute,

folgendes Problem habe ich momentan,

NUT läuft als FHEM Modul solange bis der NUT Server nicht mehr erreichbar ist.
Ich frage mit meinem NUC (auf dem FHEM läuft) einen NUT Server im Netzwerk ab, solange dieser Server erreichbar ist, kann ich auch auf das Reading state vom NUT Modul reagieren.
Schalte ich nun den Raspberry (auf dem der NUT Server läuft) aus, geht zwar der state auf disconnected, aber kein notify oder DOIF reagiert darauf, man sieht auch erst das im reading state das disconnected steht, wenn man die Seite im Browser einmal neu lädt.

Des Weiteren friert FHEM (wenn der Raspberry mit NUT Server aus ist) bei jedem pollVal für 2-3 Sekunden ein, selbst wenn ich das Modul auf attr disable 1 stelle.

Jemand die selben Probleme oder ne Idee...?


####EDIT 1
Gestern habe ich dann dummerweise auch noch ein NUT Device umbenannt, da wurde das LOG direkt sekündlich geflutet und der state hat sich jede Sekunde aktualisiert.
Selbst einmal auf DEF klicken und dann modify brachte nichts, ich musste das device erst löschen und dann neu anlegen bis es dann wieder ohne LOGFlut und im Intervall von 10/60 funktionierte.



Grüße Marcel

Hallo Zusammen,

ich habe NUT installiert und bekomme an der Konsole folgendes:
pi@RaspberryPiSlave01:~ $ sudo upsc GreenCell@192.168.0.33
Init SSL without certificate database
battery.charge: 81
battery.voltage: 12.50
battery.voltage.high: 13.00
battery.voltage.low: 10.40
battery.voltage.nominal: 12.0
device.type: ups
driver.name: blazer_usb
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.internal: 0.12
input.current.nominal: 2.0
input.frequency: 0.0
input.frequency.nominal: 50
input.voltage: 6.1
input.voltage.fault: 238.3
input.voltage.nominal: 230
output.voltage: 230.8
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 3
ups.productid: 0000
ups.status: OB
ups.type: offline / line interactive
ups.vendorid: 0001
pi@RaspberryPiSlave01:~ $


Auf dem entsprechendem Raspi der unter der IP .33 läuft scheint es unter Fhem nicht ganz anzukommen:
define USV NUT GreenCell 192.168.0.33

Reading:
battery.charge

100

2022-01-13 23:00:48
input.voltage

236.7

2022-01-13 23:00:48
lastError

UNKNOWN-UPS

2022-01-13 23:28:17
state

opened

2022-01-13 23:45:44
ups.load

3

2022-01-13 23:00:48
Woran liegt es, das nicht alle Readings angezeigt werden?

help NUT
oder: https://fhem.de/commandref_DE.html#NUT (https://fhem.de/commandref_DE.html#NUT)

ZitatasReadings
Mit Kommata getrennte Liste der USV-Werte, die als Readings verwendet werden sollen (ups.status wird auf jeden Fall gelesen).
Beispiel:

Code Auswählen Erweitern

attr dieUSV asReadings battery.charge,battery.runtime,input.voltage,ups.load,ups.power,ups.realpower

Hast du asReadings entsprechend gesetzt?

Ja, genau so waren diese sogar bei der Initialisierung vorgegeben/vorausgefüllt

Zitat von: RitterSport am 14 Januar 2022, 14:45:43Ja, genau so waren diese sogar bei der Initialisierung vorgegeben/vorausgefüllt

Ich denke, ein list des Devices würde weiter helfen.

Danke für den Support!

list USV:

CFGFN     
   DEF        GreenCell 192.168.0.33
   DeviceName 192.168.0.33:3493
   FD         4
   FUUID      61e09b22-f33f-a22c-30a2-26963d077d3e54d7
   NAME       USV
   NR         6872
   PARTIAL   
   STATE      OL
   TYPE       NUT
   UpsName    GreenCell
   buffer     
   lastStatus OL
   pollValState 20
   READINGS:
     2022-01-15 16:04:28   battery.charge  100
     2022-01-15 16:04:28   input.voltage   236.7
     2022-01-13 23:49:39   lastError       UNKNOWN-UPS
     2022-01-15 16:04:38   state           OL
     2022-01-15 16:04:28   ups.load        3
   helper:
     battery.charge 100
     battery.voltage 13.80
     battery.voltage.high 13.00
     battery.voltage.low 10.40
     battery.voltage.nominal 12.0
     device.type ups
     driver.name blazer_usb
     driver.parameter.pollinterval 2
     driver.parameter.port auto
     driver.parameter.synchronous no
     driver.version 2.7.4
     driver.version.internal 0.12
     input.current.nominal 2.0
     input.frequency 50.1
     input.frequency.nominal 50
     input.voltage 236.7
     input.voltage.fault 236.7
     input.voltage.nominal 230
     output.voltage 236.7
     ups.beeper.status enabled
     ups.delay.shutdown 30
     ups.delay.start 180
     ups.load   3
     ups.productid 0000
     ups.status OL
     ups.type   offline / line interactive
     ups.vendorid 0001
Attributes:
   asReadings battery.charge,battery.runtime,input.voltage,ups.load,ups.power,ups.realpower
   devStateIcon OL:measure_battery_100@green (DATA-STALE|UNKNOWN-UPS|opened|disconnected):measure_battery_100@red CHRG:measure_battery_100@yellow
   disable    0
   icon       it_nas
   pollState  10
   pollVal    60
   room       System
   userReadings Realbattery.runtime:input.voltage {ReadingsVal("USV1","battery.runtime",0)/60}, Realups.load:input.voltage {(ReadingsVal("USV1","ups.load",0)/(20+(1/3)+(1/15))+(17/100))},Realpower:input.voltage {(ReadingsVal("USV1","input.voltage",0))*(ReadingsVal("USV1","Realups.load",0))}

Du musst asReading an die zur Verfügumg stehenden Parameter anpassen. Steht unter helper:
   helper:
     battery.charge 100
     battery.voltage 13.80
     battery.voltage.high 13.00
     battery.voltage.low 10.40
     battery.voltage.nominal 12.0
     device.type ups
     driver.name blazer_usb
     driver.parameter.pollinterval 2
     driver.parameter.port auto
     driver.parameter.synchronous no
     driver.version 2.7.4
     driver.version.internal 0.12
     input.current.nominal 2.0
     input.frequency 50.1
     input.frequency.nominal 50
     input.voltage 236.7
     input.voltage.fault 236.7
     input.voltage.nominal 230
     output.voltage 236.7
     ups.beeper.status enabled
     ups.delay.shutdown 30
     ups.delay.start 180
     ups.load   3
     ups.productid 0000
     ups.status OL
     ups.type   offline / line interactive
     ups.vendorid 0001

battery.runtime gibt es zum Beispiel nicht.

Danke, da war wieder DAU unterwegs und hatte sich nur darauf konzentriert das :
lastError UNKNOWN-UPS vorlag.

Die möglichen Readings habe ich angepasst in as angepasst.

Zitat von: Ma_Bo am 27 Juli 2020, 18:35:23
Des Weiteren friert FHEM (wenn der Raspberry mit NUT Server aus ist) bei jedem pollVal für 2-3 Sekunden ein, selbst wenn ich das Modul auf attr disable 1 stelle.

Jemand die selben Probleme oder ne Idee...?

Hi, ich habe das selbe Problem. Nutze den NUT Server vom QNAP NAS. Seit das ausgeschaltet (tot) ist, habe ich eine hohe fhem CPU Load. Auch bei apptime auf Platz 1. attr disable und modify Device funktionieren nicht. Nur ein Löschen des Device und Neustart des fhem Servers half bei mir.

Hallo !

Bei mir steht bei den readings bei last status "FSD OL".
Weiß jemand was das genau bedeutet?
Finde nichts im Forum.

Danke,LG

Fast discharge overload?
Google sagt: https://www.google.com/search?q=APC+fsd+ol&oq=APC+fsd+ol

Einfach weil ich mal wieder komplett begeistert bin, was mit fhem von Haus aus geht (Edit: fast vergessen, wie immer tausend Dank an den Autor):

Nachdem ich mir eine Eaton USV zugelegt habe und überhaupt keine Ahnung hatte, was man damit, außer temporär Geräte mit Strom zu versorgen, machen kann ....

Erstmal viel Recherche für recht komplexe Vorgänge. WinNUT probiert, ging nicht wirklich sauber, nut (das "Original") probiert, mmh, ganz schön komplex.

Dann das hier gefunden und in Kombi mit WOL innerhalb einer Stunde ein Setup hinbekommen, was zu 90% macht wie ich es mir vorgestellt habe.

Setup Hardware:
Klar, alles was laufen bleiben soll direkt oder über Steckerleiste an der USV (Router, Switch, Intel NUC, Raspberry-fhem, Synology)
Eaton USV (Ellipse ECO 650) via USB mit der Synology (218play oder so, bin mir nicht sicher, uralt) verbunden, Synology unter Energie -> USV eingerichtet.
In fhem, ohne irgendwas auf dem Raspi nachinstallieren zu müssen, dann folgendes definiert

RAW
define EatonUSV NUT ups IP:PORT
attr EatonUSV asReadings battery.charge,battery.runtime,battery.type,device.mfr,device.model,device.type,output.voltage.nominal,ups.beeper.status,ups.delay.shutdown,ups.firmware,ups.load,ups.power.nominal,ups.status,battery.charge.low,input.transfer.high,input.transfer.low,outlet.power
attr EatonUSV event-on-change-reading .*
attr EatonUSV group Xtender
attr EatonUSV pollState 10
attr EatonUSV pollVal 60
attr EatonUSV room Xtender
attr EatonUSV stateFormat Status: ups.status / Leistungsabgabe: ups.load % (ca. outlet.power Watt) / Pufferzeit: Verbleibende-Minuten Min
attr EatonUSV userReadings Verbleibende-Minuten { sprintf('%.1f', ReadingsNum("$NAME", "battery.runtime", 0)/60) }

#define EatonUSV_Shutdown_Raspi_DOIF DOIF ([EatonUSV:ups.status] =~ "FSD OB LB") () DOELSEIF ([EatonUSV:battery.charge] = 100)
#attr EatonUSV_Shutdown_Raspi_DOIF group System

define EatonUSV_Stromausfall_LOG1 notify EatonUSV:ups.status:OB {Log 1, "EatonUSV:Verbleibende-Minuten ".ReadingsVal("EatonUSV", "Verbleibende-Minuten", "");;Log 1, "EatonUSV:ups.status ".ReadingsVal("EatonUSV", "ups.status", "");;}
attr EatonUSV_Stromausfall_LOG1 group System

define MAIL_EatonUSV_Stromausfall_DOIF DOIF ([EatonUSV:ups.status] =~ "OB") ({DebianMail('mail@mail.com','FHEM USV Bezug - Stromausfall','Verbleibende Minuten bis shutdown bei jetzigem Verbrauch: '. ReadingsVal("EatonUSV", "Verbleibende-Minuten", "0"), '')}) DOELSEIF ([EatonUSV:state] =~ "disconnected") ({DebianMail('mail@mail.com','FHEM USV disconnected oder Synology Standby','Status: '. ReadingsVal("EatonUSV", "ups.status", "0"), '')}) DOELSEIF ([EatonUSV:ups.status] eq "OL")
attr MAIL_EatonUSV_Stromausfall_DOIF group System
attr MAIL_EatonUSV_Stromausfall_DOIF wait 60:5:0

define NUC_WOL WOL MAC IP UDP
attr NUC_WOL group System_2
attr NUC_WOL interval 60
attr NUC_WOL room System
attr NUC_WOL useUdpBroadcast IP

define Synology_WOL WOL MAC IP UDP
attr Synology_WOL group System_2
attr Synology_WOL interval 60
attr Synology_WOL room System
attr Synology_WOL useUdpBroadcast IP
Zusätzlich noch das original nut auf den Win7 Nuc gepackt, damit auch der runterfährt (könnte man auch von fhem anstoßen, aber das war mir zu kompliziert auf die Schnelle). Die Synology machts automatisch. Diese beiden Geräte lassen sich über fhem WOL bei Bedarf wieder starten.

EatonUSV_Stromausfall_LOG1 hab ich noch nicht probiert. Lasst wissen falls einer von euch ...

Einziger Schöheitsfehler ist noch, dass der Raspi hart ausgeschaltet wird wenn die USV leer ist (bei mir nach ca 35 Min). Das könnte man jetzt noch mit einem script von fhem angestoßen lösen, aber der soll bis zur letzten Sekunde laufen. Weil keine Idee wie ich den extern gestartet bekomme wenn er nicht vom Strom getrennt war und dann automatisch wieder startet.  Ich hoffe, dass das Schlimmste Vorkommnis ein nicht mehr lesbares logfile sein könnte. SD Backups gibts.

... falls es jemand gebrauchen kann ...

Hallo, habe Grade eine alte Mustek PowerMust 600 via USB am Pi angebunden.

Ist es auch möglich über Nut oder Fhem den Buzzer ein oder aus zu schalten und die USV zu Testen???

Das soll ja angeblich via RS232 oder auch am PC mit der Windows Software möglich sein.

Mfg holger

Leider habe ich das Problem wenn die USV aus ist oder die USB Verbindung gezogen wird, ist der Raspberry nicht mehr erreichbar. Er Hängt sich komplett auf.

Könnt zwar eigentlich nur vor wenn die USV leer ist oder versehentlich jemand das USB Kabel zieht. Aber ist das normal und kann das verhindert werden?

Zitat von: Tueftler1983 am 30 August 2023, 07:05:22Leider habe ich das Problem wenn die USV aus ist oder die USB Verbindung gezogen wird, ist der Raspberry nicht mehr erreichbar. Er Hängt sich komplett auf.

Das ist irgendwie nicht der Sinn einer USV. Es muss eine dauerhafte Verbindung von USB und power zwischen USV und dem NUT Server bestehen.

Das FHEM NUT Device zeigt "nur" die Daten von NUT an auf die du dann FHEM-seitig reagieren kannst.

Den Sinn einer USV kenne ich, soll ja auch so genutzt werden!

Die USV speist den Raspberry, die Fritzbox und 2 Überwachungskameras. Die USV ist via USB mit dem Raspberry verbunden auf dem FHEM und NUT läuft.
Trotzdem ist es komisch das der Raspberry einfriert wenn die USB Verbindung zur USV unterbrochen ist, auch wenn dies eig nicht vor kommt.

Zitat von: Tueftler1983 am 01 September 2023, 07:41:28Trotzdem ist es komisch das der Raspberry einfriert wenn die USB Verbindung zur USV unterbrochen ist, auch wenn dies eig nicht vor kommt.

Ich vermute, dass aus Sicht des RasPis ist die USV dann offline ist - was hast du denn in NUT konfiguriert, was dann passieren soll? Hast du mal die logs geprüft? Was gibt der RasPi auf der Console aus wenn du die USB Verbindung abziehst?

Mal eine völlig andere Frage... Ich hoffe, jemand kann mich erleuchten.
Ich betreibe seit Jahren fhem unter proxmox auf meinem Server mit einer Smart UPS 1500, die per USB verbunden ist/war - mit nut.
Leider hat sich irgendwie die Platine von der USV verabschiedet und USB lieferte nichts mehr.
Habe mir jetzt eine neue (gebrauchte) Smart UPS 1500 besorgt, die hat allerdins zusätzlich zu USB eine (Netzwerk) Management-Karte eingebaut.
Irgendwie konnte ich jetzt keine Informationen finden, wie NUT (abseits von fhem) zu konfigurieren ist, damit es per Netzwerk die USV abfrägt.
Natürlich könnte ich einfach wieder zusätzlich USB anstecken, aber irgendwie wäre mir Netzwerk sympathischer. Oder ist das so gedacht, daß die USVs (nur) per USB abgefragt werden?
Eventuell hat ja jemand einen Wink mit dem Zaunpfahl für mich?
Danke im Voraus und Cheers,
Pula

Ich kenn' diese USV nicht - und hab auf die schnelle auch keine Doku über das RJ45(?) Interface gefunden. Hast du irgendwo ein Handbuch etc, welches das Interface irgendwie beschreibt?
Weiterhin ist die Frage, ob die USV bereits einen Server zur Verfügung stellt (via Netzwerkschnittstelle), dann könntest du NUT als client laufen lassen (nut.conf (https://networkupstools.org/docs/man/nut.conf.html))
Wenn du die USV über Netzwerk monitoren können sollst (Handbuch!), dann müsste NUT das können:
- mit dem scanner (https://networkupstools.org/docs/man/nut-scanner.html) kannst du nach USVen suchen
- es gibt eine Übersicht (https://networkupstools.org/docs/man/nutupsdrv.html) der Treiber, möglicherweise ist snmp-ups (https://networkupstools.org/docs/man/snmp-ups.html) der Richtige
- da es eine APC UPS zu sein scheint, könnten auch apcupsd-ups (https://networkupstools.org/docs/man/apcupsd-ups.html) oder apcsmart (https://networkupstools.org/docs/man/apcsmart.html) funktionieren
- unter port gibst du vermutlich dann [IP][:port] an

Hi!
DANKE für den Hinweis!
das mit dem nut-scanner hat mich letzendlich auf die richtige Spur gebracht!
mit diesem eintrag in der ups.conf tut es jetzt (Abfrage per SNMP, das ich im Web-Interface der USV aktiviert habe):

[apckeller]
        driver = snmp-ups
        mibs = apcc
        port = 192.168.1.25
        community = public
        snmp_version = v1
        pollfreq = 15
        desc = "apckeller"

Unter debian muss dafür zumindest das paket nut-snmp installiert werden.
Und schon is die USV auch in fhem wieder da - und ich kann das automatische poweroff auf dem Server einstellen...
Danke nochmal für den Hinweis!
Cheers,
Pula