run/kiri/run: Increasing the speed of Kiri

I keep improving Kiri to measure the efficiency of MAIA. Today I bring you a new short post with its latest enhancements and improvements. While in the previous post I focused on its autonomy, in this I will focus on its speed.

I am of the opinion that each project must have its identity. Therefore, before telling you about its improvements, I present you its logo:

It is not very good, but at least it is quite descriptive (IRI in a box) 🙂

When we talk about improving the speed of an application we can think of several things such as remove a bottleneck, parallelize the execution, reduce order of complexity or use a new library among others things. I am sorry to disappoint those who expect an ingenious solution … .

To put you in context, Kiri is an application that allows you to running a private IOTA testnet in a Low Cost Single Board Computer (LCSBC), something that can be very useful to carry out certain types of tests.

What is not necessary to running a private IOTA testnet in a LCSBC? Neither run the IXI hub nor load the addresses of previous epochs.

To what extent does the above affect the speed of Kiri? Well, I think an image here is worth more than a thousand words.

I must admit that the graphs do not indicate anything about the overall speed, but the reason is simple, it is complicated to measure accurately and it is logical to conclude that (usually), if you use less computational resources the overall speed will be higher. I think it is unnecessary to develop a convoluted metric to prove it, it is only necessary to use the new version of Kiri to realize that it works faster than the previous one (at least 25%).

Any other improvement? Some other more, although most of them are focused on fixing errors and improving the integration of IRI in Kura.

That’s all. In a few days I will bring you news from MAIA.

In case you want to donate some IOTAs to support my work, send them to my personal IOTA address:

KIFEHFFMQDPHLHGURUXDZGTJVDZMDLCFSVXXRNXKCIXJZSJNBWULBLQXYSNZNVGIJXVCITXREHUUKCHGDCSEBGYDEB (it is no longer my address, use my MAIA)

Or better yet, send them to my MAIA (we are making changes to the protocol and sometimes the node that we use is down, so for now it is better that we do not take risks :’) ): donation address.

Increasing the autonomy of Kiri

In the previous post, I introduced MAIA, a MAM-based protocol that allows generating something similar to a fixed IOTA address.

Today, I present a handful of improvements in Kiri, which have been made to measure the efficiency of MAIA.

If you do not know what is Kiri, I just tell you that it is an application for Kura that allows you to deploy private IOTA testnets in LCSBC (it has been successfully tested in Raspberry Pi 2B/3B and Up Squared).

You can get more information about Kiri on its presentation post and download it from its repository (it includes ready-to-use packages).

The main improvements, from least to most important, are:

Added patch to use unsigned snapshots

The configuration of gitignore excluded a patch that allows using unsigned snapshots in IRI . I am so sorry for anyone who had tried to deploy Kiri compiling it from the source code …

Integrated iota.lib.java – JOTA

Jota has been patched, so it can work on Kura and it has been integrated into Kiri. Now, it is possible to use code that is using IOTA’s API to work with our private IOTA testnet.

Self-coordinated node

A coordinator has been integrated into Kiri, so it is no longer necessary to use https://github.com/schierlm/private-iota-testnet for this. A Kiri private IOTA testnet is now autonomous.

The configuration of Kiri allows you to establish the interval for issuing new milestones by using the coordinator.

That’s all folks (more coming soon 😉 ).

In case you want to donate some IOTAs to support my work, send them to my personal IOTA address:

KIFEHFFMQDPHLHGURUXDZGTJVDZMDLCFSVXXRNXKCIXJZSJNBWULBLQXYSNZNVGIJXVCITXREHUUKCHGDCSEBGYDEB (it is no longer my address, use my MAIA)

Or better yet, send them to my MAIA (we are making changes to the protocol and sometimes the node that we use is down, so for now it is better that we do not take risks :’) ): donation address.

Winners of the Open IoT Challenge 4.0

We are very happy to announce that we have been selected as the runners-up of the Eclipse Open IoT Challenge 4.0. Yesterday we received the official notification and today we are even happier once we have assimilated the news.

As a result of this state of euphoria, we are celebrating our runner-up prize, with a complete redesign of the website 🙂

The challenge has been a very enriching experience for us, and an excellent opportunity to learn, experiment and validate our ideas. The employing of this wide range of technologies has been tremendously inspiring, allowing us to conceive new ideas that we will gradually post on the website.

As competitors, we would like to congratulate the rest of the winners Martín Álvarez (first place), and Domenico F. Bruscino (third place), as well as all the participants, who have been working very hard during last months.

Finally, we would like to thank the Eclipse IoT Working Group for making possible this experience.

Next year more and better. See you at the Open Challenge IoT 5.0 😉

Kiri: Private IOTA testnet in Kura

Before explaining what is Kiri, let me ask you some questions:

1. Do you want to do some tests using IOTA nodes?
2. Do you want a private IOTA testnet to have full control over the transactions?
3. Do you have low-performance devices like Low-Cost Single Board Computers?

If your answer is yes to more than one of these questions, Kiri may be of interest to you. Maybe you have a device with enough resources to run a full node, then you can use IRI. Perhaps you only need to carry out some tests, in this case, you can create a private IOTA testnet or use the PoWbox.

