Develop Reference

Communication between BLE device and different android apps on same device

I'm new in Android BLE so my question may be uncorrect or naive in some way. If this is the case please explain me where I'm wrong and kindly show me the correct way to manage this scenario.
Scenario is the following: my Android app communicates with a BLE device sending commands and getting answers from device using BLE characteristics.
Sequence is:
Device wakes up the app (the onConnectionStateChange method is called)
My app writes a command in a characteristic (I call writeCharacteristic putting the command in value parameter).
Device sends back the answer to command to my app (the onCharacteristicChanged method is triggered and value parameter contains the answer)
After waking up the app, the device doesn't do anything until a command is sent via writeCharacteristic. The device accepts different commands.
All good so far, but recently I developed a second different app to communicate with same device.
When I run both apps on same Android phone, one app sends a command to the device and the response is received by both apps! Of course the app that didn't sent the command receives an unexpected answer and goes to an unexpected status.
Ok, knowing the problem I can modify both my apps to handle this situation, but the question is: Is this behavior normal when two apps in same device communicate with same BLE device?
Is there a way for an app to establish a communication channel with a BLE device to avoid sending answer to specific commands to any other app except the one that sent the request?
My guess is that writeCharacteristic and onNotificationChanged aren't the right functions for such kind of communication, but in this case which are the alternatives?

