administrators group | i-doit Community

Michael Huhn

dazu muss man den Counter editieren, wie in der KB beschreiben:
https://kb.i-doit.com/de/grundlagen/benutzerdefinierte-zaehler.html#fuhrende-nullen

LFischer

Hey @stefanp74

nach langer Wartezeit (und einem Reminder) konnte ich die Entscheider umstimmen und wir planen (absehbar in i-doit 39) die HTML E-Mails (inkl. richtiger Tabellen) einbauen

Es gehört allerdings noch ein wenig mehr Arbeit dazu als was hier eingebaut wurde - zum Beispiel möchten wir die Entscheidung dem User überlassen und auch den WYSIWYG Editor nutzen, sofern HTML E-Mails aktiviert wurden.

Der Change liegt aktuell bei unserer QS und sollte (wenn nichts dazwischen kommt) mit der nächsten i-doit Version (aktuell für Oktober geplant) veröffentlicht werden.

Viele Grüße
Leo

LFischer

Hey @Moritz

das müsste ich zunächst mal bei unseren Projektmanagern anfragen - ich vermute aber da gibt es keine tiefere Begründung. Es bleibt häufig eine Frage der Priorität.

Jedenfalls habe ich noch mal nachgehakt und konnte die Entscheider umstimmen

Es gehört ein wenig mehr Arbeit dazu als was im anderen Topic eingebaut wurde - zum Beispiel möchten wir die Entscheidung dem User überlassen und auch den WYSIWYG Editor nutzen, sofern HTML E-Mails aktiviert wurden.

Der Change liegt aktuell bei unserer QS und sollte (wenn nichts dazwischen kommt) mit der nächsten i-doit Version (aktuell für Oktober geplant) veröffentlicht werden. Ich werde das auch gleich im anderen Topic erwähnen

Viele Grüße
Leo

LFischer

Oooh whooops, entschuldige, ich habe eben erst gesehen das du den Beitrag bereits verlinkt hast Leider gibt es da noch nichts offizielles

LFischer

Hey @Moritz

offiziell hat es dieses Feature noch immer nicht ins Produkt geschafft - es gab hier aber mal einen Community Beitrag: https://community.i-doit.com/topic/5293/email-benachrichtigung-von-ascii-tabelle-zu-html-tabelle

Hilft das vielleicht übergangsweise weiter? Bitte berücksichtige das solche Datei-Änderungen nach einem i-doit Update verloren gehen.

Viele Grüße
Leo

LFischer

Hey @cherif

das ist tatsächlich merkwürdig. Kannst du ggf. in deiner init.php eine Debug Ausgabe machen um zu prüfen ob diese durchlaufen wird BEVOR der Command seine Logik ausführt?

Setzt dein Command den Login voraus (-u admin -p admin ...)? Die Prüfung if (isys_module_manager::instance()->is_active('tools')) { ... } in der init.php kann nur funktionieren, wenn du (auch über die CLI) eingeloggt bist.

Zum debuggen kannst du die Funktion print_ar_file('xyz'); nutzen - diese schreibt dann im Hintergrund eine Datei ins i-doit Temp Verzeichnis: temp/debug_output.txt.

Viele Grüße
Leo

LFischer

Hey @cherif das klingt nach einem Problem mit dem Autoloader, ein offensichtliches Problem springt mir hier aber nicht ins Auge

Was mir aber auffällt: Dein Namespace beinhaltet tool mit kleinem t - üblicherweise werden Namespaces im "CamelCase" Format geschrieben.

Oder hast du inzwischen schon eine eigene Lösung gefunden?

Viele Grüße
Leo

Michael Huhn

@thebob1

eine i-doit 8.3 gibt es nicht. Die aktuelle Version ist die 38.

Aktuell gibt es weder eine Anleitung noch eine Funktion, um zwei Datenbanken zusammenzuführen Die Daten müssten also als Import hinzugefügt werden.

Michael Huhn

@sveno

dazu drei Punkte mit Hintergrund aus dem Code:

Stromkreise/Phasen pro PDU

i-doit modelliert das über die Kategorie Branch an der PDU. In der Liebert/Vertiv-MIB, an der sich i-doit orientiert, heisst diese Ebene lgpPduRb (Receptacle Branch), also Stromkreis bzw. Sicherungsabgang. Bei dreiphasigen PDUs entspricht das typischerweise einem Branch
pro Phase (L1, L2, L3), das hängt aber vom PDU-Hersteller-Layout ab. Pro Branch trägst du die Anzahl der Receptacles ein (Default 6).

Editieren in der PDU-Übersicht

