search for: st_flag_rw

Hi all! I'm wondering if there's anyone doing any hacking on the snmp-ups driver at the moment. I've started looking at implementing 3phase-support, and this uncovered some rather unpleasant stuff in the snmp-ups driver that I really need to fix in order to get things sane. Those of you that's allergic to SNMP might want to stop reading now, this is rather icky ;)

...Path: UPS.PowerSummary.DelayBeforeStartup, Type: Feature, ReportID: 0x11, Offset: 0, Size: 24, Value: 0 Arnaud, is HU_FLAG_ABSENT the right flag here? That seems to indicate that the variable is not actually implemented on the UPS: drivers/idowell-hid.c:99: { "ups.delay.start", ST_FLAG_RW | ST_FLAG_STRING, 10, "UPS.PowerSummary.DelayBeforeStartup", NULL, DEFAULT_ONDELAY, HU_FLAG_ABSENT, NULL}, { "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10, "UPS.PowerSummary.DelayBeforeShutdown", NULL, DEFAULT_OFFDELAY, HU_FLAG_ABSENT, NULL}, It is not...

...f", HU_FLAG_OK, NULL }, - { "battery.charge.low", ST_FLAG_STRING, 5, "UPS.PowerSummary.RemainingCapacityLimit", NULL, - "%.0f", HU_FLAG_OK, NULL }, /* Read only */ + /* the following is writeable for the Back-UPS ES 650 */ + { "battery.charge.low", ST_FLAG_RW | ST_FLAG_STRING, 5, "UPS.PowerSummary.RemainingCapacityLimit", NULL, + "%.0f", HU_FLAG_OK | HU_FLAG_SEMI_STATIC, NULL }, { "battery.charge.warning", ST_FLAG_STRING, 5, "UPS.PowerSummary.WarningCapacityLimit", NULL, "%.0f", HU_FLAG_OK, NULL },...

...t(unsigned char len) upsdebugx(2, "Auto delay off: %d\n", auto_dly_off); snprintf(outlet_name, sizeof(outlet_name)-1, "outlet.%d.delay.shutdown", num); dstate_setinfo(outlet_name, "%d", auto_dly_off); - dstate_setflags(outlet_name, ST_FLAG_RW | ST_FLAG_STRING); - dstate_setaux(outlet_name, 5); + dstate_setflags(outlet_name, ST_FLAG_RW | ST_FLAG_STRING); + dstate_setaux(outlet_name, 5); auto_dly_on = get_word(answer+iIndex); iIndex += 2; upsdebugx(2, "Auto delay on: %d\n", aut...

Here are a series of my recent changes to NUT. The first few in the set are primarily little fixes and improvements. In among those are a few for .gitignore files which of course you can ignore for SVN, and there's one for a commit to a generated file which of course should not be tracked in any VCS. Then there are a couple or three to do with generating the header files used by

...In theory, you could change the following line: > > https://github.com/networkupstools/nut/blob/v2.7.4/drivers/mge-utalk.h#L220 > > from "{ "output.voltage", 0, 0, "Lv", "%05.1f", VOLT, TRUE }," > > to "{ "output.voltage", ST_FLAG_RW | ST_FLAG_STRING, 5, "Lv", "%05.1f", VOLT, TRUE }," > > This would allow you to use the "upsrw" command to set the voltage (with appropriate scaling). > > Do you have a development environment set up for the Raspberry Pi? Sorry, I think I read the p...

...Startup, Type: Feature, > ReportID: 0x11, Offset: 0, Size: 24, Value: 0 > > Arnaud, is HU_FLAG_ABSENT the right flag here? That seems to indicate that > the variable is not actually implemented on the UPS: > > drivers/idowell-hid.c:99: > { "ups.delay.start", ST_FLAG_RW | ST_FLAG_STRING, 10, > "UPS.PowerSummary.DelayBeforeStartup", NULL, DEFAULT_ONDELAY, > HU_FLAG_ABSENT, NULL}, { "ups.delay.shutdown", ST_FLAG_RW | > ST_FLAG_STRING, 10, "UPS.PowerSummary.DelayBeforeShutdown", NULL, > DEFAULT_OFFDELAY, HU_FLAG_ABSENT, NULL}...

...;> ReportID: 0x11, Offset: 0, Size: 24, Value: 0 >> >> Arnaud, is HU_FLAG_ABSENT the right flag here? That seems to indicate that >> the variable is not actually implemented on the UPS: >> >> drivers/idowell-hid.c:99: >> { "ups.delay.start", ST_FLAG_RW | ST_FLAG_STRING, 10, >> "UPS.PowerSummary.DelayBeforeStartup", NULL, DEFAULT_ONDELAY, >> HU_FLAG_ABSENT, NULL}, { "ups.delay.shutdown", ST_FLAG_RW | >> ST_FLAG_STRING, 10, "UPS.PowerSummary.DelayBeforeShutdown", NULL, >> DEFAULT_OFFDELAY, HU_FL...

....7.4.1) Can't chdir to /var/state/ups: No such file or directory Driver failed to start (exit status=1) The new .h file reads as this ? /* Output page */ { "output.voltage", 0, 0, "Lv", "%05.1f", VOLT, TRUE }, { "output.voltage.nominal", ST_FLAG_RW | ST_FLAG_STRING, 5, "Lv ?", "%05.1f", VOLT, TRUE }, { "output.current", 0, 0, "Lc", "%05.1f", AMPERE, TRUE }, If I copy the old driver back, it works fine ? so I?m guessing I?ve got something wrong with the compile or syntax! Welcome your...

W dniu 24.08.2018 o 13:10, Charles Lepple pisze: > Sorry, I didn't mean to imply that the master branch was necessarily going to be different, just wanted to make sure you had everything set up to recompile. The real test is to see if things change after commenting out that line (such as by changing it to start with "//"): > > // { "shutdown.return", 0, 0,

On Apr 5, 2014, at 8:52 AM, Mick <michaelkintzios at gmail.com> wrote: >> The upsrw command was designed for changing variables that are typically >> stored in non-volatile memory on the UPS. Unfortunately, your UPS doesn't >> seem to do that. > > Well, if it doesn't do that, how come upsc reports the changed value? It is > only after I reboot the PC

...following line: > > > > https://github.com/networkupstools/nut/blob/v2.7.4/drivers/ > mge-utalk.h#L220 > > > > from "{ "output.voltage", 0, 0, "Lv", "%05.1f", VOLT, TRUE }," > > > > to "{ "output.voltage", ST_FLAG_RW | ST_FLAG_STRING, 5, "Lv", "%05.1f", > VOLT, TRUE }," > > > > This would allow you to use the "upsrw" command to set the voltage (with > appropriate scaling). > > > > Do you have a development environment set up for the Raspberry Pi?...

...fo_type, item->info_flags); 1.1.1.1.8.6.2.5 (aquette 10-Aug-05): /* Verify variable setability/RW */ 1.1.1.1.8.6.2.5 (aquette 10-Aug-05): if (get_current_data_attribute() != ATTR_DATA_CST) 1.1.1.1.8.6.2.5 (aquette 10-Aug-05): dstate_setflags(item->info_type, ST_FLAG_RW); 1.1.1.1.8.1 (aquette 04-May-05): } I think that these three lines are a bug, because they cause the ST_FLAG_RW flag to be set on all variables, whether or not they are declared writable. (Moreover, these lines *erase* the ST_FLAG_STRING flag from all items). I am just alerting you to thi...

