Dzisiaj dotarł UPS Green Cell. Chcę go zintegrować z HA przy pomocy integracji NUT. HA postawiony na Debianie. UPS podłączony kablem USB.
Co powinienem wpisać w to okno ?
Dane logowania, które skonfigurowałeś w serwerze NUT, oraz ewentualnie jego adres (o ile jest inny niż localhost) i port (jeśli pracuje na innym niż standardowy 3493).
Oczywiście musisz go mieć najpierw zainstalowany i skonfigurowany w debianie
https://wiki.debian.org/nut
Ooo, słabo to widzę. 
To tak naprawdę tylko kilka istotnych linijek, ale dokumentację warto chociaż przejrzeć
prawdopodobny sterownik (dla Greencell USB) to
https://networkupstools.org/docs/man/nutdrv_qx.html
lub
https://networkupstools.org/docs/man/blazer_usb.html
Jeśli uruchomisz to uzupełnij listę kompatybilności swoim modelem UPSa
PS Jeśli masz instalację Supervised to użyj Addona NUT (Network UPS Tools), ale i tak musisz go skonfigurować.
Ten protokól Twojego UPSA to Megatec/Q1 więc balazer powinien zagadać.
Tak, mam Supervised, jutro poczytam.
Chociaż myślę, że bez mojego Guru się nie obejdzie ( oczywiście w poniedziałek)
@azak43 tu wkradła się literówka - chodzi o Blazer, a konkretnie o sterownik blazer_usb
Możesz na próbę odłączyć i podłączyć USB i wydać w terminalu np. komendę
dmesg | grep "usb "
prawdopodobnie urządzenie się przedstawi w ostatnich linijkach w wystarczającym stopniu
Można też “na żywo” śledzić loga np. tak:
watch "dmesg | tail -15"
(tu informacji potencjalnie będzie więcej, bo nie jest filtrowana po ciągu, którego się spodziewam, tylko później ctrl+C)
@szopen … o ile odczyt stanu UPS i integracja z HA jest dość prosta, jak również bezpieczne zamknięcie sytemu.
Zastanawia mnie inny aspekty - załóżmy, że system się zamknął a UPS nadal zasila z baterii… i nastąpi powrót sieci.
Co w takim razie podniesie go z powrotem? Do tego potrzebny jest faktyczny zanik napięcia i jego powrót.
Z punktu widzenia sprzętu (zasilacza) taki zanik nigdy nie wystąpił, a system jest już zamknięty.
Oczywiście jest taki problem i nie ma co chować głowy w piasek, ba - nawet taka sytuacja zdarzyła mi się raz i stąd mam tygodniową dziurę w statystykach, ale rozwiązanie jest zależne od naszych wymagań 
Po tym zdarzeniu przeanalizowałem ryzyko i jako, że na HAOS generic i HA ze standardową bazą istotne awarie wskutek utraty zasilania są ekstremalnie rzadkie, postanowiłem nie zamykać systemu nawet przy krytycznym stanie akumulatora (oczywiście nikogo nie zachęcam do takich rozwiązań, szczególnie gdy ma bazę mniej odporną na tego typu wywrotki).
Lepsze rozwiązania są mniej lub bardziej naokoło - np. przed (i ewentualnie za UPSem, a przed maszyną z HA - tu taka istotna uwaga - nie każdy UPS chce pracować bez obciążenia!) UPSem smartplug(i) z dostępem chmurowym i ustawioną opcją by po powrocie zasilania się załączył(y) - to załatwia 2 kwestie za 1 zamachem - możliwość zareagowania na taką okoliczność i możliwość awaryjnego zdalnego odcięcia zasilania.
Oczywiście w takim wypadku trzeba zapewnić sobie dostęp do internetu bez UPSa. edit: z tą wstawką o routerze bez UPSa poleciałem z pamięci i coś mi się jednak “nie klei” (ale kombinowałem na różne sposoby, może to dotyczyło innej sytuacji?) edit2: jednak jest OK jeśli zakładamy potencjalną możliwość odcinania UPSa od zasilania, to oczywiste jest, że nie można mieć kluczowych elementów sieci zapewniających dostęp do internetu za UPSem, bo jest potencjalna możliwość, że się pozbawimy możliwości sterowania gdy UPS nie pracuje (rozwiązanie optymalne to główne łącze za UPSem, a backupowe bez UPSa, z łącza backupowego tam gdzie mam UPS zrezygnowałem dość dawno, bo to mocno komplikowało mi konfigurację sieci - 2x LTE, więc obecnie mam tam podtrzymywany HA i sieć i wierzę, że UPS zawsze wstanie po powrocie napięcia).
Potencjalnych rozwiązań jest z pewnością sporo więcej, chociażby można by wykombinować jakiegoś watchdoga choćby na bazie ESP, a to przy okazji by mogło załatwić też kwestię opóźnienia startu systemu w przypadku rozładowanych akumulatorów (tak właśnie wyglądał mój drugi przypadek, gdy użycie UPSa nie dało rady - powroty i zaniki zasilania podczas przywracania sieci przez ZE po dłuższej awarii spowodowały, że za którymś razem HA się nie podniósł poprawnie).
Więc nie jest to wydumany przypadek i jeśli coś jest teoretycznie możliwe to na pewno się wydarzy 
W Qnap chyba to uwzględnili i jest dodatkowy tryb reakcji na zanik napięcia zasilania.
System zamyka dostęp do krytycznych zasobów i wyłącza potencjalnie zagrożone procesy.
Myślę, że w zależności od sposobu instalacji HA udałoby się taki mechanizm również wprowadzić (chyba, że już coś takiego jest i prochu nie wynalazłem?). Potrzebna do tego wiedza jednak przekracza moje umiejętności. Czytając Twoje wpisy myślę, że dałbyś radę 
Jednak nie jest tak kolorowo i w Qnapie musisz sam oszacować czas po którym nastąpi zamknięcie systemu. Zupełnie nie uwzględnia stopnia naładowania baterii i przewidywanego czasu pracy.
W moim przypadku jest to problem, mam UPSa z zewnętrzną bat. 65Ah i czas może wynosić nawet 24h.
Zasilam z tego całą strukturę sieci, bramę garażową i kocioł CO. USP ma dwa wyjścia: jedno zasila do śmierci, a drugie wyłącza zasilanie po przekroczeniu ustawionego progu. Z tego powodu wcześniejsze oszacowanie czasu “zamknięcia systemu” jest nie możliwe - pomiar również (wyniki są grubo niepowtarzalne).
Z tego powodu powstały boje opisane w temacie
Działa to mniej więcej tak: po prostu oszukuję Qnapa tworząc wirtualnego UPS na podstawie rzeczywistego i sam, na bieżąco ekstrapoluje czas podtrzymania. Pozostałe urządzenia są odporne na gwałtowny zanik napięcia i całość działa bezawaryjnie.
Świetny pomysł, aby go podrzucić twórcom HA i HAOS, ale obawiam się że potencjalnie możliwy do realizacji tylko w HAOS generic (więc jak znam życie nie zostanie wprowadzony, jako za mało międzyplatformowy).
Chyba żartujesz, nie jestem programistą i mam tylko dość ogólną wiedzę (choć może z szerokiego zakresu?), więc nawet mając “wolę walki” (a ostatnio bardzo mi jej brakuje) nie czuję się na siłach nawet ruszyć takiego tematu (gdybym miał ciśnienie pewnie próbowałbym rozwiązania na bazie ESPHome i “bezczelnych” modyfikacji peceta).
Gratuluję pomysłu, chyba trudno to lepiej rozwiązać., ale i UPSa masz “z grubej rury”.
UPS taki sam jak w temacie, tylko wymieniłem aku na większej pojemności. Podłączyłem jako zewnętrzne. On katalogowo obsługuje do 42Ah więc przy moich 65Ah mam tylko niższy prąd ładowania na poziomie 4.2A, zamiast 6.5.
1 polubienie
@RobinI30 ten “wirtualny UPS” to chyba coś jak mam u siebie. Choć może nie do końca. Ja mam podłączone do Synology, a on wystawia w sieć serwer dla innych urządzeń z danymi od UPSa. Sam UPS podpięty jest pod USB. Nawet tutaj gdzieś były opisywane moje boje z podpięciem tego po sieci pod NR.
Mechanizm jest ten sam, różnica jest taka że Synology serwuje dane z UPS 1:1 a u mnie sygnalizacja pracy z baterii jest zgłaszana gdy zbliżam się do krytycznego poziomu naładowania aku. Oszustwo jest po to aby zbyt szybko i niepotrzebnie systemy się nie pozamykały.
Niestety taka uroda moich urządzeń, że mogę ustawić tylko czas po którym system się zamyka.
Przy tak dużych bateriach może to wystąpić pomiędzy 8-24h.
Dokładnie nie wiem ile to wynosi, ponieważ przez ten długi okres charakter obciążenia może się losowo zmieniać i trzeba na bieżąco kontrolować stopień naładowania i niepotrzebnie zbyt szybko nie zamykać systemu.
Nie robiłem rzeczywistej próby do całkowitego rozładowania … bo po 8h mi się znudziło czekać.
Dane logowania, które skonfigurowałeś w serwerze NUT, oraz ewentualnie jego adres (o ile jest inny niż localhost) i port (jeśli pracuje na innym niż standardowy 3493).
Mi na localhost nie działało, ruszyło dopiero po wpisaniu w adresie: a0d7b954-nut
Zgaduję, że masz instalację HAOS-ova (na VM) dla HAOS-generic x86-64/aarch64/rpi/khadas/odroid/tinker/yellow prawdopodobnie wystarcza localhost.
Zasadniczo po prostu to ma być prawidłowy adres serwera NUT (przecież nawet nie musi być on na tej samej maszynie).
Witam, po ostatniej aktualizacji pojawił mi się problem z dodatkiem NUT. Może ktoś podpowiedzieć, od czego zacząć
Log z ha
Logger: homeassistant.config_entries
Source: config_entries.py:388
First occurred: 10:23:48 (1 occurrences)
Last logged: 10:23:48
Config entry '192.168.99.10:3493' for nut integration not ready yet: Error fetching UPS state; Retrying in background
Log z dodatku
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
cont-init: info: running /etc/cont-init.d/00-banner.sh
-----------------------------------------------------------
Add-on: Network UPS Tools
Manage battery backup (UPS) devices
-----------------------------------------------------------
Add-on version: 0.11.0
You are running the latest version of this add-on.
System: Home Assistant OS 9.0 (amd64 / qemux86-64)
Home Assistant Core: 2022.9.5
Home Assistant Supervisor: 2022.09.1
-----------------------------------------------------------
Please, share the above information when looking for help
or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
cont-init: info: /etc/cont-init.d/00-banner.sh exited 0
cont-init: info: running /etc/cont-init.d/01-log-level.sh
cont-init: info: /etc/cont-init.d/01-log-level.sh exited 0
cont-init: info: running /etc/cont-init.d/02-set-timezone.sh
[10:55:56] INFO: Configuring timezone
cont-init: info: /etc/cont-init.d/02-set-timezone.sh exited 0
cont-init: info: running /etc/cont-init.d/nut.sh
[10:55:56] INFO: Setting mode to netclient...
cont-init: info: /etc/cont-init.d/nut.sh exited 0
cont-init: info: running /etc/cont-init.d/nutclient.sh
cont-init: info: /etc/cont-init.d/nutclient.sh exited 0
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun upsd (no readiness notification)
services-up: info: copying legacy longrun upsmon (no readiness notification)
s6-rc: info: service legacy-services successfully started
[10:55:56] INFO: Starting the UPS monitor and shutdown controller...
0.000000 fopen /run/nut/upsmon.pid: No such file or directory
0.000133 Using power down flag file /etc/killpower
0.000234 UPS: ups@192.168.99.10 (slave) (power value 1)
0.000300 debug level is '1'
0.000329 Warning: running as one big root process by request (upsmon -p)
0.000523 Init SSL without certificate database
0.001815 Trying to connect to UPS [ups@192.168.99.10]
0.002611 Logged into UPS ups@192.168.99.10
0.002769 Poll UPS [ups@192.168.99.10] failed - Data stale
{"message":"Event nut.ups_event fired."}Network UPS Tools upsmon 2.7.4
5.003444 Poll UPS [ups@192.168.99.10] failed - Data stale
{"message":"Event nut.ups_event fired."}Network UPS Tools upsmon 2.7.4
10.004268 Poll UPS [ups@192.168.99.10] failed - Data stale
15.004865 Poll UPS [ups@192.168.99.10] failed - Data stale
20.005433 Poll UPS [ups@192.168.99.10] failed - Data stale
25.006030 Poll UPS [ups@192.168.99.10] failed - Data stale
30.006647 Poll UPS [ups@192.168.99.10] failed - Data stale
35.007145 Poll UPS [ups@192.168.99.10] failed - Data stale
40.007775 Poll UPS [ups@192.168.99.10] failed - Data stale
45.008368 Poll UPS [ups@192.168.99.10] failed - Data stale
50.009081 Poll UPS [ups@192.168.99.10] failed - Data stale
55.009589 Poll UPS [ups@192.168.99.10] failed - Data stale
60.009875 Poll UPS [ups@192.168.99.10] failed - Data stale
65.010217 Poll UPS [ups@192.168.99.10] failed - Data stale
70.010985 Poll UPS [ups@192.168.99.10] failed - Data stale
75.011689 Poll UPS [ups@192.168.99.10] failed - Data stale
Edit: Już nieaktualne restart hosta rozwiązał problem.
UPS podłączony pod HA-testowe (dodatek NUT zainstalowany, integracja NUT wykrywa UPS-a, działa).
users:
- username: upsuser
password: trudnehaslo
instcmds:
- all
actions: []
devices:
- name: UT850EG
driver: usbhid-ups
port: auto
config: []
mode: netserver
shutdown_host: "false"
Chciałbym spróbować połączyć się z tym serwerem NUT na innej maszynie:
konfiguracja dodatku jako netclient
users:
- username: upsuser
password: tosamotrudnehaslo
instcmds:
- all
actions: []
devices:
- name: UT850EG
driver: usbhid-ups
port: auto
config: []
mode: netclient
shutdown_host: true
remote_ups_name: UT850EG
remote_ups_host: homeassistant
list_usb_devices: true
i_like_to_be_pwned: false
leave_front_door_open: false
remote_ups_password: tosamotrudnehaslo
remote_ups_user: upsuser
Niezależnie czy konfigurację dla → remote_ups_host podam jako np. http://IP, IP, homeassistant (nazwa po jakiej jest wpisany w supervisor/sieć) dostaję niepowodzenie połączenia
UPS [UT850EG@homeassistant]: connect failed: Connection failure: Connection refused
Gdzie robię błąd albo czegoś nie wpisałem ?
Niestety nie dało rady
UPS [UT850EG@a0d7b954-nut]: connect failed: Connection failure: Connection refused