From what I've read online in forums and blogs, Windows Phone 7 has no support for bluetooth serial. There also does not seem to be any support for communication with accessories through USB. Can someone give me a definitive answer as to whether or not Windows Phone 7 can do any sort of command and control for external accessories? I've used bluetooth serial on Android as well as the iOS external accessory framework. I would imagine there would be some level of support for external accessory communication in the Windows Phone 7 platform.
I can confirm that there is no Bluetooth/External Accessory API exposed as part of the SDK. There may be a private API available to select parties (though I'm not familiar with any apps that do so), so it might be worth contacting Microsoft.
Keep in mind that, even if you find a private/internal API you won't be able to call it (even via reflection) and it would be caught during the certification process anyway.
If it's not possible to communicate with the accessory via Sockets/HTTP then I'm afraid you're out of luck for now.
Related
I already have an home automation ios app. I can able to control devices that are configured in my home. I can able to access my device via local and remote network.
I just read apple's new ios8 HomeKit support. I want to integrate HomeKit compatibility into my app.I heard HAP(Home Accessory protocol) supported devices can only able to communicate with HomeKit Framework. Also apple said there is a bridge for third party devices to communicate with HomeKit. There is not much information about hardware protocols or procedures, how to use bridge between third party device and HomeKit ?
Is my HomeKit bridge is a real hardware?
Also i have doubts on communicating with configured accessories. Because apple HomeKit Framework have commands like "startExecutingActionSet" to perform one or multiple task , but how this commands works with our Existing commands protocols defined in ios app.
I am new to hardware engineering . So please give me a simple example of communication between apple's homekit via bridge with my Hardware device.
Thanks in advance...
A HomeKit bridge is a piece of hardware that receives HK style commands from an iDevice and translated them into the specific protocol for the target devices in your home. Phillips Hue have one of these. Apple have a protocol that the hardware manufacturers need to conform to and you need to be signed up to their MFi program to get that protocol. However someone seems to have reverse engineered the specs and you can use their code to write your own software bridge. That's what I'm doing.
In HomeKit you do not talk directly to the devices. That's pretty much the main point of HomeKit. So that each developer doesn't need to know each device's specific protocol you just trigger iOS to do the talking for a predefined action. I believe you can also add triggers and action sets by building up a group of actions that you want to happen and firing of the event. E.g. Turn off all accessories in the garage when I go inside. You don't need to know how to turn off each one, you just tell iOS to run the Off command on each device and it knows the rest. Or at least it does for the ones that have signed up to the MFi program and can listen to HomeKit commands.
I just come across about ibeacons technology which introduced by Apple but haven't got any API/framework from Microsoft.
Is there any API or framework available from Microsoft which gives support for Ibeacons implementation?
Thanks
Unfortunately, this is not possible with Windows Phone 8, because it only supports Bluetooth 3.1 iBeacons require Bluetooth 4.0, also known as BluetoothLE.
In October 2013, Nokia announced that upcoming phones would have Bluetooth LE support. Unfortunately, these only allow OS-level pairing with Bluetooth LE devices. There is no public api.
This makes it impossible to develop a third-party iBeacon Library for the Windows Phone similar to the Android iBeacon Library.
Unfortunately, Windows Phone users will have to wait for a later release with either native iBeacon support or a public BluetoothLE API that allows a third party to develop a Windows iBeacon Library.
Update: this appears to remain impossible with Windows Phone 8.1. See my comment on the answer from #keni
Update:
Windows 10 will support Bluetooth LE Advertisements. Current status as of today (4/23/2015) is that the preview build of Windows 10 still has an incomplete SDK implementation and a few bugs. However, next week a new build will be introduced and it can be safely assumed that we'll get a good glimpse on how this will actually work.
Sending and receiving pure Advertisements works already. Have a look at the Sample that you can download from github here:https://github.com/Microsoft/Windows-universal-samples/tree/master/bluetoothadvertisement
Update
a public BluetoothLE API will come in Window Phone 8.1
http://allaboutwindowsphone.com/flow/item/19234_Windows_Phone_81_receives_Blue.php
Please read the following blog post for BLE for developers in Windows 8.1
http://sviluppomobile.blogspot.com/2014/02/ble-for-windows-81-part-i.html
I know the midiXxx API, but I saw it is currently listed under 'legacy' in msdn.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd743619(v=vs.85).aspx
Is there some other API i should use to target the newer Windows versions?
Will the old API still work on Windows 7 and 8?
Thanx,
Marc
Last Friday Microsoft released a preview Windows Runtime API for MIDI. Check out the //build/ session here:
http://channel9.msdn.com/Events/Build/2014/3-548
MSDN: http://msdn.microsoft.com/en-us/library/windows/apps/dn643522.aspx
Although a preview, apps can go live and be deployed to the Windows Store. Please let us know what you like or don't like. Happy app building!
For dektop applications (non metro) you can still use the legacy API safely.
Sadly for WinRT/Metro, there is no midi support at all (see this discussion on msdn).
Hope they will change that.
Catflier is correct that there is no direct support (at the API level) for MIDI in WinRT. However, if you are wanting to have MIDI-like capabilities in your app, there are workarounds. A protocol growing in popularity is the network-based OSC (Open Sound Control). Since it is network-based, you can use that.
For example, one can use external hardware like The Missing Link which translates from MIDI to OSC. You hook up your MIDI device to The Missing Link, which then translates to OSC messages that are sent to the computer. Your app can then receive OSC messages and talk to the MIDI device. I don't have any code to show here, but I've seen demos of this working in-action.
You can see OSC in use on iOS as well with popular apps like TouchOSC.
I'm trying to implement an AVRCP/A2DP connection between my Android phone and my car PC. The A2DP bit basically works out of the box so no issue there. I want the PC to be the AVRCP CT (controller) and the A2DP sink. The phone is the AVRCP TG (target) and the A2DP source.
Where I'm having trouble is getting any sort of AVRCP connection that I can use. Windows 7 comes with a toolbar application that at least provides the basic play/pause/skip/stop type functions. So it definitely works with the software I have without any extra drivers or otherwise. However my searching has produced little results on any way to do this or documentation on creating an L2CAP connection which I believe I need.
The 32feet.NET libraries don't support L2CAP connections unless you use a Broadcom/Widcomm stack. Buying a new BT USB device may be a viable solution but at the moment I'm trying to do this all in software :). i.e. like this although there a problems noted there that weren't solve (or reported as solved)
link: How can I establish an AVRCP connection from Windows 7 (controller) to phone (target) using L2CAP on Widcomm SDK?
I'd prefer to do it C# if possible but if I had some kind of library to interface with my code, that would be fine (like the 32feet.NET library which works quite well for the things it does work on.)
This is about the closest I've got but is all a bit Greek to me and not quite enough to get me started (I'm an embedded guy):
http://msdn.microsoft.com/en-us/library/windows/hardware/ff536674(v=vs.85).aspx
Is Bluetooth really such a mess on Windows that it seems to be from my searching? There are multiple different stacks that all seem to be significantly different in terms of the API etc.
Can anyone point me in the right direction? I've done a lot of searching/reading other posts here and elsewhere and not really made any progress.
Thanks
Christian
I wasn't able to find a clean answer on this, is there or is there not a way to connect my iPhone to a bluetooth printer to execute some printing tasks?
I'm developing the app myself, so what framework could possibly do this? i read that Apple's External Accessory Framework handles bluetooth communication, but is it possible to print using that framework?
Thanks!
Since this question is 2 years old, things change and this was the first result for what I was looking for I decided to submit this answer after some "research".
From the SAME Apple Technical Q&A
Note: Bluetooth low energy accessories do not interface with the
External Accessory framework and are not required to be MFi compliant.
Instead, apps use the CoreBluetooth framework to communicate with
Bluetooth low energy accessories from iOS or OS X.
So, it may have not been possible 2 years ago, but it is possible now.
Edit: As the accepted answer points out, things are different since I posted this answer in 2010. The answer is left for posterity.
From an Apple Technical Q&A:
The External Accessory framework is designed to allow iPhone OS applications to communicate only with hardware accessories that are developed under Apple's Made For iPod (MFi) and Works With iPhone licensee program. MFi compliant accessories can be implemented as wired devices, meaning they plug in to the iPhone or iPod touch's 30-pin connector, or as wireless devices, whereby they use Bluetooth as the communication channel. Either way, an application that uses the External Accessory framework will not be notified of an accessory's presence unless the accessory identifies itself as being MFi compliant, i.e., it was specifically designed to interface with an iPhone OS application.
More information about developing MFi accessories can be found here.