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 exactly. It is a driver/NMC client, but it just sets the driver LB state, reading alarm messages from the NMC rather than from the get_object.xml page (because the NMC knows the outlet the system is attached to). Upsd and upsmon are still there. Well, we somehow bypass upssched when using local settings, but it doesn't matter at all. 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.
Also note that a setup where multiple clients connect to the NMC doesn't scale particularly well. The number of concurrent connections to the NMC is limited, depending on the model you have.
Yes, you're right, but it depends on the setup, for some of them it can be useful.
Having said that, I'd still be interested in looking at your changes, to see if there are things that we might use in the netxml-ups driver we have. Feel free to attach what you made and we can work from there. I see no reason why we couldn't create a branch in the SVN tree to see if we can work out something that fits in the existing architecture.
Ok, good. As I don't know the patch format you prefer, the whole files are attached, sorry. Please, consider that the code is still not perfect /complete, there might be many errors I didn't notice yet. The code have been tested a while, staleness included, but further testing is certainly needed.
Some notes:Had to temporary add some subdriver parameters code in the netxml-ups driver. To save coding time and avoid some error handling I used libneon sockets, even though a non-blocking read is lacking (a 1 second timeout is used instead, still acceptable for the upsdrv_updateinfo() point of view). So, need to use libneon with timeout support ATM. BTW, a small fix for the Evolution 650 model is included. Broadcast/udp support (= more clients) can be added in the future without much pain.
After reading the code, please let me know if a NSM still sounds interesting.
Best regards, Arjen
Regards, Marco
PS If you want to control multiple outlets of your UPS and want a NUT only solution, have a look at the 'clone' UPS driver that is available now.
Thanks, I've heard about it and I think it's a good thing, but I'm not going to throw away my NMC ;)
nut-nsm.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
