Cloud as a Story - Vunvulea Radu

In the last post , I talked about how I connected the yard gates to the IoT Home solution that I started to develop. Unfortunately, I was not able yet to connect the Paradox alarm system to the solution. It’s not clear for me how to connect the relay as a keyswitch zone, but I hope next weeks to receive some help and resolve the near future. Why? Because the WiFi connection is not stable, there are times when I lose the connection to the devices. This can be annoying, especially because I do not have yet a tracking mechanism that can provide me information related to the current device state. I decided to enhance my solution with tracking capabilities. Until now I didn’t add any logs to the solution because I wanted to see exactly where and what kind of data I should collect. Easily you can add logs capabilities to the system and end up with a bunch of logs that you don't need it. What? In day to day use I observed that I need the following information: When was the last

In our system we are using Azure Table to store a list of commands that needs to be send our clients and persisted until the client is available. Because the number of clients is high (more than 100.000), it would be very expensive to store the list of commands in other resources like Redis Cache or SQL Azure. From the performance perspective, Azure Table are amazing, very fast even at high throughput when you store a lot of data inside them. At the first version we done a simple mapping, where we had only one Azure Table for all our clients. For each client, we had a dedicated partition in the table. This works great because Azure Table is partitioned (scale) based on the partition. There is only a small problem with this approach and is related to maintenance and support. If a support engineering needs to look at the commands of a specific user it will be hard for him to navigate and access the data. The second approach is to create a different Azure Table for each client