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.
Related
I am wondering what is suitable for my case, using espeasy or Tasmota. I know espeasy is using http requests and Tasmota is using mqtt.
I want to control my sonoff devices by a raspberry pi that is acting as a home automation hub, and it in turn send updates and receives commands from AWSIoT platform. For interacting with AWSIoT platform, it uses mqtt.
What are the pros and cons of using either? and will it cause problems if I control several sonoff devices with http, while using mqtt for AWSIoT? or better use mqtt for all AWSIoT and sonoff?
I am not an expert on the topic but have tried a few things and got some insight for you on why to prefer MQTT over HTTP.
Security. Remember that the 'S' in IOT stands for security. Joking aside. I have not seen an option for encryption (HTTPS) of the HTTP-traffic for tasmota. (May the internet correct me if I am wrong) So choosing HTTP means your user/password (which are not a requirement but should totally be used) are transfered via URL query parameters as plain text. MQTT has built-in mechanisms for encrypting the traffic. I haven't been able to get that working in my network but I'm trying.
Flexibility/Reliability. With MQTT/Tasmota you have the ability to implement automations that do not rely on your home automation hub by having your devices publish MQTT-messages directly to each other for interaction. For example if you would like to implement an emergency off button that turns multiple devices off you do not want that to rely on your home automation server. Doing this with HTTP 'could' be done too but requires all users/passwords of all the devices to reside not only in your home automation hub but also on other single devices.
Networking. Adding new devices to your hub should be as easy as possible. In matters of HTTP your home automation hub has to know how to find your devices via IP-addresses or domain names since it has to resolve a URL. When using MQTT you just connect your tasmota devices to your broker and use their topic in the home automation hub. The devices do not even need to have a static IP or reachable domain name of mDNS name of any sort. That's in an essence what makes pub/sub for IOT so interesting in the first place.
Existing support. Before building your own home automation solution be sure to check out home assistant (my favorite) or any of the other home automation solutions if they fit your need. Do not reinvent the wheel. A tipp for home assistant: Do not use MQTT auto discovery in combination with tasmota. This is the only thing that has not worked out for me. Manually registering devices works reliably.
Hope that helps. If you still prefer HTTP checkout the app "Tasmota control".
There are plenty of devices available, which are promoted with the phrase "compatible with alexa/google home", e.g. LightBulb or Smart socket
My question is:
Is it somehow possible to use and control these devices without using alexa or Google home? I'm specifically asking for WiFi devices like smart light bulbs or sockets. I would like to just connect them to my WiFi and then control them by sending some kind of HTTP-request to the devices, without using any alexa or google cloud whatsoever.
In my opinion if the devices are all compatible with these cloud-based services, they have to share some common API, which I should also be able to use offline just in my network, should'nt I?
Unfortunately I did not find any information about such an API that I could use.
Anyone has an idea?
It sounds like you're actually asking "do smart home devices have a local API that devices like Alexa and Google Home use?" With the implication that you can then take advantage of them as well.
While some might - the general answer is "no".
Neither Alexa nor Google Home control devices directly. Both of them send their commands to their cloud services, which relay the command to a device manufacturers cloud endpoint, which then relays the specific instruction to the device or the device's local hub or gateway.
If you only want to command your Google Home compatible devices with your voice, you can simply use the Google Home app from your phone (both iOS or Android) without having the Google Home device.
I want to create a plugin with web RTC for WP.
Is it comfortable to make? or there is any other way of making a video plugin easily? Is there any expert in this field?
Webrtc is an open project that enables browsers with real time communication capabilities.
Wordpress is a content management system.
Webrtc functionalities are browser dependent( with most modern browsers supporting it except safari). It is possible to create webrtc plugin for wordpress as wordpress plugin is just a program or a set of functions written in PHP.
In the plugin you just need to first check whether the browser supports webrtc or not. If it supports webrtc then you just need to provide signalling, create peer connection and register the webrtc events handlers like onicecandidate, onaddstream.
THE WEBRTC API:
It consists of a few main javascript objects −
RTCPeerConnection: It helps us connect to peers, initialize connections and attach media streams. It also manages a UDP connection with another user.
MediaStreamRTC :
There are three key points of functionality −
1.It gives a developer access to a streamobject that represent video and audio streams
2.It manages the selection of input user devices in case a user has multiple cameras or microphones on his device
3.It provides a security level asking user all the time he wants to fetch s stream
DataChannel : you may send additional data using DataChannel API.
You can learn more about webrtc at this link webrtc peer connection tutorial ,
webrtc media stream tutorial and webrtc Data channel tutorial
There are already many webrtc plugins for wordpress--- https://wordpress.org/plugins/wprtc-real-time-video-for-wp/
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.
What all would be the requirements for the following scenario:
A GSM modem connected to a PC running
a web based (ASP.NET) application. In
the application the user selects a
phone number from a list of phone nos.
When he clicks on a button named the
PC should call the selected phone
number. When the person on the phone
responds he should be able to have a
conversation with the PC user.
Similarly there should be a facility
to send SMS.
Now I don't want any code listings. I just need to know what would be the requirements besides asp.net, database for storing phone numbers, and GSM modem.
Any help in terms of reference websites would be highly appreciated.
I'll pick some points of your very broad question and answer them. Note that there are other points where others may be of more help...
First, a GSM modem is probably not the way you'd want to go as they usually don't allow for concurrency. So unless you just want one user at the time to use your service, you'd probably need another solution.
Also, think about cost issues - at least where I live, providing such a service would be prohibitively expensive using a normal GSM modem and a normal contract - but this is drifting into off-topicness.
The next issue will be to get voice data from the client to the server (which will relay it to the phone system - using whatever practical means). Pure browser based functionality won't be of much help, so you would absolutely need something plugin based.
Flash may work, seeing they provide access to the microphone, but please don't ask me about the details. I've never done anything like this.
Also, privacy would be a concern. While GSM data is encrypted, the path between client and server is not per default. And even if you use SSL, you'd have to convince your users trusting you that you don't record all the conversations going on, but this too is more of a political than a coding issue.
Finally, you'd have to think of bandwidth. Voice uses a lot of it and also it requires low latency. If you use a SIP trunk, you'll need the bandwidth twice per user: Once from and to your client and once from and to the SIP trunk. Calculate with 10-64 KBit/s per user and channel.
A feasible architecture would probably be to use a SIP trunk (they optimize on using VoIP as much as possible and thus can provide much lower rates than a GSM provider generally does. Also, they allow for concurrency), an Asterisk box (http://www.asterisk.org - a free PBX), some custom made flash client and a custom made SIP client on the server.
All in all, this is quite the undertaking :-)
You'll need a GSM library. There appear to be a few of these.
e.g. http://www.wirelessdevstudio.com/eng/
Have a look at the Ekiga project at http://www.Ekiga.org.
This provides audio and or video chat between users using the standard SIP (Session Initiation Protocol) over the Internet. Like most SIP clients, it can also be used to make calls to and receive calls from the telephone network, but this requires an account with a commercial service provider (there are many, and fees are quite reasonable compared to normal phone line accounts).
Ekiga uses the open source OPAL library to implement SIP communications (OPAL has support for several VoIP and video over IP standards - see www.opalvoip.org for more info).