> Can you post the driver here, even if it is not completely ready?See attachements (it's split into several files). -------------- next part -------------- A non-text attachment was scrubbed... Name: data.c Type: application/octet-stream Size: 8204 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20070226/6fa44e0c/data-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: data.h Type: application/octet-stream Size: 2841 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20070226/6fa44e0c/data-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: driver.c Type: application/octet-stream Size: 12190 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20070226/6fa44e0c/driver-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: io.c Type: application/octet-stream Size: 2596 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20070226/6fa44e0c/io-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: io.h Type: application/octet-stream Size: 260 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20070226/6fa44e0c/io-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: usb_dummy.c Type: application/octet-stream Size: 401 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20070226/6fa44e0c/usb_dummy-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: usb_netbsd.c Type: application/octet-stream Size: 3270 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20070226/6fa44e0c/usb_netbsd-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: usb.h Type: application/octet-stream Size: 270 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20070226/6fa44e0c/usb-0001.obj -------------- next part -------------- io.c handles opening/probing USB (and eventually serial ports), sending command strings and receiving reply strings. data.c dissects various reply strings (in particular WH and Q3). usb_netbsd.c hadles USB I/O on NetBSD. usb_dummy.c makes the project compile and link on a non-NetBSD system. driver.c is the actual NUT driver.> Yes, input.frequency.low/high. See 'docs/new-names.txt'.OK, I incorporated all the new variables I could support. Due to extremly kind people at Masterguard providing me with detailed documentation on the phone, I also added a few more features like setting the output voltage and disabling the buzzer (both untested at the moment). I also corrected the use of the various delay values. A few more questions arose in the meantime: I can disable the buzzer, but I cant't tell (I think) whether it's currently buzzing or not. What shall I put into ups.beeper.status if it's not disabled? If I disabled it, I guess I have to put "muted" into the var? Or should it only say "muted" if it would be making a noise if not disabled? One of the status flags can inform me of an internal UPS error. Any means of propagating that? I also have a "test in progress" flag. Should I set CAL for that. Last, there's a "shutdown in progress" flag. Any place for that one?
Hello again. Back in the day (2007) I wrote a USB-capable driver for my Masterguard/Phoenixtec UPSes (in case you locally archived this list, this very mail is a reply to a rather long thread from then), which I used ever since. However, the world has been going on since then and I need to get away with the old 2.0.4 binaries currently in use. These boxes (I use two A3000-19 and two A700-19) are extremely robust and while Masterguard has been acquired by Chloride, then Emerson and is now Vertiv and finally they moved from Erlangen to Munich, I'm still talking to the same person and they still provide preventive maintanance and battery replacement (at very reasonable prices), so I'd like to stick to them. So I'll need to pick up my old work and integrate someting into an up-to-date version of NUT and try again to upstream it. The (even back then) existing masterguard driver is not an option (provides less than half the information mine does) and looks weird. No existing driver seems to support the central get-status (GS) command used by these UPSes. I could just try to port my thirteen-year old work (USB will only work on NetBSD) but I guess it's preferrable to start over. I do have an official protocol definition (which I was asked not to disclose). These UPSes have both serial and USB ports; the USB protocol is neither HID nor a usual (as far as I can tell) serial-over-USB one, but trivial. According to reading my sources, it may require some timing quirks but I'm unsure whether my workarounds in the old code were owed to the UPS or old NetBSD USB code. Reading through the Developer Guide, it looks like the qx driver (which I guess didn't exist back then) could be well suited, but I'm unsure how it handles USB and whether, if one command sent to the UPS will return a dozen values, it will issue the command once or a dozen times (which could be a show-stopper since the connection is awfully slow). In case it turns out I can't base on the qx framework: what's the suggested way to abstract the serial/USB connection thing. Any hints/documentation pointers welcome.