Whenever there is a communication there are at least a sender and a receiver involved. The simplest form is a peer-to-peer communication with just one of each. But as soon as you start building a network you move to several senders and one receiver, or even several senders and several receivers if you need to cover a larger zone.
Most networks use a simple star topology with only two types of devices: gateways and devices. A gateway (or router) manages the connections from multiple devices. The gateway is then responsible to forward the messages to a backend that will handle them and eventually send them to the user’s application. This is commonly named “uplink” (from the device to the cloud). But there is also the possibility of a “downlink”, that is: from the cloud to the device.
In most LPWA solutions, the gateway will just do that, forward messages back and forth. This is also commonly known as a “bridge”, because it “bridges” between two different technologies (a wireless network and an IP network, for instance).
Gateways tend to be quite expensive even if they are only doing that forwarding task. This is because they have to be able to handle many different end nodes at a time, including downlinks sometimes. This also involves supporting multiple different radio channels and being able to decode them in parallel with specific hardware or software defined radio solutions.
But if you plan to do a PoC or deploy a small network with, tens of devices, then a simple single channel gateway will probably do the job at a fraction of the price. You can do that using an AllWize board.
Master mode
The Wize modules we use in the AllWize K2 (RC1701HP-WIZE) can be set into “master” mode to listen to incoming packets in a certain channel and data rate. The module can even handle specific per-device encryption keys but we can also transparently forward the message to the main MCU, like in a simple RF-link.
The AllWize Library will then parse the message into an allwize_message_t struct:
From your user code, you can check if there is any message pending using available() and retrieve it using the read() method. The library only holds the latest message, so that’s
something you will have to do frequently, in your main loop.
Serial bridge
The simplest way to process the incoming packets is to connect the AllWize K2 to a computer and send the data via serial to it. You can do that with any AllWize board (K1 or K2). This approach requires two steps:
Sending the data to the computer via serial
Parsing and forwarding the data in your computer
When I say “computer” I mean anything with a OS and, probably, connection to your local network (and maybe the Internet). A Raspberry Pi (or similar SoC computers) will work great doing this.
With this approach the “gateway” is actually split into two different devices: the AllWize board with the Wize radio module and the Raspberry Pi that does the serial to IP bridging.
You can find the code for the AllWize K1 using an Arduino board in the wize2serial example of the AllWize library repository.
MQTT handler
The IP part in the diagram above is not specified. It could be a POST request (push), or maybe an API (pull), or it can be an MQTT publication (pubsub). MQTT stands for Message Queuing Telemetry Transport and it’s a lightweight protocol designed specifically to transmit sensor data using unstable networks. It is widely adopted in the DIY domotics world and a de facto standard.
Using the wize2serial example above, you can now write a simple python script that would parse the serial lines and forward them to a MQTT broker:
As you can see, each line is parsed looking for some common parameters and some additional ones which are field values. MQTT topic is defined after the CI parameters which is used as a node identifier. The topic template is defined as “team/<ci>/field_<id>” and it will send as many messages as additional fields in the parsed line.
This approach will allow you to create a Wize to MQTT bridge for a small network in an easy way.
The AllWize G1
The serial to MQTT approach above is doable but there is a slightly better solution where you remove the requirement for a secondary machine to parse and process the messages. The trick is to use a WiFi enabled host for the AllWize K1 instead of a regular Arduino board. The perfect candidate here is an ESP8266-based board like the Wemos D1.
That’s why we decided to offer an AllWize G1 pack for a stand-alone single-channel gateway
based on Wize, using an AllWize K1 and a Wemos D1 host board.
Wize to MQTT bridge
Coding a Wize to MQTT bridge like the one we have done before but using an AllWize G1 is a lot simpler. You have the full example available in the AllWize Library repository under the wize2mqtt example folder. But let me just show you the core method retrieving the data from the Wize radio and sending the data to the MQTT broker:
As you can see, everything we did on the python script before is done now inside the MCU, removing the Raspberry Pi for the equation. Of course, you will still need an MQTT broker like you did before, but it could also be in the cloud.
Now, with just an AllWize G1 and any number of AllWize K1 or AllWize K2 nodes, you can have your own network reporting to a local or online MQTT broker in no time. You can then spend time on subscribing to the MQTT topics where the data is being posted to analyze or graph the data or rise notifications.