Als FHEM-Neuling habe ich mein erstes Modul geschrieben: APCUPSD.
Das Modul dient der Abfrage von USV-Daten (Unterbrechungsfreie Stromversorgung) über den APCUPSD-Dienst (www.apcupsd.com).
Zwar stellt NUT samt zugehörigem FHEM-Modul einen ähnlichen (generischen) Dienst bereit, da ich aber durchgehend auf allen Systemen direkt APUPSD samt den zugehörigen Wartungs- und GUI-Tools einsetze will ich ungern darauf zurückgreifen - zumal NUT intern eigene Berechnungen durchführt die sich mir nicht erschließen.
Das Modul kann alle USV-Parameter als Readings (konfigurierbar) zur Verfügung stellen.
Dazu zählen beispielsweise die Temperatur, der Akkuladestand, Ein- und Ausgangsspannungen, die Systemlast, der USV-Status usw.
Bei mir läuft das Modul auf einem Raspberry Pi mit insgesamt 3 verschiedenen APC USV-Systemen wovon zwei direkt per USB und eins über einen FTDI-USB-RS232-Wandler per Host-gespeistem Hub angeschlossen sind.
Bei der Entwicklung habe ich mich an diversen anderen offiziellen FHEM-Modulen und der für mich auffindbaren Dokumentation zu diesem Thema orientiert.
Ich hoffe das Modul ist mir einigermaßen Regelkonform gelungen...
Eine englische und deutsche Dokumentation ist enthalten.
Für jegliche Rückmeldungen, Verbesserungshinweise, Anmerkungen, Bugfixes usw. bin ich sehr dankbar!
Insbesondere wäre ich für Informationen dankbar wie man ein solches Modul offiziell zur FHEM-Distribution hinzufügt.
Hallo
Ich hab einen NUC mit Ubunte Server Installation.
Der NUC, eine Fritzbox, ein Lan Switch, ein HM-Lan Adapter und ein Synology NAS.
Das Nas ist aber eigentlich immer aus.
Es ist ein APC Back-UPS ES 550.
Kann ich das UPS per USB Datenkabel an den Nuc anschliessen.
Dann nach dieser Anleitung Installieren:
http://blog.is-a-geek.org/konfiguration-einer-apc-backup-ups-auf-ubuntu-serverdesktop (http://blog.is-a-geek.org/konfiguration-einer-apc-backup-ups-auf-ubuntu-serverdesktop)
Auf den Nuc greife ich nur per SSH.
Da kann ich die Instalation von Nano wohl weglassen?
Kann dein Modul den NUC bei kritischem Akku runterfahren?
Ist zwar blöd da bleibt er dann aber auch wenn der Strom wieder da ist.
Das eigentliche Herunterfahren der Systeme macht APCUPSD selbst - wenn es richtig konfiguriert ist.
Das FHEM-Modul stellt nur die APCUPSD-Readings in FHEM bereit.
Hallo
Hab das Modul mal installiert.
Geht soweit.
Ein log für den Betrieb, oder nur für den Akkubetrieb.
Oder eine Alarmmeldung bei Stromausfall.
Sollte damit möglich sein.
Hallo.
Habe das Modul auch auf meinem Solaris 11.2 Hauptserver installiert auf dem auch FHEM läuft.
Dort ist das opencsw Package von apcupsd installiert.
Nach dem Lesen des Moduls konnte ich es zum Laufen bekommen.
Ein
ln -s /opt/csw/sbin/apcaccess /sbin/apcaccess
macht auch Fhem das Vorhandensein des APCUPSD Packages bekannt.
Vielen Dank.
Gruss
Zitat von: premultiply am 22 Juni 2015, 11:49:09
Als FHEM-Neuling habe ich mein erstes Modul geschrieben: APCUPSD.
Das Modul dient der Abfrage von USV-Daten (Unterbrechungsfreie Stromversorgung) über den APCUPSD-Dienst (www.apcupsd.com).
Zwar stellt NUT samt zugehörigem FHEM-Modul einen ähnlichen (generischen) Dienst bereit, da ich aber durchgehend auf allen Systemen direkt APUPSD samt den zugehörigen Wartungs- und GUI-Tools einsetze will ich ungern darauf zurückgreifen - zumal NUT intern eigene Berechnungen durchführt die sich mir nicht erschließen.
Als Autor von NUT möchte ich da noch kurz was dazu sagen.
Zum einen war das auch für mich das erste Modul - USVs wurden anscheinend bisher sträflich vernachlässigt. ;)
Zum anderen macht NUT keine internen Berechnungen mehr - das hab ich wieder rausgeschmissen, nachdem ich festgestellt habe, dass das mit dem Attribut
userReadings viel besser geht.
Jetzt kann man also aussuchen, ob man die USV per apcupsd oder NUT ausliest. Ich liebe offene Systeme. :D
Hab Heute volgendes im Log:
Zitat2015.08.16 18:02:18 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/34_APCUPSD.pm line 142.
Ich vermute mal es ist via asReadings ein Wert eingetragen den APCUPSD (temporär?) nicht liefert(e)?
Funktioniert einwandfrei, danke für das Modul 8)
Hallo premultiply,
danke für das Modul!
Würde mich freuen, wenn du es als "reguläres" Modul in FHEM bringen würdest. 8)
Gruß Benni.
Klasse Modul. Danke. Klappt auch bei mir. War nur durch den Screenshot irritiert, da dort Port 3552 steht.
Für ein einchecken dieses Moduls wäre ich auch sehr dafür.
Wie du das allerdings machst, weiß ich nicht so genau. Ich denke da musst du dich im Developer Bereich umschauen.
Gibt es eigentlich noch mehr Readings die man von der USV auslesen könnte? Ich habe bspw eine APC BR900G (http://www.amazon.de/gp/product/B006VWYD40?psc=1&redirect=true&ref_=oh_aui_detailpage_o08_s00)
Wenn du list <devicename> in FHEM eingibst zeigt es alle Werte an die von deiner USV via APCUPSD bereitgestellt werden. Mittels asReadings kannst du sie dann ggf. auswerten.
Das steht auch in der Modulhilfe ausführlich beschrieben.
Ich habe da auch mal eine Frage dazu.
Wird das Module noch irgendwann eingecheckt und wird dazu ein Wiki Beitrag geschrieben?
Wird das Modul noch erweitert z.B. Möglichkeit zus Steuerung der USV?
Wenn mir einer sagt wie das geht, gerne.
Welche Steuermöglichkeiten für die USV vermisst du?
Hoffe es liest hier einer noch mit der sagen kann wie man es in eincheckt.
Direkt vermissen tue ich mal nix war nur Neugierig und direkt einfallen tut mir auch erstmal noch nix da ich noch auf meine USV warte.
Ich habe da aber schon mal ne Frage ob ich das richtig verstanden habe.
Ich muss zuerst APCUPSD Installieren und einrichten auf dem Raspberry und anschließend kann ich dann mit dem Modul die Daten auslesen?
Angeschlossen wird dabei die USV per USB an den Raspberry soweit richtig?
Nun habe ich wen ich das bis dato alles richtig verstanden habe eine Frage.
ich habe eine APC Smart UPS SMT750I und mir dazu eine APC Network ManagementCard AP9619 gekauft um die USV im LAN Netzwerk einbinden zu können.
Ist es nun irgendwie und wen ja wie möglich die USV in FHEM einzubinden und alle live Daten auszulesen wen ich sie im LAN Netzwerk habe?
Moin,
https://forum.fhem.de/index.php/topic,18962.0.html
Greetz
Eldrik
Welches Protokoll die APC Netwerkkarten sprechen kann ich dir momentan nicht sagen.
Habe selber darauf verzichtet und bei mir mehrere USV via USB und Seriell auf einem RasPi für gesamte Netzwerk gebündelt.
Allerdings ist es grundsätzlich so, dass APCUPSD als Server fungiert. D.h. mit entsprechender Konfiguration können andere Rechner im Netz mittels APCUPSD auf beliebige USV-Einheiten zugreifen.
APCUPSD spricht mit lokal angeschlossenen USV-Einheiten (z. B. per seriell oder USB) oder aber auch mit solchen die selbst über eine APC-Netzwerkkarte verfügen oder aber auch mit anderen APCUPSD-Instanzen im Netzwerk.
Das Modul spricht direkt mit je einer APCUPSD-Instanz. Diese muss auch nicht zwangsläufig auf dem gleichen System wie FHEM laufen. Es werden nur Teile des APCUPSD-Gesamtpakets, genauer das Tool apcaccess, für die Kommunikation zwischen Modul und Dienst benötigt.
Hallo,
hab das Modul auch ausprobiert, läuft (SMART-UPS 1000 RM)! Aber dein Screenshot ist ja nett, sind deine Batterien wirklich seit 2004 drin ?!?!
/Daniel
Witzig, ist mir bisher nie aufgefallen dass das Akkutauschdatum bei der USV nie zurückgesetzt wurde.
Wenn sie aber nicht öfter benutzt werden oder der Entladestrom recht gering und die Umgebungstemperatur niedrig ist halten die Akkus aber schon ein paar Jährchen durch.
Also kurzes Feedback leider passt die Smart Slot Karte AP9619 nicht in die USV die neuen APC USVs haben einen ein klein wenig anderen Slot so das man für diese nun neue karten benötigt...
Habe das ganze jetzt per USB an einen Raspberry angeschlossen damit geht es.
Ich habe nun noch eine Frage.
Hast du noch vor das Module offiziell in FHEM einzuchecken würde mich sehr freuen wen du das noch machen würdest und einen kurzen Wiki Artikel dazu verfasst damit es Hand und Fuß hat. :)
Hallo Zusammen,
ich habe eine APC-USV via USB an einen Win 7 Server angeschlossen. Auf dem Server läuft auch eine fhem Instanz (mit fhem2fhem verbunden).
Gibt es eine Möglichkeit, mit fhem auf Windows über das APCUPSD -Modul auf die USV zuzugreifen?
LG
Jorge
Es reicht wenn du auf dem Windows-System APCUPSD als Dienst installierst und entsprechend konfigurierst (Lokale USB-USV mit Netzwerkfreigabe).
Dann kannst du mittels des FHEM-Moduls und der APCUPSD-Installation auf dem FHEM-Server (bzw. genauer dessen apcaccess-Tool) auf den APCUPSD-Dienst auf dem Windows-System zugreifen.
Alternativ kannst du das FHEM-Modul auch so modifizieren (Dateipfad editieren) dass es apcaccess.exe unter Windows findet und aufruft.
Der Rest sollte identisch und Plattformunabhängig sein.
Das FHEM-Modul findest du unter https://github.com/premultiply/fhem-modules/blob/master/FHEM/34_APCUPSD.pm (https://github.com/premultiply/fhem-modules/blob/master/FHEM/34_APCUPSD.pm). Patches/Pull Requests sind willkommen.
Zitat von: premultiply am 14 Juni 2016, 18:23:43
Es reicht wenn du auf dem Windows-System APCUPSD als Dienst installierst und entsprechend konfigurierst (Lokale USB-USV mit Netzwerkfreigabe).
Dann kannst du mittels des FHEM-Moduls und der APCUPSD-Installation auf dem FHEM-Server (bzw. genauer dessen apcaccess-Tool) auf den APCUPSD-Dienst auf dem Windows-System zugreifen.
...
Danke für den Hinweis.
Habe jetzt das APCUPSD-Paket auf dem Windows-Server installiert. Funktionierte auf Anhieb ohne große Änderungen im Script. Den apcaccess Client für Windows habe ich probiert, funktioniert im Windows-fhem nach Änderung des Installationspfades. Noch besser: Habe auch auf dem RPI APCUPSD installiert, aber den Server nicht aktiviert, und in APCUPSD.pm den apcaccess Client mit dem Windows APCUPSD Server verbunden. Und das upsstats.cgi mit einem Weblink eingebunden (Auf dem Windows-Server läuft auch ein Apache Webserver). So habe ich in fhem volle Kontrolle über die Server-USV.
LG
Jorge
upsstats.cgi
Sag mal wie lange halten die Akkus bei euch so?
BATTDATE : 30/09/13
Und heute hat sie das erste mal den wöchentlichen Test nicht mehr bestanden. Ist bei mir immer so ziemlich genau 3 Jahre was die Akkus halten.
/Daniel
Das ist nicht sonderlich lange aber noch im normaler Haltbarkeitsbereich.
Die mögliche Nutzungsdauer hängt von vielen Faktoren ab.
Da wäre zunächst die Qualität des Akkus selber und seine grundsätzliche Eignung für den USV-Betrieb (sehr hohe Entladeströme!)
Weitere Faktoren sind die Umgebungstemperatur sowie die Anzahl der, die Dauer von und die Strombelastung während der Entladevorgänge.
Soll heißen: Läuft die USV mit hoher Last und in gut geheizter Ungebung regelmäßig auf Akkubetrieb ist das derAkku-Lebensdauer nicht sonderlich zuträglich.
Hallo premultiply,
ich nutze seit kurzem dein Modul, welches sehr gut funktioniert - danke hierfür!
Eine Frage: Im Log stehen regelmäßig PERL WARNINGS:
2016.10.22 11:31:52 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/34_APCUPSD.pm line 142, <$fh> line 145.
Kannst du bitte bei Gelegenheit mal prüfen ob du das korrigieren kannst?
Danke im Voraus und Grüße
Franco
Ich vermute mal du hast bei asReadings entweder keine Angaben gemacht und/oder dort Werte drin stehen die deine USV nicht liefert.
Kannst du mal ein "list <DEVICE>" machen und die Antwort hier posten?
Hi premultiply,
danke für deine Antwort - anbei ein list <device>
Internals:
BATTDATE 2016-04-15
CFGFN ./FHEM/00_myDevices.cfg
DEF 60 localhost:3551
HOST localhost:3551
INTERVAL 60
LOWBATT 20
MODEL Back-UPS ES 700G
NAME UsvWz
NR 95
SERIALNO 5B1615T46986
STATE ONLINE - BATTERY: ok L: 0 M: 38.4
TYPE APCUPSD
Readings:
2016-10-25 14:36:41 battery ok
2016-10-25 14:36:41 battv 13.6
2016-10-25 14:36:41 bcharge 100
2016-10-25 14:36:41 lastxfer Automatic or explicit self test
2016-10-25 14:36:41 linev 236
2016-10-25 14:36:41 loadpct 0
2016-10-25 14:36:41 state ONLINE
2016-10-25 14:36:41 timeleft 38.4
Helper:
ALARMDEL No alarm
APC 001,036,0943
BATTDATE 2016-04-15
BATTV 13.6 Volts
BCHARGE 100.0 Percent
CABLE USB Cable
CUMONBATT 11 Seconds
DATE 2016-10-25 14:36:07 +0200
DRIVER USB UPS Driver
END APC 2016-10-25 14:36:41 +0200
FIRMWARE 871.O4 .I USB FW:O4
HITRANS 266.0 Volts
HOSTNAME PI3-JESSIE
LASTSTEST 2016-10-14 15:40:09 +0200
LASTXFER Automatic or explicit self test
LINEV 236.0 Volts
LOADPCT 0.0 Percent
LOTRANS 180.0 Volts
MAXTIME 0 Seconds
MBATTCHG 5 Percent
MINTIMEL 3 Minutes
MODEL Back-UPS ES 700G
NOMBATTV 12.0 Volts
NOMINV 230 Volts
NUMXFERS 1
SENSE High
SERIALNO 5B1615T46986
STARTTIME 2016-10-03 22:28:39 +0200
STATFLAG 0x05000008
STATUS ONLINE
TIMELEFT 38.4 Minutes
TONBATT 0 Seconds
UPSMODE Stand Alone
UPSNAME PI3-JESSIE
VERSION 3.14.12 (29 March 2014) debian
XOFFBATT 2016-10-14 15:40:20 +0200
XONBATT 2016-10-14 15:40:09 +0200
Attributes:
alias WzMMediaUSV
asReadings BATTV,BCHARGE,LINEV,LOADPCT,TIMELEFT,LASTXFER
group OTHER
icon measure_battery_100
room INFO,Devices
stateFormat state - BATTERY: battery L: loadpct M: timeleft
verbose 0
Kannst du hieraus ein Fehler von mir erkennen? Soweit ich sehe habe ich asReadings gesetzt...
Viele Grüße
Franco
Bei mir kommt auch der fehler
PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/34_APCUPSD.pm line 142.
Und hier gleich das list dazu
Internals:
DEF 120 localhost
HOST localhost:3551
INTERVAL 120
LOWBATT 20
MODEL Smart-UPS 750
NAME USV
NR 368
SERIALNO 3S1540X02058
STATE ONLINE
TYPE APCUPSD
Readings:
2016-11-19 07:24:59 battery ok
2016-11-19 07:24:59 battv 27.1
2016-11-19 07:24:59 bcharge 100
2016-11-19 07:24:59 state ONLINE
2016-11-19 07:24:59 timeleft 127
Helper:
ALARMDEL 30 seconds
APC 001,027,0684
BATTV 27.1 Volts
BCHARGE 100.0 Percent
CABLE USB Cable
CUMONBATT 0 seconds
DATE 2016-11-19 07:24:30 +0100
DRIVER USB UPS Driver
END APC 2016-11-19 07:24:59 +0100
FIRMWARE UPS 09.3 / ID=18
HOSTNAME raspberrypi
MANDATE 2015-09-30
MAXTIME 0 Seconds
MBATTCHG 5 Percent
MINTIMEL 3 Minutes
MODEL Smart-UPS 750
NOMBATTV 24.0 Volts
NUMXFERS 0
SERIALNO 3S1540X02058
STARTTIME 2016-11-16 17:16:46 +0100
STATFLAG 0x07000008 Status Flag
STATUS ONLINE
TIMELEFT 127.0 Minutes
TONBATT 0 seconds
UPSMODE Stand Alone
UPSNAME raspberrypi
VERSION 3.14.10 (13 September 2011) debian
XOFFBATT N/A
Attributes:
asReadings BATTV,BCHARGE,LINEV,LOADPCT,OUTPUTV,TIMELEFT,LASTXFER
room Keller
Woran könnte das liegen?
Es wurden per asReadings (Default)Werte angegeben die die angeschlossene USV offensichtlich nicht liefert.
Einfach manuell nur verfügbare Werte per asReadings angeben und schon sollte die Fehlermeldung verschwinden.
Habe es jetzt angepasst das nur noch das drin steht was auch wirklich von der usv kommt.
Habe aber noch immer eine Warnung
PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/34_APCUPSD.pm line 142, <$fh> line 1813.
Wie kann das sein ein list sieht jetzt so aus
Internals:
DEF 120 localhost
HOST localhost:3551
INTERVAL 120
LOWBATT 20
MODEL Smart-UPS 750
NAME USV
NR 368
SERIALNO 3S1540X02058
STATE ONLINE
TYPE APCUPSD
Readings:
2016-11-21 09:46:45 battery ok
2016-11-21 09:46:45 battv 27.1
2016-11-21 09:46:45 bcharge 100
2016-11-21 09:46:45 state ONLINE
2016-11-21 09:46:45 timeleft 127
Helper:
ALARMDEL 30 Seconds
APC 001,027,0667
BATTV 27.1 Volts
BCHARGE 100.0 Percent
CABLE USB Cable
CUMONBATT 0 Seconds
DATE 2016-11-21 09:46:36 +0100
DRIVER USB UPS Driver
END APC 2016-11-21 09:46:45 +0100
FIRMWARE UPS 09.3 / ID=18
HOSTNAME raspberrypi
MANDATE 2015-09-30
MAXTIME 0 Seconds
MBATTCHG 5 Percent
MINTIMEL 3 Minutes
MODEL Smart-UPS 750
NOMBATTV 24.0 Volts
NUMXFERS 0
SERIALNO 3S1540X02058
STARTTIME 2016-11-20 18:23:01 +0100
STATFLAG 0x05000008
STATUS ONLINE
TIMELEFT 127.0 Minutes
TONBATT 0 Seconds
UPSMODE Stand Alone
UPSNAME raspberrypi
VERSION 3.14.12 (29 March 2014) debian
XOFFBATT N/A
Attributes:
asReadings BATTV,BCHARGE,TIMELEFT
comment LASTXFER,LINEV,OUTPUTV,LOADPCT
room Keller
Gruß
Dennis
Ich habe leider gerade keine weitere Idee mehr woher die Meldung kommt.
Leider kann ich das nicht testen/nachvollziehen da bei meinen 3 USV-Systemen dies nicht auftaucht.
Probleme sollte es dadurch aber nicht geben.
Zitat von: Blablubblaber am 21 November 2016, 09:49:00
Habe aber noch immer eine Warnung
PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/34_APCUPSD.pm line 142, <$fh> line 1813.
Ich würde die Zeile 142 so ergänzen:
$hash->{helper}{$_} =~ m/^([\-\d\.]*)(.*)$/ if ($hash->{helper}{$_});Dann dürfte die Perl Warnung nicht mehr kommen und es dürfte auch keinen Einfluss auf den weiteren Programmablauf haben.
Gruß
Dan
Achso, ohne das Modul bisher zu benutzen ist mir beim Überfliegen des Codes aufgefallen dass das Modul blockierend arbeitet.
Ich empfehle das Modul auf DevIo zu erweitern um es non-blocking zu machen.
Bei einem offiziellem Check-In ins FHEM Repo sollte es möglichst auch non-blocking sein. 8)
Verstehe mich bitte nicht falsch, ich finde es toll dass es Leute wie Dich und mich gibt die in ihrer Freizeit Sachen für die Community bereitstellen.
Das Modul ist für den ersten Versuch toll, nur eben noch ausbaufähig... 8)
Gruß
Dan
P.S. Bin nur auf das Modul aufmerksam geworden weil ich selbst gerade eine APC UPS bestellt habe und die dann auch in FHEM einbinden will.
Hi zusammen,
ich habe den Vorschlag von Dan mal getestet mit folgendem Ergebnis:
PERL WARNING: Use of uninitialized value $1 in numeric gt (>) at ./FHEM/34_APCUPSD.pm line 143.
Scheint leider noch nicht die Lösung zu sein...
Grüße
Franco
Also bei mir besteht der Fehler weiterhin.
Was mir auch aufgefallen ist wen ich das Modul öffne dann friert FHEM für ein paar Sekunden ein bis es offen ist.
Ist das wegen dem von @DeeSPe angesprochenen non-blocking?
Gruß
Dennis
Zitat von: Blablubblaber am 05 Dezember 2016, 09:30:48
Was mir auch aufgefallen ist wen ich das Modul öffne dann friert FHEM für ein paar Sekunden ein bis es offen ist.
Ist das wegen dem von @DeeSPe angesprochenen non-blocking?
Kann ich mir kaum vorstellen, da im normalfall keine Aufrufe getätigt werden die FHEM ernsthaft blockieren. Der Datenabruf mittels apcaccess erfolgt initial und dann nur noch über einen Timer.
Ich betreibe dies bei mir selbst mit 3 größeren USV-Systemen und vielen anderen Geräten ohne solche Probleme.
Es könnte aber durchaus sein, dass z. B. mit deiner APCUPSD-Konfiguration grundsätzlich etwas nicht stimmt und dieses somit in irgendein Timeout läuft beim Datenabruf.
Wenn du auf der Konsole apcaccess ausführst sollte sofort eine Antwort kommen. Nichts anderes ruft das Modul auf.
Habe übers Wochenende FHEM einmal komplett neu aufgesetzt und es seitdem nicht nochmal probiert gehabt bevor ich das gerade geschrieben habe (sry).
Habe es nachdem Post von dir nochmal ausprobiert und muss sagen das das Problem weg ist.
Es muss wirklich an irgend einer Konfiguration gelegen haben.
Aber das Problem mit der Perl Fehlermeldung im Log nach einem neustart von FHEM bleibt bestehen.
Hallo,
schade dass das Modul noch nicht eingecheckt ist ;) :-[ :-X :'(
Hallo premultiply,
ich stelle mich mit an. Kurze Zwischenfrage: Braucht Dein Modul dden Apache CGI Webserver?
Dank und Grüße
Jörg
Hallo zusammen,
ich hatte das Problem, dass in den Helpers die Daten zwar korrekt angezeigt wurden, die Readings aber verkrüppelt waren:
xoffbatt: 2017
Das sollte eigentlich ein vollständiges Datum sein, so wie hier:
xoffbatt: 2017-09-27 13:42:06 +0200
Auf der Suche nach der Lösung bin ich auf Code im 34_APCUPSD Modul gestoßen, welches (vermutlich) die Einheiten der Readings entfernen soll, leider entfernt das mehr, als eigentlich nötig.
Eine Lösung war dann (für mein System) schnell gefunden:
Meine Version von /sbin/apcaccess (apcupsd-3.14.13) unterstützt den Parameter '-u', der die Units entfernt.
Folgender kleiner Patch löst für mich das o.a. Problem:
--- fhem/FHEM/34_APCUPSD.pm
+++ fhem/FHEM/34_APCUPSD.pm
@@ -97,7 +97,7 @@ sub APCUPSD_RetrieveData($) {
my $name = $hash->{NAME};
my ($cmd, $val);
- $cmd = $apcaccess." status ".$hash->{HOST}." 2>&1";
+ $cmd = $apcaccess." -u status ".$hash->{HOST}." 2>&1";
$val = `$cmd`;
if ( $val =~ m/^Error/ | ! length($val) ) {
@@ -139,12 +139,7 @@ sub APCUPSD_RetrieveData($) {
foreach (split (',', $attr{$name}{asReadings})) {
s/^\s+//;
s/\s+$//;
- $hash->{helper}{$_} =~ m/^([\-\d\.]*)(.*)$/;
- if ( length($1) > 0 ) {
- readingsBulkUpdate($hash, lc($_), 0+$1) if defined $hash->{helper}{$_};
- } else {
- readingsBulkUpdate($hash, lc($_), $2) if defined $hash->{helper}{$_};
- }
+ readingsBulkUpdate($hash, lc($_), $hash->{helper}{$_}) if defined $hash->{helper}{$_};
}
readingsEndUpdate($hash, 1);
Da ich ungerne verschieden Versionen des Moduls im Umlauf haben möchte, hänge ich keine vollständige neue 34_APCUPSD.pm an, könnte das aber machen, wenn Interesse besteht.
LG
Christian
ich habe eine APC USV per USB an meiner Synology angeschlossen. Dort den USV Server Aktiv. Kann ich mit dem Modul nun was machen ?
Gibt es Alternativen zu diesem Modul?
@ChrisW: das geht mit dem NUT modul.
Zitat von: justme1968 am 28 Dezember 2017, 12:44:56
@ChrisW: das geht mit dem NUT modul.
Also installiere ich wohl doch auch besser unter Debian nicht nur APCUPSD sondern auch das NUT. Hat jemand mal Powerchute ausprobiert?
ob du nut oder apcupsd verwendest hängt von der usv ab die du verwendest. und wie weit du netzwerk fähig sein willst.
meine antwort bezog sich auf die kombination mit der synology.
die usv hängt dort an der synology, diese kann den status per nut an andere clients weiter geben. da bietet sich das nut modul an-
Die APC läuft bei mir nun via ESXI unter FreeNAS, da ist NUT schon installiert.
wenn du nut verwendest solltest du vermutlich auch das NUT modul verwenden.
Hallo,
wo kann man das Modul runterladen?
Und wie muss ich es installieren?
Oder ist das Projekt gestorben?
Schöne Grüße
ThomasDr
Hi,
im ersten Post des Threads.
LG
Zitat von: choenig am 22 Juni 2018, 22:44:11
im ersten Post des Threads.
Hallo,
danke, wahrscheinlich hab ich es nicht gesehen weil ich nicht angemeldet war und mich erst zum Antworten eingeloggt habe.
Schöne Grüße
ThomasD
Hallo, danke für das Script. Eine Frage. Kann man das ins offizielle Repository mit reinnehmen oder erfüllt das Skript nicht die kritierien?
Hallo,
auch danke für das Scipt funktioniert problemlos bei mir.
Die Frage wieso dieses Modul es nicht ins offizielle FHEM geschafft hat stellt sich mir allerdings auch.
Gruß
Patrick
Zitat von: neo_owl am 18 August 2019, 15:18:46
Die Frage wieso dieses Modul es nicht ins offizielle FHEM geschafft hat stellt sich mir allerdings auch.
Wieso, 34_APCUPSD.pm ist doch standardmäßig vorhanden unter /opt/fhem/FHEM nach Installation. Damit ist es doch "offiziell", oder irre ich damit?
Das module ist kein Standard von Fhem. Muss per Hand installiert werden.
Ist der Entwickler noch aktiv? Würde dass sonst gerne übernehmen.
Gruß Florian
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: Florian_GT am 14 Januar 2020, 01:29:35
Das module ist kein Standard von Fhem. Muss per Hand installiert werden.
Ist der Entwickler noch aktiv? Würde dass sonst gerne übernehmen.
Gruß Florian
Gesendet von meinem MI 9 mit Tapatalk
premultiply hat sich Oktober 2019 das letzte mal eingeloggt. Schwierig zu sagen, aber das ist schon eine lange Zeit. Schreib' ihn doch direkt an - einen aktiven Maintainer für das Modul begrüße ich, auch wenn es "tut was es soll".
Ist die Sache mit dem Maintainer eigentlich zwischenzeitlich geklärt?
Ich habe nämlich wegen einer anderen Geschichte zur Zeit stacktrace laufen und erhalte regelmäßig diese Meldungen:
2020.05.09 13:45:05 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/34_APCUPSD.pm line 142.
2020.05.09 13:45:05 1: stacktrace:
2020.05.09 13:45:05 1: main::__ANON__ called by ./FHEM/34_APCUPSD.pm (142)
2020.05.09 13:45:05 1: main::APCUPSD_RetrieveData called by ./FHEM/34_APCUPSD.pm (163)
2020.05.09 13:45:05 1: main::APCUPSD_PollTimer called by fhem.pl (3313)
2020.05.09 13:45:05 1: main::HandleTimeout called by fhem.pl (676)
Zitat von: JWRu am 09 Mai 2020, 13:55:46
Ist die Sache mit dem Maintainer eigentlich zwischenzeitlich geklärt?
Ich habe nämlich wegen einer anderen Geschichte zur Zeit stacktrace laufen und erhalte regelmäßig diese Meldungen:
2020.05.09 13:45:05 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/34_APCUPSD.pm line 142.
2020.05.09 13:45:05 1: stacktrace:
2020.05.09 13:45:05 1: main::__ANON__ called by ./FHEM/34_APCUPSD.pm (142)
2020.05.09 13:45:05 1: main::APCUPSD_RetrieveData called by ./FHEM/34_APCUPSD.pm (163)
2020.05.09 13:45:05 1: main::APCUPSD_PollTimer called by fhem.pl (3313)
2020.05.09 13:45:05 1: main::HandleTimeout called by fhem.pl (676)
2020.12.19 12:24:57 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/34_APCUPSD.pm line 142.
2020.12.19 12:24:57 1: stacktrace:
2020.12.19 12:24:57 1: main::__ANON__ called by ./FHEM/34_APCUPSD.pm (142)
2020.12.19 12:24:57 1: main::APCUPSD_RetrieveData called by ./FHEM/34_APCUPSD.pm (163)
2020.12.19 12:24:57 1: main::APCUPSD_PollTimer called by ./FHEM/98_apptime.pm (178)
2020.12.19 12:24:57 1: main::apptime_getTiming called by ./FHEM/98_apptime.pm (86)
2020.12.19 12:24:57 1: main::HandleTimeout called by fhem.pl (677)Die gleiche Meldung gibt mir stacktrace (in kombinierter Verwendung mit Apptime) auch im Sekundentakt ins Logfile. Gibt es hier schon etwas neues zur Weiterentwicklung?
Vielleicht passt ja das hier https://forum.fhem.de/index.php/topic,118946.0.html
Auch mir fallen die Meldungen im Log auf.
am FHEM mit ner kleinen Back-UPS XS 700U habe ich Zwei Zeilen im Log nach Neustart:
2021.02.22 08:04:22 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/34_APCUPSD.pm line 142, <$fh> line 454.
2021.02.22 08:05:22 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/34_APCUPSD.pm line 142.
am FHEM mit der "großen" Smart-UPS RT 2000 RM XL gibt es nur eine Log Zeile nach Neustart:
2021.02.22 08:19:31 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/34_APCUPSD.pm line 142.
Es sind nur Warnings, klar. und es läuft auch alles. dennoch sollte man das doch mal angehen?
Der Verfasser des Moduls war leider sein Anfang Dezember nicht mehr hier.
Guten Tag,
meine APC ist über einen NIC vom Typ AP9630 angebunden.
D.h., die Infos bekommt man via Webinterface.
Gibt es hierfür schon ein FHEM Modul?
Hallo zusammen,
mich haben die Meldungen im Log und insbesondere bei stacktrace schon länger geärgert.
Ich habe hier 2 Stück Back-UPS ES 700G in Betrieb und bei stacktrace=1 diese Meldung im Log:
2021.07.14 14:03:58 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/34_APCUPSD.pm line 142.
2021.07.14 14:03:58 1: stacktrace:
2021.07.14 14:03:58 1: main::__ANON__ called by ./FHEM/34_APCUPSD.pm (142)
2021.07.14 14:03:58 1: main::APCUPSD_RetrieveData called by ./FHEM/34_APCUPSD.pm (163)
2021.07.14 14:03:58 1: main::APCUPSD_PollTimer called by fhem.pl (3425)
2021.07.14 14:03:58 1: main::HandleTimeout called by fhem.pl (696)
Die Lösung zur Beseitigung der Meldungen liefert das Modul selbst (Device specific help), habe es aber auch jetzt erst nach gefühlten Jahren gelesen.
Mit dem simplen Befehl list <device> bekommt man im list u.a. eine Aufstellung der unterstützen Readings, bei mir:
helper:
ALARMDEL 30 Seconds
APC 001,036,0943
BATTDATE 2018-11-17
BATTV 13.6 Volts
BCHARGE 100.0 Percent
CABLE USB Cable
CUMONBATT 180 Seconds
DATE 2021-07-14 14:13:03 +0200
DRIVER USB UPS Driver
END APC 2021-07-14 14:13:57 +0200
FIRMWARE 871.O4 .I USB FW:O4
HITRANS 266.0 Volts
HOSTNAME nobby-rasp
LASTSTEST 2021-07-05 21:26:21 +0200
LASTXFER Automatic or explicit self test
LINEV 230.0 Volts
LOADPCT 6.0 Percent
LOTRANS 180.0 Volts
MAXTIME 0 Seconds
MBATTCHG 10 Percent
MINTIMEL 3 Minutes
MODEL Back-UPS ES 700G
NOMBATTV 12.0 Volts
NOMINV 230 Volts
NUMXFERS 11
SENSE Medium
SERIALNO 5B1846T47554
STARTTIME 2021-02-13 12:17:08 +0100
STATFLAG 0x05000008
STATUS ONLINE
TIMELEFT 31.1 Minutes
TONBATT 0 Seconds
UPSMODE Stand Alone
UPSNAME USV_2
VERSION 3.14.14 (31 May 2016) debian
XOFFBATT 2021-07-05 21:26:31 +0200
XONBATT 2021-07-05 21:26:21 +0200
Standardmäßig wird bei der Definition des Moduls mit angelegt:
Attributes:
asReadings BATTV,BCHARGE,LINEV,LOADPCT,OUTPUTV,TIMELEFT,LASTXFER
Ein Vergleich mit den unter helper aufgeführten readings zeigt, dass das reading "OUTPUTV" von diesem Model nicht untertützt wird.
Also kurzerhand das Attribut angepasst zu
attr <device> asReadings BATTV,BCHARGE,LINEV,LOADPCT,TIMELEFT,LASTXFER
und schon sind die Warnungen im Log bei aktiviertem stacktrace Geschichte.
Norbert
Hallo, auch wenn das ein älteres Modul ist hoffe ich dass sich da jemand mit PERL-Kenntnissen dazu äußern kann.
Das Modul ansich funktioniert.
Allerdings werden bei mir bei einigen Readings nur die ersten Teile angezeigt.
Also z.B. bei XONBATT wird nur "2022" statt "2022-01-22 17:22:57 +0100"
Hier wird also irgendwo im Code beim "-" abgeschnitten und das übersteigt meine PERL-Kenntnisse.
Internals:
BATTDATE 2021-11-26
CFGFN
DEF 60 192.168.30.2
FUUID 61f02642-f33f-5588-816d-49f6b84276cd48d1
HOST 192.168.30.2:3551
INTERVAL 60
LOWBATT 20
MODEL Back-UPS RS 1200G
NAME BackUPC
NR 368886
SERIALNO 3B1303X09312
STATE ONLINE
TYPE APCUPSD
READINGS:
2022-01-25 18:10:07 battery ok
2022-01-25 18:10:07 battv 27.2
2022-01-25 18:10:07 bcharge 100
2022-01-25 18:10:07 laststest 2022
2022-01-25 18:10:07 lastxfer Automatic or explicit self test
2022-01-25 18:10:07 linev 231
2022-01-25 18:10:07 loadpct 12
2022-01-25 18:10:07 state ONLINE
2022-01-25 18:10:07 timeleft 71.5
2022-01-25 18:10:07 xonbatt 2022
helper:
ALARMDEL No alarm
APC 001,037,0968
BATTDATE 2021-11-26
BATTV 27.2 Volts
BCHARGE 100.0 Percent
CABLE USB Cable
CUMONBATT 32 Seconds
DATE 2022-01-25 18:10:06 +0100
DRIVER USB UPS Driver
END APC 2022-01-25 18:10:07 +0100
FIRMWARE 877.L4 .I USB FW:L4
HITRANS 294.0 Volts
HOSTNAME pfSense.local
LASTSTEST 2022-01-22 17:22:57 +0100
LASTXFER Automatic or explicit self test
LINEV 231.0 Volts
LOADPCT 12.0 Percent
LOTRANS 176.0 Volts
MAXTIME 0 Seconds
MBATTCHG 5 Percent
MINTIMEL 10 Minutes
MODEL Back-UPS RS 1200G
NOMBATTV 24.0 Volts
NOMINV 230 Volts
NUMXFERS 4
SELFTEST NO
SENSE Medium
SERIALNO 3B1303X09312
STARTTIME 2021-11-27 15:45:40 +0100
STATFLAG 0x05000008
STATUS ONLINE
TIMELEFT 71.5 Minutes
TONBATT 0 Seconds
UPSMODE ShareUPS Master
UPSNAME apc
VERSION 3.14.14 (31 May 2016) freebsd
XOFFBATT 2022-01-22 17:23:07 +0100
XONBATT 2022-01-22 17:22:57 +0100
hmccu:
Attributes:
DbLogExclude .*
asReadings BATTV,BCHARGE,LINEV,LOADPCT,TIMELEFT,LASTXFER,LASTSTEST,XONBATT
Kann ich bestätigen, in den helpern noch OK, im reading gekürzt.
Internals:
BATTDATE 11/14/19
DEF 60 127.0.0.1:3551
FUUID 5db6d3f4-f33f-7ae5-f681-d04ba120af770c71
HOST 127.0.0.1:3551
INTERVAL 60
LOWBATT 20
MODEL Smart-UPS RT 2000 RM XL
NAME APC_USV
NR 224
SERIALNO QS1213130141
STATE ONLINE / 22.5 °C / 21 % Last / Schutzzeit ca. 221 min
TYPE APCUPSD
Helper:
DBLOG:
bcharge:
logdb:
TIME 1643134892.11898
VALUE 100
loadpct:
logdb:
TIME 1643136452.1809
VALUE 21
state:
logdb:
TIME 1641136719.34159
VALUE ONLINE
timeleft:
logdb:
TIME 1643136512.1815
VALUE 221
READINGS:
2022-01-25 19:47:32 Load_VA 420
2022-01-25 19:47:32 Load_Watt 294
2022-01-25 19:50:32 battery ok
2022-01-25 19:50:32 battv 54.5
2022-01-25 19:50:32 bcharge 100
2022-01-25 19:50:32 itemp 22.5
2022-01-25 19:50:32 laststest 2022
2022-01-25 19:50:32 lastxfer Automatic or explicit self test
2022-01-25 19:50:32 linev 228.9
2022-01-25 19:50:32 loadpct 21
2022-01-25 19:50:32 model Smart-UPS RT 2000 RM XL
2022-01-25 19:50:32 outputv 228.1
2022-01-25 19:50:32 state ONLINE
2022-01-25 19:50:32 temperature 22.5
2022-01-25 19:50:32 timeleft 221
helper:
ALARMDEL 5 Seconds
APC 001,051,1232
BATTDATE 11/14/19
BATTV 54.5 Volts
BCHARGE 100.0 Percent
CABLE Ethernet Link
CUMONBATT 31 Seconds
DATE 2021-12-29 11:03:01 +0100
DLOWBATT 10 Minutes
DRIVER PCNET UPS Driver
DSHUTD 240 Seconds
DWAKE 0 Seconds
END APC 2022-01-25 19:50:32 +0100
EXTBATTS 2
FIRMWARE 418.8.I
HITRANS 242.0 Volts
HOSTNAME FHEM-DG-BUSTER
ITEMP 22.5 C
LASTSTEST 2022-01-16 16:16:39 +0100
LASTXFER Automatic or explicit self test
LINEFREQ 50.0 Hz
LINEV 228.9 Volts
LOADPCT 21.0 Percent
LOTRANS 196.0 Volts
MANDATE 03/25/12
MAXLINEV 228.9 Volts
MAXTIME 0 Seconds
MBATTCHG 5 Percent
MINLINEV 228.9 Volts
MINTIMEL 3 Minutes
MODEL Smart-UPS RT 2000 RM XL
NOMBATTV 48.0 Volts
NOMOUTV 230 Volts
NUMXFERS 2
OUTPUTV 228.1 Volts
REG1 0x00
REG2 0x00
REG3 0x00
RETPCT 0.0 Percent
SELFTEST NO
SERIALNO QS1213130141
STARTTIME 2021-12-29 11:02:39 +0100
STATFLAG 0x05000008
STATUS ONLINE
STESTI 336
TIMELEFT 221.0 Minutes
TONBATT 0 Seconds
UPSMODE Stand Alone
UPSNAME HUBER_USV
VERSION 3.14.14 (31 May 2016) debian
XOFFBATT 2022-01-16 16:16:55 +0100
XONBATT 2022-01-16 16:16:39 +0100
Attributes:
DbLogExclude .*
DbLogInclude bcharge,loadpct,state,timeleft
asReadings BATTV,BCHARGE,ITEMP,NOMPOWER,LINEV,LOADPCT,MODEL,OUTPUTV,TIMELEFT,LASTSTEST,LASTXFER
comment 1400 W / 2000 VA
event-min-interval bcharge:3600,loadpct:3600,timeleft:3600
event-on-change-reading .*
group APC_USV
room EDV_USV
stateFormat state / temperature °C / loadpct % Last / Schutzzeit ca. timeleft min
userReadings Load_Watt:loadpct.* {(ReadingsVal($name,'loadpct','0') * 14)},
Load_VA:loadpct.* {(ReadingsVal($name,'loadpct','0') * 20)}
verbose 3
Zitat von: Nobbynews am 14 Juli 2021, 14:21:29
Also kurzerhand das Attribut angepasst zu
attr <device> asReadings BATTV,BCHARGE,LINEV,LOADPCT,TIMELEFT,LASTXFER
und schon sind die Warnungen im Log bei aktiviertem stacktrace Geschichte.
Norbert
Danke für den Hinweis. Ich nutze eine APC Back-Ups ES 550G, die laut Modulhilfe OUTPUTV nicht unterstützt. Habe OUTPUTV aus dem Attribut asReadings rausgenommen. Das hat aber nichts gebracht. Im Log sehe ich weiterhin diese Warnungen:
2023.02.20 15:41:59 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/34_APCUPSD.pm line 142, <$fh> line 721.
2023.02.20 15:41:59 1: stacktrace:
2023.02.20 15:41:59 1: main::__ANON__ called by ./FHEM/34_APCUPSD.pm (142)
2023.02.20 15:41:59 1: main::APCUPSD_RetrieveData called by ./FHEM/34_APCUPSD.pm (163)
2023.02.20 15:41:59 1: main::APCUPSD_PollTimer called by ./FHEM/34_APCUPSD.pm (81)
2023.02.20 15:41:59 1: main::APCUPSD_Define called by fhem.pl (3976)
2023.02.20 15:41:59 1: main::CallFn called by fhem.pl (2155)
2023.02.20 15:41:59 1: main::CommandDefine called by fhem.pl (1276)
2023.02.20 15:41:59 1: main::AnalyzeCommand called by fhem.pl (1127)
2023.02.20 15:41:59 1: main::AnalyzeCommandChain called by fhem.pl (1415)
2023.02.20 15:41:59 1: main::CommandInclude called by fhem.pl (628)
Zitat von: Verkehrsrot am 20 Februar 2023, 16:14:54
Habe OUTPUTV aus dem Attribut asReadings rausgenommen. Das hat aber nichts gebracht. Im Log sehe ich weiterhin diese Warnungen:
Diese Meldung habe ich nur noch bei einem Neustart von FHEM. Im normalen Betrieb kommt nix mehr.
Ich habe es nun nachhaltig gelöst, indem ich aus der Zeile 79:
$attr{$name}{asReadings} = "BATTV,BCHARGE,LINEV,LOADPCT,OUTPUTV,TIMELEFT,LASTXFER";
OUTPUTV herausgenommen habe.
Habe ich bei mir auch gerade so gemacht, aber noch nicht getestet.
Daher hierzu (noch) kein Hinweis.
Bei einem reload des Moduls kam jedenfalls keine Meldung von stacktrace.
Hallo, ist das nun schon ein reguläres Modul?
Wie verwende ich es denn? finde im Wiki keine Anleitung
Danke VG
Hi
muss man bei dem apcupsd services die ports 3551 oder 3552 irgendwie aktivcieren?
danke
Zitat von: riker1 am 19 April 2024, 10:23:34Hallo, ist das nun schon ein reguläres Modul?
Nein, ist es nicht.
Zitat von: riker1 am 19 April 2024, 11:09:14muss man bei dem apcupsd services die ports 3551 oder 3552 irgendwie aktivcieren?
Der Port muss in der apcupsd.conf eingetragen sein.
Sollte aber standardmäßig so sein.