A Modern RFID App Using NativeScript


Mehfuz has finished a first pass at an RFID scanning app for the Invengo XC-1003 (see earlier progress reports: part I and part II) leveraging NativeScript.  You can see the code for the app at GitHub.

The app uses 4 plugins: SQLite, GeoLocation, Maps, and RFID.

The interaction goes through 3 screens.  In this short screencast the app:

  • Displays the location of the device, acquired via the GeoLocation Plugin
  • Presenting the lcoation as LAT/LONG and a Map, using the Maps Plugin
  • Scans an RFID Tag, using the RFID Plugin
  • Provides the history of previous reads, including their location, stored locally using the SQLite Plugin, and
  • Provides details of a read in the history, with a Map of the location where the read happened

This App architecture relies in the ability of NativeScript to extract meta-data from a library so it can be used at the JavaScript layer.  In the App, Mehfuz created a thin layer on top of that, a Plugin, to simplify accessing the (RFID) sensor.  As we see more industrial devices built on Android, this benefit of NativeScript will enable quickly creating powerful and pretty applications.

For more information on NativeScript, check NativeScript.org.  If you have an iOS or Android device, you may want to install the Samples App and play with it.

Hello Invengo XC-1003!

Mehfuz just published an initial NativeScript Plugin to call into the RFID libraries in the Invengo XC-1003 (see Part I for details of the device).  Mehfuz also published a simple NativeScript App that uses the Plugin to read a tag and display it.


The plugin is written in JavaScript/TypeScript. The code (see invengo.android.ts) is platform and library specific but it is plain TypeScript calling into the RFID API via the meta-data automatically extracted by NativeScript from the .aar file.  The plugin builds on that “raw” interface and provides a nice abstraction to be used by applications.

The structure of the demo application using the Plugin is like any other NativeScript App: some Javascript (or more properlyTypeScript in this case), the CSS for the visual elements, and some Layouts (created manually or through a tool) for the screens.

In this particular case the app is not intended to be cross-platform but in general the platform-specific features are pushed down to the plugin and the app itself can be cross-platform.  All while using TypeScript/JavaScript and CSS.

Mehfuz is working on a nicer version of the app; stay tuned.

Addendumhere is a short video with the RFID plugin and a SQLite plugin.

Addendum 2 – A more capable solution,  using also the GeoLocation plugin and the Google Maps plugin, is now available.

Linux Inside … ThingMagic Sargas


Our ThingMagic Sargas just arrived.  This is a small (87mm x 80 mm x ) fixed RFID reader that packs a nice punch.  It has 2 high performance UHF RFID antenna ports capable of reading 750 tags a second at distances over 9 meters and an ethernet port, but it also has a BLE, USB, 4 GPIOs, micro-SD, and HDMI.  Inside there is a 1GHz ARM Cortex 8 running Linux (Debian) where you can run your own code.

We will use the Sargas as a second reader so we can manage more RFID Antennas covering a larger space. Initially we will connect the Sargas to a Raspberry Pi 3 in the same arrangement we used previously  with the ThingMagic M6.  In that configuration the pi 3 runs the AMTech Gateway and it communicates with the reader using LLRP over ethernet.

The next step will be to move the gateway inside the Sargas, so we no longer need the pi 3.  This should be straight-forward; Debian running Node.js.

After that we want to run applications directly in the Sargas using the HDMI to connect an external monitor.  We have not yet decided on what to try out first.   The application could just report on the setup and simple statistics, or can be an actual application.  For example, a Sargas can be combined with a couple of short-range antennas and a large monitor, to provide a smart display for clothing that has RFID tags.

Ideally, we would like to write these applications using NativeScript, similar to how we want to use NativeScript to write RFID applications for the Invengo XC-1003, but more on that later…

Come for NativeScript, Angular and CouchBase – Stay for a Pokemon

This Thursday (Jul 28, ’16), we are hosting a MeetUp at 6pm at our location in downtown Palo Alto (Google Maps – MeetUp info).  Mehfuz and Nic will show how to create native cross-platform Apps using NativeScript and CouchBase.

CouchBase is an open-source, distributed (shared-nothing architecture) multi-model NoSQL document-oriented database; NativeScript is an open source platform for building cross-platform Native mobile applications using JavaScript and CSS.  NativeScript leverages a high performance bridge between any native platform API and JavaScript which can be used to create Plugins that extend the platform.  Mehfuz and Nic will show how to use the CouchBase plugin in an app where information created by one user in one smartphone can automatically be shared with another user in another smartphone.

