I forgot to mention...
> Actually, given that the output is a DC-DC converter, you really will
>want to have some way to measure battery voltage so you can get
>SOC/runtime. I would suggest writing to their support and tell them
>what you want. From the site, they have higher than usual odds of
> If you don't have a machine that can run nut as part of the always on,
> then your RPI0W approach makes a lot of sense.
This is definitely my scenario.
No other intelligence is involved so the Rpi was one-stop-shopping.
I had thought about an Rpi Pico, but again, it would not have been as
strai
Tom via Nut-upsuser writes:
>>That makes sense. So you'll have input voltage, output voltage, and
>>output current I would guess. You might consider a nodemcu (ESP8266)
>>publishing via MQTT to reduce power and use of unobtainium.
>
> Yes, that is exactly what I was planning to instrument. May
Greg:
Thanks for your inputs...
>That makes sense. So you'll have input voltage, output voltage, and
>output current I would guess. You might consider a nodemcu (ESP8266)
>publishing via MQTT to reduce power and use of unobtainium.
Yes, that is exactly what I was planning to instrument. Maybe
Tom via Nut-upsuser writes:
> 1. Yes, I plan to use a Raspberry Pi Zero W with an I2C interface wired to
> it which can monitor multiple channels of voltage and current. Here is an
> example I am considering:
> https://www.amazon.com/Comimark-INA3221-Triple-Channel-Current-Voltage/dp/B07X524KSK
Jim:
> Regarding dummy-ups looping, note that NUT v2.8.0 introduced a
separation of mode to
>`dummy-once` (default for `*.dev` files to be slurped once) and
`dummy-loop` (default for
> others to be re-read, e.g. `*.seq` files or your use-case). Previously it
behaved like a
>`dummy->loop` for all.
> Do you think there could be some merit in either embellishing dummy-ups
or deriving a new driver from it that is sanctioned as a 'file-based'
interface for NUT?
I'd say one problem would be relative inefficiency and overheads: you have
one process talking to the device to extract data, save it
Is that with both UPSes on same machine?
A quick guess would be that insufficient data points to identify the device
are configured (vendorid, productid, serial...) in ups.conf, so both
drivers connect to the first match. I'd expect them to conflict and one
would die or both loop reconnecting, if
Charles:
Thank you,
I will take a look at the i2c drivers you mention as well as your notes.
As I noted in my previous post, I currently like the looks of the ina3221
i2c device. It has a 16-bit ADC, can measure 12+ volts directly, it has 3
channels, and it can sense current. Although I probabl
On February 20, 2023 12:01:46 PM GMT+02:00, Laurent Taieb via Nut-upsuser
wrote:
>Hi mailing list,
>I looked at all FAQ and docs and can’t find a solution.
>I installed but on both Kali Linux and Ubuntu.
>(For comparison purposes)
>I’m trying to connect and monitor two UPS APC via usb.
>One is
Hi mailing list,
I looked at all FAQ and docs and can’t find a solution.
I installed but on both Kali Linux and Ubuntu.
(For comparison purposes)
I’m trying to connect and monitor two UPS APC via usb.
One is a back-ups bx1400 which I can see via via upsc.
The second one is a more recent one smc 150
11 matches
Mail list logo
