I have a Google Home mini, and a CSRMesh bluetooth.
First, I need to pair my bluetooth device with google home, and after create a action for google assistant for light control for device.
I not have idea how start this project and if is possible, somewhere idea?
Actions do not run on the Google Home device itself, and Home devices do not directly manipulate most bluetooth smarthome devices. Instead, these devices rely on a cloud-based server, and the Assistant communicates with this server to control the devices.
Related
Since the latest update (I think some time in December 2022), the built-in camera app on my Samsung Galaxy S21 asks for "Nearby devices" permission, and refuses to run if I don't grant it. By "Nearby devices" it means "Bluetooth". I don't know why it calls the permission
"Nearby devices": all other references to Bluetooth call it "Bluetooth",
and you can also access a nearby device using Wi-Fi or even NFC if the device
is close enough.
It doesn't actually need Bluetooth to take photographs, or even to record movies,
but you might have a Bluetooth microphone (I don't) and you might want to use
it to get better sound quality when recording a movie.
Of course the Android best practice advice at
https://developer.android.com/guide/topics/permissions/overview
is not to ask for runtime permissions unless and until you need them,
but Samsung aren't doing that.
I don't want the camera app to announce my presence by probing the Bluetooth headset of
anyone who happens to be near me, and they might regard such an action as intrusive.
So I don't want to give the camera app its nearby devices permission, but it won't
run at all without it.
So how do I get the camera app to run without accessing Bluetooth?
I found some workarounds for this. If your device supports it, you can download Expert Raw from the Galaxy Store. This will take still photos without requiring "Nearby devices" permission. However it doesn't seem to be able to do selfies because there seems to be no way to switch cameras, and it can't do movies or many of the extra tricks that the full camera app can do.
Another option is to run the camera app with Bluetooth disabled. Then it can have its "Nearby devices" permission, but it can't use it. The problem with this is that if you use Bluetooth at other times you have to remember to disable it and enable it.
So I wrote a tiny app which disables Bluetooth, runs the camera app, and restores the previous enabled or disabled state of Bluetooth when the camera app exits. I put this on my home screen instead of the camera app: it has the same icon. You have to remember to exit properly from the camera app using the Back button: the Home or Recents buttons leave my app and the camera app sitting on the task's back stack, so my app doesn't get to run and restore the Bluetooth state.
The app is available on github here in case anyone else wants to use this solution.
I have created a smart switch using NodeMcu Esp8266 wireless chip and programmed Websocket to create a TCP protocol to communicate. I wanted to know how should I proceed to interface this with google assistant and host my app on home control settings on Google assistant app?
Google's SDK for android google assistant
Here if you are connecting to a Google Home
When performing a BLE scan using startScan(onFoundBLEDevice, onBLEScanError). First, is the parameter sent to onFoundBLEDevice a single device or is it a list of devices? And if the answer is "single device" what happens when there is more than one BLE device in the local vicinity when performing the scan?
Secondly, Since my goal is to retrieve the battery level from my own smartphone (the one that is paired AND connected to my smartwatch) how can I tell which of the devices found by my scan is the one that's connected? Or do I even need to perform a scan? Is there another way to retrieve the device object in order to then get the battery service 0x180F and then the battery level characteristic, 0x2a19? In other words, I want to be sure that the battery level I retrieve is that of my phone, not my buddies sitting next to me.
UPDATE: my smartphone is a Samsung Galaxy S3 running Android 4.3 and my smartwatch is a Samsung Gear S2 running Tizen 2.3.1. I'm using Tizen Bluetooth API.
The BluetoothLEScanCallback (In your case onFoundBLEDevice) is invoked everytime a device is found. (For 3 nearby devices -> 3 calls)
I've scanned nearby devices from my gear while it's connected with a Mobile through 'Samsung Gear' app. No, There's no way to distinguish specific Mobile connected via Gear Manager from other devices. So, You can't find the connected device in this procedure. (Unless you are developing the app for personal use, In that case you can hardcode your Mobile device's UUID)
Samsung Provides 'Accessory' SDK for such purposes.
Samsung Accessory SDK
Any data you exchange using Accessory SDK would provide you info of specific 'The Connected' device via Samsung Gear. Check Out the API References, Programming Guides and Android-End Sample apps and Tizen-End Sample apps in Accessory SDK section.
I want make a simple app (action) on Google Home speaker but I cannot find any docs in which is described how to get access to mic.
Is there any chance to develop VoIP app on the Google Home device?
In short - no. (Or at least not at this time.)
The only access Google provides third-party built apps is through Actions on Google, and this does not provide direct access to the microphone or to an audio stream.
For example, if I have a friend over and he wants to show me a video using a given app that runs both on my device and his device. Could that app display a QR code on the screen or something that he could scan and instantly be granted access to my Chromecast device?
As Ali mentioned, Chromecast devices are discovered and apps launched via local network applications. One an app is started, it could easily connect with a cloud service that allows other (non-local) devices to talk w/ your Chromecast via the cloud service. A Chromecast Receiver application is just a HTML5 application (HTML, CSS, and JavaScript). You can really do what ever you want once your application gets launched.
If displaying a QR code that allows some kind of rendezvous with your cloud application is what you want to do, you can certainly do that.
I presume your friend's mobile device is on the same wifi network, right? Currently, a chromecast device has no identity outside of its local wifi network, so if the sender is not on the same network as the receiver, there is no way they can exchange messages. Back to your question, if your friend is on your network, then he could see your device except from those applications for which your device is not whitelisted for. Is that the case you want to handle through, say, a QR code? If so, that is currently not doable either since whitelisting is not just a local setup. Maybe I misunderstood your question?
Based on your questions, you are saying that both you and your friend have the same app. If so, and if your friend connects to your wifi network, then he will see your chromecast (you do not whitelist a device for a phone, you whitelist a device for an app id and as long as your friend has the same app (hence the same app id I resume), your whitelisted device will be discoverable by his phone. On the other hand, if you do not want to give him credentials to get on your network, then you need a cloud backend and a lot of work, since although your chromecast device can send a message to cloud and your cloud service can notify the other user's phone (using, say notification or some other mechanism that you employ in your app), the reverse (i.e. sending a message from your friend's phone to your chromecast (through your cloud service)) is much harder. Your friend's phone can send your phone a message (again via a back end service, a bluetooth communication, NFC, etc and then your phone using your app can send that to the chromecast receiver but I am sure you are getting the idea that it is a lot of work. Signing up on your wifi network can be made easier with a QR code or something so at this pint, that would be the easiest solution.