Mehfuz will also show how to use his Estimote plugin; combined with the CouchBase plugin, the iBeacon data read by one phone is automatically synchronized to the other.

We are sprinkling a slight IOT overlay on the MeetUp.  We took some of the RFID configuration we used in a Conference App earlier this year and we now have them connected to a Raspberry Pi 3.  UPS-willing, the plan is to add some RFID tags to the badges for the MeetUp and show you how a modern Data Speed Layer (like AMTech.Solutions) can be used to track an asset (you) on a space.

Following the Pokemon Go mania, I’ve ordered some Pokemon figures as prizes for the attendees. Raichu arrived yesterday, others to follow (update – All Pokemons are here; check the Flickr Album).  See you on Thursday.


Capstone ’16 Project at CSUMB – Quantifying the BIT Building

I mentored a Capstone project at Cal State University Monterey Bay (CSUMB) this last Winter.   The project involved quantifying the BIT building using a combination of video cameras running Computer Vision software (Placemeter), iBeacons (Estimote) and GPS, all connected using the IOT Platform from AMTech, and a solutions stack from Progress: Modulus, NativeScript and Telerik Platform.


My post at Progress Blogs has more details.

AMTech – An Overview

This is an overview of the IOT Platform, expanding on The Elevator Pitch and The 2 minute Overview.  Additional notes are available here.

The Big Picture: Two AMTech Examples

AMTech is usually part of a larger software solution; two recent examples are the BIT Building at CSUMB and the ProgressNEXT Conference App.

Quantify the BIT Building at CSUMB

The goal of the Quantify the BIT building project is to track activity in the most recent  building in the CSUMB campus.  The project uses sensor data from 3 sources: iBeacons and GPS, mediated through  a smartphone app, provide identity/location data, while IP Cameras provide anonymous traffic data thanks to a Computer Vision startup Placemeter.  Below is the arch diagram for the project:


The general structure of the system follows the Lambda Architecture: the sensor data is collected into an “Immutable data store” for analytics and reporting and is also fed into a “Speed Layer” for real-time processing.  In the CSUMB case, MongoDB was used for the immutable data store (Hadoop is a common solution), and AMTech for the speed layer.  Real-time content and rules are programmed into the AMTech platform and are then exposed to the Application Layer through CRUD operations on Things and through Notifications.

The functionality of the solution is implemented through these layers.  For example, the Mobile App recognizes the iBeacons and will post relevant events to the AMTech system. The event triggers a number of actions on Things and can generate a notification that is received and interpreted by the Server-side logic.  Together the system tracks occupancy and can present room occupancy data when requested by the end user, or it can push a notification if the room occupancy gets beyond a threshold.

ProgressNEXT Conference App

Another project where we used AMTech was the ProgressNEXT conference app where we used RFID tags to track participants at the venue in Las Vegas.  In this case we used another piece of the platform, the M2MBridge.  This project was the first AMTech-based project and we did not use include an immutable store, though it would have been useful.  The general architecture is as follows:


The M2MBridge is an Open Source Node.js application with a Plugin system that can be used to manage and control a variety of sensors and actuators.  The M2MBridge was critical for this application: during the ProgressNEXT conference, the M2MBridge was interacting with 3 RFID readers that were themselves controlling 8 RFID Antennas.  The bridge talked to the readers using LLRP and then pushed the results to the platform using REST and WebSockets.  The bridge is very flexible and performant; it could easily have handled many more antennas.  AMTech supports different ways of managing M2MBridge instances so it is very easy to replicate installations and to manage many sensors.

The complete ProgressNEXT solution includes a mobile app and sever-side content and logic.  As in the case of the CSUMB application, the interaction between AMTech and the Application Layer is through REST and WebSocket calls.


AMTech is a multi-tenant platform that is both a PAAS and a SAAS.  As a PAAS, a creator user defines types for Things and Observations, and deployable Activities that act on them.  The Activities define the Rules that act on things and observations, the Notifications they can generate, and Actors, corresponding to roles and associated permission.

