My idea is to have single addressable RGBW LED strips in all my rooms. For the sake of practice and interest, I do not simply want to by some controller, I want to start this project with some custom self-build infrastructure, consisting of some Arduinos and/or raspberry pis. My initial idea was to just setup a simple local server on a raspberry (which controls the arduinos connected to the LEDs) and build myself an app to control the lightning. That part is clear to me and should not be a problem, but I thought it might be a plus to integrate my devices directly to Google Home so I do not need any extra app.
I read through the Smart Home Platform but things are not 100% clear to me. I read things about requirements like public Oauth2 Server. I was wondering, if it is possible to get this working without setting up any server which has to be reached publicly, because otherwise I won't waste time on that topic.
If you want to control your room devices from a smartphone and are satisfied with local operation from few meters away than you should consider BLE on phone and devices.
Obviously, you would need to write your own app, but luckily with BLE you can use publicly available apps such as LightBlu for the dev phase and maybe even for later use (I have not looked into that lately).
A question about registering BLE notification on android:
I am developing an app that once the android device detects our beacon/ble hardware, should write something to one of the writable characteristics of that hardware.
Trying to understand, on the android app side how can I register some intent to be called when a ble connection was made to the android framework.
since a broadcast receiver registered in manifest can no longer launch my app and android background services policy was changed, this can't be done. so..
I am trying to use JobScheduler which was designed to be launched based on criteria. this can launch a JobService to do the job.
When the app is in foreground or background this seems to be working.
The thing is, I need to be notified when the app is not running (Not even in background)
I'm working on a voice recognition app that connects to custom hardware using a bluetooth handsfree profile (HFP aka headset profile) connection. The application is used to pass PCM audio data to a cloud based voice recognition server, by leveraging the Android AudioRecord class. This functionality works fine if the application initiates the SCO connection, but if the headset hardware initiates the SCO connection, by issuing the AT+BVRA HFP command to the phone, Google Assistant always hijacks the phone. Thus, my question is how can I stop this? Is there a way to programmatically tell Google Assistant to chill? I've tried many different things (AudioManager sco management, AudioRouting preferred connection, BluetoothHeadset profile class, Java Reflection & View.setAssitBlocked(true), etc...), but none of them seem able to either block Google Assistant or recapture the SCO connection. (It also seems that the handset opens up an A2DP for google assistant's audio feed). I'm hoping this is possible with a Java based solution... ?
As noted by another answer, what is likely happening is that Android is broadcasting an ACTION_VOICE_COMMAND intent, and since Google Assistant is set up to receive it, it gets priority on the connection. Your app could register for the intent and see if it gets priority on receiving it.
I'm currently working on an experimental Android Kernel (Research). I'actually trying to find some ways to preserve battery charge by implementing a kind of power management tool on the kernel level. I'm working on the msm-hammerahead kernel (used by the nexus 5 running Android 5.0).
I'm trying to figure out if there exists a way to switch between network types (2G,3G,Wifi) at runtime. I know that there exist the possibility to switch the default network type within the build.prop file(ro.telephony.default_network).
Does anybody know if it is even possible to achive this?
The android kernel is not the place to look for network switching. build.prop is also useless for this because it just contain the default boot values.
Switching network interfaces is a very bad idea, because the android framework need to be synchronized with the lower linux layer state.
I would suggest checking the ConnectivityManager.java in the android framework to understand better how the network switching works.
is there a way for a server to push some data to a client, wirelessly and seamlessly, which may be Windows(Phone), iPhone, Mac, or Android device, without any OS integration?
If so, what's the best design pattern to do this, and what are the best technologies to go about this?
Push technology is simply a methodology of the server initiating the transfer of data, rather than the client asking the server for it.
Apple makes push technology relatively easy to use by providing such functionality built-in on the OS. As well as Android through the Google Cloud Messaging for Android. Windows, however, does not.
Apple push notifications and Google's messaging for Android is seemingly magical and/or functionality that the OS needs to handle; however, this isn't necessarily the case. The advantage of having it "integrated" in the OS, is the same as having a framework handle the functionality for you.
Speaking in technical terms, push technology is a long-lived connection from the client to the server that accepts messages. These messages would be considered pushed messages, since the client did not make an individual request for them.
The main thing to keep in mind when implementing push technology yourself, is that the client is in charge of keeping that long-lived connection alive as much as possible. Because client IP addresses can change between disconnects, servers are not guaranteed that a client's address will be persistent across disconnects. Moreover, clients can be connected from behind a firewall, making it impossible for a server to reach the client.
For comparison, pull technology is the more traditional process of a client connecting to a server and requesting data.
Your best bet for Apple iOS will be using their push notification service.
For Android devices you should use the Google Cloud Messaging for Android. Alternatively, you can create your own background service to handle the messaging; here's a guide.
For Windows (desktop at least), you will have to create your own service to perform such duty. Here's an MSDN guide explaining how to create a Windows Service using Visual Studio (VB and C#). There might be frameworks already built that handle such messaging on Windows, however, I don't know of any.
Use WebSocket (with or without socket.io).
In the future, you could use WebRTC.
With Websockets, the setup is really simple. The client (a user agent, like a browser or a WebView) connects to the Websocket server, over http(s) (less problems with firewalls) and that's it. There's a bidirectional socket with an event-based API.
If by "OS integration" you mean "write special code for each platform" then the answer is no.
As you mentioned, you would like file system access, and background processing. That combination is not available in a cross-platform way at this moment.
If by "OS integration" you meant "without having to wait for apple/google/ms to provide the ability" then the answer is yes/maybe.
All the popular platforms have Push notifications and background processing support, as long as you code it the way each particular platform expects it.
But file system access will be limited to what restrictions the platform places on you. For instance in ios and win8(phone) there is no wy to write or read a file outside of your own apps private file structure. For security reasons, you cannot access the file system of other apps.
UPDATE:
The general pattern here is to release an app for every platform you want to support.
The app will register itself with its respective platform's push notification service.
You will write generic server side code to accept the data you want to push to all your client devices. Then you will invoke the respective push API's for each platform you support, causing the client devices to wake up and trigger the app that you provided to respond.
When the app opens, you get the app to contact your server and download the full data "the push notification being just the wakeup call for your app"
This way you can easily tell how which of your devices have received the data.
Each platform specific app must save the data to its own local storage and provide a way for the data to be shared via the methods supported by its respective platform.
On IOS it can be as simple as supporting the "Open In.." paradigm.
On W8Phone, you'll have to publish the data via one of the available "sharing contracts"
And so forth for every platform you want to support.
This is the general pattern at the moment. There are some caveats. On IOS, the app will nt automatically start when a push notification is received. This means your app will only download the whole of the data when the app is opened by the user.
A mobile app also cannot generally run indefinitely in the background. This means that once the app is started, you have a limited window for push notifications to be automatically processed by your app. After the allowed "background time". The app will close and any push notifications beep on the device, but wont open the app until the user taps on one of the notifications or opens the app directly.
Technically you could use XMPP Libraries, it is meant for implementing chat system (msn, gtalk, facebook chat, etc...) but this could work well as a push message system because it is opensource and well built to handle all the cases you never thought of. Also you could host your own server and send push message that way...
Why not use a webservice? In my previous project I used webservice to deliver data from mysql database. The webservice I used was nusoap. On the client side I used kSoap library for Android. Hope this helps.
if you want to receive and send real time communication between a server and client (irrespective of the device or OS), i would highly recommend you use XMPP technology because it is designed for the sort of things you're asking for.
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language [XML] that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. The core features of XMPP defined in [XMPP‑CORE] provide the building blocks for many types of near-real-time applications, which can be layered on top of the core by sending application-specific data qualified by particular XML namespaces.
http://xmpp.org/rfcs/rfc6121.html#intro - that is the latest RFC which will give you a good starting point.