On Tue, Dec 9, 2014 at 9:40 AM, Stuart Henderson <st...@openbsd.org> wrote: > On 2014/12/09 09:36, David Higgs wrote: >> On Tue, Dec 9, 2014 at 5:02 AM, Stuart Henderson <st...@openbsd.org> wrote: >> > On 2014/12/08 15:04, David Higgs wrote: >> >> As per an earlier thread on misc@, this fixes sensorsd.conf(5) >> >> parsing of SENSOR_INDICATOR values. Since parsing as integers was both >> >> undocumented and confusing, it is no longer supported. Also, bail on >> >> error if the high/low values don't create a valid range. >> > >> > Low/high transitions don't make sense for these types of sensor anyway. >> > That was a quick hack because the indicator sensors don't function as >> > "status" sensors (but I didn't get as far as working out why). >> > >> >> This mimics existing behavior, but still isn't very intuitive. I.e. >> >> "low=Off:high=On" will always be "within" user limits. Should >> >> indicators limits behave differently? >> >> >> >> Feedback is welcome. >> > >> > Specific feedback on the diff, I'm not keen on the case sensitive >> > comparison (so at least use strcasecmp). But it feels to me like if >> > we're changing things in this area we should fix it properly rather than >> > continue the hack but using strings instead of integers. In my opinion >> > the proper fix would be to treat these sensors as "status" sensors. >> > >> >> I'm looking into adding some status changes to upd(4), but it probably >> isn't safe to assume that all devices provide useful status >> indicators. I don't think all of them have an obvious mapping to >> status and are best left as informational, but sensorsd(8) should have >> a way to add user limits / triggers regardless. >> >> I'll look into this, thanks. > > I was thinking more that it might be better for sensorsd internally > to treat state transitions of "indicator" sensors like it treats > status changes, rather than change how the sensors themselves report. > What do you think?
Yes, that makes a lot of sense. I still think that some of them should have an associated status for reporting purposes (AC power loss or mfi(4) drive status), but indicators could automatically trigger on value changes. User-specified high/low settings will be ignored or rejected. The %l (above / below / within / etc) output may need rethinking... --david
