The Sigfox Micro basestation has been announced during the last Sigfox Connect event in Berlin. The base-station allow to extend the Sigfox public network, at low price, for your private location.
This post is detailing my experience with the micro base-station and the field test I’ve made on an industrial site.
Continue reading
The usual attack on Sigfox network is related to the “security”. Behind this large concept, for real, the only point is related to the use of clear payload over the air. As a consequence some are extending this to the possible replay after 2048 frames so regarding a standard use of Sigfox is will be about 6 month later…
That said, for real, all of this is just ignorance from these pseudo “security” experts and developer laziness. Don’t beat me for saying that, I’m part of the lazy developer, the only difference is I’m not complaining and I’m aware the solution is in my own hands.
Because, for real, the payload encryption exists as documented in the post I’ve published on May 2017 and detailed on the Feb 2017 technical security paper published by Sigfox or like in this document.
So saying the Sigfox is not proposing payload encryption is wrong and this option is also fixing any 6 months later message replay. It’s like saying WiFi is not secured because you can create an open-network.
So now, let’s see why encryption is not the default option, why a network encryption standard is not the best option and then see how to stop to be a lazy developer and make encryption working.
Continue reading
STM32 solution for using Sigfox is actually one of the best offer on the market has the solution is powerful, low consumption and allows global coverage with the use of the last Sigfox library versions including Monarq, Bubble… Different module providers are actually designing solutions based on this platform.
In this post we are going to see how to configure the STM32 platform, starting from a STM32L053 devkit plus a S2LP extension. Using a eclipse/gcc environment. The environment installation is described in this post about installing Eclipse for STM32.
This is a Frequent question I received from many hackers or companies: How can I get a Sigfox subscription for my IoT device?
We need to start saying a Sigfox subscription is a right to have its device data to be proceeded for a year. In the LPWA technology there is no SIM cards or any physical things attached to the subscription. You buy a device from a semiconductor company, when this device is compatible with Sigfox you have an ID attached to this device. This ID is uniq and used to identify the device on the Sigfox network. So once you have a subscription, you attach this subscription to this device ID then you will be able to access your device data from the Sigfox backend.
That’s clarified we can address the question of this post: what are the way to access a subscription?
Since I’m using Sigfox backend there are a lot of operations I’m regularly manually doing. Thanks to the Sigfox API, it is possible to automate these manual operations to gain in productivity and save time.
The most consuming operation were for me to manage the device type because each of them have multiple callback and every callback uses many parameters. The callback replication is for me a recurrent operation when adding a new contract, when creating a new version of application, when instancing for dev, prod… It’s also a complex operation when you have to ask a third party ( like a client ) to configure a device-type for connecting to your service. As a consequence these operations are the first one I’ve automated thanks to the Sigfox Api.
I’ve decided to publish this usefull code to let you saves time on these operation with a new set of API accessible on IngeniousThings Sigfox Api portal and available on GitHub as OpenSource.
In this set of API (actually 3, will grow) you will find operation to export/import a full deviceType configuration and to duplicate a DeviceType.
Have fun !
Since a long time I’m trying to understand how the Sigfox right (ACL) works and stop affecting all the rights to my API access every time I’m creating a new one. More than that, when I’m working with clients or other LPWAn passionates I do not like requesting full access to the Sigfox backend to help them or integrate them in my backend.
So, it was a nice opportunity to tale a look to the ACL and document them with an overall overview instead of the detailed information you can get from the User Creation screen. (You may note that this documentation can’t be accessed from the API access creation screen but the groups are the same as for users).
As a backend developer, the Sigfox API is not a really good experience. This for multiple reasons and it is a good example on how a really good product can get a developer push-back just because of the interaction layer.
I can’t change the API itself (and its not y role) but as I was bored to use POSTMAN tool and the Sigfox backend documentation (who already used it will understand) I decided to spend some hours this week to rewrite most of the API endpoint into a clean open-api format into a Spring application to get benefit of the SpringFox swagger front.
This project is not fully terminated but already in place with the most used API endpoint. The next will arrive soon. Read mode to get access.
Following the previous post where we saw how to transmit data on Sigfox with an Arduino MKRFox1200, in the second part we will learn how to consume these data in a backend site. To make this simple we are going to implement a solution using Adafruit.io service. This service allows to create graphics from data received from an API. We will configure Sigfox backend to push device data to this API.