search for: gamatronics

On Dec 18, 2013, at 3:17 AM, Leon Vak wrote: > Actually, someone has already done most of the work for our units, however I might have general technical details to contribute, like the fact that the driver for our equipment is called "gamatronic", while actually it is just the well-known SEC protocol (from the former Systems Enhancement Corporation) and not our invention. I wonder

I was told by someone who used to have a Gamatronic to use the Fenton driver. However, when I use the Fenton driver I receive the following error: Unknown ups - please report this ID string: #GAMATRONICS SC06GM0G V8.0 Detected Unknown C06GM0G on /dev/ttyS1 The person who pointed me at this driver mentioned that Gamatronic changed their banner and a patch or code change is needed. I installed nut from rpm, so I don't have the source. Does anyone have advice how to get this ups to talk t...

Greetings to all developers of the Network UPS Tools, and Merry Christmas greetings to those of you who celebrate! I have been looking in to your work from time to time, and I am very impressed with your efforts. I think this is a good time to officially supply the required information about Gamatronic products to the community. Furthermore, I would like to know how our company may contribute

I have a Gamatronic Smart Compact 750. I have it connected to my linux machine via serial cable and am running nut 2.0.3. There is no interruption in power, but the ups is reporting OB (on battery). Is there a configuration option I am missing? The relevant ups.conf entry is: [Gamatronic] port = /dev/ttyS1 desc = "Home Gamatronic UPS" driver = genericups

Hi I am running FC5 with nut coming from the fc5 extras repositories. I am trying to configure a Gamatronic D-Compact ups. The cable that came with the ups has a serial connector on one end and a usb on the other. cat /proc/bus/usb/devices produces T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P:

I wasn't clear. battery.runtime.low is not a counter, but a value estimated in seconds that is decreasing conforming the battery is discharging. It's mean: How much time (in seconds) will be necessary until the battery achieve the depleted status ( http://www.networkupstools.org/protocols/sec.html#Estimated_Minutes ) . If the UPS don't have a load, this value will be higher than the

This is the same as https://github.com/networkupstools/nut/issues/254 , right? (It's on my TODO list. DDL updates take a little longer than HCL updates.) Other comments below. > On Dec 29, 2015, at 1:55 PM, Thiago Wiezbicki - NHS <thiago.wiezbicki at nhs.com.br> wrote: > > Device Manufacturer: NHS > Device Name: Laser Senoidal 5000VA > > upsc output when the UPS is

Device Manufacturer: NHS Device Name: Laser Senoidal 5000VA upsc output when the UPS is in normal condition: battery.charge: 100 battery.current: 0.4 battery.date: 12292015 battery.runtime: 00000 battery.runtime.low: 59940 battery.temperature: 00 battery.voltage: 163.4 device.mfr: NHS Sistemas de Energia device.model: Laser Senoidal 5000VA device.type: ups driver.name: gamatronic

Julius: I just realized after committing Michal's patch that you have a more comprehensive patch on the tracker that approaches this piece of code differently. We can go ahead and apply the following patch to the trunk if you still think it's relevant: https://alioth.debian.org/tracker/index.php?func=detail&aid=303719&group_id=30602&atid=411544 If you have a newer version of

Device Manufacturer: NHS Device Name: Expert C Online 6000 upsc output: battery.charge: 100 battery.current: 0.6 battery.date: 01012014 battery.runtime: 00000 battery.runtime.low: 59940 battery.temperature: 29 battery.voltage: 210.5 device.mfr: NHS Sistemas de Energia device.model: EXPERT GIII 8kVA device.type: ups driver.name: gamatronic driver.parameter.pollinterval: 20

On Jan 13, 2016, at 6:00 AM, Thiago Wiezbicki - NHS <thiago.wiezbicki at nhs.com.br> wrote: > > The battery.run.low can be higher than battery.runtime, do you agree? I agree with that statement, given what the gamatronic driver is currently reporting. However, I think it should report the elapsed time as battery.runtime.elapsed. I have created a Github issue to clarify the

On Nov 12, 2014, at 5:46 AM, Thiago Wiezbicki <thiagowzb at gmail.com> wrote: > > > Device Manufacturer: NHS > Device Name: Expert C Online 6000 > > upsc output: > > battery.charge: 100 > battery.current: 0.6 > battery.date: 01012014 > battery.runtime: 00000 Quick question: does "battery.runtime" update when the device is on battery, or is this

Below the answers: > This is the same as https://github.com/networkupstools/nut/issues/254 , right? Yes, this UPS is the same. > Does battery.runtime only get updated when on battery power, or is this with a different load? > battery.runtime.low: 59940 > battery.temperature: 00 Yes, this time time is updated on battery power, This is a dynamic counter that changes with a different

Hi Leon! Thanks for your effort in reaching out! I have been involved in Open Source projects and used Open Source for years. Your questions are very common ones for companies interested in getting involved in Open Source projects, so I will attempt to provide you with some answers. NUT is a collaborative effort, but as these projects go there is not a single person "in charge"

On Nov 22, 2014, at 5:16 AM, Thiago Wiezbicki <thiagowzb at gmail.com> wrote: > Below , it's a second upsc command using our UPS on battery and with device ID, battery time, battery low time that UPS calcs correctly. Let me remember now, We have the same UPS in 6, 8, 10 and 12 kVA version, and it's names are : Expert C Online 6000 , 8000 , 10000 and 12000 ( or Expert G III

What information Do I need to provide more, beyond upsc and shutdown tests for add these devices on HCL ? Thanks, ------------------------------ Thiago Wiezbicki -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20141125/07793b94/attachment-0001.html>

On Jan 8, 2016, at 7:09 AM, Thiago Wiezbicki - NHS <thiago.wiezbicki at nhs.com.br> wrote: > >>> battery.runtime: 00076 >>> battery.runtime.low: 59940 >> >> This seems rather high. This variable is supposed to represent the runtime [in seconds] below which the UPS will signal "LB", but this capture only shows "OB". > > This value

On 3/20/07, Julius Malkiewicz <jpmalkiewicz@gmail.com> wrote: > I would like to use the gettimeofday() call to do some timing - but > it is invoked optionally, therefore it is _not_ required. I'm aware > that different unix(es) have different header files to include to get > to the gettimeofday() syscall - on linux it is <sys/time.h>. > > How do I modify the

On 12/17/2013 08:43 PM, Ted Mittelstaedt wrote: > > Before doing that you should try to make some kind of proposal. > Basically you want to say how easy you think it would be to support your > product. For example if your product speaks an interface language > that is very similar to other products that are already supported, a > developer can easily take an existing module

*Q: Quick question: does "battery.runtime" update when the device is on battery, or is this field always zero?* *A: Yes, the UPS battery time starts counting when the device starts on battery.* Q: "battery.runtime.low" should be the number of seconds remaining before switching to "LB" status. This seems large, even for a 6000 VA UPS. Is this configurable? A: I