Adapter "iobroker.nut" - UPS Daten im iobroker

pusemuckel

Hallo apollon,

prima Idee. Ich versuche gerade den Status meiner UPS die an der Diskstation hängt über NUT abzufragen. Der Diskstation UPS-Server verwendet NUT und lässt sich entsprechend abfragen.

Mit "MONITOR ups@192.168.1.5 1 monuser secret slave" greit man auf den Server zu. Lässt sich das noch in den Adapter einbauen?

Gruß

apollon77

Also an sich musst du die IP des iobroker Servers auf der Diskstation freigeben für USV Zugriff und dann in der Adapter-Konfig den IP vom Server, Standard Port und Name "ups". Try it. So geht es bei mir, hab auch ne Synology DS 213+

Bluefox

Auf den ersten Blick sieht das gut aus.

Können das auch nicht deutsche Anwender benutzen? Dann solle admin noch übersetzt werden.

systemDictionary = {
        "host_ip":   {"en": "NUT Server IP",       "de": "IP von NUT Server",    "ru": "IP NUT сервера"},
        "host_port": {"en": "NUT Server port",     "de": "Port von NUT Server",  "ru": "Порт NUT сервера"},
        "ups_name":  {"en": "NUT Name of the UPS", "de": "NUT Name für UPS",     "ru": "NUT имя UPS"}
    };

Ich würde noch die test_upslist.js und test_upsvars.js Dateien in test Verzeichnis einpacken und dann .npmignore Datei hinzufügen

https://github.com/ioBroker/ioBroker.ja … .npmignore

Damit die Dateien nicht auf npm auftauchen.

Man kann readme mit

