I'm working on some home automation programs and one of the things I want to be able to do is detect when my 4th generation Apple TV has woken from sleep. This will generally only ever happen when someone pressed a button on its Siri remote to wake it up.
I have a PC (connected to the same TV as the Apple TV) that has a Pulse-Eight USB-CEC adapter, so naturally the first thing I tried was using CEC to determine when the Apple TV is awake. Unfortunately it's not reliable, since monitoring the Apple TV's power status to see when it wakes up produces false positives. (I should note that I do not have "Control TVs and Receivers" enabled on the Apple TV, and can't turn it on for the particular project I'm working on because I need the Apple TV to not change the TV's input.)
I'm trying to think of some other way to do this. I'm open to any possibilities, including things like:
Making use of private APIs on the Apple TV
Running an 'always on' program in the background of the Apple TV that sends a signal when the Apple TV wakes up, if that's even possible. (I suspect that it isn't.)
Monitoring the bluetooth communication between the Siri Remote and the Apple TV, if that's possible
Somehow filtering HDMI-CEC commands so that I can turn on 'Control TVs and Receivers', allow the Apple TV's CEC commands for turning on and off the TV, and exclude commands for changing the TV's input.
Any other method, no matter how hacky or ridiculous, as long as it works!
Does anyone have any suggestions? I'm running out of things to try!
I tried to post below on apple discussion / support communities but was told i don't have the right to post this content. Maybe someone in this group can succeed in doing it:
Apple TV 4 CEC integration is great when it works, but it doesn't work all the time and not with all the various equipment out there, you can do a search across forums and you will see lots of unhappy users. I would like to use a raspberry PI to detect when my AppleTV goes to sleep and wakes up and programmatically turn my tv on or off using its RS232C or custom CEC commands.
I used a bonjour services explorer and compared every single result between sleep and on states and there are no differences whatsoever. I would have expected Apple to welcome such automation projects and make this information readily available with a variable such as status: sleep or status: on.
Is there a way I could tell the two states apart via the network connection?
If not, could one build a TvOS app which runs on the background and makes this information available to clients somehow?
I finally found a method that seems to work consistently. This method is incredibly hacky and not at all the sort of way I'd prefer to do this, but it's the only one I've found so far that works consistently.
I have taken an old USB webcam and affixed it to the front of my Apple TV so that its lens is directly in front of the Apply TV's front facing light. Whenever the Apple TV is asleep, I simply check for the light turning on by taking images from the camera and analyzing their average luminosity. Since the lens is right next to the light, when it turns on it'll create a huge blown out white circle in the image that's incredibly easy to detect.
As long as the Apple TV is asleep, the light turning on seems to indicate 100% of the time that it has woken up. I have yet to find a single incident of either a false positive or false negative.
Since pressing buttons on the Siri remote causes this light to blink, this also means that I can detect buttons being pressed by looking for changes in the light while the Apple TV is awake. It's not 100% accurate, since some button presses are faster than the frame rate of my crappy old USB webcam, but it works well enough.
I would vastly prefer to find a better method of doing this, like making a request over the LAN to the Apple TV where the response clearly indicates it being awake or asleep, but so far it doesn't look like that's possible.
Here I am, six and a half years later, and I've finally found a better way to get the power state of my Apple TV.
I can simply use pyatv, which has a function named power_state that returns the Apple TV's current power state.
Related
I have 2 applescripts (saved as apps) that make webhook calls in a loop to control the volume of my stereo. Each script displays a dialog that asks for a number of ticks to tick the volume up or down, and it loops to make the webhook call each time.
Background: I wrote a program called pi_bose that runs on my raspberry pi to send commands to my Bose Series 12 stereo. It sends codes on the 28Mhz band using a wire as an antenna plugged into one of the GPIO ports. Node red receives the webhook calls and runs that script. But there are various things that can make it fail. The antenna can be loose because the pi has been bumped. Node red isn't running. The program has a small memory leak that causes a problem after having been used for about 6 months. And sometimes there's background interference that makes not every transmission work (I could probably use a longer antenna to address that I guess). But sometimes, whatever is playing on the stereo is just so soft that it's hard to detect the subtle change to the volume. And sometimes, it seems that either the webhook call happens slowly and the volume is changing - it just happens over the course of 20-30 seconds. So...
I know I could do the loop on the pi itself instead of repeating the webhook call, but I would like to see progress on the mac itself.
I'd like some sort of cue that gives me some feedback to let me know each time the webhook call happens. Like, a red dot on the AppleScript app icon or something in the corner of the screen that appears for a fraction of a second each time the webhook call is made.
Alternatively, I could make the script make some sort of sound, but I would rather not disrupt audibly whatever is playing at the time.
Does anyone know how to do that? Is it even possible to display an icon without a dialog window in applescript?
I want to use a SensorTag 2 so that it is sitting there broadcasting it's data (and, critically connectable over bluetooth) from when it's turned on to when\if I ever turn it off. Out of the box, the tag is set to only advertise over Bluetooth for a few mins which means that when the connection eventually fails or when the device connected to the tag boots etc etc you can't connect again without physically visiting the tag and resetting it.
I see there is firmware that the myWeatherCenter people have created that lets the tag work as a weather station by basically setting it to advertise indefinitely... frustratingly though their firmware is only the sensortag version 1 :-(
I've researched on and off for months and months now and nothing coming back.. suggesting either nobody else wants this, there is a really simple solution everyone one else knows about or ...? I can't even see anyone else asking this question really... which is worrying.
Does anyone have a firmware file that sets this setting for the sensortag 2 or know how to modify the firmware to set this setting?
It is definitely possible to change the SensorTag 2/CC2650 platform so that its behavior suits your use case. I - for example - currently use a custom firmware doing pre-processing of sensor readings on the SensorTag and sending data directly in the advertisement message indefinitely (of course you have to tweak intervals and payload to get a decent battery life).
I assume you have CCS and the sources (SensorTagApp and SensorTagStack) at hand?
I recommend flashing the current SensorTagStack first, if not done yet (though I'm not yet on 2.2 myself).
In the SensorTagApp project under Application you find SensorTag.c. In there you should change:
#define DEFAULT_DISCOVERABLE_MODE GAP_ADTYPE_FLAGS_LIMITED
to
#define DEFAULT_DISCOVERABLE_MODE GAP_ADTYPE_FLAGS_GENERAL
This is the usual advise and might already do the trick.
In my firmware I also changed (in SensorTag.c, in the SensorTag_init function):
uint16_t advertOffTime = 0;
to
uint16_t advertOffTime = 1;
Please try these changes and get back to me. If that wasn't enough I will do a more thorough comparison of the stock firmware and my custom firmware. I also recommend the more specific ti Bluetooth low energy forum.
You could find the workflow for a complete solution and the firmware for continuous advertising which I created recently, at Sensortag CC2650STK Custom Firmware Modification&Download Workflow (Continuous Advertising) using Code Composer Studio, Debugger DevPack and Flash Programmer 2 software
The situation goes a little something like this:
I am programming Xcode whilst concurrently listening to music on my Bluetooth headphones... you know to block out the world.
Then, I go to launch my app in the iOS simulator and BOOM all of a sudden my crystal clear music becomes garbled and super low quality like it is playing in a bathtub 2 blocks away... in the 1940s.
Note: the quality deterioration does NOT occur if I am playing music on my laptop or cinema display and I launch the sim. It seems to be exclusively a Sim -> Bluetooth issue.
The problem is more than just annoying. Because often after stopping the simulator the crappy bathtub quality music continues. To fix it I have to open sound preferences in OSX and briefly toggle back to my laptop sound and then back to my Bluetooth headphones.
This is a big deal because I launch the simulator 50x a day and have to do this toggle thing every time as well as suffer listening to 40s era mono ham radio quality music.
For your information, the headphones I am using are Plantronics BackBeat Pro and I am up to date on firmware. I am on OSX 10.11.4 and Xcode 7.3... but this problem has persisted through all versions for 2+ years now. Can you save me from the 1940s?
I've managed to fix it, and it actually seems to be a microphone issue. Go to System Preferences -> Sound, select the Input tab and set Internal Microphone as the input (mine was set with my headphones').
Crappy sound goes way after that =)
EDIT (May 30 2018):
I've found out an easier way to do the same as above. Instead of opening the System Preferences, you can just go to the Mac OSX toolbar, press Option (alt) + click on the sound icon and then select "Internal Microphone" from the "Input Device" list. Print screen as follows.
If you're using Xcode 9 or higher, you can set a default audio input and output for the simulator. This can be done by launching the simulator from Xcode and navigating to I/O > Audio Input within the menu bar and selecting Internal Microphone. This solution will save your audio preference so you won't have to change it on every launch.
On Simulator, Select;
I/O -> Audio Input -> Macbook [Pro]
Done.
Seems like years of suffering are finally over, Xcode 12 Beta Release Notes:
Simulator defaults to the internal microphone unless you explicitly choose a different audio source. This avoids triggering phone call mode on Bluetooth headsets which degrades audio quality while listening to music. (59338925, 59803381)
You can also switch to Mac's internal mic in System Preferences -> Sound, that's how I usually fix this bug (I have Sony Wh-1000XM3)
I just picked up the Lenovo Thinkpad Yoga 15 (20DQ001KUS) for $799. Here is a link: http://shop.lenovo.com/us/en/laptops/thinkpad/yoga-series/yoga-15/#tab-tech_specs
I'd really like to get the tablet features working in Linux Mint 17.2. I have been doing some googling and found some old scripts below:
https://github.com/admiralakber/thinkpad-yoga-scripts
https://launchpad.net/magick-rotation
With their help, I was able to put together a python script that polls my accelerometer values (found in /sys/bus/iio/devices/iio:device*) to figure out when the screen should be rotated. The difficult part seems to be detecting when the device should be in laptop or tablet mode. If I bend the lid past 180 degrees, or if I tilt the device on its side so that it is perpendicular to the ground, there is a light on my keyboard that shuts off and the keyboard itself is completely disabled. This appears to be a bios feature and indicates that there is definitely a sensor. This would be ideal, and it would solve all of my current problems.
Unfortunately, I have been unable to find any sensor readout in linux that would tell me when the computer should be in tablet mode. I need this to determine when autorotate should be turned on, when the touchpad/trackpad/keyboard should be disabled, and when I should launch or kill the onscreen keyboard app.
In the meantime, I'm using the lid's incline sensor (also found in /sys/bus/iio/devices/iio:device*). This works mostly, as It can detect tent mode and tablet mode. Unfortunately, the sensor is aligned to gravity, so it cannot tell the difference between laptop mode and stand mode (because the lid/screen is in the same orientation with respect to gravity).
The older scripts suggest that there is a special keycode in older models that is triggered when the mode changes from laptop to tablet and vice-versa. Unfortunately, I am not seeing any such keycode/scancode being thrown when I monitor xev/evtest.
In short, I'd like to be able to programmatically determine when the laptop screen/lid is opened more than 180 degrees. Can anyone help me with this?
My current script is linked below, if anyone else wants to see how I'm doing it (or if anyone else wants to make suggestions), I've only spent a day on it, so it's nowhere near finished. I'll probably publish it for GNU release at some later point in time for anyone else needing the same functionality.
https://gist.github.com/anonymous/5d2c2d2967eac8774b69
P.S. As an aside, I'm still trying to get full functionality from the ALPS touchpad. Using some psmouse DKMS installers, I have been able to get multi-touch capabilities like two-finger scroll and two/three finger tap working. However, the 3 physical buttons don't do anything (even in xev/evtest). Passing proto=imps to the psmouse module causes them to work , but breaks multi-touch functionality. If anyone would like to offer advice for that, I'd be grateful as well.
I'm using a Virtex 5 FPGA and want to have a few +5/0 I/O pins to communicate with a microcontroller. The only peripherials I've used on the board so far are pushbuttons and switches and no one I've asked seems to know the simplest way to do this I/O. I've looked around the board specification but haven't found any simple way of doing it. I would appreciate any advice you might have.
This is not an easy thing to do. If you don't have the schematic of the board, then you need to get volt meter with some fine pitch probes and reverse engineer the board.
It is pretty easy if you have 2 boards, with one board it can be really hard since the BGA signals may not be connected to a via and therefore not available on the bottom of the board, and even if they are, then you don't know exactly which pin they are connected to. But with some luck, you can find them since the VIA can only be connected to 4 possible pins surrounding it!
The first thing you need to do is to identify your chip, find the BGA print of the IC from Xilin'x web site.
If your board has some buttons already, then if you are lucky, those signals may be routed to the pins of the FPGA that are available on the bottom of your board. Here are the things you need to do:
Make sure you have good ESD protection to perform these test
Put your voltmeter into 'buzzer' mode
Check the pins of your connector and find out how it is connected, see if there is a pull-up and/or pull-down resistors on the board
when you find the 'active' pin of your connector, start connecting the other probe to the VIAs one by one
When you hear a buzz, make a note of the position (guess or measure the distance between the side of t he IC and the location of the via)
Identify the 4 possible pins that the signal can be connected to
Write a code to get all those 4 signals and connect them to ChipScope
In Chip Scope, capture all 4 signals and see which one is the one with the right connection!
alternative, you can create a design with inputs only, capture all the inputs and put them into a memory block and create a trigger logic to capture all the signals whenever any of the inputs changes, after lots of work and analysis, you will find the correct pins.
Anyway, these are just crazy ideas since this is a really difficult thing to do without having the PCB info of the board.
Good luck with your hacking.