...f", HU_FLAG_OK, NULL }, - { "battery.charge.low", ST_FLAG_STRING, 5, "UPS.PowerSummary.RemainingCapacityLimit", NULL, - "%.0f", HU_FLAG_OK, NULL }, /* Read only */ + /* the following is writeable for the Back-UPS ES 650 */ + { "battery.charge.low", ST_FLAG_RW | ST_FLAG_STRING, 5, "UPS.PowerSummary.RemainingCapacityLimit", NULL, + "%.0f", HU_FLAG_OK | HU_FLAG_SEMI_STATIC, NULL }, { "battery.charge.warning", ST_FLAG_STRING, 5, "UPS.PowerSummary.WarningCapacityLimit", NULL, "%.0f", HU_FLAG_OK, NULL },...

Hi, I've recently got a Raspberry Pi working with NUT and my MGE Pulsar ESV+, using the U-TALK driver, a USB Serial adapter and original cable. I've overcome the documented problems with these units and have it running, except for one little niggle! It's installed in central Europe, where the utility voltage is 240v, it's constantly in trim mode and pushing the voltage down to

...0, Size: 24, Value: 0 > >> > >> Arnaud, is HU_FLAG_ABSENT the right flag here? That seems to indicate > >> that the variable is not actually implemented on the UPS: > >> > >> drivers/idowell-hid.c:99: > >> { "ups.delay.start", ST_FLAG_RW | ST_FLAG_STRING, 10, > >> > >> "UPS.PowerSummary.DelayBeforeStartup", NULL, DEFAULT_ONDELAY, > >> HU_FLAG_ABSENT, NULL}, { "ups.delay.shutdown", ST_FLAG_RW | > >> ST_FLAG_STRING, 10, "UPS.PowerSummary.DelayBeforeShutdown", NULL, &g...

...ng!) p6=1 B1200 p6=2 B2400 P6=3 B4800 p6=4 B9600 maybe cycle through speeds to autodetect? echo off e0 echo on e1 */ dstate_setinfo("input.transfer.low", "%s", ""); dstate_setflags("input.transfer.low", ST_FLAG_STRING | ST_FLAG_RW); dstate_setaux("input.transfer.low", 3); dstate_setinfo("input.transfer.high", "%s", ""); dstate_setflags("input.transfer.high", ST_FLAG_STRING | ST_FLAG_RW); dstate_setaux("input.transfer.high", 3); dstate_setinfo("battery.ru...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I would like to propose an interface change/extension, in order to be able to clearly differ from a PRE_SEND and a POST_RECEIVE item_t->preprocess-ing calls. IMHO there is no option to differ from item->preprocess(..), called from [1] and called from [2], at the moment. My idea is to extend the item_t->preprocess(..) with an additional

...mmand would be Lv 24000. > In theory, you could change the following line: https://github.com/networkupstools/nut/blob/v2.7.4/drivers/mge-utalk.h#L220 from "{ "output.voltage", 0, 0, "Lv", "%05.1f", VOLT, TRUE }," to "{ "output.voltage", ST_FLAG_RW | ST_FLAG_STRING, 5, "Lv", "%05.1f", VOLT, TRUE }," This would allow you to use the "upsrw" command to set the voltage (with appropriate scaling). Do you have a development environment set up for the Raspberry Pi?

...ot;UPS.PowerSummary.RemainingCapacity", NULL, "%.0f", HU_FLAG_OK, NULL }, - { "battery.charge.low", ST_FLAG_STRING, 5, "UPS.PowerSummary.RemainingCapacityLimit", NULL, - "%.0f", HU_FLAG_OK, NULL }, /* Read only */ + { "battery.charge.low", ST_FLAG_RW | ST_FLAG_STRING, 5, "UPS.PowerSummary.RemainingCapacityLimit", NULL, + "%.0f", HU_FLAG_OK | HU_FLAG_SEMI_STATIC, NULL }, { "battery.runtime", 0, 0, "UPS.PowerSummary.RunTimeToEmpty", NULL, "%.0f", HU_FLAG_OK, NULL }, { "battery.voltag...