search for: generic_modbus

Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes: > Nearby there's also a `generic_modbus" name. Wondering if the new driver > should be (similar to) `generic_gpio`. sound good. It would be nice if there were an abstraction layer for various GPIO access methods, rather than hard-coding linux, even if there is only one implementation of the abstraction. I'm not that clear...

Great, thanks! Also just for context, this sounded reminiscent of one of the first NUT drivers, `genericups` (for simple contact-closure support, with IIRC serial-port connections rather than GPIO). Nearby there's also a `generic_modbus" name. Wondering if the new driver should be (similar to) `generic_gpio`. @Community verdict: Then there was also an effort some years ago to name drivers with a `nutdrv-*` prefix... WDYT? As usual, naming is among the hardest problems in IT ;) Jim On Wed, Feb 22, 2023 at 4:34 PM MODRIS B?...

...library specifics, now see open/close/read lines that any library should support. Need to split into 2 files, may to go for library? On 2/22/23 20:17, Greg Troxel wrote: > Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes: > >> Nearby there's also a `generic_modbus" name. Wondering if the new driver >> should be (similar to) `generic_gpio`. > sound good. > > It would be nice if there were an abstraction layer for various GPIO > access methods, rather than hard-coding linux, even if there is only one > implementation of the abstractio...

...open/close/read lines that any library should support. Need to split > into 2 files, may to go for library? > > On 2/22/23 20:17, Greg Troxel wrote: > > Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes: > > > >> Nearby there's also a `generic_modbus" name. Wondering if the new driver > >> should be (similar to) `generic_gpio`. > > sound good. > > > > It would be nice if there were an abstraction layer for various GPIO > > access methods, rather than hard-coding linux, even if there is only one > > im...

...th *some* single definition; I looked at precedents of `git grep -w HB` in the codebase, there are a few `setval()` hits, namely: * adelsystem_cbi.c: "BVAL_HIALRM_I", * al175.c: "BATTERY VOLTAGE STATUS", * asem.c: "charge_percentage >= hb_threshold (default 75)", * generic_modbus.c: "usually ... charging state > 85%", * pijuice.c: "battery_charge_level > HIGH_BATTERY_THRESHOLD (macro 75)" * similarly in hwmon_ina219.c added by PR https://github.com/networkupstools/nut/pull/2430 that started this discussion The first one seems to be about an alarm,...

...I looked at precedents of `git > grep -w HB` in the codebase, there are a few `setval()` hits, namely: > > * adelsystem_cbi.c: "BVAL_HIALRM_I", > * al175.c: "BATTERY VOLTAGE STATUS", > * asem.c: "charge_percentage >= hb_threshold (default 75)", > * generic_modbus.c: "usually ... charging state > 85%", > * pijuice.c: "battery_charge_level > HIGH_BATTERY_THRESHOLD (macro 75)" > * similarly in hwmon_ina219.c added by PR > https://github.com/networkupstools/nut/pull/2430 that started this > discussion > > The first on...

Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes: > During discussion at > https://github.com/networkupstools/nut/pull/2430#discussion_r1592317940 I > found that while `nut-names.txt` documents the `battery.charge.low` as the > "Remaining battery level when UPS switches to LB (percent)", there is no > counterpart as `battery.charge.high`.

...> > grep -w HB` in the codebase, there are a few `setval()` hits, namely: > > > > * adelsystem_cbi.c: "BVAL_HIALRM_I", > > * al175.c: "BATTERY VOLTAGE STATUS", > > * asem.c: "charge_percentage >= hb_threshold (default 75)", > > * generic_modbus.c: "usually ... charging state > 85%", > > * pijuice.c: "battery_charge_level > HIGH_BATTERY_THRESHOLD (macro 75)" > > * similarly in hwmon_ina219.c added by PR > > https://github.com/networkupstools/nut/pull/2430 that started this > > discussion &g...