What is Kiri for? To create private IOTA testnets easily using LCSBCs (I think that a Raspberry PI 2 B is enough). Anyone who has deployed an IOTA node will know that the minimum requirements are higher than what you can have with a PI. If you have also tried to install it on an ARM device you will also know that deploying RocksDB is not a simple task.

If you only want to do some tests using IOTA and you want to have full control over the transactions, Kiri can be your ally. All you need is a device running Kura. As you use a private IOTA testnet, few computational resources are needed and a PI could be powerful enough for it.

You can download the code here. In the demo directory, there are deployable packages ready to be used (tested in PI2B, PI3B and Up Squared). The code is 80% third-party resources and 20% code to execute them in Kura.

You must consider that it is an experimental tool. On the negative side, surely its use denote several failures, but on the positive side, in the future, it will allow doing many more things ;). If you have a bug or an idea, create an issue in GitHub.

I hope you like Kiri. In case you want to donate some IOTAs to support my work, send them to my donation address.

Final report

I recently discovered this painting by Paul Gauguin and it fascinates me since that moment. The painting, seen from right to left, is an allegory of human life passing through birth, D’ou Venons Nous – Where do we come from?, the present, Que Sommes Nous – What are we?, and death, Où Allons Nous – Where are we going?.

In this post, we make a similar journey through our participation in the Eclipse Open IoT Challenge 4.0 with the project trusted indoor positioning system for nursing homes. First of all, we start with our proposal. Then, it is shown what we have achieved and what we have learned. Finally, the post concludes with our eyes on the future.

Before we start, we would like to issue a warning. This is our seventeenth post (listed at the end) and we are not going to paraphrase what we have already written in the sixteen previous posts. It would be a waste of time for us and unfair to anyone who has read the previous ones. Therefore, when we use recycled material, we will warn you about it, providing the link to the original source, just in case you want to go deeper.

Having that said, let’s start.

Executive Summary

• Where do we come from? Motivation and proposal

  • A system which provides you with a proof that you can use as an evidence of a fact.
  • Our proposal is focused on nursing homes.
    • Guaranteeing an appropriate care of the elderly in these centres.

• What we are. Results and lessons

  • How we compete
    • To gain experience, improve ourselves and try to win.
  • What we are
    • Computer engineers focused on research.
    • We have a bit knowledge about Eclipse IoT stack tools.
  • Approach
    • We focus on an interesting, useful and realizable idea.
    • We have always prioritized what we considered most necessary, to validate our PoC.
  • Technological Stack
    • Our proposal is built using Kura.
    • Besides Kura: MQTT, React, Java Servlets, Websockets, IOTA, Android….
  •  Community
    • We know very well the importance of disseminating the obtained results.
    • We have posted seventeen times, sometimes about the proposal, sometimes about technology and others about parts of the system.
  • Results
    • Jura: “It swears”; a set of Kura’s components to deploy trusted indoor positioning systems.
    • Mide: “It measures”; A repository in which we have generalized some of the experiments that we have carried out as analysis tools.
    • Mira: “It looks”; Android app focused on the relatives of nursing home’s residents and built using the Anonymous Trusted IPS of Jura.
  • Lessons learned
    • If we had not competed in the challenge trying to give the best of us, we would never have done anything of what we have done. Looking back we are proud of what we have achieved.
    • We think that this is a wonderful opportunity for many professional profiles. Students, recent graduates, entrepreneurs, curious, or like us, researchers looking to gain experience in the field.
    • We are so convinced of the advantages of blockchain technologies that we have a stack of blockchain’s books that we will study eagerly during the next weeks.

• Where we go. Future works

  • We have an overflow of ideas.
  • The results are good enough to propose more ambitious goals, but we do not know yet what will be our next step.

Where do we come from? Motivation and proposal

You do not really understand something unless you can explain it to your grandmother – unknown and wrongly attributed to Albert Einstein.

Perhaps, the closest concept to describe our initial idea is a notary system. It is not the best definition, but it is what we would say to our grandmas. A system which provides you with a proof that you can use as an evidence of a fact.

Could you think more than 5 situations in which the reading of a sensor would serve to prove something? We are pretty sure that you can think much more than 5 situations. In our case, there are dozens of situations which come to mind.

Often the events are used to prove something, but they lack any probative value to a third party since for this we must guarantee some properties in the events such as authentication, non-repudiation or integrity (anyone else thinking about keeping them in a blockchain?). However, it is not enough to store an event with those properties, but we should also guarantee that the event is real.

For us, guaranteeing the latter is much more complicated than the former, and now that the challenge comes to the end, we must say that the difficulty to find a solution which satisfied us, almost made us renounce. In the end, we found a solution that convinced us, so we should focus on win-win situations.

This led us to make a proposal focused on nursing homes.

We firmly believe that a system which allows guaranteeing an appropriate care of the elderly in these centres, is good for everyone:

• It is positive for our loved ones to have a guarantee that they will receive the best care by the staff of the nursing home.
• It is excellent for relatives, to be informed of any incident and to have mechanisms that enforce their rights.
• It is the best transparency policy for a nursing home.

We had several ideas about what kind of information to guarantee and finally, we decided to develop an Indoor Positioning System (IPS) using Bluetooth Low Energy beacons (BLE beacons or simply beacons) that would allow us to guarantee the location of people.

[16] When we speak of an IPS, the image of a plan with moving points, quickly comes to mind. This is not what we want. We want to use the locations in a way that allows us to say something similar to: X certifies that Y was in place Z at time T.

