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?
