Event based on demand IOT measurements

In my last article I wrote about a gRPC microservice event service (without a message broker) based on a design principle used in kubernetes between the control plane and nodes (link)

I have developed a couple of IOT solutions and wanted to check if I could fire off 5 simultaneous events using these microservices, in turn they then dispatch to 5 IOT based services for "on demand measurements", this gives me control over the measurements, I can set the sample size and the interval between each sample.

So here is the diagram overview.

The flow is simple, I create a restful POST call to the api microservice, this then uses the HTTPPath gRPC protocol, alerts the 5 subscribed services (this is the basis of the eventbus). The services then do a lookup on the gRPC server (this simulates the node watch event in kubernetes) and each obtain the workload needed to perform the IOT measurements.

For the IOT interface I have used 5 onion omega 2 devices, they run a linux kernel, have a fully fledged wifi module, 12 gpio pins and a usb connector. I'm a golang hacker so with this cross compiler I can deploy the golang binary on these devices using scp and then ssh to execute them :)

GOOS=linux GOARCH=mipsle go build -o build ./...

The device connects to an atmega640 microcontroller. I designed this device for almost any type of IOT service (the pcb was made by OSH Park an amazing service btw) using kicad, I hand soldered the actual processor.

So why not use the omega gpio pins ? I could of course, but because I have already built the one wire interface for the ds18b20 digital thermometer and adc (analog to digital converter) for the XL335 accelerometer, I decided it would be easier (lazy programmer) to go with the atmega. The atmega then communicates with the omega via serial data (usb). This gives me a good layer of abstraction, I can plugin in any type or set of sensors to the usb port of the controller.

I have also made use of keepalived (VRRP - another great topic) and HAProxy to ensure some form of HA for the IOT backend. Each omega device has 2 (or 3) microservices that can be deployed, each service has a specific function one measuring a set of sensors while another measuring another set (i.e humidity, wind speed etc). In this configuration if the master fails, keepalived ensures the "backup" route is used so that we don't have a loss of service.

Here is screenshot of the setup. It's still all in a prototype phase

I also custom built my own isp programmer using an attiny 85 (top right in the screenshot), the code for the atmega was developed using c, avr-gcc to compile and avrdude to flash the device. I only have one setup at the moment, so the other 4 omega devices just return a json stub response.

I used a raspberry pi for my dev environment with the tool chain installed (avr-gcc, avrdude, vim, and tmux) - it' nice and portable for all my IOT development.

Screenshot of tmux, vim and c code.

I then execute the make in another tmux pane and flash the atmega640.

I managed to get it all working, here is a screenshot of the curl to take 5 measurements with a 50 ms interval and also set a callback when the measurements have completed.

Finally the actual output from microservice running on the omega with the callback service responding with a 200 OK.

I double checked the values from the atmega (I use int values) this avoids loading floating point libraries and dependencies, I do all the final calculations in the golang microservice, i.e the value I'm getting from the ds18b20 probe is 335 (multiply this by 0.0625) and I get a value of 20.9 deg Celsius, on my wall temp gauge in the room I read 21.0. The roll, pitch and yaw calculations for the acceleremoter are also done in the golang microservice.

So in conclusion I'm really happy with the design and the pattern used for "on demand event based IOT measurements". The next step is then to add in https (certs - self signed for now) for each omega restful call that interacts with the microservices and add a jwt token to protect each endpoint. A nice to have that I'm considering, is building a surface mount (really small footprint) tiny usb incircuit serial programmer for each omega, this will allow me to automate the flashing of each atmega using the usb and scp to copy the hex files. The whole system would then be fully automated, linting, unit testing, code analysis, building, deploying and flashing of the firmware.

In my next article I will show how I implemented it all using ArgoCD and Tekton, with monitoring (prometheus, grafana) and logging (elasticsearch, fluentd, kibana) for each service.

I had great fun integrating the hardware, c, golang, event driven design, microservices , restful API's, gRPC and protobuf with kubernetes for a scalable , high available, IOT solution.