[WIMS] Ambient Light events for power management

[WIMS] Ambient Light events for power management

Rich Gray rgray at plustechnologies.com
Wed Sep 9 20:28:54 UTC 2009


Hi Bill,

In what sense are you using optional?  As in to meet the spec the 
printer must have a light sensor?  Or that the Ambient Light trigger 
is optional in the implementation of the spec?  For the AL trigger, 
if there is no hardware the implementation could always treat things 
as high illumination.  I see the main advantage of AL sensing as a 
way, in some environments, to know when to go into deep sleep rapidly.  
Maybe it's not worth it if a printer can wake up very quickly.

I guess I see this feature as being most useful in medium office/SOHO 
settings, (medium printers?) where light will most likely me a
meaningful 
indicator of "business hours".  High end printers are more likely to be 
in 24/7 shops?  Low end will not have the sensor because they want to 
save every last penny.  (Or maybe I'm all wet about these scenarios, 
but I wanted to throw out the idea.)

Cheers!
Rich

Richard B. Gray
Senior Software Engineer
Plus Technologies
A Division of Digital Controls
444 Alexandersville Road
Miamisburg, OH 45342-3568
937-384-0444 ext. 2405
877-899-7587 toll free
937-384-0842 fax
rgray at plustechnologies.com
www.plustechnologies.com 

-----Original Message-----
From: wims-bounces at pwg.org [mailto:wims-bounces at pwg.org] On Behalf Of
William Wagner
Sent: Wednesday, September 09, 2009 4:10 PM
To: 'Ira McDonald'; wims at pwg.org
Subject: RE: [WIMS] Ambient Light events for power management

Certainly an interesting idea, and I suspect that there may be other
event
driven triggers that have some appeal. Perhaps we might want to include
some
way of providing for optional triggers, and defining these triggers, so
that
they would remain within the standard management structure rather than a
proprietary one. The counter-argument says that, unless the printer is
essentially offline, an incoming job normally is a trigger and these
other
event driven triggers are unnecessary.

Comments I received on the previous draft suggest that too much is
mandatory. Indeed, they asked if this effort was only intended for
high-end
devices. I think, if we are to get good adherence, we need to keep the
mandatory elements to the minimum. Perhaps it might be necessary to
identify
multiple levels of support rather than make elements optional, so that a
"level" value gives a true statement of what elements are supported.

Bill Wagner

-----Original Message-----
From: wims-bounces at pwg.org [mailto:wims-bounces at pwg.org] On Behalf Of
Ira
McDonald
Sent: Wednesday, September 09, 2009 3:19 PM
To: wims at pwg.org; Ira McDonald
Subject: [WIMS] Ambient Light events for power management

Hi,

Excerpted by permission from an offline thread today with Rich Gray,
some comments on yesterday's Power Management Model draft:

----------------------------------------------

Rich originally wrote:

1113 [RFC3231]
1114 IETF Schedule MIB, RFC 3231, January 2002.
1115 http://www.ietf.org/rfc/rfc3629.txt

Wrong RFC in link.

One way I've always thought for printers in some settings to manage
power would be to simply have an ambient light sensor and sleep if
it's dark.  Would this spec support such a thing? Perhaps Ambient
Light could be a policy trigger?

----------------------------------------------

Ira replied:

Thanks for the editorial catch.

I like your idea of events for AmbientLight (High/Low/Off?) and
an event-based policy to Sleep, Suspend, or Hibernate based
on the Low/Off events (Low, because most sites keep some
lights on all the time).

-----------------------------------------------

Rich replied:

For many situations, ambient light sensing would work really
well for setting deep sleep mode, particularly for a device in an
interior room. It has this nice automatic property.  If someone
shows up at 2am and wants to print, the printer wakes up.
When they leave, the printer resumes its beauty sleep. ;)

If the office lighting is on a central timer, the printer will follow
that timer.  Perhaps "Occupancy Sensor" might be a more
generic term for such triggers, although I can't think of a less
costly way to do it than a simple light sensor.  Seems like a low
cost, potential high payoff thing.  If the sensor could be read by
host software, it could be used for routing/scheduling decisions
too.

-----------------------------------------------

Comments?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
wims mailing list
wims at pwg.org
https://www.pwg.org/mailman/listinfo/wims


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
wims mailing list
wims at pwg.org
https://www.pwg.org/mailman/listinfo/wims

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the wims mailing list