Home
Always when we encounter new IoT platform, first thing we ask for is transparency, security, portability and DX (yes, the Developer Experience; a new buzzword ©THiNX 2017). So we have decided to go on our own, open-source, public and completely transparent way. Our test WiFi AP's are public and you're free to use them with credentials disclosed in the source code.
We're striving to write secure code while giving it off to public scrutiny, we expect your inputs and we run regular dependency checks in order not to get flu from someone else. All the code is verified on CI using SourceClear, Sonarqube and others.
You can join us, if you are solving similar problem.
- Create account at our example THiNX server
- Create new API Key and get your Owner ID from Settings > User Profile page.
- Check out platform library for your IoT device and insert API Key and Owner ID
- Register the device
- Observer, attach, rebuild, update, notify...
List of all your devices incl. last checkin time, firmware version, etc. You can perform device property updates as well as link, build and deploy firmwares. Devices can be transferred between accounts. Config updates can pushed in bulk.
The dashboard displays various information about the device, but most interesting would be probably the
status. As many devices are not able to send anything except for a couple bytes, you can write and attach Status Transformer JavaScript functions in your device detail. Those will for e.g. convert status 0xba8e3c662 from SigFox message to human-readable variant "Battery 3.42V" with optional#etag for error and#wtag for warning. This value is updated by libraries’setStatus(String)functions in form of a HTTPS request.
Those are access keys for you and your devices. You can create as many keys as you like, preferably one per device. Most of the activities on API will be based on those access keys. Future ACL hierarchy extension is expected. Per-build API Key rotation feature is coming soon.
Add your GIT repositories with App sources. In case the repositories are private, add a key in the RSA Keys section to access them securely.
Add your RSA keys for secure read-only access to your private git repositories.
Key-value based environment strings you define will be injected as variables to your source-code of the language you prefer. You can use this to inject SSID and PASSWORD of your WiFi (and even API Keys will be done like this soon) in case you don't want to store those in the GIT repository (e.g. your repo is public).
You can use your Owner ID (from Profile) and respective API Key to log into THiNX MQTT. You have rights limited to access your channels ownly.
Data from MQTT streams are currently not displayed on Dashboard, but intended to be processed outside THiNX. In THiNXLibs those functions are called publish(...), publishStatus() and publishStatusUnretained().
This example for ESP8266 shows how to redirect MQTT traffic from THiNX to your local broker and also includes tiny node.js ETL (extract-transform-load) script that scrapes humidity values from MQTT and forwards then to InfluxDB/Grafana instance for visualisation.
Browse in your your build logs, download artefacts or keep an eye on security with audit log.
Personal details. Nobody expects those to be true. Your account is activated based on e-mail and that's enough. You can use any name, any avatar, nobody cares and all the data are kept as secure as possible anyway, because that's how we do it.
However, it enables you to enter your phone number and get in touch with us directly as a developer. Additionally it provides Notification settings (we don't send any notifications at all, but seriously, we need a consent in case we'd actually need to do that).