Die Kategorie PDU-Übersicht (C__CATS__PDU_OVERVIEW) ist intern eine virtuelle Kategorie (source_table = isys_catg_virtual_list). Virtuelle Kategorien aggregieren nur, sie haben keine eigene Speicher-Spaltenstruktur, daher ist der Edit-Button ausgegraut. Das ist gewolltes
Verhalten, kein Bug der Demo.

"Stromverbraucher zu Receptacle verbinden"

Receptacles sind in i-doit kein eigenständiges Objekt. Die Tabelle isys_cats_pdu_branch_list hat lediglich eine Integer-Spalte receptables (= Anzahl). Receptacle-Namen, Pwr-Werte und akkumulierte Energie holt i-doit ausschliesslich per SNMP, die Default-OIDs zeigen auf
die Liebert/Vertiv-Enterprise-MIB (1.3.6.1.4.1.476.1.42., Felder lgpPduRcpEntry). Überschreibbar sind die Pfade unter snmp.pdu.path.* in den Tenant-Einstellungen.

Ohne SNMP-fähige PDU bleibt die Receptacle-Spalte auf "Anzahl" sitzen. Die Verknüpfung Server zu PDU läuft dann nicht receptacle-genau, sondern connector-genau über Verkabelung:

Am Verbraucher: Kategorie Stromverbraucher mit Anschluss
An der PDU: Kategorie Stromversorger oder einfache Connectors-Einträge
Verbindung per Verkabelung (Kabelverbindung).

Wenn du es receptacle-genau abbilden willst, hat sich diese Convention bewährt: pro Receptacle einen Output-Connector auf der PDU anlegen, benannt nach Phase und Slot (z. B. L1 / Rec 1 bis L3 / Rec 6), und den Server-Power-Anschluss per Verkabelung mit genau diesem
Connector verbinden. Die Demo macht es ähnlich, dort heissen die Outputs allerdings nur 16A-Anschluss 01 bis 12.

Auslastung pro Phase/PDU/Rack

Zwei Wege:

Live (SNMP): PDU spricht SNMP, OIDs sind in den Tenant-Settings gesetzt, PDU-Übersicht zeigt die Werte automatisch.
Statisch (Report): Nennlast aus Stromverbraucher (Felder Volt, Watt, Ampere) summieren und per Connector-Titel an der PDU gruppieren. Voraussetzung: der Phasen-Prefix aus Punkt 3.

Skeleton für den Report-Manager (Belegung pro PDU, gefiltert auf Power-Output-Connectors):

  SELECT
      rack.isys_obj__title                              AS Rack,
      pdu.isys_obj__title                               AS PDU,
      SUBSTRING_INDEX(pdu_conn.isys_catg_connector_list__title, '/', 1) AS Phase,
      COUNT(*)                                          AS Receptacles_total,
      SUM(CASE WHEN pdu_conn.isys_catg_connector_list__isys_cable_connection__id IS NOT NULL
               THEN 1 ELSE 0 END)                       AS Receptacles_used
  FROM      isys_catg_connector_list         pdu_conn
  JOIN      isys_obj                         pdu
         ON pdu.isys_obj__id                 = pdu_conn.isys_catg_connector_list__isys_obj__id
        AND pdu.isys_obj__isys_obj_type__id  = 49
        AND pdu.isys_obj__status             = 2
  LEFT JOIN isys_catg_location_list          pdu_loc
         ON pdu_loc.isys_catg_location_list__isys_obj__id = pdu.isys_obj__id
        AND pdu_loc.isys_catg_location_list__status       = 2
  LEFT JOIN isys_obj                         rack
         ON rack.isys_obj__id                = pdu_loc.isys_catg_location_list__parentid
        AND rack.isys_obj__isys_obj_type__id = 4
  WHERE     pdu_conn.isys_catg_connector_list__status            = 2
        AND pdu_conn.isys_catg_connector_list__type              = 2       -- 2 = OUTPUT
        AND pdu_conn.isys_catg_connector_list__isys_connection_type__id IN (4, 5)  -- Schuko + IEC
  GROUP BY  rack.isys_obj__id, pdu.isys_obj__id, Phase
  ORDER BY  Rack, PDU, Phase;

Hintergrund zu den Konstanten: C__CONNECTOR__OUTPUT = 2, Connection-Type IDs 4 und 5 = Schuko und IEC-Power-Connector (aus isys_connection_type). Damit bleiben Netzwerk-Ports und der PDU-Input aussen vor.

Watt-Summen pro Phase folgen demselben Pattern, sobald Stromverbraucher am Server gepflegt ist; dafür joinst du über isys_cable_connection auf die Verbraucher-Seite und ergänzt SUM(consumer.isys_catg_pc_list__watt).

Michael Huhn

@thebob1

die angezeigten Daten in der Quickinfo sind fest definiert und können nicht angepasst werden.
Einfacher wäre es die Objektliste anzupassen.

administrators

Posts

Member List