To do that, we believe that, currently, there is no better technology than blockchain. Storing the locations in a blockchain allows us guaranteeing that [9]:

1. The locations are stored in a distributed ledger and it is not possible to block their access.
2. A message cannot be repudiated.
3. It is not possible to modify or remove registered locations.
4. It is not possible to add past information that can be trusted. The timestamp of the location and the timestamp of the transaction will determine if the message should be trusted or not.

We do not want to cheat you, we would have liked to develop a visualization tool too. At the beginning of the challenge, we even started to develop a tool for it (among other things) [12]. A picture is worth a thousand words.

Why did we abandon the development of this tool? The main reason was that we had to prioritize and focus our efforts on the certification processes instead of the visualization.

To make it even clearer, we finished with the IPS in mid-February, and we had a full version of our proposal by the end of that month. We could have finished this visualization tool. Instead, we preferred to use the available time on what we considered most necessary, validating our Proof of Concept (PoC), the scalability [10,13,14] and the usability [12,15,16].

This is the general idea of our proposal. We have tried to explain it in a simple way, but since it never rains to everyone’s taste, for some of you it might have been too long and for others too short. For the latter, we refer you to these posts [2,13] in which we try to explain in more detail what is the approach that we propose.

What we are. Results and lessons

How we compete

Since the challenge began, we have had an idea in mind, we are competing. Our goal is to gain experience, but if we are competing, we will try to win, and because of that, we have tried to do our best 😉

And we want to highlight the above because it is probably one of the greatest personal lessons we have learned during the challenge. If we had not competed in the challenge trying to give the best of us, we would never have done anything of what we have done. Looking back we are proud of what we have achieved. We do not want to encourage anyone to become a psychopath obsessed with victory, but to set goals and give the best of themselves to achieve them. It’s great to compete, even against oneself.

We summarize below those things which we believe that are important to analyze in order to know how we have competed: i) what we are, ii) our approach, iii) our technological stack and iv) our relationship with the community. Due to its importance, we will show the results in a separate section.

What we are

We present ourselves. So you can get an idea of our background, we quote from [4]:

Our team consists of three computer engineers; all of us from different fields, with great interest and curiosity about IoT but inexperienced in it. Because we work with some Eclipse tools we knew about the challenge, which we thought was a great opportunity to gain experience and (why not?) get some cool gadgets for free!

We knew some Eclipse IoT stack tools, but we had worked only a little with them (Kura, Mosquitto, Paho and maybe some other). For this reason, and based on the limited knowledge we had, we started looking for an (i) interesting, (ii) useful and (iii) realizable idea.

Although we are computer engineers, so far we have dedicated more time to research than to development. Francisco J. Quesada is a PhD student, Francisco Moya is also a PhD student (he also works as Android developer), and Fco Javier Estrella is a PhD in Computer Sciences since 2015 (he recently has focused on software development).

Now, that the end of the challenge is near, we can say that this is the first time that we have participated in this kind of projects, and it has been a fantastic and enriching experience for us. We think that this is a wonderful opportunity for many professional profiles. Students, recent graduates, entrepreneurs, curious, or like us, researchers looking to gain experience in the field.

Approach

Despite being computer engineers, we have dedicated much more time on research than on development. This has conditioned us both when making the proposal and when developing it. In what way?

We believe that our strengths lie in proposing solutions and verifying their viability.  Because of that [4] we focus on an (i) interesting, (ii) useful and (iii) realizable idea and [9] we did not want to propose anything that seemed like a good idea, but in practice would not be feasible. As it is indicated in the proposal, we have always prioritized what we considered most necessary, to validate our PoC.

We do not believe that our approach is better than others. We think that it is the best one for our profiles. As we said before, in our opinion, the challenge is a great chance because it allows the participation of professionals of various types of profiles.

Technological Stack

