Traditional update of my teaching support on IoT. This year I’ve addressed my speak to larger and different audiences. As a consequence I publish a totally renewed slide-deck with 203 slides. I’ve improved the IoT business model description, use-cases and technology area. I also detailed the platform side of the IoT solutions.
Feel free to reuse this content for your own conference and speak. I’m available for conference, talk … let me know.
The full PDF is available on the following link.
Ceph is a distributed storage system use in Cloud environment. Recently I’ve been facing an I/O congestion during night period.
This I/O saturation is impacting the application performance on OpenStack even if the system was really resilient to this activity level.
In this post I’ll explain why I had a such situation on the CEPH infrastructure and what are the settings to modify this I/O level.
Continue reading
Raspberry Pi is a good solution for creating low-cost, powerful embedded devices when you have no need of self powered solution.
I had to create a such device recently to make a programming machine for my IoT devices. I was looking for a compact solution, powered with PoE, industrial grade, able to run a Java program and host a custom HAT with my home-made chip programmer.
Here you see a picture of the first prototype of this product with the different components visible: The green board is a Rapsberry Pi compute module CM3+ with 16GB eMMc flash drive. The blue motherboard is a Waveshare PoE board for CM3+. The Black board is my custom HAT hosting the programming solution based on a STM32.
In this post, I’ll detail a bit these different components and the way they are configured to illustrate how to easily make a such system alive.
Continue reading
Helium is a crowdsourced-crypto-blockchain-Iot network working with LoRaWan. With all these trendy name, for sure they had the key elements to raise a large amount of money. That’s great for the development of this technology.
I’ve decided to write about this IoT network after an interesting talk given at the Zurich IoT meetup today (thank you CoVID-19 for making us the opportunity to reach such event, today online, bad things can get positive sometime).
Helium is a crowdsourced network. It means, like for TheThingsNetwork or Amazon Sidewalk, the infrastructure, at least the gateways part (antennas) are provided by anybody, basically you and me. That way the network deployment costs are really limited and the network have no boundaries.
Compared to TTN, Helium network is “crypto-blockchained” basically, the gateway owner are mining different challenges like registering some network change, proving the location of a gateway, cryptocurrency transactions… For this work, for maintaining the network architecture and relaying the messages, the gateway’s owner are earning HNT (Helium Network Tokens) ($2.24 each today).
Compared to TTN where you make it running for free, just because you are convinced about the sharing economy, Helium base its business model on a promise of getting some money back from your investment the gateways (+energy, communications…).
Helium is an IoT network, a LPWAN for being more precise. It relies on LoRaWan standard protocol & gateways. You need to add an Helium miner software on a backend system to make it running.
So they are looking to Uber-ize the telecom domain, at least this is what they are expecting.
Continue readingShort tips: when a drive has been formatted for Linux (like a SDCard for a RPI) and you want to clean it ans reuse it as a normal (Fat32) drive, you can’t do it from Diskutil graphical tool.
Continue reading
In a previous post I’ve been presented an idea for creating a kind of satellite solution for watching over pandemic progress over the world using low cost connected thermometers. You can get the details of this idea in my blog post “What IoT can propose against Pandemic“. Basically the proposal is to add an ultra low cost IoT communication feature into a thermometer and report the information when an over heat has been detected. That way we could be able to determine the level of pandemic and its geographical progression over time. So I won’t detail all the business model and financing proposal, you will find all of this in my previous post.
The second step is now to make a prototype of a such device to show how too make it possible. For making this I’ve selected the thermometer you see on the picture above and decided to hack it and connect it to Sigfox network. This thermometer comes from Amazon and cost 14€ but is really like all low cost thermometer we can find.
Continue reading
Ten month ago, I was starting investigating the Ultra Low Cost Iot thanks to Sigfox given access to the experimentation they made in this area. The Ultra Low Cost IoT is defined by manufactured devices under or near the cost of $1.
Such level of price are enabling scalable deployment of devices and mass data capture, more than it has ever been able to made. And basically, it is not a question of device cost, it is a question of scalable use-cases where the higher device cost where a business model killer.
This is basically reducing the price of devices by a factor of 5x to 10x. No miracle, this is also reducing the device capabilities and concerns different use-cases than the one previously designed. In another word, Low Cost IoT is not classical IoT for a lower price, it’s a new IoT area where we find new use-cases, new business model and more generally is source of innovation.
Continue readingWhen you want to transfer some UDP protocol from a remote server not directly accessible from your local host you can use a combination of SSH and socat to make this communication possible.
The application case is, as an exemple, a SNMP communication with a server in a DMZ to get metrics in a local area dashboard. Like in this exemple.
You have an intermediate host where SSH is accessible you can use as a gateway.
1- on the local host (on the left side), create a SSH tunnel with a TCP port forwarding (here 10000).
ssh -L 10000:localhost:10000 **gateway_host_ip**2- on the gateway host, route the traffic received from the port we have previously associated to the UDP target host:port
socat tcp4-listen:10000,reuseaddr,fork UDP:**target_host_ip**:**udp_port**3 – on the local host, route the traffic received from the given UDP port to the previously associated TCP port for tunnelling
socat -T15 udp4-recvfrom:**udp_port**,reuseaddr,fork tcp:localhost:10000That’s it.