Adapter "iobroker.nut" - UPS Daten im iobroker

apollon77

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

jens.maus

~~@apollon77:~~

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

Ok. scheint erst einmal prinzipiell zu funktionieren. Danke.

Allerdings hab ich da immer noch eine frage bzgl. des "severity". Ich finde die Unterscheidung zwischen "idle" und "operating" nicht wirklich intuitiv. Ich würde vermutlich die severity levels etwas anders nennen:

0 - unknown
1 - normal
2 - minor
3 - major
4 - critical

Das erscheint mir irgendwie intuitiver und besser auf den Term "severity" zugeschnitten. Den neuen "unknown" state (0) würde ich übrigens als fallback vergeben falls es ein neuen status gibt bzw. wenn ein keine Verbindung zum NUT server gibt und der status somit unbekannt ist.

apollon77

Hey,

wie zulöetzt schon diskutiert finde ich kein in meinen Augen sinnvolles allgemeingültiges Mapping "Bug-Severities" Daher hatte ich eher die IDee auf den Zustand des Geräts zu gehen.

Daher war ich auf die Idee gekommen die ich habe:

idle = steht bereit, macht aber gerade nichts, könnte auch "standby" heissen

operating = Sie tut das was Sie soll wenn Sie im Einsatz ist, weil gerade der Strom weg ist, alles ok, läuft "as planned"

operating_critical = Sie tut immer noch was Sie soll, aber der Zustand ist kritischer, also bald ist Sie aus

action_needed = Der Besitzer sollte schauen was da los ist, er muss was tun

unknown = Status unbekannt (genau, Nut nicht da und sowas)

Vllt ist auch "severity" der falsche Name … "status" war schon vergeben, das würde noch besser passen."condition" ist vllt besser weil es ja der "aktuelle Zustand des Geräts" ist ...

jens.maus

~~@apollon77:~~

wie zulöetzt schon diskutiert finde ich kein in meinen Augen sinnvolles allgemeingültiges Mapping "Bug-Severities" Daher hatte ich eher die IDee auf den Zustand des Geräts zu gehen. `

Wieso denn? ich finde das was du ausgewählt hast lässt sich doch prinzipiell super mappen?

Einfach deine severity levels wie folgt umbenennen:

` > idle -> normal

operating -> minor

operating_critical -> major

action_needed -> critical `

Die NUT Status die du ausgewählt hast passen schon darauf IMHO.

~~@apollon77:~~

Daher war ich auf die Idee gekommen die ich habe:

idle = steht bereit, macht aber gerade nichts, könnte auch "standby" heissen

operating = Sie tut das was Sie soll wenn Sie im Einsatz ist, weil gerade der Strom weg ist, alles ok, läuft "as planned"

operating_critical = Sie tut immer noch was Sie soll, aber der Zustand ist kritischer, also bald ist Sie aus

action_needed = Der Besitzer sollte schauen was da los ist, er muss was tun

unknown = Status unbekannt (genau, Nut nicht da und sowas) `

Nun, aber gerade mit dem Term "operating" hab ich so meine Probleme. Ich finde das suggeriert das alles i.O. ist, was aber den status betrifft bedeutet das aber das der Strom gerade weg ist und sie auf Batterien läuft. Das sollte IMHO nicht "operating" heissen weil das suggeriert das wie gesagt alles OK ist. Idle finde ich auch komisch, weil da denkt man das ding arbeitet nicht sondern idled nur rum und überwacht nicht.

~~@apollon77:~~

Vllt ist auch "severity" der falsche Name … "status" war schon vergeben, das würde noch besser passen."condition" ist vllt besser weil es ja der "aktuelle Zustand des Geräts" ist ... `

Ich verstehe schon deine Motivation dahinter, aber ich denke mit der normalen "severity" Einteilung wie ich sie oben aufgelistet habe sollte es IMHO auch gehen. Ist halt einfach eine Abstufung des Schweregrades der Ereignisse bzw. des momentanen USV Status. Bei deiner Einteilung muss man immer noch schauen welcher Status wirklich nun wo reinfällt.

apollon77

Gibts denn noch von anderen Nutzern Ideen/Meinungen dazu? :-))

Würden Dir denn bessere Begriffe anstelle "operating" und "idle" (oder "standby") einfallen?

Mein Problem ist genau das mir minor/major zu wenig-aussagekräftig sind

Vllt normal (oder monitoring)/active (oder activated)/active_critical/action_needed/unknown? und das ganze als "condition" anstelle "severity"

etv

Hallo,

hab den Adapter auch gerade installiert, hat problemlos funktioniert! Läuft auf einer Synology DS1515 und überwacht so die über USB angeschlossene USV. Muss mich erst mal in den viiiiiieeeeelen Datenpunkte einlesen - schaut sehr umfangreich aus. Hab da noch keine Idee was ich in ioBrocker davon dann sinnvoll verwenden/Loggen werde.

Grüße

Tom

apollon77

@jens.maus: Mal eine Frage: Wie nutzt DU denn VIS mit Wertelisten? Ich habe mich da mal etwas umgeschaut, aber ausser quasi das Tür/Fenster-Widget zu nehmen und dort fpr 0, 1 und 2 die Icons auszutauschen kriegt man das nicht so hin … oder hab ich ein flexibleres Widget übersehen?

Wenn nicht sollte man das vllt mal als Feature-Request einkippen

jens.maus

~~@apollon77:~~

@jens.maus: Mal eine Frage: Wie nutzt DU denn VIS mit Wertelisten? Ich habe mich da mal etwas umgeschaut, aber ausser quasi das Tür/Fenster-Widget zu nehmen und dort fpr 0, 1 und 2 die Icons auszutauschen kriegt man das nicht so hin … oder hab ich ein flexibleres Widget übersehen? `

Wenn man eine Grafik will kommt man um das Tür/Fenster-Widget (z.B. tplMfdCustom10) nicht drumrum. Wenn einem allerdings auch eine Textdarstellung reicht dann kann man auch einfach eine ValueList HTML (tplValueListHtml8) nehmen. Klappt wunderbar.

apollon77

Auch wenn Offtopic: Richt nach nem Feature-Request für ein neues Widget mit flexibler Anzahl Grafiken

ChristianF

Ich danke auch sehr für diesen Adapter! Tolle Arbeit!

Es wäre cool, wenn es noch ein Feld "Restlaufzeit" gäbe. In PowerChute gibt es sowas, aber ob nut das übermittelt, weiß ich nicht..

VG

Christian

apollon77

Das sollte battery.runtime sein und ist in Sekunden

ChristianF

Perfekt, danke! Jetzt muss ich nur noch rauskriegen, wie ich das für die Vis in Minuten umrechnen kann:)

apollon77

Bei via kannst du Rechnen. Heißt "bindings " und geht mit geschweiften Klammern. Schau mal auf der github Seite vom iobroker.vis.

Mehr falls nötig wenn ich wieder aus dem Urlaub zurück bin.

rascal

hey,

der Nut Adapter müllt mir das Log zu, da er bei jedem Aufruf da rein schreibt.

Ich habe schon versucht den Log Level auf warn und error zu setzten, hilft nix, er scheint trotzdem im log auf.

Ist das ein Bug oder habe ich was übersehen?

NEWS

Adapter "iobroker.nut" - UPS Daten im iobroker

Support us

236

32.4k

81.4k

1.3m