In the past years we had developed some Eclipse RCP applications, so we knew OSGi. For us [5] OSGi is ideal for managing IoT gateways and we believe that it is a wise movement that Kura has been developed using it. It is difficult to explain OSGi in a simple way and it may be even more difficult to explain its benefits (http://tuhrig.de/when-modularity-comes-down-to-osgi/). For us, Kura is one of the best examples to prove the suitability of OSGi in certain scenarios.

Our proposal is built using Kura, being its versatility vital for our proposal. [4] Something that makes us feel especially happy is that everything works in Kura. We know that for some parts of the system there are better alternatives, but deploying everything in the same tool will help in its deployment, management and maintenance.

Obviously, we use other things besides Kura:

1. MQTT. Kura provides an MQTT broker, Artemis, and a MQTT client, Paho. Is not it great? 🙂
2. React. We have developed two websites [7,11] as Kura components that use this library.
3. Java servlets and WebSockets. We use them in Kura to provide the backend of the websites and the Android app. Moreover, we had to patch some Jetty packages in order to be able to use WebSockets in Kura.
4. The Apache Commons Mathematics Library. We had integrated this library in Kura to execute least squares methods.
5. The Legion of the Bouncy Castle Libraries. These libraries were also integrated into Kura. In this case, they are used to sign an encrypt locations.
6. IOTA. A blockless distributed ledger. We have integrated in Kura a patched version of JOTA that allows us to communicate with an IOTA node to make and read transactions.
7. Android.

We would like to highlight that [12] in our proposal we do not use the official version of Kura, but a fork in which we solved an iBeacon’s bug in the Raspberry 2. Notice that once we certainly figure out if this is a failure of Kura or an incompatibility with our system, we will carry out a pull-request.

By the way, we are pleased to tell you that we have already made a small contribution to Kura and that makes us extremely happy 🙂

Community

Due to our professional background, we know very well the importance of disseminating the obtained results. We know that this can be extremely boring, but the effort is worthy.

In our case, we started this blog when we applied for the challenge [1]. Since then, we have posted seventeen times. Sometimes with articles in which we explain the proposal [2,4,9], sometimes with more technical articles explaining the parts of our solution in detail  [6,7,8,11,14,16] and other times with more general articles [1,3,5,10,12,13,15].

In addition to the dissemination of the results in the blog, we have also created the twitter account @trustiot in which we have been tweeting our results.

Thanks to this, and to the members of Eclipse IoT who have helped us to spread our work, we have obtained quite acceptable levels of dissemination:

• Our newly created blog has received 3165 visits.
• Our newly created twitter account has 33 followers. Ok, only with us there are already three followers…, but you will not take away our happiness :). For a newly created account that specifies that it is for a challenge, we think this number of followers reflects that there are people interested in what we propose.
• We were surprised to find that we received some visits from Reddit (#1, #2, #3, #4).
• We were even more surprised to realize that in the #ict channel of Discord community of IOTA some users were analyzing if what we published in one of our last posts [14] could be useful for this project. After analyzing the ICT project we believe that what we do is not valid for that project, but who knows, maybe something of we do might help them to see something clearer (perhaps communicating IOTA nodes using MQTT to create a cluster is not a bad idea).

At the beginning of this section, it is said that all this work is boring, and we have not changed our opinion, but in view of the results, we think that all this effort was well spent.

We want to end the section indicating that everything we have developed is open source. There are three repositories at your disposal:

• JURA (https://github.com/trustingiot/jura) [6,7,8,11,14]: Trusted Indoor Positioning System for Kura.
• MIDE (https://github.com/trustingiot/mide) [10,12,13,15]: A set of experiments conducted for the challenge.
• MIRA (https://github.com/trustingiot/mira) [16]: An Android app for nursing homes.

Results

Our most tangible results can be seen just before the title of this section, three software repositories. If someone is curious about the origin of the names, clarify that we (almost) always use the third person singular of a Spanish verb (jura=it swears, mide=it measures, mira=it looks, …).

Do you want to know what you can find in each repository? We tell you.

Jura

[11] Jura is not a monolithic tool, it is a Kura’s components based tool:

• Jura: “It swears”; a set of Kura’s components to deploy trusted indoor positioning systems.
  • Faro [6]: “Lighthouse”; a multimodal beacon.
  • Graba [7]: “It records”; a recording system.
  • Ubica [8]: “It locates”; an indoor positioning system.
  • Firma [11]: “It signs”; a signer, encrypter and validator of locations.
  • IOTA’s worker [14]: A node to make IOTA’s transactions in a distributed way.

What does the above mean? It means that in each particular device it is only deployed what is necessary.

We said earlier that we have tried to do our best and we think that the parts of Jura are an example of this. We have not only implemented the basic functionality, but everything we think is useful (different beacons protocols, different positioning algorithms, different systems for the certification of locations, …).

We invite you to review the different post to discover all the functionality. Some of them even include gifs that show what the system can do [7,11].

Mide

Usually, when we develop a PoC we spend more time performing tests than building the final solution. Our case has not been an exception.

When we made the proposal we decided to use some tools that we had never used before. Due to this, we spent the first months of the challenge doing all kinds of tests and it was not until the end of January when we were able to connect all the pieces [4].

What is Mide? A repository in which we have generalized some of the experiments that we have carried out as analysis tools.

Mira

Our PoC has two parts. The main one is Jura, the other part is Mira.

Mira is an Android app focused on the relatives of nursing home’s residents and built using the Anonymous Trusted IPS of Jura.

Mira allows access to the records of resident’s locations from an Android phone. Since it uses the [11] Anonymous Trusted IPS of Jura it can guarantee that all locations are encrypted independently and that it is not possible (or at least it is not easy) to apply heuristic methods to associate transactions with a user.

Mira not only allows to check the resident’s locations by decrypting the transactions and validating its digital signature but also allows to share them with other Mira’s users using MQTT. As each location is sent to a unique address and is encrypted using a unique key, sharing an event does not compromise the resident’s security and anonymity.

Does the nursing home had some careless attitude with your relative and you have an event that proves it? Share it with who you need (your brother, your lawyer, your insurance company, …) and enforce your rights.

Do you want to know more about Mira? In its post, we show you what it does with a use case full of videos [16].

Where we go. Future works

We are very happy with our experience in the challenge as well as with the results obtained. It is said that when you are happy, it shows.

At this moment, we might say that we have something like an overflow of ideas 🙂

A proof of concept is only a proof, but we believe that the results are good enough to propose more ambitious goals. We do not know yet what will be our next step. Perhaps we will propose a more general solution or maybe we will contact nursing homes in the area to obtain their feedback, or even carry out an experimental trial. If you found interesting our proposal, we encourage you to add our blog to your bookmarks. We have the feeling that in the future we will post much more interesting things 😉

Regarding IOTA, in our opinion, it is the future. Well, maybe not IOTA, but it will be very similar. When the challenge began we had a general notion of blockchain technologies. At this moment, we are so convinced of the advantages of those technologies, but we are not experts yet. For this reason,  during the next months, we are going to eagerly study a stack of blockchain’s books with the aim of understanding these technologies in depth.

Throughout the challenge, we have realized that there is room for a huge number of solutions in this area. Some, as in the case of our proposal, will use these technologies whereas others will improve the way in which we interact with them. We believe that this is the biggest cake to be shared in the coming years and that all of us can take our part. As before, we are still unclear about the next step to take in this area. However, we are calmed because we know that while we read the books, we will have time to think about it 🙂

As a curiosity about the latter, in the last days, we have started to be interested in IOTA nodes, especially thinking about permanodes. Who knows? Maybe in a few weeks you will find a new IOTA public node powered by Up Squared 🙂

Posts

1. Kick-off (Nov 13, 2107).
2. Our Approach. Part I. Indoor Positioning System (Dec 3, 2017).
3. In the top 12 proposals!!! (Jan 25, 2018).
4. Preliminary results (Jan 28, 2018).
5. Building Deployment Packages for Kura (Feb 2, 2018).
6. Faro: A Multimodal BLE Beacon (Feb 7, 2018).
7. Graba: A BLE Beacons Recording System (Feb 12, 2018).
8. Ubica: An Indoor Positioning System (Feb 21, 2018).
9. Our Approach. Part II. Trusted IPS (Mar 1, 2018).
10. The Race to the Tangle (Mar 1, 2018).
11. Firma: In IOTA We Trust (Mar 2, 2018).
12. Testing: One, two, three (Mar 4, 2018).
13. The Race to the Tangle II. Teamwork (Mar 7, 2018).
14. Parallelizing IOTA transactions in Kura (Mar 10, 2018).
15. Testing: Four, five, six (Mar 14, 2018).
16. Mira: To Enforce your Rights (Mar 15, 2018).
17. Final report (Mar 15, 2018).

Mira: To Enforce your Rights

We are very happy to write this post, which is the last ‘thematic’ one that we are going to publish for the Eclipse Open IoT Challenge 4.0.

In this entry, we are going to talk about Mira, our Android app. It is focused on nursing homes and it is the culmination of our proposal. “Mirar” is the Spanish word of the verb “to look“; the translation of mira in English is “it looks“. You can download the code here.

It is necessary to understand our proposal as a whole in order to understand what Mira is. In a nutshell, we are participating in the challenge with the proposal trusted indoor positioning system for nursing homes:

1. An IPS is a system to position elements indoors. When we speak of an IPS, the image of a plane with moving points quickly comes to our minds. This is not what we want. We want to use the locations in a way that allows us to say something similar to: X certifies that Y was in place Z at time T.
2. To do the above, we believe that, currently, there is no better technology than distributed ledgers. Storing locations in a distributed ledger allow us guaranteeing that they can be trusted.
3. Why do we focus on nursing homes? We believe that there are big problems to address in the generalization of the use of Trusted IPS. The only cases in which it can be applied reasonably today are those in which there are win-win situations. For us, there is a clear win-win situation in nursing homes, and this is the main reason that leads us to focus on these scenarios. It is a case in which our technological proposal is useful. If you want to go deeper into our approach, we refer you to this post.

Our Proof of Concept (PoC) has two parts. The main one is Jura, a Trusted IPS developed as Kura components which is able to store locations in a distributed ledger like IOTA. Jura implements two trusted IPS systems, (i) a public system in which locations are signed and transferred to a specific address and (ii) an anonymous system in which each location is signed, encrypted with a unique key and transferred to a unique address.

The other part of the PoC is Mira, our Android app focused on the relatives of nursing home’s residents and it is built using the Anonymous Trusted IPS of Jura.

Use Case

Let us tell you a story.

It is not a funny story, but we think it is illustrative.

Let’s suppose a nursing home in which Jura has been deployed and in which all residents carry a personal and non-transferable beacon.

For each beacon, there is a unique identifier called DIW (Device Identification Word). The DIW can only be obtained by authorized staff. Notice that it is necessary to know the administration password and have access to Firma Website in order to get it. If both requirements are met and we also know the MAC of the beacon we can obtain the beacon’s DIW.

Stephen is a new resident of the nursing home. When he goes to check-in for the first time, nurse Mel assigns him a beacon. Mel provides the identifier and DIW of the beacon to Stephen and to his son Tod.

Mel explains Stephen and Tod that this is a new service that offers the nursing home to residents and relatives. A service that allows them keeping track of Stephen’s locations at all times.

This causes father and son to move from a state of curiosity to one of concern. They think: ‘anyone can monitor Stephen‘.

In order to calm them, Mel explains that the system does not work as they think. Each time the nursing home register a location of Stephen, it saves it in a different place and using a different password. Only those who know the identifier of Stephen and his DIW can know the places where the locations have been saved and the passwords that have been used.

Once the above is clarified, they ask Mel about the benefits of the service. Mel explains that:

1. It is an optional service. The nursing home has a fixed schedule for catering services, family visits, doctor visits, recreational activities and late arrivals. The staff try to take care of all residents in the best way, but like all humans, they make mistakes. Younger residents are reluctant to use the service, but those with mobility problems, dementia or Alzheimer’s disease feel safer using the service. They believe that the staff take better care of them.
2. If Stephen uses the service, all his locations will be digitally signed by the nursing home and it will not be able to remove or modify them. Stephen or Tod may use the locations to prove any negligence in the nursing home and the nursing home cannot deny the authenticity of the locations.
3. Currently, the service is in its early stages. In the future, it will offer a wide range of functionalities such as early detections of diseases, optimisation of emergency evacuations, personalized care or guaranteed attention among others.

Although Stephen and Tod are not fully convinced to use the service since they have never used anything like that, they decide to use it.

Mel explains to them that they will be able to use the service from their phones and provides them with a link to download Mira.

When they open Mira, they find two options, (i) relatives and (ii) shared locations.

Mel explains to them that they must select ‘relatives’ in order to enter the identifier as well as the DIW of Stephen’s device (beacon). Since the identifier is hard to remember, Mira allows them entering a name for the device.

# Click on ‘add relative’ and that’s it.

# Once added, to see his/her location records, simply click on his/her name.

Mel explains them that:

• The icon with the label ‘Verified‘ is the guarantee which shows that it is signed by the nursing home.
• The icon on the right allows them to share the location.

Before explaining how to share the locations, he asks them to click the label ‘Verified‘ on a particular location. They do it and Mira shows them a website.

Mel explains them that this is the place where the location of Stephen is stored, and lets them know that there are hundreds of copies in computers around the world.

He tells them to go back to Mira to explains them how to share a location.

#  The locations are shared from Mira to Mira, and to do this you only have to click on the icon on the right and enter the phone number of the other person. – Mel tells them. – But do not worry about SMS costs, we use our own communication service, something called MQTT. When you share a location with another person, you are telling them where it is stored and its password, so it is no longer anonymous. Anyway, as each location is stored in a different place and with a different password you are only revealing the location you want to reveal, the rest remain anonymous to others. Therefore, if you need to share a location with a relative, a social assistant, a lawyer or any other person, you can rest assured that they will only be able to see what you want to share.

Stephen and Tod carry out a small test between them and see how everything works as Mel has told them.

And this is Mira. We hope you find it useful 🙂

We know that there are still many problems to solve before these tools can be used with full guarantees, but we believe that in a few years they will be omnipresent. We focus on nursing homes, but the main idea can be applied directly in other contexts (kindergartens, hospitals, animal residences, …) and with some modifications in many more (check-in/check-out, supply chain management, emergency response, pay per use, …).

Testing: Four, five, six

We commented on Testing: One, two, three, that we would like to develop a software tool which would allow anyone to fine-tune his/her installation to a position as accurately as possible. This tool is ready and available in mide repository.

It is a Java command-line tool developed using Ubica code. To use it, it is only necessary to consider that:

• The name of each dataset indicates in which coordinates it has been created (x1000y2000.txt = {“X”:1000,”Y”:2000}).
• The configuration is defined in the config.properties file.

When we wrote the first Testing post we captured five datasets placing a beacon in different coordinates (the datasets are also available in the repository):

{"X":1800,"Y":1000}
{"X":3400,"Y":1000}
{"X":3400,"Y":1900}
{"X":5300,"Y":1900}
{"X":6300,"Y":1900}

We have tested the tool with those datasets and the results have been better than we expected. To put you in context, in the first Testing post we indicated the following:

At the beginning of the challenge, we carried out several tests until we achieved a maximum error of two meters when positioning. This is enough for us because it allows knowing the rough position of each beacon. In a nursing home, we could know the room in which each resident is located. If it is a medium-size room, we could also know the area in which the resident is located.

After trying different configurations we have obtained the best results with the following values:

dataset=dataset
distance.algorithm=Accuracy
least.squares.algorithm=NonLinear
retention.time=60
publication.rate=1000
delay=5
scanning.window=10000
attenuation=0.5
cutoff.rate=0.9

With this configuration the results have been as follows:

{"X":1800,"Y":1000}: 1,137 m.
{"X":3400,"Y":1000}: 0,736 m.
{"X":3400,"Y":1900}: 0,570 m.
{"X":5300,"Y":1900}: 1,084 m.
{"X":6300,"Y":1900}: 1,277 m.
Mean error: 0,961 m.

An error of less than one meter. Far beyond our expectations 🙂

Parallelizing IOTA transactions in Kura

This post is shorter than the others, but no less interesting :). We could even say that for us it may be the most important one so far.

What’s the fuss about? From now on, Jura is scalable in terms of locations stored in the tangle. How? Using IOTA’s workers.

For us, our proposal is nothing more than a proof of concept. Aspects such as health or privacy should not be treated lightly and we are not experts in any of those areas. Therefore, we focus on checking whether what we want to do is possible to validate our idea.

Something critical is the storage of locations in the tangle, because although it is ‘free’, it is not as fast as we need it. In our last post, we published experiments on how we try to make IOTA transactions more quickly. We are proud of having implemented this funcionality in Jura.

From now on, Jura has a new feature, iot.challenge.jura.worker.iota.feature. With this, we can create a cluster of IOTA’s workers that are coordinated using MQTT. We want to highlight that it is not the same to send as many transactions as possible to the tangle with random data than with data which follow a given pattern that must be maintained. Our approach, almost identical to the one used in the collaborative approach, is as follows:

• Each cluster’s node uses the worker.iota service.
• The service adds itself to the list of IOTA’s workers of the cluster, publishing a message in topic /jura/cluster/iota/worker/<worker-id>.
• The IotaService assigns jobs to each worker by publishing them in the topic /jura/cluster/iota/todo/<worker-id>.
• The workers publish the results of the jobs in the topic /jura/cluster/iota/done/<work-id>.

At this stage, the question is whether is it necessary to store 10, 100 or 1000 locations per minute? Now we can. For example, as a result of two simulations using the FIRMA address, we have obtained:

• Using an Up Squared: 11 transactions. 40.9 seconds each transaction.
• Using our LCSBC’s cluster: 35 transactions. 12.86 seconds each transaction.

Obviously, the next question would be, how many computers are necessary to make X transactions? We do not know, but now it is possible to check it 😉

The Race to the Tangle II. Teamwork

This post is a continuation of the race to the tangle in which we discuss how we try to increase the number of transactions we make to the tangle with the hardware we have.

For those who are not sure about what we are doing, we would like to remark that we are developing an IPS and storing locations in the IOTA. So we are not developing an IPS on the IOTA.

Why do we store locations in the tangle? Because our goal is to use the locations as evidence of facts, and we believe that having them stored and signed in the tangle is ideal for our purpose. You can review the last part of this post to see an example of what we do with the locations which are stored in the tangle (notice that the images of the web are gifs).

For us, the locations that we store in the tangle are like a snapshot of the current state of the installation. Obviously, the more locations we store, the more representative the snapshot will be. Therefore, the underlying issue to be addressed is to increase the number of locations stored in the tangle with the hardware we have. We do not talk about using cloud solutions or better hardware, but to optimize the performance of the hardware that we are using.

After these considerations, it is time to move on to the interesting part.

First of all, the code. Keep in mind that it is a code to carry out tests (not for production). Before using it, you should analyse it in order to understand how it works.

We have the following Low-Cost Single Board Computers (LCSBC):

• 1 x Up Squared.
• 1 x Raspberry Pi 2 Model B + Micro SD 32 Class 10.
• 3 x Raspberry Pi 3 Model B + Micro SD 8 Class 4.

We use Eclipse Kura in all the LCSBC so they can easily communicate with each other by MQTT. Using the MQTT connection we can create a cluster of LCSBCs (hereinafter nodes). Our approach is as follows:

• Each node uses the worker service.
• The service adds itself to the list of workers of the cluster, publishing a message in topic /mide/iota/workers/<worker-id>.
• The node which starts an execution uses the manager service. Speaking properly, the execution uses the service (there is no public manager service).
• The POW is not parallelized, but the transactions. Why? Because: i) it is a complex task, and ii) without a fast connection between nodes it does not make sense (this would even slow down the system).
• The manager assigns jobs to each worker by publishing them in the topic /mide/iota/todo/<worker-id>.
• The workers publish the results of the jobs in the topic /mide/iota/done/<work-id>.

Analysing our previous results we realised that the deviation in the average transaction time per LCSBC is high. Therefore, we follow two approaches:

• Collaborative: Each transaction is assigned to a free worker. It should be most efficient.
• Competitive: The workers compete with each other to be the fastest in each transaction (like blockchain mining). It should be more stable.

We have conducted two experiments in which we have sent 300 transactions to the following addresses:

• https://thetangle.org/address/99999999999999999999999999999999999999999999999999999999999999COMPETITIVEAPPROACH
• https://thetangle.org/address/999999999999999999999999999999999999999999999999999999999999COLLABORATIVEAPPROACH

Unfortunately, there is a bug in the IOTA library which provokes that sometimes an exception occurs in the POW. In our implementation, we discard these transactions, and therefore we do not consider them in the results. It is important to note that the error occurs during the POW, so the results would be better without this bug.

The bug also affects the execution in a different way depending on the configured mode. While in the competitive mode the nodes work until the end of the execution because these nodes are called for each particular work, in the collaborative mode this does not happen. Our solution to analyse the results has been keeping only the valid data of the competitive mode and all the data until the first bug in the collaborative mode. In the collaborative mode we have done several tests until we achieved a case in the bug appear late (after many transactions).

The results are:

Competitive

• Transactions: 232.
• Time: 4708 seconds.
• Time per transaction: 20.29 seconds.
• Transactions per hour: 177.4
• Variance: 237.51
• Standard deviation: 15.41
• Maximum transaction time: 86 seconds.

Collaborative

• Transactions: 203.
• Time: 3107 seconds.
• Time per transaction: 15.6 seconds.
• Transactions per hour: 230.75.
• Variance: 9984.75.
• Standard deviation: 99.92.
• Maximum transaction time: 679 seconds.

Here you can find the comparison with the previous ones:

Testing: One, two, three

This weekend we have met up in order to perform some experiments, and taking advantage of this meeting we are going to show you how to install Jura.

First of all, we want to highlight the purpose of our meeting. The main goal is to discuss a tool that we want to develop in order to improve the experience with Jura. If you are not interested in it you can skip it and go to the next section.

Our proposal focuses on indoor positioning using BLE beacons. If you do not know how this is done you can review a previous post or even better this Degree’s Thesis. Usually, each beacon is located at a given point and they are scanned by devices that are in motion. As we explain here, we use the opposite scheme in order to be able to trust the scannings.

A common problem in indoor positioning using beacons is the noise (interferences in the environment, collisions in waves, surfaces with different reflection indexes, …). You can review the previous Degree’s Thesis for more information about that.

At the beginning of the challenge, we carried out several tests until we achieved a maximum error of two meters when positioning. This is enough for us because it allows knowing the rough position of each beacon. In a nursing home we could know the room in which each resident is located. If it is a medium-size room, we could also know the area in which area the resident is located.

How can we say that we are positioning with an error smaller than two meters? Because we did the following:

1. We recorded datasets by placing a beacon at a given point. This evolved into Graba’s recording service.
2. The scannings of the datasets were sent to the positioning service. This evolved into Graba’s player service.
3. We computed the positioning error as the arithmetic means of the Euclidean distance between the real position and the one calculated by the service.

We think that it would be great to generalize this functionality because doing that anyone can test different scanners’ locations in order to fine-tune his/her installation and obtain better results. Today we have recorded some datasets using Graba. We will use them in order to test the tool that we want to develop.

Deployment of Kura

We have used the following hardware:

• 3 x Raspberry Pi 3 Model B.
• 1 x Raspberry Pi 2 Model B.
• 1 x Up Squared.
• 1 x Kindle fire.

The installation was configured as follows:

• Four scanners of iBeacons (the four Rasps using Faro).
• One Up Squared as a MQTT broker and Graba’s service.
• One Kindle fire as an iBeacon.

First of all, it was necessary to install Kura (‘Raspbian (Model 2 or 3, No Net)’ for UP Squared), but not the official version, a fork in which we solved an iBeacon’s bug in the Raspberry 2. Notice that once we certainly figure out that this is a failure of Kura or an incompatibility with our system we will carry out a pull-request.

By the way, we are pleased to tell you that we have already made a small contribution to Kura and that makes us extremely happy :).

