Anyone knows if external accessory can launch terminated apps in iOS?
The documentation, from Apple, says that "Declaring support for specific protocols lets the system know that your app can be launched when that accessory is connected".
So if my app register a protocol X, and I connect my iPhone to a bluetooth accessory that has that protocol (X), my app is launched, in background, even if is terminated (like CoreBluetooth)? And I can send commands to that accessory?
Thanks
I think it's clear from the External Accessory Programming Topics, which you quoted (copied below), that the app can be launched, meaning the app didn't need to be already running in the fore or background. However "launched" to me does not imply launched in the background, such as is done with the CoreBluetooth background modes, but rather, it means launched normally into the foreground.
Apps that are able to communicate with an external accessory must declare the protocols they support in their Info.plist file. Declaring support for specific protocols lets the system know that your app can be launched when that accessory is connected. If no app supports the connected accessory, the system may choose to launch the App Store and point out apps that do.
Related
I am working on open-source programs to control Amateur radio via serial ports. However, since serial ports are an exclusive resource only one application can use it at a time, but there is many applications that want to talk to the radio. I am writing an application that pretends to be a radio so the client can talk to it. Under the covers via SignalR sends and receives radio information via HamBus which the repo is on GitHub if you are interested.
So what I need is for the ham app that wants to talk to a radio via rs-232 to talk to my app via ptys instead.
On Windows, I use virtual COM ports and it seems like I can use PTY for the same purpose.
Is this possible? Can I do it with C# and .NET Core?
node-red-contrib-homekit is a slick way to create virtual HomeKit devices in Node-RED, providing a bridge to non-HomeKit-aware hardware.
When it is time for my Node-RED flows to talk to real HomeKit devices, however, it seems to get messy.
To control a HomeKit device (thermostat, outlet, bulb, occupancy sensor, etc.) from a Node-RED flow, the most elegant solution I know of is to install Homebridge and something like homebridge-mqtt alongside Node-RED, which feels to me like a big, awkward hammer.
I feel like I'm missing something--is there a more direct approach? Or am I doing it in an advisable way?
As far as I know, there is no way to talk from Node-RED to HomeKit enabled devices using the HomeKit protocol. Apple only publish the specs for client devices and services, but the HomeKit server, and therefore UI, can only be iOS device. You can think of HomeKit as the Apple alternative to Node-RED. And the control can only be one way - from Homekit to Node-RED. You can make the data flow both ways though. For instance you can create virtual HomeKit switch in Node-RED, that the Home app can control using automation (like turning on when you're home). Thus you can have binary communication between them.
The protocol actually specifies a set of predefined accessories with their options and capabilities, and each manufacturer should provide API for the selected accessory. One physical device can have multiple virtual accessories - like temp and humidity sensors, that are shown as two items in Home app, but might be one actual device.
You need to use your iPhone/iPad to add and control the bridge/accessories, that you can create in Node-RED or are licensed HomeKit devices. But they are not able to talk to each other using that protocol. You'd have to find alternative way for doing this by looking for another API by the manufacturer. For instance Hue is certified as HomeKit and you can add it to your Home app directly, but if you want to control it with Node-RED you'd need their other API as the HomeKit server is proprietary.
Also for Node-RED use the updated node-red-contrib-homekit-bridged that can simplify your management.
I’m in the process of changing my setup from the node-red Homekit node to a separate Homebridge with the MQTT plugin myself. Not only because it is more elegant but also more flexible HomeKit-wise, provides a “separation of concerns” between processes running, and also let’s me just add one bridge to Home app.
There’s also a websocket plugin for Homebridge which also plays nice with node-red but as I have a mosquitto MQTT broker running anyway I might as well use the “language of IoT”.
I am in the process of connecting Homekit related devices and services with Node-RED using Homebridge. Both Homebridge and Node-RED can be installed on the same machine (a Pi).
There are several plugins available to connect Homebridge with Node-RED and maybe you can create a flow that then controls your devices for which you also have to find a plugin in Node-RED. It may be a bit over engineered as there are tons of plugins available for Homebridge directly but using Node-RED is much more fun. The MQTT way is also a good start but I didn't want to mess with protocols and stuff.
I'm currently doing a test UWP app, the goal would be to put this on a Raspberry PI with Win 10 IOT ont it.
I've not much content, the application just display all the zodiac signs, and when one signed is clicked, it displays the current sign information. This will be display on a monitor here. So I would like to be able to navigate between sign, with a remote by example(but I'm open to any other proposal).
What would be the more adequate to navigate on the application(knowing that I don't need to enter anything, that it's not a touch screen but a simple monitor).
Thank you
You could use the GPIO port on the Raspberry Pi to connect the device with any of external controllers of your choice. Wired buttons would be pretty simple, and for a remote your could use an infrared receiver. The GPIO allows you to interact with pretty much anything electronic so the possibilities are pretty much endless.
For interacting with the GPIO port you need to add a reference to the "Windows IoT Extension SDK" to your universal windows app project.
The samples repository has code examples on how to interact with the GPIO port, and many of them are explained with tutorials.
I am trying to find a clever way to keep a BLE app active in the background on iOS 6, without breaking any of Apple's rules. I plan to use the phone as a peripheral device and another BLE circuit as the central. My app will automatically be opened when a user arrives to a building using geofencing. After that the iPhone will connect to the first BLE central device it sees (the device will be in its white list). The user will then be able to move throughout the building switching to different BLE "nodes".
My question is: What do I need to do in the background when a user is stationary at their desk so that the app does not get suspended due to memory resources?
My idea is based on this solution for a separate problem: There could potentially (not regularly) be 10-50 users in an area with only a few BLE "nodes" and I read at bluetooth.org that I could setup a dynamic connection system, basically rotating connections through all the users.
My idea is to setup a similar dynamic system where the central device (not the iPhone) disconnects the device on regular intervals (30-40 minutes) and then the iPhone will reconnect.
Is this something that some feasible? Is this against the iOS development guidelines? I was unable to find anything explicit about this. I have also asked on the iOS developer forum, but unfortunately it is not as popular as this site.
Thanks in advance!
Xcode -> Project target -> Capabilities -> Enable background mode
Check Uses Bluetooth LE Accessories
Capabilities
Also enable the following key in .plist file
Required background modes
App communicates using CoreBluetooth
Plist
I'm working on firmware for an MFI device and when the user plug in his device I can test if he has a specific app. However, if he doesn't have it I would like to open App Store and show him the application so he can download it.
I cannot figure out how to do that. Any ideas or links to docs that can help?
Yours
/peter
This is from the developer docs at this link.
Declaring the Protocols Your Application Supports Applications that
are able to communicate with an external accessory should declare the
protocols they support in their Info.plist file. Declaring support for
specific protocols lets the system know that your application can be
launched when that accessory is connected. If no application supports
the connected accessory, the system may choose to launch the App Store
and point out applications that do.
To declare the protocols your application supports, you must include
the UISupportedExternalAccessoryProtocols key in your application’s
Info.plist file. This key contains an array of strings that identify
the communications protocols that your application supports. Your
application can include any number of protocols in this list and the
protocols can be in any order. The system does not use this list to
determine which protocol your application should choose; it uses it
only to determine if your application is capable of communicating with
the accessory. It is up to your code to choose an appropriate
communications protocol when it begins talking to the accessory.
So as long as your app and your device have the same external accessory protocol, you shouldn't have to do anything to get that behavior.