Dear Arnaud, Now I started to write a driver that simulates continous power breaks. (E.g. in every 30 minutes.) This could be used for testing of setup of client upsmons. I have to simulate a behaviour of a real UPS. The physical model contains an extra attribute: the charging current that needed to compute recharge time and actual battery charge during the recharge process. Can we call this variable "battery.current.recharge"? Or should I put it into "driver.*" name space? Cheers Gabor
Citeren "Kiss Gabor (Bitman)" <kissg op ssg.ki.iif.hu>:> I have to simulate a behaviour of a real UPS. The physical model > contains an extra attribute: the charging current that needed to compute > recharge time and actual battery charge during the recharge process. > > Can we call this variable "battery.current.recharge"?We already have 'battery.current' and 'battery.capacity' variables, so you should use these instead. These allow you to simulate charging/discharging your virtual battery and also calculate the (virtual) charge it accumulates. You could base setting the LB flag on the 'battery.charge.low' value then.> Or should I put it into "driver.*" name space?Not at all. This is used for variables that are passed to drivers in the 'ups.conf' file. You shouldn't add these yourself. Best regards, Arjen PS Please use the nut-upsdev mailing list for development related messages. -- Please keep list traffic on the list
[Redirected from nut-upsuser]> > I have to simulate a behaviour of a real UPS. The physical model > > contains an extra attribute: the charging current that needed to compute > > recharge time and actual battery charge during the recharge process. > > > > Can we call this variable "battery.current.recharge"? > > We already have 'battery.current' and 'battery.capacity' variables, so you > should use these instead. These allow you to simulate charging/discharging > your virtual battery and also calculate the (virtual) charge it accumulates.Eeeer... I don't agree. Tipically charge current and discharge current differ by an order of magnitude. After 25 minutes of discharge batteries are charged for 24 hours or so. Full discharge time is battery.capacity / battery.current. However full charge time is battery.capacity / battery.current.recharge. These two are totally independent attributes of a UPS. I repeat: this is a simulation. There is no real UPS behind the driver. (It is like dummy-ups but reported values change automatically by the time.) Without specifying the charge rate there is no way to imitate how fast the battery is filled with energy after utility power returned.> PS Please use the nut-upsdev mailing list for development related messages.Ooops... sorry. :) Gabor
On Thu, 1 Oct 2009, Stuart D. Gathman wrote:> keep simulation parameters in a separate config file from driver parameters.Meanwhile file docs/developers.txt writes (watch the third sentence): | Note: this does not apply to drivers. Driver authors should use the | upsdrv_makevartable() scheme to pick up values from ups.conf. Drivers | should not have their own config files. | | Drivers may have their own data files, such as lists of hardware, | mapping tables, or similar. The difference between a data file and a | config file is that users should never be expected to edit a data file | under normal circumstances. This technique might be used to add more | hardware support to a driver without recompiling. Now what? :-) It is hard to decide if "charging current of an imaginary UPS" or "the maximal charge time" is a hardware description or simulation data. Gabor
Kiss Gabor (Bitman) wrote:> On Thu, 1 Oct 2009, Stuart D. Gathman wrote: > >> keep simulation parameters in a separate config file from driver parameters. >> > > Meanwhile file docs/developers.txt writes (watch the third sentence): > | Note: this does not apply to drivers. Driver authors should use the > | upsdrv_makevartable() scheme to pick up values from ups.conf. Drivers > | should not have their own config files. > | > | Drivers may have their own data files, such as lists of hardware, > | mapping tables, or similar. The difference between a data file and a > | config file is that users should never be expected to edit a data file > | under normal circumstances. This technique might be used to add more > | hardware support to a driver without recompiling. > > Now what? :-) > > It is hard to decide if "charging current of an imaginary UPS" or > "the maximal charge time" is a hardware description or > simulation data.I agree it is a tricky decision. But I still think that the "charging current" (and other simulated properties) is a "hardware description" rather than a driver config. Think about it this way, if some magic could make your simulated UPS real, what would be in the driver config? The description of the UPS that will be magically synthesized goes in your simulation parameters. The configuration for using one of your magically manufactured UPSes goes in the driver config. Did you know that a hologram of a configuration of lenses and mirrors behaves just like real lenses and mirrors (for laser light)? And this also goes for CGI holograms of lenses and mirrors that could not be actually made of any known material - and this is commonly used in laser printers and scanners.
Oooops. The URL is: http://bakacsin.ki.iif.hu/~kissg/pd/nut/ Gabor