A Windows 10 app that will act as display / control interface for industrial control systems. The app syncs with the cloud, so you can monitor what's happening remotely. It is meant for developers/makers who are building or prototyping industrial control systems based on MCU/Arduino or PLCs and want to give them a touch-screen interface like this: The result is that "Normal people" can interact with your system, which means makers and hackers can get their industrial prototypes and custom-built systems into sellable state 3 times faster.

• Multi-protocol IoT gateway will capture data from MQTT, BLE, serial and sync it to the cloud
• Dashboard will show the data and controls on a touch-schreen device
• Offline-first brings "IoT cloud" to you and runs on your local network, which means low latency and reliability regardless of your internet connection. It will record the data while offline and sync later.
• Idiot-proof It's one package that you download from the store, so you can't screw it up. You don't need to know linux commands or SSH, It requires no special skills beyong setting up a normal windows computer and running an app.

Grab an Arduino, and write your sensor / control software like you usually would, make it collect readings and control motors / pumps / whaver. Take a look at our guide for making Arduino's work realiably. Your goal is to connect your Arduinos to the local application and the applciation will take care of syncing to the cloud, You will have somethign like this: Next, head over to our integrationGuide and choose the mode of communication that suits you. Take your time to read the considerations we give to the way you should design the system for best results. It should take you no more than a day to make your device talk to the app. The app will detect your device and display all the readings immediately.

For Industrial and semi-industrial settings, the app is meant to be run in Assigned Access mode. When the applciaiton is run in this manner, user cannot quit the applicaiton unless they have administrator password. If the application crashes, it will be restarted. To make sure the applicaiton is running at all times (and collecting data), set the computer to LogOn automatically, and to restart after power failure. We did this on a touch-screen device and as a result you get a really nice control-panel type device.

• The server API is secured with TLS and JWT (pertty standard stuff)
• The LAN is somewhat secure (AES keys Individually provisioned for each device)
• Some areas of the app can be protected with a pin to stop accidental and foolish stuff
• Whoever has admin access to the PC is god
• Whoever can reprogram your hardware / arduino is god

The app is meant to harvest data from different sources, the more the marrier. Currently only LAN is implemented, but we are working on more of them:

• LAN Networking ✓
• USB HID ⧗
• BLE ⧗
• Serial-JSON ⧗
• Ethernet-enabled PLCs ⧗
• Yoctopuse Kit ⧗
• KNX protocol ⧗

Check our data model here

The application runs an embedded MQTT server, GnatMQ, on local port 1883 It is meant to be used in conjunction with an arduino or simular device that's sending MQTT messages over the network. It expects to recieve readings on the topic "readings".

It will also signal presence of the broken on the local network by broadcasting UDP packets on port 44000 The packets contain the work 'sekret" in unicode (yes, I know it's stupid). The idea is for any network device that requires a display to detect this mesage and connect to the app. If the app detects that there is another broker on the network, broadcasting UDP messages, it will notify the user of the conflict. If the "Local Device Management" functionality is disabled, UDP broadcasting and MQTT server are shut down.

• We are considering AllJoin and other LAN networking standards.
• We are considering Implementing network Fail-over
• We are planning to implement AES encryption

Enable the application to collect data frin BLE sensors. We have not yet created a complete plan around how we want to implement BLE, but currently we belive that the best way to implement BLE sensors is through the use of broadcasts. However, doing so introduces a problem - several applciaitons will recieve the BLE broadcast simultaneously

In our current plans, serial port is a tricky one and we are debating wether we should include it. The chief problem with serial ports is that:

• Serial ports include no identifying information. One day 'COM1' is an arduino, the next day it's a printer.
• Opening a serial port to an arduino causes it to restart.
• When one opens a serial port, you do not know if you are catching a data frame from the start or in the middle of a transmission. In our current thinking, serial port functionality only makes sense if you have an embedded board, such as raspberi pi, and have an MCU /Arduino permanently connected to the hardware serial port, as opposed to one emulated over USB. However Windows 10 is not the best OS when it comes to support of single-board computers. So we find ourselves in a bit of a dialemma, and consider the plan here to need some refinement.

The application aims to collect data form Arduino / MCU devices connected through USB-HID. This repository includes a PDF that describes HID descriptors used for common sensors and other stuffs. Work on this functionality has not yet begun. We will aim to provide examples with Arduino Due and Leonardo

We suppport use of the app on the following

• Windows 10 Pro on a generic computer
• Latte Panda a board with embedded Arduino Leonardo Controller. An RTC must be added for any serious work
• UP Mini PC which can make sense if you add an Arduino Hat
• Windows 10 IoT Core on a Raspberri Pi (Testing only)
• Windows 10 IoT Core on Dragonboard 410c (has no RTC, so is only of limited use).
• One day we will have a .Net core deployment with Avalonia as UI, so you'll be bale ot deploy this on any linux machine. But that is faaar down the road.

To test the app and server components, use the virtual device option in setting. However, activating this option in more than one instance of the applicaiton at the same time will result in weired sync issues, as they will be producing data for the same device, and the server won;t know which data to choose. .

We do not accept dealing with problems that will arise from running this app in the background while the user is torrenting porn or installing yet another virus. If you are not prepared to dedicate at least one of those cheap set-top boxes, then this isn't for you.

Headless linux-boxes are cheaper, but there is always something wrong with them - they run out of disk space, your forgot the IP address, someone stepped on them, etc. Whatever the case - average dude at the factory can't see what's happening, and can't fix a problem by clicking buttons.

The app will never contain the actual control loop, i.e. it will never respond to readings from a sensor to change setting on one of the actuators. The reason for this is simple - first the app should not be a safety-critical component of hte system, it's crash and restart should have no effect. second is that your system has failure modes known only to you. For isntance, we've seen systems where a disconnected PH probe will report a reading of 14, and activating pumps based on this information would cause disaster. Only you as developer of the hardware can know of these details and should manage them.

The server is currently written on ASP.net 4.6 and is due for replacement with ASP.net core. The REST API is due to be replaced with a Websocket-based system

Uses Azure API APP in-built twitter authentication. The Server grabs a token from twitter, and then creates it's own token. The token is avaliable in app in Settings tab under Twitter Authentication, click the button called "CopyAuthToken".

You need to pass this token when making an API request using the header X-ZUMO-AUTH

DASHBOARD: https://waffle.io/quickbird-uk/QuickbirdUWP

Websocket Endpoint: {serveruri}/Websocket

StorePage: https://www.microsoft.com/en-us/store/apps/quickbird/9nblggh6cclt

API Docs: https://greenhouseapi.azurewebsites.net/swagger/ui/index

Arduino Code: Check Examples Folder

• Syncfusion.SfChart
• Newtonsoft Json.net
• SQLLite (to be replaced by Dbreeze)
• GnatMQ (modified)
• EntityFrameworkCore

Alerts + core server complete.

Port to .Net core

• Replace twitter
  • Use Identity
  • Require phone text confirmation
  • Open signup
  • Organizational linking
• Fat Sync API
  • All dependant data should be downloaded in a single request (mult-table download).
• Billing ?
• Alerts
• Control

Maintenance:

• Public Release on store.
• Bug fixes
• Stable App
• Welcome page
• Documentation
• Make the system testable and usable

• Removed all non working features to make it clean.

• API breaking update to sync code
• Sensor histories now use UploadedAt instead of UpdatedAt

• Keep the app open source
• We may or may not keep the server component open source