[gelöst] USV an Proxmox in LXC durchreichen

crunchip

@pedder007 sagte in USV an Proxmox in LXC durchreichen:

welche sagt, dass der NUT Server auch direkt unter PVE laufen muss

Ja
Wenn Proxmox das Signal bekommt, fährt der Host entsprechend die Maschinen herunter

David G.

Hab NUT auch auf Proxmox direkt installiert.
Hab es aber irgendwie nie hinbekommen, dass er wie ich möchte runterfährt........

Irgendwann hab ich es dann qick and dirty gemacht.

Die Daten der USV Frage ich eh mit dem Nut Adapter ab.
Ein kleines Script fährt Proxmox dann über den Proxmox Adapter runter (hat sogar den Vorteil, dass man sich noch etwas Logig bei machen kann bei Bedarf).

Pedder007

Hallo @crunchip und @David-G, danke für Eure Rückmeldungen!

Das mit dem Herunterfahren wäre dann ja die nächste Herausforderung, nach meinem aktuellen Problem überhaupt erst einmal im Container an die DPs der USV zu kommen, Ich hatte dazu auch bereits verschiedene Erfahrungsberichte im Netze gelesen, danke!

Ich werde dann aber mal noch NUT direkt unter PVE installieren. Ich hatte das bisher so verstanden, dass ich die Daten der USV am durchgereichten USB-Port alle direkt mit dem NUT im Container lese. Deshalb auch meine Nachfrage hier.

Pedder007

@crunchip leider laufe ich mit der NUT Installation direkt unter PVE in genau das gleiche Problem.
Hier nochmals das, was ich bisher konfiguriert habe, um ggf. dort auch Fehler auszuschließen:

root@proxo:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0001:0000 Fry's Electronics MEC0003
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@proxo:~# lsusb -v -s 001:003

Bus 001 Device 002: ID 0001:0000 Fry's Electronics MEC0003
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x0001 Fry's Electronics
  idProduct          0x0000 
  bcdDevice            1.00
  iManufacturer           1 MEC
  iProduct                2 MEC0003
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
....

dann konfiguriert:

root@proxo:/etc/nut# cat nut.conf

MODE=netserver

und

root@proxo:/etc/nut# cat ups.conf
pollinterval = 15
maxretry = 3

offdelay = 120
ondelay = 240

[apc]
# APC Back-UPS GreenCell 600VA
# driver = blazer_usb
driver = nutdrv_qx
port = auto
desc = "APC Back-UPS GreenCell 600VA"
vendorid = 0001
productid = 0000
serial = 0

hierbei hatte ich dann auch bereits beide Treiber ausprobiert.
Also 'blazer_usb' weil er hier so ausgegeben wird
und 'nutdrv_qx' weil er mir so ausgegeben wurde bei:

root@proxo:~# nut-scanner -U
Scanning USB bus.
[nutdev1]
        driver = "nutdrv_qx"
        port = "auto"
        vendorid = "0001"
        productid = "0000"
        product = "MEC0003"
        vendor = "MEC"
        bus = "001"

ich laufe am Ende aber wieder in die gleiche Fehlermeldung, welche ich bereits im Container hatte:

root@proxo:~# upsdrvctl start
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)
USB communication driver (libusb 1.0) 0.43
libusb1: Could not open any HID devices: insufficient permissions on everything
No supported devices found. Please check your device availability with 'lsusb'
and make sure you have an up-to-date version of NUT. If this does not help,
try running the driver with at least 'subdriver', 'vendorid' and 'productid'
options specified. Please refer to the man page for details about these options
(man 8 nutdrv_qx).

Also irgendwo scheinen da Rechte schief zu hängen, allerdings vertehe ich nicht genug Linux um da mehr draus zu interpretieren als ich ja schon (meine ich) gemacht hatte.

Evtl. gibt's ja noch andere Ideen hier im Forum dazu?

crunchip

@pedder007 sagte in USV an Proxmox in LXC durchreichen:

Also 'blazer_usb' weil er hier so ausgegeben wird
und 'nutdrv_qx' weil er mir so ausgegeben wurde

Ist doch der falsche Treiber?
Benötigst du nicht den usbhid?

David G.

Ich habe auch eine Green Cell und habe blazer_usb angegeben.

Kann am Handy den Text leider nicht kopieren, also entschuldigt die Screenshots.
Aber so läuft meine Green Cell.

Das override war ein test von mir. Braucht man nicht. 2 IPs hab ich angegeben, weil ich mal 2 am läuft hatte und was probiert hatte.

Marc Berg

@pedder007 sagte in USV an Proxmox in LXC durchreichen:

Wenn man mal sucht, wie andere das Problem behoben haben, findet man u.a., dass diese zwei Zeilen in der ups.conf auskommentiert werden müssen:

productid = 0000
serial = 0

Pedder007

@marc-berg das wars
@David-G, ja ich weiß, ich hatte hier im Forum den entsprechenden Thread gefunden.

nun sah es mit 'blazer_usb' so aus:

root@proxo:/etc/nut# upsdrvctl start
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Megatec/Q1 protocol USB driver 0.14 (2.8.0)
Duplicate driver instance detected (PID file /run/nut/blazer_usb-apc.pid exists)! Terminating other driver!
Please note that this driver is deprecated and will not receive
new development. If it works for managing your devices - fine,
but if you are running it to try setting up a new device, please
consider the newer nutdrv_qx instead, which should handle all 'Qx'
protocol variants for NUT. (Please also report if your device works
with this driver, but nutdrv_qx would not actually support it with
any subdriver!)

Supported UPS detected with megatec protocol
Vendor information read in 1 tries
No values provided for battery high/low voltages in ups.conf

Using 'guestimation' (low: 10.400000, high: 13.000000)!
Battery runtime will not be calculated (runtimecal not set)

ich habe dann doch wieder den 'nutdrv_qx' aktiviert und das Gemeckere wird deutlich weniger:

root@proxo:/etc/nut# upsdrvctl start
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)
USB communication driver (libusb 1.0) 0.43
Duplicate driver instance detected (PID file /run/nut/nutdrv_qx-apc.pid exists)! Terminating other driver!
Using protocol: Q1 0.07
Can't autodetect number of battery packs [-1/13.60]
Battery runtime will not be calculated (runtimecal not set)

Ich versuche mich nun dann mal am Rest der Konfiguration

Marc Berg

@pedder007 sagte in USV an Proxmox in LXC durchreichen:

@marc-berg das wars

Ich habe das so interpretiert: Entweder man trägt dort Daten ein, die auch passen, oder man lässt es komplett weg. Sonst sucht der Treiber nach einer ProductID "0000", die es nicht gibt. Die Fehlermeldung ist dann aber ziemlich irreführend.

Pedder007

@marc-berg ja das ist sie definitiv, ich war, bei meiner Recherche, darüber leider nicht gestolpert.

Allerdings scheint das aufsetzen von NUT unter PVE deutlich aufwändiger als auf dem Raspi, bzw. wie hier beschrieben
Damit laufe ich an der Stelle '(sudo) upsd' direkt wieder auf Probleme.

Ich habe das jetzt hiermit durchexerziert und nun sehe ich endlich mal ne'n output:

root@proxo:/# upsc apc@localhost
Init SSL without certificate database
battery.voltage: 13.60
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 15
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.parameter.vendorid: 0001
driver.version: 2.8.0
driver.version.data: Q1 0.07
driver.version.internal: 0.32
driver.version.usb: libusb-1.0.26 (API: 0x1000109)
input.frequency: 50.0
input.voltage: 228.4
input.voltage.fault: 222.7
output.voltage: 228.4
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 15
ups.productid: 0000
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0001

Muss jetzt ne'n Break machen und werde dann heute Abend oder die Tage bei Pkt. 4 weitermachen, wobei das dann wohl nicht mehr so gut passt, da ich ja nun keinen Apache auf meinem ioBroker Container laufen lassen will.
Mal sehen, dass scheint ja alles etwas kniffelig zu sein

Pedder007

Hallo nochmal,
so bin wieder ein Stück weiter, aber immer noch nicht wirklich glücklich.

Ich bin jetzt so weit, dass ich im ioBroker Container via NUT die gleichen Betriebsdaten bekomme wie sie mir auch auf der LVE Console angezeigt werden (siehe letzter Post).

iobadm@iobroker:/etc/nut$ upsc apc@192.168.188.100
Init SSL without certificate database
battery.voltage: 13.60
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 15
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.parameter.vendorid: 0001
driver.version: 2.8.0
driver.version.data: Q1 0.07
driver.version.internal: 0.32
driver.version.usb: libusb-1.0.26 (API: 0x1000109)
input.frequency: 50.0
input.voltage: 223.4
input.voltage.fault: 222.7
output.voltage: 223.5
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 14
ups.productid: 0000
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0001

NUT scheint somit ja dann zumindest auf beiden 'Seiten' richtig konfiguriert.

[EDIT, hat sich erledigt - ich DAU hatte doch noch den falschen Treiber auf PVE aktiviert
Was mir hierbei allerdings auffällt, dass es...... nicht auf der PVE Console ausgegeben!?]

Darüber hinaus habe ich aber nun noch ein weiteres ungelöstes Problem, weil ich die Daten irgendwie auch nicht in der zugehörigen Instanz des NUT Adapters angezeigt werden.
Diesen habe ich wie folgt konfiguriert:

Und er legt auch DP an, welche aber nicht mit denen hier übereinstimmen und er geht auch auf grün, aber es kommt eben nichts!?

Hat da mal noch jemand einen Tipp? @Marc-Berg @crunchip ?

David G.

@pedder007

Das bekomme ich im Shell:

root@pve:~# upsc ups@192.168.99.58
Init SSL without certificate database
battery.charge: 100
battery.voltage: 13.60
battery.voltage.high: 13.00
battery.voltage.low: 10.40
battery.voltage.nominal: 12.0
device.type: ups
driver.name: blazer_usb
driver.parameter.pollinterval: 10
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.version: 2.8.0
driver.version.internal: 0.14
driver.version.usb: libusb-1.0.26 (API: 0x1000109)
input.current.nominal: 2.0
input.frequency: 50.0
input.frequency.nominal: 50
input.voltage: 234.6
input.voltage.fault: 234.1
input.voltage.nominal: 230
output.voltage: 234.1
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 4
ups.productid: 0000
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0001
root@pve:~#

Im ioBroker:

Edit
Im Konsolenauszug hast der der USV einen anderen Namen gegeben als in den Einstellungen vom NUT Adapter.

In der Konsole apc und im Adapter upsc.

Pedder007

@david-g sagte in USV an Proxmox in LXC durchreichen:

In der Konsole apc und im Adapter upsc.

Meine Güte, manchmal sieht man den Wald wirklich vor lauter Bäumen nicht, das wars! Danke
Das kommt wahrscheinlich aber auch daher, weil die ganze Implementierung mal wieder so ein Stückwerk zwischen anderen 'Baustellen' hier war. Dann passiert genau so etwas

Habe jetzt die selben DPs wie Du, auch im ioBroker.

Dann mache ich mich nun dann mal an die Implementierung der zugehörigen Shut-Down Steuerung

Segway

@pedder007

Habe diesen Thread entdeckt. Habe ein ähnliches Problem aber meine APC Smart USV 750 ist über APCUSVD konfiguert und per USB angeschlossen.
Hab extra ne VM aufgesetzt dafür um den Passthrough hinzukriegen. Läuft seit Jahren Problem.

Nun möchte ich auch auf LXC umstellen aber krieg die USV nicht gemutet. Wie gesagt nutze APCUSVD und habe weder ein /dev/usb noch /dev/tty* noch ein /dev/ACM0 oder hidev*

Sollen ich neuen Thread aufmachen oder hier weiter falls jemand eine Idee hat ?

David G.

Falscher Thread

Pedder007

Hallo @segway, sorry da kann ich Dir auch nicht weiterhelfen.
Ich bin froh, dass ich mein eigenes Setup halbwegs im Griff habe

lessthanmore

@segway Was ist der Grund dafür das extra in einem lxc statt direkt auf dem host laufen zu lassen?

Segway

@pedder007 sagte in [gelöst] USV an Proxmox in LXC durchreichen:

Hallo @segway, sorry da kann ich Dir auch nicht weiterhelfen.
Ich bin froh, dass ich mein eigenes Setup halbwegs im Griff habe

Kein Ding Alles gut

@lessthanmore sagte in [gelöst] USV an Proxmox in LXC durchreichen:

@segway Was ist der Grund dafür das extra in einem lxc statt direkt auf dem host laufen zu lassen?

Hab nun viel gelesen. Ich bekomme leider nicht hin (wie zB ein zigbee usb stick) diesen USB Port zu linken zB per Symlink. Die connection läuft halt nicht über ACM0, tty* oder usb-irgendwas.
Das läuft irgendwie über hid* ... aber dafür braucht man wohl Treiber.
Erkenntnis zur Zeit:

Treiber auf einem (pve) Host installieren
nut server installieren und konfigurieren
separate CT mit einem nut client laufen lassen sowie der Gui /Cgi für Browser

Ich überlege noch

crunchip

@segway sagte in [gelöst] USV an Proxmox in LXC durchreichen:

aber dafür braucht man wohl Treiber.

https://networkupstools.org/stable-hcl.html

crunchip

@segway sagte in [gelöst] USV an Proxmox in LXC durchreichen:

separate CT mit einem nut client laufen

Für was?, es reicht doch server und client direkt auf dem host, proxmox fährt dann bei bedarf runter

NEWS

[gelöst] USV an Proxmox in LXC durchreichen

Support us

481
Online

31.7k
Users

79.7k
Topics

1.3m
Posts

NEWS

[gelöst] USV an Proxmox in LXC durchreichen

Support us

481Online

31.7kUsers

79.7kTopics

1.3mPosts

481
Online

31.7k
Users

79.7k
Topics

1.3m
Posts