[![NPM version](http://img.shields.io/npm/v/iobroker.nut.svg)](https://www.npmjs.com/package/iobroker.nut)
[![Downloads](https://img.shields.io/npm/dm/iobroker.nut.svg)](https://www.npmjs.com/package/iobroker.nut)

[![NPM](https://nodei.co/npm/iobroker.nut.png?downloads=true)](https://nodei.co/npm/iobroker.nut/)

erweitern, wenn auf npm gepuscht ist.

Ansonsten, das ist ein Beispiel von einem einfachen Adapter, was auch andere benutzen müssen um die Kommunikation mit den Geräten nicht über Scripte zu machen.

Es ist sehr bequem im Adapter die Logik zu haben wie hier. :!:

Danke!

apollon77

Danke für das Feedback. Ändere ich heute Abend.

Zum "NPM push-Thema" fehlt mir noch etwas eine Anleitung … gibts das schon irgendwo wie das für iobroker sein muss?

Update: Ich hab das https://gist.github.com/coolaj86/1318304 und https://docs.npmjs.com/getting-started/ ... m-packages gefunden. Passt das? Passt das mit der Gross/Kleinschreibung? (ioBroker auf git vs iobroker auf nom?)

Eine Frage noch: Es ist ja eine ganze Latte an "createState"-Zeug drin und hinter her die "setState"s. Jetzt hatte ich gelesen das die createState am Ende alle asynchron erfolgen - wie kann ich denn sicherstellen das bei setState auch alle angelegt sind? Aktuell hab ichs einfach durch die "Trennung" im Programmablauf gemacht, aber ob das reicht weiss ich nicht ...

Übersetzung: Ich gehe davon aus das sobald ich ein Tag habe mit class="translate" dann steht im Tag-Body quasi der translate-key und der Rest steht im systemDictionary!?

Bei den Test-Skripten war die Idee das die auch einfach von usern benutzt werden zu können um die grundsätzliche NUT Kommunikation zu testen wenn z.B. der Adapter keine Daten gibt oder nicht verbinden kann. Ist ggf einfacher als immer den Adapter-Konfig zu ändern und auf das Schedule zu warten. Dann immer noch ausschliessen?

pusemuckel

~~@apollon77:~~

Also an sich musst du die IP des iobroker Servers auf der Diskstation freigeben für USV Zugriff und dann in der Adapter-Konfig den IP vom Server, Standard Port und Name "ups". Try it. So geht es bei mir, hab auch ne Synology DS 213+ `
Danke das klappt wunderbar!

Bluefox

~~@apollon77:~~

https://docs.npmjs.com/getting-started/ … m-packages gefunden. Passt das? Passt das mit der Gross/Kleinschreibung? (ioBroker auf git vs iobroker auf nom?) `
Ja alles passt und link ist auch richtig. Eigentlich du musst nur npm account erzeugen und dann "npm publish" schreiben.

~~@apollon77:~~

Eine Frage noch: Es ist ja eine ganze Latte an "createState"-Zeug drin und hinter her die "setState"s. Jetzt hatte ich gelesen das die createState am Ende alle asynchron erfolgen - wie kann ich denn sicherstellen das bei setState auch alle angelegt sind? Aktuell hab ichs einfach durch die "Trennung" im Programmablauf gemacht, aber ob das reicht weiss ich nicht … `
Geht es um Javascript Adapter? Falls nicht, dann

setState und setObjectNotExists können unabhängig von einander aufgerufen werden und in der beliebige Reihenfolge.

~~@apollon77:~~

Übersetzung: Ich gehe davon aus das sobald ich ein Tag habe mit class="translate" dann steht im Tag-Body quasi der translate-key und der Rest steht im systemDictionary!? `
Richtig.

~~@apollon77:~~

Bei den Test-Skripten war die Idee das die auch einfach von usern benutzt werden zu können um die grundsätzliche NUT Kommunikation zu testen wenn z.B. der Adapter keine Daten gibt oder nicht verbinden kann. Ist ggf einfacher als immer den Adapter-Konfig zu ändern und auf das Schedule zu warten. Dann immer noch ausschliessen? `
Dann natürlich nicht. Es gibt die Möglichkeit diese tests aus dem Konfig aufzurufen, aber es ist nicht trivial. lass es so.

apollon77

~~@Bluefox:~~

~~@apollon77:~~

https://docs.npmjs.com/getting-started/ … m-packages gefunden. Passt das? Passt das mit der Gross/Kleinschreibung? (ioBroker auf git vs iobroker auf nom?) Ja alles passt und link ist auch richtig. Eigentlich du musst nur npm account erzeugen und dann "npm publish" schreiben.

Cool Done.

Was muss ich dann noch tun das es zum "offiziellen Adapter" werden kann :-)

~~@Bluefox:~~

~~@apollon77:~~

Eine Frage noch: Es ist ja eine ganze Latte an "createState"-Zeug drin und hinter her die "setState"s. Jetzt hatte ich gelesen das die createState am Ende alle asynchron erfolgen - wie kann ich denn sicherstellen das bei setState auch alle angelegt sind? Aktuell hab ichs einfach durch die "Trennung" im Programmablauf gemacht, aber ob das reicht weiss ich nicht … `
Geht es um Javascript Adapter? Falls nicht, dann

setState und setObjectNotExists können unabhängig von einander aufgerufen werden und in der beliebige Reihenfolge. `

Ok, dann vereinfache ich das alles noch weil ich dann das setState direkt hinter dem Erzeugen des Objekts machen kann.

UPDATE: Done auf github und bald in 0.2.0.

~~@Bluefox:~~

~~@apollon77:~~

Übersetzung: Ich gehe davon aus das sobald ich ein Tag habe mit class="translate" dann steht im Tag-Body quasi der translate-key und der Rest steht im systemDictionary!? Richtig.
Auch da schaue ich das ich die Zusatzinfos zum Adapter noch mind. de+en mache. Aktuell ist es "en".

Was ,muss ich denn tun um die admin/index.html "neu" zu laden? Ich hab bei mir lokal das ganze erweitert und ins lokale Verzeichnis eingespielt. Aber auch wenn ich ioBroker komplett neu starte wird mir in den Adapter-Settings immer noch das "alte" angezeigt? Hatte auch nen anderen Browser versucht.

Any idea?

UPDATE: "iobroker upload nut" war die Lösung :-) In Arbeit

~~@Bluefox:~~

~~@apollon77:~~

Bei den Test-Skripten war die Idee das die auch einfach von usern benutzt werden zu können um die grundsätzliche NUT Kommunikation zu testen wenn z.B. der Adapter keine Daten gibt oder nicht verbinden kann. Ist ggf einfacher als immer den Adapter-Konfig zu ändern und auf das Schedule zu warten. Dann immer noch ausschliessen? Dann natürlich nicht. Es gibt die Möglichkeit diese tests aus dem Konfig aufzurufen, aber es ist nicht trivial. lass es so.
Hab Sie jetzt in ein Test-Verzeichnis geschoben, aber schliesse Sie nicht aus.

apollon77

v0.2.0 vom Adapter ist auf npm verfügbar und deutsch und englisch übersetzt (Mein Schulrussisch von vor vielen Jahren will glaube keiner haben ;-) )

jens.maus

~~@apollon77:~~

v0.2.0 vom Adapter ist auf npm verfügbar und deutsch und englisch übersetzt (Mein Schulrussisch von vor vielen Jahren will glaube keiner haben ;-) ) `

Hier nur kurz die Info das dein NUT adapter perfekt funktioniert. Danke dafür. Kann ich somit auch meine USV in VIS einbinden.

Einziger Hinweis den ich noch hätte wäre ggf. extra objekte für die Interpretation der reinen NUT statuswerte mit in VIS über deinen adapter einbinden zu lassen. D.h. im grunde z.b. "ups.status" nicht nur als "OL" für on-line zu listen sondern eventl. booleans oder ähnliches dafür zu verwenden damit man in VIS dann entsprechend den status besser abfragen kann und seine Widgets irgendwie darauf besser reagieren können.

apollon77

Hi,

die Idee ist gut, ich konnte bisher aber noch keine Liste von allen relevanten "status" Strings bzw Kombinationen (es gibts z.B. auch "OL CHRG" oder so wenn er gerade lädt und so). Wenn Du eine Liste findest gern her damit :-))

… Ok, doch was gefunden:

` > Possible values for status_set:

OL - On line (mains is present)

OB - On battery (mains is not present)

LB - Low battery

HB - High battery

RB - The battery needs to be replaced

CHRG - The battery is charging

DISCHRG - The battery is discharging (inverter is providing load power)

BYPASS - UPS bypass circuit is active - no battery protection is available

CAL - UPS is currently performing runtime calibration (on battery)

OFF - UPS is offline and is not supplying power to the load

OVER - UPS is overloaded

TRIM - UPS is trimming incoming voltage (called "buck" in some hardware)

BOOST - UPS is boosting incoming voltage

FSD - Forced Shutdown (restricted use, see the note below) `

Es kann aber mehreres davon da sein. Wie würdest Du das abbilden? Alles als separate Flags sodass du auf alles separat zugreifen kannst oder wie? Bin da gerade noch unschlüssig …

Die Flag Idee wäre dann Objekte anstelle ups.status=String ala

nut.0.ups.status.OL=true/false
nut.0.ups.status.OB=true/false
...
...
nut.0.ups.status.CHRG=true/false
...

````Und halt so geparst das ggf mehrere davon "true" sein könnten.

Und vllt den originalen String noch irgendwo zusätzlich (wie nut.0.ups.status.value=String)

jens.maus

~~@apollon77:~~

[…]

Es kann aber mehreres davon da sein. Wie würdest Du das abbilden? Alles als separate Flags sodass du auf alles separat zugreifen kannst oder wie? Bin da gerade noch unschlüssig …

Die Flag Idee wäre dann Objekte anstelle ups.status=String ala
nut.0.ups.status.OL=true/false
nut.0.ups.status.OB=true/false
...
...
nut.0.ups.status.CHRG=true/false
...

````Und halt so geparst das ggf mehrere davon "true" sein könnten.

Und vllt den originalen String noch irgendwo zusätzlich (wie nut.0.ups.status.value=String) `  

Also ich würde das ganze unter nut.0.ups.XXXXX so lassen wie es ist, aber zusätzlich eben in der oberen eben noch etwas wie folgendes implementieren:

nut.0.status.online = true/false (OL/OFF)
nut.0.status.onbattery = true/false (OB)
nut.0.status.lowbattery = true/false (LB/HB)
nut.0.status.replacebattery = true/false (RB)
nut.0.status.charging = true/false (CHRG)
nut.0.status.discharging = true/false (DISCHARGE)
nut.0.status.bypass = true/false (BYPASS)
nut.0.status.calibration = true/false (CAL)
nut.0.status.overload = true/false (OVER)
nut.0.status.trimming = true/false (TRIM)
nut.0.status.boost = true/false (BOOST)
nut.0.status.shutdown = true/false (FSD)

Und dann würde ich vmtl. noch ein zusätzliches Objekt einfügen wie 'nut.0.status.severity' und das als int definieren. 0 würde da sowas bedeutet wie "alles ok", 1 z.B. sowas wie "minor", 2 dann sowas wie "medium" und 3 sowas wie "emergency" und dann versuchen die dinger darauf zu mappen damit man entsprechend dann in VIS oder ähnlichem darauf reagieren kann das z.b. "replacebattery" nur ein minor event ist, aber sowas wie "onbattery" z.b. medium (2) ist und "overload" z.b. "emergency"….

apollon77

Hey,

die 0.3.0 auf NPM hat zuminderstens mal den neuen "status" Channel mit den EInzel-Boolean-Werten der Stati.

Zu der "Severity"-Idee muss ich nochmal meditieren … weil ich denke das die Einschätzung was wie "schlimm" ist durchaus persönlich ist. "ReplaceBattery" z.B. sollte eine zeitnahe Aktion des Owners auslösen ... also an sich sehr wichtig ... aber halt aktuell nicht für den Betrieb ; "Overload" wäre beides ... hm ... hmm hmm .... ;-)

jens.maus

~~@apollon77:~~

die 0.3.0 auf NPM hat zuminderstens mal den neuen "status" Channel mit den EInzel-Boolean-Werten der Stati. `

Wow, das ging schnell. Danke, ging auch sofort! Damit kann man jetzt zumindest auf gewisse events reagieren, sehr gut.

~~@apollon77:~~

Zu der "Severity"-Idee muss ich nochmal meditieren … weil ich denke das die Einschätzung was wie "schlimm" ist durchaus persönlich ist. "ReplaceBattery" z.B. sollte eine zeitnahe Aktion des Owners auslösen ... also an sich sehr wichtig ... aber halt aktuell nicht für den Betrieb ; "Overload" wäre beides ... hm ... hmm hmm .... ;-) `

Nun, die Idee die ich dahinter hatte ist/war das man eben auf ein einzelnes Objekt dann reagieren kann und somit merkt das sich was geändert hat. Jetzt muss man eben mehr oder weniger alle status Objekte überprüfen ob sich was geändert und dann immer zwingend eine eigene Bewertung vornehmen. Aber vielleicht fällt dir ja noch was besseres ein um das gleiche zu erreichen :)

apollon77

~~@jens.maus:~~

Nun, die Idee die ich dahinter hatte ist/war das man eben auf ein einzelnes Objekt dann reagieren kann und somit merkt das sich was geändert hat. Jetzt muss man eben mehr oder weniger alle status Objekte überprüfen ob sich was geändert und dann immer zwingend eine eigene Bewertung vornehmen. Aber vielleicht fällt dir ja noch was besseres ein um das gleiche zu erreichen :) `

Hm … Wäre dafür nicht "ups.status" am sinnvollsten - sobald sich der Wert ändert ist was passiert. So mache ich es gerade und schicke Notifys.

jens.maus

~~@apollon77:~~

Hm … Wäre dafür nicht "ups.status" am sinnvollsten - sobald sich der Wert ändert ist was passiert. So mache ich es gerade und schicke Notifys. `

Stimmt, für eine einfache Änderung ist das ausreichend. Trotzdem wäre so ein "severity" wert sicherlich sinnvoll um eine schnelle Einschätzung zu bekommen ob das System "ok" arbeitet oder ob es was minimales, wichtiges oder sehr wichtiges zu beachten gibt. Wenn einem der wert nicht gefällt kann man ja trotzdem kurzerhand das ganze selbst machen anhand der bools die du jetzt hinzugefügt hast.

apollon77

Hey,

ich habe mal etwas nachgedacht und folgende Idee die ich sinnvoll finde :-)

Unter "status" gibts neben den Werten jetzt noch folgende Booleans, die verschiedene Status Oder-verknüpft enthalten:

is_idle: OL

is_operating: OB, CHRG, DISCHRG, CAL, TRIM, BOOST

is_operating_critical: LB, HB, FSB

action_needed: RB,BYPASS, OFF, OVER

TRIM und BOOST könnte man auch bei "is_operation_critical" reinpacken. Noch nicht ganz sicher.

Ob "CHRG" zu "idle" oder "operating" gehört bin ich mri auch noch nicht soooo sicher :-)

Die Logik wäre dann so dass der entsprechende Wert gesetzt ist wenn einer der Unterwerte gesetzt ist.

Alternativ wäre ein Wert der dann textuell "idle"/"operating"/"operation_critical"/"action_needed" oder Zahlen dafür hat

Meinungen dazu? Jens? :-)

jens.maus

~~@apollon77:~~

ich habe mal etwas nachgedacht und folgende Idee die ich sinnvoll finde :-)

Unter "status" gibts neben den Werten jetzt noch folgende Booleans, die verschiedene Status Oder-verknüpft enthalten:

is_idle: OL

is_operating: OB, CHRG, DISCHRG, CAL, TRIM, BOOST

is_operating_critical: LB, HB, FSB

action_needed: RB,BYPASS, OFF, OVER

TRIM und BOOST könnte man auch bei "is_operation_critical" reinpacken. Noch nicht ganz sicher.

Ob "CHRG" zu "idle" oder "operating" gehört bin ich mri auch noch nicht soooo sicher :-)

Die Logik wäre dann so dass der entsprechende Wert gesetzt ist wenn einer der Unterwerte gesetzt ist.

Alternativ wäre ein Wert der dann textuell "idle"/"operating"/"operation_critical"/"action_needed" oder Zahlen dafür hat

Meinungen dazu? Jens? :-) `

Zur Vereinfachung der momentanen Situation kann man das sicher machen. Jedoch denke ich wäre es immer noch sinnvoll irgendwie/wo eine einzelnen Variable zu haben die einem dann mittels enums/status integers zulässt z.B. in VIS eine einzelne Bedingung auszuwerten um dann z.B. ein widgets darzustellen bzw. andersfarbig zu markieren. In deinem genannten Fall müsste ich ja wiederum vier verschiedene status variablen checken und dann selbst oder/und Verknüpfungen damit herstellen. IMHO sollte es irgendwie doch möglich sein mittels einer einzelnen variable Aktionen zu definieren damit ich diese dann in einem VIS widgets entsprechend nutzen kann.

Ansonsten aber ist die Idee die NUT status irgendwie weiter zu gruppieren schon eine gute Idee.

apollon77

> Alternativ wäre ein Wert der dann textuell "idle"/"operating"/"operation_critical"/"action_needed" oder Zahlen dafür hat

Ich hab da aktuell zu wenig VIS Know how.

Wenn ich einen textwert (Enum) baue wie "status_current_info" mit den textwerten "idle"/"operating"/"operation_critical"/"action_needed" und es wird immer das "schlimmste" (also letztes hat höchste Prio) genommen ist das dann nutzbar?!

paul53

~~@apollon77:~~

Alternativ wäre ein Wert der dann textuell "idle"/"operating"/"operation_critical"/"action_needed" oder Zahlen dafür hat `
Ja, Jens bevorzugt einen Multistate-Datenpunkt (Werteliste) mit 4 Zuständen, wobei die Priorität zu beachten ist, wenn die Bedingungen für mehrere Zustände gleichzeitig auftreten können, z.B.:

{
  "_id": "nut.0.status.severity",
  "type": "state",
  "common": {
    "name": "status.severity",
    "role": "indicator",
    "type": "number",
    "read": true,
    "write": true,
    "desc": "Status gewichtet",
    "min": 0,
    "max": 3,
    "def": 0,
    "states": "0:idle;1:operating;2:operating critical;3:action needed"
  },
}

apollon77

Im Github ist mal eine Version mit Severity-Feld … Please Test :-)

Ich hab noch die IDee ein "Command"_State zu haben um von Aussen per upsmon auch noch Status-Updates zu melden, aber das tut nicht. Da muss ich den Adapter auf "deamon" umbauen :-(

Community Forum

NEWS

Adapter "iobroker.nut" - UPS Daten im iobroker

Support us

865

32.4k

81.5k

1.3m