After installing Kura we activated the MQTT broker in the Up Squared and later we connected all MQTT clients (Up Squared included) to the broker. This took a few minutes.

Deployment of Jura

First of all, we installed Faro in the four Raspberries, configuring them as iBeacon’s scanners.

From now on, Faro will publish any iBeacon that it detects, using MQTT.

As we explained in Faro’s post, in order to avoid the saturation of the MQTT broker, it sends messages periodically but including a chunk of all the detections obtained in the payload’s body. By doing this it is possible to get all transactions in return for a small delay, which is totally fine for our purpose.

At this point, the iBeacon’s scanners are ready. Let’s prepare Graba. In this case, we only install it in the Up Squared. As we indicated in Graba’s post, we have developed a React’s website in order to manage Graba’s services, so the creation of the iBeacon’s locations datasets is a very simple task.

Prior to showing an example of the process, it is necessary to indicate that the dataset only records the detections. Before creating the dataset it is necessary to manually measure the points where the scanners and the beacons are located. We know that it is a boring task, but there is no other option… Why do you think we are all together today? 🙂

On the positive side, creating a dataset using Graba’s web is as simple as this:

Deployment of Ubica

Although it is not necessary to use Ubica to create the datasets, we would like to show you how a Jura’s installation is defined using Ubica in order to give you a big picture of Jura.

