Meine "USV" wird ständig getrennt und neu gefunden

[Christian72D]

Ich habe meine eaton USV per USB an dem Synology Server hängen.
Und die gibt die Werte frei für fhem.

Leider sehe ich jetzt fast jede Minute folgende Einträge:

Code Auswählen Erweitern

2018.05.01 01:36:40 1: 192.168.1.11:3493 disconnected, waiting to reappear (USV)
2018.05.01 01:36:42 1: 192.168.1.11:3493 reappeared (USV)

Angelegt ist sie wie folgt:

Code Auswählen Erweitern

Internals:
   DEF        ups 192.168.1.11
   DeviceName 192.168.1.11:3493
   FD         4
   NAME       USV
   NR         267
   PARTIAL   
   STATE      opened
   TYPE       NUT
   UpsName    ups
   buffer     
   lastStatus OL CHRG
   pollValState 0
   Helper:
     DBLOG:
       battery.charge:
         logdb:
           TIME       1525665625.43294
           VALUE      100
       battery.runtime:
         logdb:
           TIME       1525665625.43294
           VALUE      1731
       state:
         logdb:
           TIME       1525665624.67292
           VALUE      OL CHRG
   READINGS:
     2018-05-07 06:00:24   battery.charge  100
     2018-05-07 06:00:24   battery.runtime 1731
     2018-03-22 19:33:57   lastError       ACCESS-DENIED
     2018-05-07 06:00:24   output.voltage  230.0
     2018-05-10 07:12:00   state           opened
     2018-05-07 06:00:24   ups.load        12
   helper:
     battery.charge 100
     battery.charge.low 20
     battery.runtime 1731
     battery.type PbAc
     device.mfr EATON
     device.model Eaton 3S 550
     device.serial 000000000
     device.type ups
     driver.name usbhid-ups
     driver.parameter.pollfreq 30
     driver.parameter.pollinterval 5
     driver.parameter.port auto
     driver.version DSM6-2-23541-180126
     driver.version.data MGE HID 1.33
     driver.version.internal 0.38
     input.transfer.high 264
     input.transfer.low 184
     outlet.1.desc PowerShare Outlet 1
     outlet.1.id 2
     outlet.1.status on
     outlet.1.switchable yes
     outlet.2.desc PowerShare Outlet 2
     outlet.2.id 3
     outlet.2.status off
     outlet.2.switchable yes
     outlet.desc Main Outlet
     outlet.id  1
     outlet.switchable no
     output.frequency.nominal 50
     output.voltage 230.0
     output.voltage.nominal 230
     ups.beeper.status enabled
     ups.delay.shutdown 20
     ups.delay.start 30
     ups.firmware 02
     ups.load   12
     ups.mfr    EATON
     ups.model  Eaton 3S 550
     ups.power.nominal 550
     ups.productid ffff
     ups.serial 000000000
     ups.status OL CHRG
     ups.timer.shutdown 0
     ups.timer.start 0
     ups.vendorid 0463
Attributes:
   asReadings battery.charge,battery.runtime,input.voltage,ups.load,ups.power,ups.realpower,output.voltage
   disable    1
   pollState  10
   pollVal    60
   room       Arbeitszimmer
   stateFormat Kapazität: battery.charge % Last: ups.load %

[Amenophis86]

Ist denn auf der NAS das gleiche Verhalten gegeben?

[Christian72D]

Denke nicht.
Würde das NAS gemeldet bekommen daß die USV getrennt ist müsste es sich ja runter fahren... macht es aber nicht.

[Senior Service]

Habe das gleiche Problem und deshalb gerade wie folgt gepostet.

Antw:Ankündigung: NUT - Network UPS Tools
« Antwort #136 am: Heute um 16:51:13 »

Im Prinzip hat das Modul gleich funktioniert.
Jedoch dokumentiert das  Log minütlich folgender Eintrag:

2018.12.06 16:41:12 1: localhost:3493 disconnected, waiting to reappear (USV)
2018.12.06 16:41:12 1: localhost:3493 reappeared (USV)

Ein ändern der Attribute pollState und pollVal bewirkt keine Änderung des Abfragezyklus.

[pyramid]

Liebe fhem-Gemeinde,

bei mir war genau das gleiche Thema aufgetreten. Ich war gerade dabei einen Post als Hilferuf zu schreiben, dabei bin ich (zumindest für mein System) auf die Lösung gestoßen.

Ausgangspunkt war, dass im Minutentakt die Log-Einträge vom USV/NUT-Modul geschrieben werden.

Ich nutze eine Synology Diskstation DS219p an einer APC BX950 USV verbunden per USB.

Code Auswählen Erweitern


...
2019.04.29 23:55:12 1: diskstation.fritz.box:3493 reappeared (USV)
2019.04.29 23:56:13 1: diskstation.fritz.box:3493 disconnected, waiting to reappear (USV)
2019.04.29 23:56:15 1: diskstation.fritz.box:3493 reappeared (USV)
2019.04.29 23:57:18 1: diskstation.fritz.box:3493 disconnected, waiting to reappear (USV)
2019.04.29 23:57:19 1: diskstation.fritz.box:3493 reappeared (USV)
...


Nach längerem Durchsuchen meiner Logfiles ist mir auch aufgefallen, dass es in der ersten Zeit nach dem Einrichten der USV (NUT) keine Einträge dazu gab. Es wurde lediglich ein morgens nach dem Start der Diskstation ein "reappeared" gemeldet und abends bei Herunterfahren der Diskstation ein "disconnect. Soweit ergibt es einen Sinn.

Der Zeitpunkt ab dem das Ganze angefangen hat war bei mir der 12.Januar 2019 / 14:47 Uhr vermutlich nach einem fhem Neustart. Das Logfile enthält hier folgende Einträge zum Theme "NUT":

