Arjen de Korte ha scritto:
Users don't read the documentation or the man pages. You know that first
hand (no pun intended). :-)
?
Could it be that the card is rebooting? If you're running multiple
clients in parallel, this might trigger an NMC reset.
Ok, I didn't noticed it at first: the NMC
Citeren Marco Chiappero :
The problem is, that this flag will never be cleared by an alarm message.
I can't see the problem, it's just for testing purpose, while
setting things up. Once done NUT must be restarted, if that schema
is used.
It's either we don't use the test buttons, or tell p
Arjen de Korte ha scritto:
Citeren Marco Chiappero :
Maybe there is something I'm missing, but if that particular machine
don't need to go down just do not let it shutdown, it will simply see
the low battery flag and notice it.
The problem is, that this flag will never be cleared by an alarm
Citeren Marco Chiappero :
Maybe there is something I'm missing, but if that particular machine
don't need to go down just do not let it shutdown, it will simply
see the low battery flag and notice it.
The problem is, that this flag will never be cleared by an alarm
message. The NMC does s
Arjen de Korte ha scritto:
There is no guarantee that the machine where the driver is running on is
also powered by the UPS. Most systems administrators like NUT because it
allows you to centralize UPS monitoring from a single machine. Allowing
the above would mean that each NMC would require a
Citeren Marco Chiappero :
I'm getting frequent data stale errors too.
Most likely, the NSM is not accepting the subscription. In order not
to flood the NSM with connection attempts, the driver will only retry
once every 180 seconds and continues running in non-subscribed mode as
a fallba
Citeren Marco Chiappero :
When you read the corresponding values from the summary page, the
values are reversed however. If we would parse the summary page
between these alarms (be it right after parsing an alarm or just
before receiving the next), with every new incoming alarm, the
previ
Marco Chiappero ha scritto:
Well, the test is supposed to perform a shutdown, so it's assumed that
NUT is restarted. I see no problem in this behaviour.
I compiled your code yesterday evening, everything looks fine but I
noticed that every 180 secs a new subscription is made: is there a
reason
Arjen de Korte ha scritto:
Citeren Marco Chiappero :
When you read the corresponding values from the summary page, the values
are reversed however. If we would parse the summary page between these
alarms (be it right after parsing an alarm or just before receiving the
next), with every new inc
Citeren Arjen de Korte :
BTW it's the same reason why we need to parse differently the
subscription reply, there is no root element). Maybe my code was a
little bit obscure about it.
No, it was very clear. But the NMC sends out alarms separately.
What's different here, is that the arrival o
Citeren Marco Chiappero :
In the meanwhile I'm having a really quick look at the code
and there is a small issue in the upsdrv_updateinfo:
the alarm parsing code is fine as long as you have a single message
at time in the socket buffer "buf", but if the NMC sends burst of
messages the ne_xml
Arjen de Korte ha scritto:
Citeren Marco Chiappero :
I like it! I'm waiting for news :)
I just committed a 'clone-outlet' driver and a first shot of the
integrated NSM client in the netxml-ups driver. Have fun!
Thanks! I hope to have a try tomorrow :)
In the meanwhile I'm having a really q
Citeren Marco Chiappero :
I like it! I'm waiting for news :)
I just committed a 'clone-outlet' driver and a first shot of the
integrated NSM client in the netxml-ups driver. Have fun!
I'm pleased we had this long chat, thank you! :)
Likewise. Your example code really helped in figuring
Arjen de Korte ha scritto:
Citeren Marco Chiappero :
[...]
I like it! I'm waiting for news :)
I'm pleased we had this long chat, thank you! :)
Best regards,
Marco
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.d
Citeren Marco Chiappero :
Yes, that's what I'm intending to do (and what I have already done
for a large part already by the way). This will reduce the latency
for changes in the power state to essentially zero. At the same
time, we can increase the pollinterval to something like 60+
seco
Arjen de Korte ha scritto:
Yes, that's what I'm intending to do (and what I have already done for a
large part already by the way). This will reduce the latency for changes
in the power state to essentially zero. At the same time, we can
increase the pollinterval to something like 60+ seconds
Citeren Marco Chiappero :
Uhm are you saying we should subscribe even the netxml-ups driver to
lower NUT load? Maybe there's something I don't know yet about the
extrafd... but, shouldn't we make better to include the nsm code in
the netxml-ups driver/mge subdriver?
Yes, that's what I'm i
Arjen de Korte ha scritto:
Citeren Marco Chiappero :
We will have an NSM client in NUT, if not only to limit the polling rate
(which has bothered me for quite a while). Currently, at a mere 5 second
polling rate, the CPU load for the netxml-ups driver is almost an order
of magnitude that of th
Citeren Marco Chiappero :
Understood... you are indeed right and I'm a bit doubtful...
However adding this in NUT requires a low amount of code, NUT is
using almost no CPU at all and the configuration can be still simple
enough (for example: MODE=standalone, LISTEN = name.domain.tld,
bas
Arjen de Korte ha scritto:
Citeren Marco Chiappero :
This is what I expected too, but from what I have observed when trying
this out, this doesn't seem to be the case. If we poll for the XML
summary pages after receiving an alarm, the discussion is moot anyway,
since so far I have not seen any
Citeren Marco Chiappero :
Never mind. The alarm messages are not bound to a specific outlet,
but are sent to all NSM clients that are connected.
The NMC will send some alarm messages rather than others depending
on the outlet the client system it is attached to.
This is what I expected too,
Arjen de Korte ha scritto:
Citeren Marco Chiappero :
Never mind. The alarm messages are not bound to a specific outlet, but
are sent to all NSM clients that are connected.
The NMC will send some alarm messages rather than others depending on
the outlet the client system it is attached to.
For
Citeren Marco Chiappero :
I managed to get twice connected at the same time from the same
machine to a single UPS using different hostnames, so it's
definitely not an IP based check (at least here with 66102 / EC).
Never mind. The alarm messages are not bound to a specific outlet, but
are
Marco Chiappero ha scritto:
Did you already try to connect multiple drivers yet? The NMC I'm using
(66102 / GA) seems to allow only a single TCP connected subscription
from any single IP. So if a driver is already connected, starting
another one will make the NMC disconnect the others that are
Marco Chiappero ha scritto:
Yes, I think you're right. I tried ones, and I sow that the NMC closes
Damn, s/ones/once/ && s/sow/saw/... thought some words, wrote some
others. Sorry for my bad English. :-(
Regards,
Marco
___
Nut-upsdev mailing list
Arjen de Korte ha scritto:
Citeren Marco Chiappero :
More or less, yes. In order to limit the number of variables that need
to be set, I would limit the configuration to LOCAL only and provide
some sensible defaults for the shutdown delay and shutdown timer
however. By explicitly setting these
Citeren Marco Chiappero :
I'm sorry, I'm a bit tired and I didn't read carefully this part, so
please forget the previous message. So, connected mode only,
one_ups-one_driver, same configuration options from the previous
code? Ok?
More or less, yes. In order to limit the number of variabl
Arjen de Korte ha scritto:
Please do follow up on the NSM driver, but make this a separate one (so
don't include it in the netxml-ups driver). This not only reduces the
load on the NMC, but it will also make the code much cleaner, since you
don't have to deal with the differences between conne
Arjen de Korte ha scritto:
Citeren Marco Chiappero :
Yes, if we do care about detailed info. The summary page can be enough
for that, but at this point we should introduce changes in the
netxml-driver and a new configuration key (such as "extended = true")
which is not good.
The summary page
Citeren Marco Chiappero :
In that case, you would indeed be able to run multiple NSM enabled
drivers in parallel. The only objection that remains then is that
putting this in the netxml-ups driver is probably not a good idea.
It would be quite a burden on the little micro controller in the
Arjen de Korte ha scritto:
No. This would be a problem when using the UDP protocol, that I didn't
implemented, where there is a single socket reading broadcast messages
sent by the UPSes. In such case we would need the driver approach (but
that breaks the single_UPS--single_driver_instance desi
Citeren Marco Chiappero :
1) Both netxml-ups drivers can't connect at the same time via NSM
to their respective NMC's. We must have two instances of the
netxml-ups driver running (to provide access to all variables in
the UPS) and as far as I can see we can only accommodate one NSM
client
Arjen de Korte ha scritto:
1) Both netxml-ups drivers can't connect at the same time via NSM to
their respective NMC's. We must have two instances of the netxml-ups
driver running (to provide access to all variables in the UPS) and as
far as I can see we can only accommodate one NSM client (due
Citeren Marco Chiappero :
Sorry but I'm getting bored with this discussion, I would prefer be
told that you do not want to include such code (which is not a
problem) instead of reading sometimes pointless objections. The
subdriver solution is not going to break backward compatibility or
s
Stuart D. Gathman ha scritto:
If I understand the problem correctly, here is a possible solution: create
another daemon (mged) that connects to the high end UPS and in turn listens on
multiple sockets, one for each outlet. Each socket would simulate a simple
UPS. There would be a NUT driver for
On Mon, 26 Oct 2009, Arjen de Korte wrote:
> >A possible sample configuration could be:
> >
> >[globalups]
> > driver = mgensm-ups
> > port = parallel
> > minimum = 1
> > ups1.port = ups1.domain.com
> > ups1.outlet = main
> > ups2.port = ups2.domain.com
> > ups2.outlet = 2
> > ...
>
> Yes. In the
Arjen de Korte ha scritto:
Citeren Marco Chiappero :
A possible sample configuration could be:
[globalups]
driver = mgensm-ups
port = parallel
minimum = 1
[...]
The 'minimum' parameter and redundancy is something that should be dealt
with in the client(s), not the driver. This is
Citeren Marco Chiappero :
A possible sample configuration could be:
[globalups]
driver = mgensm-ups
port = parallel
minimum = 1
ups1.port = ups1.domain.com
ups1.outlet = main
ups2.port = ups2.domain.com
ups2.outlet = 2
...
The 'm
Arjen de Korte ha scritto:
Sure, but a single driver could contain all the (vendor) specific
logic without tainting the upsd code (starting from a netxml-ups clone
and my patch).
Your proposed changes to the netxml-ups driver
I have never proposed changes to the netxml-ups driver, I proposed
Citeren Marco Chiappero :
Ok, I clearly see your point now, the NSM would not follow this
design rule, however it could be an acceptable solution, requiring
not much code and no modification at all to the current structure.
It's not a design rule, its how the socket protocol works. One
co
Arjen de Korte ha scritto:
That is where the problem lies. Currently, the upsd server connects to
drivers in a one driver (instance), one UPS mode:
UPS-1 --- driver-A + + upsmon client
| |
UPS-2 --- driver-B --- upsd server --- upsmon c
Citeren Marco Chiappero :
Yes, that's why I was asking about mge-xml subdriver vs. new driver
choice. However my idea was to keep things easy and to basically
create a NSM clone for NUT.
That is where the problem lies. Currently, the upsd server connects to
drivers in a one driver (insta
Arjen de Korte ha scritto:
So you can't run more than one NSM driver on a single host (which would
be needed to fit into the existing NUT infrastructure, where each
controllable outlet should be exposed as a single UPS). You'd need a
special kind of driver instead that would expose all the NMC'
Citeren Marco Chiappero :
Currently I have no spare time for coding (I hope to have some time
in the next weeks), but in the meantime I'd like to continue
discussing about the NSM driver for further details.
I have digged into this deeper and have come to the conclusion that
creating a dr
Marco Chiappero ha scritto:
Hi Arjen,
sorry for my late reply, it's been a really hard work week.
Hi Arjen,
are you there?
Currently I have no spare time for coding (I hope to have some time in
the next weeks), but in the meantime I'd like to continue discussing
about the NSM driver for furth
Hi Arjen,
sorry for my late reply, it's been a really hard work week.
Arjen de Korte wrote:
I very much like the basic concept behind this, this is certainly worth
investigating further. I would prefer to make this a separate driver
(proposal, netnsm-ups) instead though. The reason is that you
Citeren Marco Chiappero :
[...]
It's quite simple, upsd sees and exposes a single UPS as usual, but
I'd say there's no way to support redundant configurations.
Have a look at the code.
I very much like the basic concept behind this, this is certainly
worth investigating further. I would p
Arjen de Korte wrote:
Considering the latter, maybe. It all depends how well this fits into
the existing driver-server-client architecture and from what I
understand from the above, it looks like you're basically creating an
integrated driver/client that bypasses the upsd server.
Uhm, not exa
Citeren Marco Chiappero :
some time ago I bought at discount price a NMC for managing a few
computers using the programmable outlets features available on my MGE
Evolution, unuseful otherwise (ATM). However, expecially for my server
machine, I don't like very much the NSM client provided by MGE/
Hi all,
some time ago I bought at discount price a NMC for managing a few
computers using the programmable outlets features available on my MGE
Evolution, unuseful otherwise (ATM). However, expecially for my server
machine, I don't like very much the NSM client provided by MGE/Eaton and
I'd rath
50 matches
Mail list logo