As we said before, we have met in one of our homes, so be welcomed.

We made a plan of the room measuring tape in hand (for those worried about the details, it’s just for tests!) .

Next step, let’s install and configure Ubica in Up Squared.

Once we have installed it, we must define the installation. For this, it is necessary to indicate the points of the plan (in millimetres) and the locations of the scanners (also in millimetres). You can use ‘hcitool dev’ to get the bluetooth address of each device if you do not know it.

Where do we place the scanners? For our tests, there were located close to the power sockets. Ideally, they would be equally distributed around the room, close to the ceiling, away from possible sources of noise, …

This is our installation.

This is our plan (scanners’ locations are approximate).

And this is our configuration for Ubica’s installation service (scanners’ locations are accurate).

 {
  "id":"home",
  "points":[
   {"X":1200,"Y":0},
   {"X":8400,"Y":0},
   {"X":8400,"Y":3700},
   {"X":3600,"Y":3700},
   {"X":3600,"Y":5700},
   {"X":0,"Y":5700},
   {"X":0,"Y":1200},
   {"X":1200,"Y":0}
  ],
  "scanners":[
   {"addr":"B8:27:EB:C8:E8:ED","position":{"X":5700,"Y":400}},
   {"addr":"B8:27:EB:1F:82:3C","position":{"X":6400,"Y":2800}},
   {"addr":"B8:27:EB:23:CD:49","position":{"X":3500,"Y":3200}},
   {"addr":"5C:F3:70:66:23:97","position":{"X":1200,"Y":2000}}
  ]
 }

After that, the installation is ready (it’s simple, right?) and we finish this post. We will publish the results of the tests soon.

To conclude, we would like to tell you that, if you want to use Jura but this seems hard and unfriendly, you might be happy knowing the following. We have some experience developing Eclipse RCP and RAP applications and when the challenge began we started developing a RAP application to define plans, see positions, etc.

A picture is worth a thousand words.

Unfortunately, we have had to prioritise other parts, so we do not know if we will finish it someday or not. Who knows? Maybe for the Open IoT Challenge 5.0 😉