The Bluetooth standard itself doesn't define anything how multiple apps would behave if both have a GATT connection to the same device. In the standard there is just one "GATT client".
Now both iOS and Android have taken one step further in a way that might seem unintuitive. Instead of only allowing one app at a time to communicate, multiple apps can be connected over the same GATT client to a device. The OS "multiplexes" the communication from/to the apps. The behaviour is that responses to read and write requests can only be seen by the app that made the request. So if you do readCharacteristic only that app will get the onCharacteristicRead callback. Notifications however will be delivered to both apps to the onCharacteristicChanged callback, since it wouldn't make any sense to send the notification to only one.
When you say that the "response" to a write request is the notification, that's not correct in terms of GATT terminology. The response to a write request is always empty per specification (or an error). If your peripheral emits a notification, then in your case that might be the "answer" according to your own logic, but it's not a response or any way related to your write request per the GATT specification. That's why Android can't (and shouldn't) send the notification to only one device.
I suggest that you simply ignore notifications you are not expecting. If you want to associate an "answer" to a write request, you can change your protocol to include a transaction id in both packets so they can be matched.
When I write "app" above, I really mean BluetoothGatt objects. You can call connectGatt twice with the same remote device in the same app, which will behave the same as if you connected from two different apps.

How to get data from RS-485 connected by USB

I need to read data from some Data Aggregator Device over RS-485 interface by USB port (USB-to-RS-485 converter used) for the Desktop App on JavaFX, so I have stacked on checking connection and getting proper values.
Data Aggregator Device collects information about produced current, power etc. from PV-module (Solar Energy). This device has the only RS-485 port. As I read from a documentation, it uses Modbus RTU protocol (with settings: 9600-8N1).
To be honest, It's my first experience with working on COM-ports and Devices. That is why I don't know even am I correctly connect pins. I read a lot of things related with RS-485, Modbus. But, still, I am on the first steps.
So, I use simple UTP cable to connect. And what I have done:
This is how I connect USB-to-RS485 converter
And this is
about Data Aggregator Device
Windows found virtual "COM3" port, after connecting USB to PC. Then I try to check connection with Terminal 1.9 by Bray. I try to send something. And as receiving messages it sent me some data also. However, it doesn't mean that everything connected well. Also terminal shows me some FRAME ERROR.
I know, that Modbus protocol based on "master-slave" scheme. Therefore, PC as a client is "Master" and device as a server is "Slave". I have to send some request to the slave to get some expected response. But, how?!
Please, check my connections! I don't know what to do next.

RS-485 is differential and requires just two wires, you can safely remove the ground wire (GND). Then, connect the wires to R+ and R- on your USB-to-RS485 converter
Done that, may I ask you how you tried to send something? Modbus requires a final byte, the CRC which is hard to determine by hand. Did you create a valid modbus packet?
A valid modbus packet requires a receiver address, the payload length, the data itself and the final CRC

I don't know about java, but if you do have specification of devices protocol, you can surely use terminal program to send message to modbus and read messages back. That way you will have protocol tested and it shouldn't be to hard to make custom software later. But until you can send message and get back meaningful message using terminal software I recommend you to stick to it.
This youtube video will give basic knowledge needed about modbus RTU packet format: https://www.youtube.com/watch?v=OvRD2UvrHjE
The most difficult part is calculating CRC every time. But luckily you can download Docklight terminal. It actually has an option to calculate CRC automatically for modbus and add it at last positions of the packet.
You can download free version at their homepage.
docklight.de
It is very simple to use. Same as Bray terminal you used.. And here is example of how to set up modbus CRC calculation for every package.
https://docklight.de/manual/sendingmodbuscommandswithc.htm
I know they also have great support.
Once you successfully send message to device and get answer, things will get much easier because you will understand how protocol actually works. Modbus RTU is very mature protocol, but it is still used because many existing systems use it and it is very simple to add it to some device. All device needs is Serial port (UART) to connect to modbus. So it is not that hard to understand it and use it. Just check out explanation video and terminal specifically adopted for modbus that I gave links in this message.

A connection between 2 applications

I would like to manage a connection between 2 applications, they will run on diffrent phones.
The purpose doesn't really matters let's say that it would be some kind of a chat.
How can I create this connection between the applications? I know how to do it on pc java programs using the socket and the serverSocket classes but I guess it's diffrent in here since the phone might change his ip when he moves between networks.
So how would you do that? how would you create a connection between 2 applications/phones

Given the scenario you described in your comment, using Push Notification i.e Google Cloud Messaging (GCM) might be sufficient.
So, when program B wants update from program A, it will ask the server to push a notification (via GCM) to program A. Note that program A will not connect to the server every x time to check for updates.
Another out-of-the-box solution is to use SMS if the communication is not so frequent and messages are short. Here I mean SMS that will be processed directly by your app (given it has certain attention word) and will not go to the inbox i.e. no SMS notification on the phone

Since the two phones will, as you note, have changing IP addresses, you'll probably need to use an intermediary.
The general design pattern here would be to have a server with a fixed IP or DNS address that relays messages between your two mobile devices. The simplest implementation would be a webserver, to which each phone would connect via HTTP(S) to transmit data or poll for updates.
There are a number of backend-as-a-service platforms that provide this type of functionality pre-built, and would likely suffice for something like a chat system. Check out Cloudmine and Parse.
If you need a low-latency or near-realtime connection, you could also consider implementing your own server that uses the Android C2DM (Cloud to Device Messaging) service.

See Android's Sample Bluetooth Chat App, It will give you an idea for how it can be achieved.

Is it possible to transfer data directly between two android devices to other users in the same network?

Let's say I have two android mobile devices, connected to the same wireless network, and that network hasnt external/internet access.
Without third party software, is it possible to transfer data through wifi without knowing the ip from each other and without creating an hotspot? Something like we do on Windows (if 2 pcs are on same network, they can share information directly without internet access)
Starting with the basics, I would like to develop an application, where android phones on same network appears on a list , and then a user choose on of them and writes something - and if the other user have the same app running, appears that on his phone (and then he can reply of course - basically, a chat.
I know this make no practical sense, but believe makes all the sense for what I need to do (it's not a chat of course). If anyone knows anything, please help me - i found nothing.
Thanks in advance.

If you want to send data or messages from one phone to another using the network you will eventually need the IP address of the recipient phone. However, If you don't care about targeting specific phones you could always send UDP broadcast packets that each device on the network should receive.
If you don't want to manually specify an IP you'll need to create a discovery protocol that a phone uses to discover all the other phones on the network. You could do this buy scanning all available IP addresses and checking to see if they are a valid android phone. Or you could have each phone broadcast its presence on the network using a UDP broadcast packet sent to a predefined port.
Once you have discovered all the phones on the network its really up to you to decide how you want to send the data between phones and there are hundreds of examples of how to send data between devices/computers/processes using sockets.

sms receive on Port 0 of mobile

I am configuring my J2ME app to get an event from the push registry on receipt of an SMS.
Would I be able to access the SMS message, before it reaches the inbox?
I have read that messages sent to port0 of the mobile go directly to native inbox and we can't access it. Is there any way of diverting or even sniffing these messages so as to perform an operation on them from within the J2ME app.

According to this discussion, it is not possible to receive a SMS on port 0 using a MIDlet before it enters the inbox. And while I am not familiar with the
Wireless Messaging API, various other posts seems to indicate that you cannot access the inbox either (I might be wrong on this).
What I think you could do instead is to open a serial connection to the modem part of the phone and listen for an UR code (Unsolicited Response, "events") indicating
that a new SMS is arrived, read it and if it matches your criteria delete it (from the inbox, you still have your copy) using AT commands.
See the AT+CNMA command (New Message Acknowledgement) and similar in the standard (most mobile phone AT commands are by the way specified in 27.007).
For the following I have no idea if if even makes sense/is possible. I only mention it for completeness.
As for processing the SMS before it arrives in the inbox I think the
only option (without it having being sent to a specific port that you listen for) is
SIM application toolkit (which can do a hell of a lot of things), although that is way outside the scope of J2ME and highly obscure and highly un-trivial. Only follow this route if you are really, really desperate.