I'm trying to accomplish something simple. When someone turns on a hue light, if it's after 6pm, set the light to a specific color.
I haven't been able to find a way to do this without polling constantly (which seems lame).
The main Hue iOS app has alarms, but lights only respond to alarms when they are turned on. So the app's alarms also fail to set a specific color after 6pm when a light is turned on at 7pm.
The API has now been updated to support this. A rule with the following conditions can be stored on the bridge so no need to keep polling from an app. First condition specifies the times you want the rule to trigger, second condition specifies a certain light must be on and third condition specifies that light must have just changed from being off.
"address":"/config/localtime", "operator":"in", "value":"T18:00:00/T23:00:00"
"address":"/lights/1/state/on","operator":"eq","value":"true"
"address":"/lights/1/state/on","operator":"dx"
But a Hue app using the API is already polling the bridge, at whatever the heartbeat is set to. So, when the heartbeat fires, you read the cache, inspect you light's state, and store its "reachable" value, which is false if the light is physically off, and true if it is physically on. The next time through the loop, check it again. If it was false and is now true, bingo: the light was just turned on, so send it a command to set the color you want.
Because the API uses heartbeat-based polling, not callbacks or interrupts, this is the best you can do to detect external changes (like a light being physically switched on or off, or a light being changed by some other application, IFTTT rule, etc.) You do have control over the heartbeat interval of resources by type, so you can poll the lights more frequently to be able to react more quickly.
Related
I am trying to set a non repeating alarm ..but i am not able to do so...When i am setting alarm using below code it alaways repeat in each day. I dont want to repeat the alarm ever in life. When i set the alarm i just get the option of set , setInexactrepeating. So how to set alarm only once?
alarmManager= (AlarmManager) getSystemService(Context.ALARM_SERVICE);
Intent intent=new Intent(this,AlarmReceiver.class);
pendingIntent=PendingIntent.getBroadcast(this,0,intent,0);
alarmManager.setInexactRepeating(AlarmManager.RTC_WAKEUP,calender.getTimeInMillis(),
AlarmManager.INTERVAL_DAY,pendingIntent);
You can do it by making a change in your last two line of Code i.e.
alarmManager.setInexactRepeating(AlarmManager.RTC_WAKEUP,calender.getTimeInMillis(),
AlarmManager.INTERVAL_DAY,pendingIntent);
In the above line of code you have used ".setInexactRepeating" that will set a repeating alarm and "Alarm Manager.INTERVAL_DAY" will force it to repeat it on same time everyday.
Now for setting a non-repeating alarm you suppose to set a EXACT Alarm that can be set as (I am directly putting it blow from Android Developers)
Set an exact alarm
The system invokes an exact alarm at a precise moment in the future. If your app targets Android 12 (API level 31) or higher, you must declare the "Alarms & reminders" special app access; otherwise, a SecurityException occurs.
Your app can set exact alarms using one of the following methods. These methods are ordered such that the ones closer to the bottom of the list serve more time-critical tasks but demand more system resources.
setExact()
Invoke an alarm at a nearly precise time in the future, as long as other battery-saving measures aren't in effect.
Use this method to set exact alarms, unless your app's work is time-critical for the user.
setExactAndAllowWhileIdle()
Invoke an alarm at a nearly precise time in the future, even if battery-saving measures are in effect.
setAlarmClock()
Invoke an alarm at a precise time in the future. Because these alarms are highly visible to users, the system never adjusts their delivery time. The system identifies these alarms as the most critical ones and leaves low-power modes if necessary to deliver the alarms.
Below Link will help you in detail:
https://developer.android.com/training/scheduling/alarms
I have a plugin for Homebridge that operates shades, i.e. WindowCovering Services. It basically imitates the remote for the shades. The remote has 16 channels and one of them, 0, operates all shades. Each shade/channel is an Accessory on a Dynamic Platform. As the shades move I am updating the CurrentPosition and PositionState Characteristics. This seems to work fine now. However, some updates never seem to reach Homekit.
When multiple shade/channels are moving at the same time, this shows in the Home app as "Opening" or "Closing". When the PositionState is updated to Stopped, the icons show the current %age open. However the updates on some shades will get lost.
I thought perhaps a delay between update calls is required, so I implemented a scheme that prevents calls being made close together with a configurable delay. That seemed to improve things, but updates are still lost and I don't really know if the delay is required.
All PositionState updates go through this code. I have been debugging this issue for quite a while and am convinced the code is executed, but I can't figure out why the Home app does not see the Stop.
updateStateCB() {
this.service.getCharacteristic(this.platform.Characteristic.PositionState).updateValue(this.positionState);
this.logTimeCh('Update state:' + this.positionState);
}
Where might I be going wrong here? Is the delay between calls required? Is there a bug in Homekit somewhere?
Thanks
I have an app that monitors or ranges iBeacons inside a building. How can I detect how long a user spends in a particular room?
I've observed that the proximity for a given beacon may jump from near to far, based on orientation of the device. This means that I cannot simply say that once the range is unknown, the visit is over. Should I continuously range a distance to a beacon and consider the visit to start/end once I detect X consecutive "near/unknown" states for a given beacon?
There is no guarantee you will get any number of ranging callbacks with proximity "unknown" before a beacon disappears. Instead, you should use the monitoring APIs, and consider a room exited when you get a call to didExitRegion. Sometimes iOS will give you a spurious exit notification, so you need to protect against this. I do so by starting a timer on region exit, and I only perform the exit logic if I don't get a didEnterRegion callback within five seconds.
Of course, all this assumes that the "room" or "department" has beacons whose transmitter range end precisely at the edge of the room/department. Without very precise placement and control over transmitter power, this is unlikely to be exactly true. You have to decide if you can live with this approximation.
Consider an application where it's desirable to grab the keyboard when focused in order to capture all window manager commands (Alt+F4 and whatnot) for processing. Now, this has the downside that the user has no way of switching to another application or virtual desktop via the keyboard when the keyboard is grabbed. I'd like to have a user-defined whitelist of key combination (say, the key combinations for switching virtual desktops) that are excluded from the grab.
I can think of two possible approaches. When a whitelisted key event arrives, either
Somehow tell X to continue processing it as usual. This sounds like a more natural way of doing it but I can't find a way to do this, or
Ungrab the keyboard and re-send the event by hand to the window manager for processing, however I don't know where to send it (the root window?) or whether that would even work.
Can anyone fill in the blanks on those? Any other suggestions?
If there's no way to exclude keys from a grab, I guess I'll have to settle for having an "escape key" that ungrabs the keyboard when pressed. The user'll have to press both that and then the window manager command, though, which isn't as nice.
I don't think there's a way to do it. None of the mechanisms work quite how you would need them to.
Approach 1 is sort of what the window manager does if it decides not to intercept a click or key for example. However, the WM is using "passive" grabs on particular keys (XGrabKey=passive XGrabKeyboard=active) and then XAllowEvents(). XAllowEvents() does not work with XGrabKeyboard(). also, when you XAllowEvents with one of the Replay modes, the replayed event bypasses all passive grabs on the window that had the original grab and on all its parent windows. The WM's grabs will be on the root window which will always be a parent so there is no way to replay to the root window, best I can tell. Doing XGrabKey on every possible key would be sort of psycho anyhow.
Approach 2 would have bad race condition problems, because other key and mouse events could be processed before you could resend, so you'd reorder keys and send events to destroyed windows and other confusion. Also, there is no good way to send a key event. XSendEvent() is ignored by many clients (it sets a send_event flag in the event allowing this). XTest extension can be used but may be disabled on production X servers and still has race condition issues.
What you probably would need is a protocol extension that let you do an AllowEvents(mode=ReplayKeyboard) after a GrabKeyboard and without bypassing passive grabs on parent windows.
One caveat is that I don't know all the wild stuff that can be done with XKB and XInput2, so maybe there's something in those extensions.
Anyway, as far as I know you have to settle for the "escape key," though it might be nice eventually for the X server and/or the window manager specs to have "VMWare/VNC-type-thing awareness," that won't help you in the short term. An EWMH spec extension could be as simple as a new _NET_WM_WINDOW_TYPE for vnc/vmware/stuff-like-that and the window manager could reduce its keybindings or add an extra modifier to them or something when that window was focused, for example.
I am trying to write a program that monitors when the screen has been redrawn.
Meaning if any part of any window is redrawn, then the program is notified.
As far as I understand I should use a journal record hook like at
http://www.vbaccelerator.com/home/vb/code/libraries/Hooks/Journal_Record_Hooks/article.asp
However, I do not understand which MSG type would get me the WM_PAINT events (WH_CALLWNDPROC and WH_CALLWNDPROCRET do not seem to do the job). I'm not even sure that WM_PAINT is what I'm looking for...
Basically, if I knew when the DC associated with GetDesktopWindow() has changed then my problem would be solved.
Question is: How do you monitor screen updates?
I don't believe this is possible without hooking the display driver. I can imagine there would be some serious performance implications if it were possible in general...
You would be better taking a screenshot every second or whatever. Every version of Windows has the little network icon in the tray always changing when you transfer data over a network, meaning the screen will be changing pretty much constantly.