Code Auswählen Erweitern


2019.02.12 06:32:01 1: diskstation.fritz.box:3493 reappeared (USV)

2019.02.12 14:47:17 0: Server started with 144 defined entities (fhem.pl:18463/2019-01-30 perl:5.024001 os:linux user:fhem pid:443)
2019.02.12 14:47:17 3: NUT antwortet nicht
2019.02.12 14:47:17 1: diskstation.fritz.box:3493 disconnected, waiting to reappear (USV)
2019.02.12 14:47:17 1: diskstation.fritz.box:3493 reappeared (USV)

2019.02.12 14:47:24 2: NUT Error: ACCESS-DENIED

2019.02.12 14:48:19 1: diskstation.fritz.box:3493 disconnected, waiting to reappear (USV)
2019.02.12 14:48:20 1: diskstation.fritz.box:3493 reappeared (USV)

2019.02.12 14:49:23 1: diskstation.fritz.box:3493 disconnected, waiting to reappear (USV)
2019.02.12 14:49:24 1: diskstation.fritz.box:3493 reappeared (USV)

2019.02.12 14:50:25 1: diskstation.fritz.box:3493 disconnected, waiting to reappear (USV)
2019.02.12 14:50:26 1: diskstation.fritz.box:3493 reappeared (USV)
...


Nun hab ich mir mal genauer meine aktuelle Device-Definition angeschaut uns festgestellt, dass das Attribut disable auf dem Wert "1" stand. So hatte ich es anfangs sicher nicht definiert.
Nachdem ich das Attribut wieder auf den Wert "0" zurückgesetzt habe, gab es auch prompt keine Logfile-Einträge mehr. (Reproduzierbar, da die Logeinträge wieder auftreten, sobald ich "disable =1" setze)

@Christian72D: In Deiner Device-Definition habe ich auch "disable 1" gesehen. Ich würde es an Deiner Stelle ebenfalls auf "0" zurücksetzen und schauen ob es damit behoben ist.

Am Ende kann ich zwar nicht sagen, warum es zu diesem Umstand gekommen ist, aber wenigstens das Problem für mich beheben.

Viele Grüße
  Markus

[Senior Service]

Hallo pyramid

Vielen Dank für Deinen Artikel!
Leider hat das bei mir keinerlei Erfolg gebracht. Bei mir stand das Attribut "disable" schon auf 0. Jetzt habe ich es ganz gelöscht, leider ohne Auswirkung auf die minütlichen Logeinträge.

Könntest du  bitte noch prüfen, ob die Attribute pollState und pollVal bei dir arbeiten. Ein Ändern der Attribute pollState und pollVal bewirkt bei mir keine Änderung des Abfragezyklus.

Vielen Dank!

[pyramid]

Könntest du  bitte noch prüfen, ob die Attribute pollState und pollVal bei dir arbeiten. Ein Ändern der Attribute pollState und pollVal bewirkt bei mir keine Änderung des Abfragezyklus.

Ja, habe ich bei mir getestet.
Wenn ich die Werte für pollState und pollVal hoch- oder heruntersetze werden die entsprechenden Readings weniger oft oder schneller aktualisiert.

[Senior Service]

Vielen Dank!

Da muss ich bei mir offensichtlich noch weiter suchen und schrauben. 

Beste Grüße!

[Chris489]

Gibt es schon eine Lösung?

Ich habe das selbe Problem aktuell 

Grüße

[Chris489]

War es nun so einfach ?

im DEF die Portnummer angehangen und es funktioniert.

ups 192.168.0.199:3493

[Juergen156]

Bei mir war es so einfache. Ich habe den Wert von "disable" auf "0" gesetzt und alles lief wieder.
Warum der Wert nach Monaten auf "1" stand, kann ich nicht mehr nachvollziehen.

Danke für den Hinweis.
Viele Grüsse

[Jorche]

Hallo zusammen,
meine APC USV zeigt an einem RPI das gleiche Symptom. Leider haben weder Port noch Attribut disable irgendwas dran geändert, dass regelmäßig die Kommunikation zusammenbricht und das Log geflutet wird.
Ursache scheint bei mir tatsächlich die USV zu sein, welche sich dann nicht mehr mit dem NUT Dienst synchronisiert.

Lösung von mir ist nun, einen Cron-Job laufen zu lassen, welche alle Stunde den Status des NUT kontrolliert und diesem im Falle eines Fehlers neu startet. Dabei obacht, es kann passieren, dass der NUT Service läuft, die USV aber immer noch im Dämmerzustand ist.
Im NUT Status steht dann "ups@localhost is unavailable" oder "ups@localhost is unavailable" obwohl der Status "active" / "running" ist.

Auch hier hilft NUT service stop/start 

Seit der Integration des kleinen Watchdogs, läuft die NUT Kommunikation ohne endlose Log Einträge.

Grüße
Jorche

[StephanFHEM]

2018.12.06 16:41:12 1: localhost:3493 disconnected, waiting to reappear (USV)
2018.12.06 16:41:12 1: localhost:3493 reappeared (USV)

Ein ändern der Attribute pollState und pollVal bewirkt keine Änderung des Abfragezyklus.

Das gleiche Thema habe ich in letzter Zeit vermehrt. Es wäre ja nicht so schlimm (mit den Log-Einträgen kann ich leben). Dummerweise wird aber das Reading state danach aktualisiert obwohl sich der Wert nicht ändert und ich ein event-on-change gesetzt habe...
Ergebnis: Mein Telegram sendet mir immer wieder eine Info, dass die USVs geladen sind und in den Normalmodus zurückgehen.....

Wie kann man das lösen?

[yersinia]

Versuch mal die Attribute zu setzen:
verbose 0 
pollState 300
pollVal 900