On 22:17, Thu 25 Sep 14, Charles Lepple wrote:> > I think the OMNIVS800 protocol 2012 entry came from Tripp Lite test results. (There have definitely been naming collisions in the past; hence, the messages in the drivers if you accidentally choose the wrong one.) > > Confusingly, if the USB ProductID is 0001, the Tripp Lite specific "Protocol" number (shown in "ups.firmware.aux") is probably not 0001. But if the ProductID is greater than 0001, the ProductID and Protocol should match. >Your messages in the driver helped me when I initially chose the wrong one and got the usual "Driver Not Connected" error!"> > OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe > > the OMNIVSING800 just needs to be added to the list next to it. > > Will do.Thanks> > > You're right, we have a "magic constant" in the "input.voltage" and "output.voltage" calculations for your protocol. > > https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1240 > > https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1360 >Yes I found that conversation.> > For some reason that made sense at the time, the "ups.debug.*" variables in tripplite_usb actually start printing from value+1 (I suppose because v_value[0] is always 'V'). So the input.voltage.nominal value gets set properly because v_value[1] is actually '2'. >Actually if this is reliable across models we could use it to scale actual input/output voltages respectively> I went ahead and changed the 230V nominal to 240V.Thats a moot point. After European Harmonisation (UK was on 240V EU on 220V) they settled for 230V nominal but then defined tolerences of +/-10% so that everyone suddenly "conformed" to the new regulations without doing anything. Whilst a lot of the UK is actually on 230V now my current house is still on 240V. Looked very strange on my main BestPower and Riello UPS RRD graphs as they show the +10V step change in measured voltage. Having said all that the BestPower delivers 240V and the Riello 230V (adjustable). The Tripp Lite says 240V on the box and is delivering that as its ONLINE nominal output (but drops to <200V on battery power given its a budget UPS). n>> https://github.com/networkupstools/nut/commit/f61edb5161de97944074867832edc014323340b1 > > If you want to rebuild the driver, let me know - even though yours seems to be from NUT 2.6.4, I doubt there will be any issues with building the 2.7.2+ Git version and dropping it in. >No problem. I just installed NUT 2.6.4 as that is the latest from debian (wheezy) and it happens to be running from CF on an SBC - but I have the src and toolchain on the box so no reason why I couldnt rebuild it. regards Dave
On Sep 26, 2014, at 3:48 AM, Dave Williams <dave at opensourcesolutions.co.uk> wrote:> On 22:17, Thu 25 Sep 14, Charles Lepple wrote: >> >> I think the OMNIVS800 protocol 2012 entry came from Tripp Lite test results. (There have definitely been naming collisions in the past; hence, the messages in the drivers if you accidentally choose the wrong one.) >> >> Confusingly, if the USB ProductID is 0001, the Tripp Lite specific "Protocol" number (shown in "ups.firmware.aux") is probably not 0001. But if the ProductID is greater than 0001, the ProductID and Protocol should match. >> > Your messages in the driver helped me when I initially chose the wrong > one and got the usual "Driver Not Connected" error!" > >>> OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe >>> the OMNIVSING800 just needs to be added to the list next to it. >> >> Will do. > Thanks >> >> >> You're right, we have a "magic constant" in the "input.voltage" and "output.voltage" calculations for your protocol. >> >> https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1240 >> >> https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1360 >> > Yes I found that conversation. >Well, I ended up linking to the latest version of those files, so this shows the change better: https://github.com/networkupstools/nut/commit/f61edb5161de97944074867832edc014323340b1 Still a magic constant, but now it has the nominal voltage factored in.>> For some reason that made sense at the time, the "ups.debug.*" variables in tripplite_usb actually start printing from value+1 (I suppose because v_value[0] is always 'V'). So the input.voltage.nominal value gets set properly because v_value[1] is actually '2'. >> > Actually if this is reliable across models we could use it to scale actual input/output voltages respectivelyThat's the thing, due to the patchwork of methods required to poll the different 0001-type protocols, it *was* scaling some of the voltages - just not for protocol 1001 or 2001.>> I went ahead and changed the 230V nominal to 240V. > Thats a moot point. After European Harmonisation (UK was on 240V EU on > 220V) they settled for 230V nominal but then defined tolerences of > +/-10% so that everyone suddenly "conformed" to the new regulations > without doing anything. Whilst a lot of the UK is actually on 230V now > my current house is still on 240V. Looked very strange on my main > BestPower and Riello UPS RRD graphs as they show the +10V step change in > measured voltage.I can change it back to 230V - I was going off of the x2 factor you mentioned. Either way works for me.> Having said all that the BestPower delivers 240V and the Riello 230V > (adjustable). The Tripp Lite says 240V on the box and is > delivering that as its ONLINE nominal output (but drops to <200V on battery > power given its a budget UPS). > n> >> https://github.com/networkupstools/nut/commit/f61edb5161de97944074867832edc014323340b1 >> >> If you want to rebuild the driver, let me know - even though yours seems to be from NUT 2.6.4, I doubt there will be any issues with building the 2.7.2+ Git version and dropping it in. >> > No problem. I just installed NUT 2.6.4 as that is the latest from debian (wheezy) and it happens to be running from CF on an SBC - but I have the src and toolchain on the box so no reason why I couldnt rebuild it. > regards > DaveFeel free to ask on the list if you run into any problems while rebuilding. Debian doesn't have too many odd substitutions in their control files, so it's pretty easy to either reconfigure NUT to match the ./configure paths used by the .debs, or download the debian/ overlay from http://packages.debian.org/wheezy/nut and update the versions to use the latest tar.gz source snapshot from here: http://buildbot.networkupstools.org/public/nut/waterfall?show=Debian-x64-gcc -- Charles Lepple clepple at gmail
On 08:09, Fri 26 Sep 14, Charles Lepple wrote:> Well, I ended up linking to the latest version of those files, so this shows the change better: > > https://github.com/networkupstools/nut/commit/f61edb5161de97944074867832edc014323340b1 > > Still a magic constant, but now it has the nominal voltage factored in.Just building your latest code now. Which commit is this in (just to check I have it?)> > > I can change it back to 230V - I was going off of the x2 factor you mentioned. Either way works for me.OK lets just make sure we are answering the right question. The general/specified UK/European voltage is 230V but the UPS is generating 240v. What is input.nominal.voltage meant to mean in the context of what the UPS (and upsc) reports? My guess its what it would expect to see so you can relate input.voltage to it. In that respect its 230V for the territory the model is sold into even though Tripp lite are selling it as a 240V model. Either way the differentiation only has to deal with 2x0V versus 110V and so unlikely to be the source of any confusion. Dave
> > > OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe > > > the OMNIVSING800 just needs to be added to the list next to it. > > > > Will do.Don't see the model in the compatibility web page yet at http://www.networkupstools.org/stable-hcl.html. Am I missing something? Dave
On Sep 29, 2014, at 3:28 PM, Dave Williams <dave at opensourcesolutions.co.uk> wrote:>>>> OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe >>>> the OMNIVSING800 just needs to be added to the list next to it. >>> >>> Will do. > Don't see the model in the compatibility web page yet at > http://www.networkupstools.org/stable-hcl.html. Am I missing something?We're almost finished redoing the way we build the website (to coincide with the next release of NUT). The latest is here: http://buildbot.networkupstools.org/~buildbot/cayman/docs/latest/stable-hcl.html?manufacturer=Tripp-Lite Source for that page is: https://github.com/networkupstools/nut/blob/master/data/driver.list.in -- Charles Lepple clepple at gmail