As a SAAS, a follower user can import a set of Activities, and configure them, e.g. by creating specific Things.  Access to the SAAS Services (CRUD Operations on Things and Notifications via WebSockets) are controlled by the Actors associated with each follower user as defined by the SAAS administrator.

Things, Observations and Rules

Things and Observations have properties; some common to all types, others specific to each type.  Common properties include the @type and @id (both URIs and both immutable), a creationTime, the position (in an extended WKT format) and a proximityArea.  Associated with the Things and Observations there is also a user/tenant creator which is used to determine whether the entity is visible for a request, based on the Role (Actor) of the requestor.

For example, 3 of the types defined in the CSUMB application are csumb_Building, csumb_Person and iBeacon, while corresponding Thing instances are csumb:BIT and csumb:LITwombat@gmail.com and alcides_sorto@mumble.com, and csumb:BIT:beacon1 and csumb:LIT:beacon4.   All 3 types have a location – in the case of a csumb_Building a Polygon of GPS coordinates, while the other two are a single coordinate – but while the location of a Building is fixed, and that of a Beacon varies very infrequently, that of a Person changes frequently and may not even be defined.  For example, a person that has been detected through a GPS geolocation will have a specific location, but one detected via an iBeacon will only be known through its proximity to that iBeacon.

BeaconDetected is an example of an Observation.  When a smartphone gets close to an iBeacon, it detects a BLE message that eventually triggers a beaconDetected.  This observation has a property that identifies the iBeacon detected and another that identifies the csumb_Person of the smartphone user

Observations can trigger Rules, and execute Actions.  One of rules in the CSUMB application uses the iBeacon ID in the observation to get the iBeacon Object and from there it extracts its geolocation.  Another rule then uses this location to update the location of the csumb_Person object associated with the Person ID in the Observation.  The updated location can further trigger new rules and actions, including updating an occupancy count on a TrackedSpace enclosing the old (decrement count) and the new (increment count) locations.

Here is a graphical description of one rule: the incoming observation triggers a rule that generates two new observations: FromLocation and ToLocation.


A Gateway, a Sensor Network and a Rules System

From another perspective, the AMTech platform has a Gateway, the M2MBridge, and two Cloud-side components, a Sensor Network and a Rules System.  All three interact through Observations sent through Topics (same terminology as with MQTT topics).


The M2MBridge is an Open Source Node.js application with a Plugin system that can run in a variety of platforms, including the new Raspberry Pi 3.  The cloud side of the Bridge is a Thing, and so are the Plugins.  These Thing objects can generate Observations and will accept Actions.  For example, at ProgressNEXT, the plugins generated RFID reads.


Rules, Observers and Reasoners

Rules in AMTech are called Reasoners.  A Reasoner is defined through an Observer that operates on one or more Topics (think MQTT Topics) supplying events (called Observations) to generate a collection of entities (Thing and / or Observations) on which a sequence of Actions will operate.  Entities are connected through a standards-based Domain Application Protocol.  See Observers and Reasoners for details.

The AMTech DAP

The Entities (Observations and Things) in AMTech are exported using a Domain Application Protocol based on internet standards: REST and WebSockets for transport, JSON for the data, and JSON-LD for the relationships among entities.  See The AMTech DAP for details.

The Implementation – Cassandra, Titan, Kafka and Storm

Underlying the AMTech platform lies several clusters of services.  The things and observations as well as the relationships are kept on an Apache Cassandra cluster, using Titan as the GraphDB.  The Activities run on a Apache Storm cluster, and all these pieces are kept together via Apache Kafka queues.  The result is highly scalable and performant.

Mapping the concepts to the architecture, Entities (Things, Observations, Notifications) are kept on Cassandra, while the Activities are converted into code that is deployed to Storm.  Some Activities are meta-data driven and don’t need a full Deploy, just a Publish.

In addition, the M2MBridge provides a flexible, manageable and configurable gateway to sensors. The gateway is a node.js application and can run on devices like macOS and Raspberry Pi 3.

Additional Services in AMTech

AMtech includes a number of services.  Most notable is support for location and proximity.

Location is provided through OpenStreetMaps, support for WKT, and inclusion of efficient algorithms to operate on locations (e.g. whether a location is contained within another).

Similarly, AMT provides efficient support for operations like extracting all objects that are within a given Proximity area.

AMTech also provides services for Mail, Billing, User management, etc.  More in follow-up posts.