Wenn ich mich recht entsinne, hat die Abfrage per APCUPSD auf ein NMC2 nur per SNMP funktioniert (oder über PowerChute).
Dafür fehlen die Konfig-Optionen im Modul - zumindest konnte ich über keinen der „Standart-Ports“ eine Verbindung zum NMC2 herstellen.
Wenn APCUPSD an die Daten rankommt, sollten sie auch im Modul sichtbar sein. Wenn nicht, wird mein Modul es auch nicht können.
Hier hat es wohl schon mal einer geschafft, die Daten einer NMC2 mit APCUPSD auszulesen. Ansonsten empfielt sich vor dem Kauf einer USV der Blick in die APCUPSD bzw. NUT kompatibilitätsliste. Insbesondere neuere USVs werden oft nicht unterstützt, weil deren Protokoll nicht frei ist.
ich versuche gerade meine neue USV mittels deines Skripts anzubinden. In meinem Fall ist meine Synology der NUT Server und der IPS-Raspi der NUT-Client. upsc ups@ip-Adresse gibt mir auch die passenden Daten.
Habe nun Socket, Register Variable und Timer Job angelegt und die IDs entsprechend angepasst. Bekomme aber folgende Fehler:
Fatal error: Call to undefined function CSCK_SetOpen() in /var/lib/symcon/scripts/48421.ips.php on line 81
Abort Processing during Fatal-Error: Call to undefined function CSCK_SetOpen()
Error in Script /var/lib/symcon/scripts/48421.ips.php on Line 81
danke für deine Antwort. Vielleicht stehe ich auch total auf dem Schlauch, binde das erste mal überhaupt ein Modul in IPS ein. Habe nun nochmal folgendes in der Reihenfolge gemacht:
Modul eingebunden vom Gihub Repo (Version 4.2)
Neue Instanz erstellt (ACPUPSD attached USV), es wird automatisch noch der Splitter angelegt
Konfiguration der Splitter Instanz mit HostIP meiner Synology (NUT Server) und Port (3493)
Übergeordnete Instanz ist der unter 2. angelegte Socket
Im Log sehe ich nun, dass zumindest das Binding funktioniert, es kommt aber „no valid ups data found“.
Liegt es am Modell (APC Back-UPS RS900Pro)?
Dann habe ich versucht eine neue RegVar anzulegen und das Skript kopiert, wie es auf Tommis Seite steht (http://www.tdressler.net/ipsymcon/nut_ips.html) und das entsprechende TimerEvent. Im Skript die ID der RegVar geändert.
Dann sehe ich im Log:
13.08.2017 11:06:00 | PHP | Error: Error: Call to undefined function CSCK_SetOpen()
Error in Script /var/lib/symcon/scripts/58526.ips.php on Line 80
134 in IPSLibrary/app/core/IPSLogger/IPSLogger.inc.php (call IPSLogger_Out)
33 in IPSLibrary/app/core/IPSLogger/IPSLogger_PhpErrorHandler.inc.php (call IPSLogger_Err)
121 in IPSLibrary/app/core/IPSLogger/IPSLogger_PhpErrorHandler.inc.php (call IPSLogger_PhpErrorHandler)
in IPSLogger_PhpFatalErrorHandler
13.08.2017 11:07:00 | ScriptEngine | Result for Event 44765
<br />
<b>Notice</b>: Undefined variable: IPS_SENDER in <b>/var/lib/symcon/scripts/58526.ips.php</b> on line <b>64</b><br />
<br />
<b>Fatal error</b>: Call to undefined function CSCK_SetOpen() in <b>/var/lib/symcon/scripts/58526.ips.php</b> on line <b>80</b><br />
Abort Processing during Fatal-Error: Call to undefined function CSCK_SetOpen()
Error in Script /var/lib/symcon/scripts/58526.ips.php on Line 80
Ich komme da leider nicht weiter und bin für weitere Tipps sehr dankbar.
Das APCUPSD Script und weiter wurden durch Module ersetzt. Bitte nicht mehr verwenden und gleich löschen. Deshalb sind die Seiten auch so gekennzeichnet. Ich muss die wohl ganz entfernen.
Für eine Synology braucht man auch das NUT Modul, nicht APCUPSD.
Wenn dann noch keine Daten kommen fehlt wahrscheinlich auf der Synology der IP Eintrag in „Zugelassene Synolgy Diskstation“ (Systemsteuerung->Hardware und Energie->Usv
Die Logger Fehlermeldung kommt von der IPSLibraryund hat nichts mit dem Modul oder dem Script zu tun.
kannst Du bitte mal nach dem Modul sehen - funkt unter der aktuellen 5.0 Ninja nicht mehr:
IPS-Err-PHP 2018-01-24 20:43:35.652 Warning: InstanceInterface is not available
Error in Script C:\IP-Symcon\modules\ipsymcon-phpmodule-by-Tommi\APCUPSD\module.php on Line 560
134 in scripts\IPSLibrary\app\core\IPSLogger\IPSLogger.inc.php (call IPSLogger_Out)
37 in scripts\IPSLibrary\app\core\IPSLogger\IPSLogger_PhpErrorHandler.inc.php (call IPSLogger_Err)
in IPSLogger_PhpErrorHandler
560 in modules\ipsymcon-phpmodule-by-Tommi\APCUPSD\module.php (call IPS_GetProperty)
378 in modules\ipsymcon-phpmodule-by-Tommi\APCUPSD\module.php (call SendENData)
225 in modules\ipsymcon-phpmodule-by-Tommi\APCUPSD\module.php (call Query)
835 in scripts\__generated.inc.php (call UpdateEvent)
1 in C:\Windows\System32\- (call APCUPSD_UpdateEvent) IPS-Err-PHP 2018-01-24 20:43:35.653 Warning: InstanceInterface is not available
Error in Script C:\IP-Symcon\modules\ipsymcon-phpmodule-by-Tommi\APCUPSD\module.php on Line 561
134 in scripts\IPSLibrary\app\core\IPSLogger\IPSLogger.inc.php (call IPSLogger_Out)
37 in scripts\IPSLibrary\app\core\IPSLogger\IPSLogger_PhpErrorHandler.inc.php (call IPSLogger_Err)
in IPSLogger_PhpErrorHandler
561 in modules\ipsymcon-phpmodule-by-Tommi\APCUPSD\module.php (call IPS_GetProperty)
378 in modules\ipsymcon-phpmodule-by-Tommi\APCUPSD\module.php (call SendENData)
225 in modules\ipsymcon-phpmodule-by-Tommi\APCUPSD\module.php (call Query)
835 in scripts\__generated.inc.php (call UpdateEvent)
Was soll ich da nachsehen, es hat ja mit der alten Version funktioniert. Die beiden angemeckerten Zeilen sind(waren) absolut IPS Standard. Wenn das Modul ordentlich geladen ist (im Log schauen) und die InstanceID gültig ist, gibt es keinen Grund für einen Fehler.
Das ist nicht das erste Problem mit 5.0, ich erinnere an die Entfernung des fast 13Jahre lang vorhandenen ~String Profils kürzlich. Solange sich gefühlt täglich was an der API was ändert, mache ich nichts für 5.0.
Dachte ich mir schon. Ich habe gerade erst letzte Woche meine eigene „Prod“-Installation auf 4.4 gezogen.
Bei allem Respekt für die Arbeit von Paresy und für die Möglichkeit zum Einblick in die neue Version: für Fehlersuche wie diese in instabilen Releases habe ich schlicht keine Zeit.
ich habe das APC-Modul gerade frisch installiert und bekomme regelmäßig Variablen aktualisiert, habe aber immer Ausrufezeichen an der Instanz und
an dem Client Socket. Das scheint an dem Client-Socket zu liegen, der immer gleich nach Abfrage beendet wird.
Das graue Ausrufungszeichen ist normal. Die Verbindung wird nach dem Abholen der Daten vom Modul bewusst wieder getrennt. Das wird allerdings von der Clientsocket-Instance als potentieller Fehler gewertet