I'm going to realize a indoor positioning application using Cisco Meraki technology.
I've inserted the floor plan in the Meraki dashboard and activated the web server to manage the receive of the HTTP POST scanning API.
In the HTTP POST I obtained the latitude, longitude, x and y arrays and all of them have the same value for all connected devices despite devices are not in the exactly same position.
So my question is:
is it possible to obtain the device's location with one only Access Point (only one Meraki MR33) or I need more APs?
For mobile devices to be tracked properly, a minimum of three access points (with four or more preferred for better accuracy and precision) should be detecting and reporting the received signal strength (RSSI) of any client station, asset tag, or rogue device being tracked. It is preferred that this detected signal strength level be -75dBm or better.
Related
I'm implementing a bacnet library to read and write some object instances.
But I don't understand, why with a PC and with an application like Yabe if I ask to a common controller to read more than 300 objects, the segmentation is supported, instead with a mobile phone and on the same request to the same controller the segmentation is not supported.
Both the PC and the smartphone are in the same network on Wifi.
So what is the problem/difference?
It is nothing to take with a PC or a mobile phone. Any IP compatible devices mobile phone, desktop, laptop, Arduino chips will work with BACnet.
Your problem is segmentation. You will have to handle the segmented messages coming from the Controller.
Every BACnet controller vendor specifies the MaxApduLength (i.e max length of data to be transferred within one UDP packet). The standard APDU length is 1476 bytes. So a BACnet controller cannot send the data more than the length of APDU specified within it.
Requesting 300 objects from a controller results definitely in a large APDU than the controller's limit. In this case Controller will send you segmented messages each with sequence number. You will have to handle this all segmented messages and combine them in one message then only you will get exact response. This is same with Yabe and other BACnet clients.
I have also written BACnet libraries for our mobile applications in Java and Swift 4.0 and both can read any number of objects from controller with segmentation support added. I have tested these with controllers having more than 400 objects.
Segmentation is used for APDUs (responses) that are too large to fit in one frame on the datalink. If both devices support segmentation, then great. If one of the device does not support segmentation, and the APDU does not fit, then "Segmentation not supported" error is issued. (and you have to then retry a smaller request).
I have just started using Thingsboard and made some good progress in understanding how some of the basic stuff works ( mainly sending sensor data using mqtt ). But I have come to a complete halt at one point. Here is an explanation of the problem. Thingsboard version is 1.3.1
My setup:
4x RPi (Raspberry Pi) used as gateways to gather data from bluetooth
beacons
A set of bluetooth beacons
Here's what the system is supposed to do:
Send periodic data from the gateways ( RPi ) to inform thingsboard that the gateway is alive
The above part is working fine. I have set up the gateways to connect to thingsboard using access token, and post the data ( both the attributes and telemetry ). For sending attributes I use "v1/devices/me/attributes" and for telemetry data I use "v1/devices/me/telemetry", as mentioned in the documentation.
A typical string from the gateway indicating that it is alive is
{"gwA.macid": "00:00:00:00:00:00", "gwA.timestamp": "2018-02-16T19:20+01:00"}
The above part is working well. This is just for an indication that the gateway is well and able to communicate with the Thingsboard server. All the gateways connect to thingsboard using it's own respective access token and posts the above data.
Now the problem part ( or where I got halted )
The gateways gather the data about the nearby bluetooth beacons and post it too.
The data format in which the gateways posts the beacon data is
{"bcn000001.mac": "00:00:00:00:00:00", "bcn000001.timeepoch": 1518939044}
The gateway ensures that each beacon data will have the correct prefix. For example
{"bcn000001.mac": "50:80:25:AA:BB:CC", "bcn000001.timeepoch": 1518939044}
{"bcn000002.mac": "50:80:25:RR:AA:DD", "bcn000002.timeepoch": 1518939039}
{"bcn000003.mac": "50:80:25:GG:33:EE", "bcn000003.timeepoch": 1518939020}
But the data about the same sensor can also come from another gateway. How do I show it on a single widget irrespective of which gateway the data comes from. If I choose "entity list" then either it does not work, or shows up all the 4 RPi gateways on the widget. This is not what I want. I have attached an image. I am not sure if I am able to explain this well but pls do let me know if there is any other information that I can furnish. I am adding an image to point to some things that I just mentioned. I have even separated the data out by using a prefix ( as mentioned in one of the earlier SO posts ). I have spent close to couple of days on this. This was not supposed to be difficult. At least that's what I thought when I got started.
Note: As I explore, I just learnt (realized) one more thing. I think this part was a little confusing so I thought I should inform others. When one adds a device in Thingsboard, there is an option to specify if the device "Is a Gateway". What it is trying to tell(ask?) is that whether thingsboard gateway service is installed on that device. In my case I made the mistake(?) of thinking that a device that gathers data from sensors and posts it to the server is a gateway device. I guess I'll try to install thingsboard gateway service on the raspberry pi, then see how it goes. I'll post an update once I am done but in the meantime any useful comments or suggestions - please keep em coming.
I have seen others ask very similar question on SO. Something fundamental like this shouldn't be so difficult. No point in have a hundred pages of documentation without a clear explanation of most basic steps towards setting up an IoT backend/dashboard. All I wanted to do is to display the same sensor data ( say Sensor A ) coming from "any one of the devices", to show on the same widget. If I choose single entity, the widget won't update if the data comes from other device. If I choose entity list, and turn on "Resolve as multiple entities", then I end up with the widget showing all the devices
you are using wrong API. The API you are looking for is gateway API which allows to push telemetry and other messages on behalf of other devices. Please use this API https://thingsboard.io/docs/reference/gateway-mqtt-api/ on the Raspberry Pi gateways. You can also use our Gateway project and modify it for your needs.
We are currently working on an application on linux (a.o. RasPi running latest Debian Jessie) that connects to a BLE device (developed by us). This tool has evolved from cherry-picking files from the bluez (5.46) stack and adding an application layer on top. This all works quite nicely, except for the fact that connecting is incredibly slow. From the output of our tool, I understand that a truckload of messages need to be exchanged to communicate GATT services and characteristics, and each of those costs one connection interval of time. Since it is a low power device, we want the connection interval to be relatively high, and thus the high delay.
When connecting with Android BLE Scanner, I see (on the device side) that BLE Scanner manipulates the connection interval to a low value, gets all the requested data, and then sets the connection interval back to its original value. Note, btw, that neither BLE Scanner nor our Bluez-derived application take the preferred connection parameters into account.
Now I want to have our application do the same: set the connection interval to 8ms, get all info about characteristics and services, and set the connection interval back. In the Bluez stack I even find a nice function in the HCI layer for this: hci_le_conn_update.
But now the challenge: the rest of the application is built on top of the GATT functionality and even though the BLE specification defines a hierarchy between those two (with some layers in between), in code they seem absolutely independent of each other.
There are two parameters to the hci_le_conn_update function that are HCI specific: 'dd' (file descriptor to device) and 'handle' (some value that identifies the connection). The hcitool tells me that when I create a connection, the first handle is 64, so I tried with that value. For 'dd' I used hci_dev_open to get a file descriptor for the device. This worked. Sort of.
As I said before, the min/max values are not entirely taking into account. So when I set it to 6/10, I get 11 and when I set it to 6/50, I get 60. This is a bit too undeterministic for my taste, and I would prefer a function that directly changes the connection interval instead of giving a range that is mostly ignored anyway. Also the fact that I have to use a hardcoded magic number 64 gives me a bad itch. I can actually control the connection interval on the embedded device's side, but I want the control at the side of the client application.
The goal is to update the connection interval in a Bluez-GATT-based application. Within certain limits, I do not mind that much how I get there. Any suggestions?
In the official dbus API, there is no method to change connection parameters. (See https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt and https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/device-api.txt). The key is therefore to send the Connection Parameter Update Request from the peripheral side. You can of course experiment with sending a raw hci command but that is a bit "hacky" and has no guarantees to not mess up the BlueZ daemon.
If you would like to discuss the features of BlueZ such as an connection parameter update request api, you should do that on the BlueZ mailing list (http://www.bluez.org/contact/) rather than here.
this is my first question here and I realize this question might be open ended, but I'm looking for specific solutions, and any solution would be accepted.
I have GPS devices which send data packets to an IP on a port, both of which I can configure. I wish to use one of Google's, Amazon's or Microsoft's offering of cloud services. I am using python. Here is an implementation I found online :-
https://github.com/rdkls/gps-tracker-server
The data is coming as packets which are not over HTTP protocol. I have considered building a network listener over a socket on Google Compute Engine, but I'm not sure if it will be able to handle simultaneous requests from 1000 devices if such a situation ever arises. The Google Cloud IoT core offering seems to fit my need perfectly, but it is in private beta right now, which means I can't use it. I think I'll need a message queue service. But most of the offerings from these three companies requires messages over HTTP. Keep in mind that I can't change how the messages are sent from the GPS devices.
The messages sent are in this format -
https://drive.google.com/file/d/0B2EklrIn3KugS2NJYWZGWlVWeGdMbjM4WHQ2TUZmYWhIRmt3/view?usp=drive_web
Format:
data is sent in (byte sized) packets directly to the IP:Port over GPRS connections, one heartbeat packet every minute and GPS details every minute from each device. It also requires teh server to eply to the messagee for acknowledgement since it's not over TCP/IP.
So basically, which service and which architecture should I use keeping scalability, reliability and cost in mind?
I think for a 1000 devices, that would send such messages every minute, total would be 43M messages. I'm not sure but I'm looking for something that'll cost me about 1000$ that is 1$ per device per month.
Looking at various GATT-based profiles, it seems that services are always exposed in the GATT server rather than the GATT client. For instance, the Time Profile (TIP) has the server exposing the Current Time Service (CTS). So, if a phone is to update a heart rate monitor with the current time using TIP, the phone will be the server whereas the monitor will be the client. But, being a heart rate monitor, the Heart Rate Profile expects the monitor to be a GATT server.
So, for a monitor that takes the current time from a phone, should it be a GATT client or server? Should it be set as a client whilst time syncing with the phone and set as a server otherwise? Should a custom profile be implemented such that the CTS is exposed in the client instead?
Thanks
Generic Attribute Profile (GATT) defines how server and client communicate with
each other using Attribute Protocol for the purpose of transporting data. Client
and server roles are determined when a procedure is initiated and released when the procedure is ended. Hence, a device can act in both roles at the same time.
I would suggest you to read Bluetooth Spec. In Part G 2.2 it explains the roles and configurations.
Client—This is the device that initiates commands and requests towards the
server and can receive responses, indications and notifications sent by the
server.
Server—This is the device that accepts incoming commands and requests
from the client and sends responses, indications and notifications to a client.
Back to your question:
The Time profile enables the device to get the date, time, time zone,
and DST information and control the functions related the time.
In your case, the monitor will be the GATT client when it takes the time from a phone. However, it can be a server at the same time for another procedure (operation, request etc.) with the phone.
In short, client and server roles are not fixed to the devices. When your phone exposes the current time, it will be server. Similarly, when it gets the current time from the monitor, it will be client. no need to customize the profile. If you want your phone to get the current time from a device and expose it to another device, just implement the same profile for client and server roles to your phone.
EDIT:
According to TIP profile spec, to get the current time information, the GATT Read Characteristic Value sub-procedure shall be used with the handle of the Current Time Characteristic. Monitor as a client will read the Current Time Characteristic from the GATT Table of the server (in this case it is the phone). As soon as the monitor retrieves the value from phone, it can update its Current Time Characteristic Value, and expose it to its environment in three ways:
Notifying it to its subscribed clients (BLE notifications). If you do it in this way, you will customize the Bluetooth TIP profile since this procedure is not defined there (I had a quick look to the document and didn't see it).
Broadcasting it in the advertisement packet (Doesn't require BLE connection)
Another BLE device connects to the monitor and reads the Current Time Characteristic value. This is the recommended way if you want to use Bluetooth SIG defined TIP profile as a server.