More Maintainable Architecture approach. iotp Framework

Hello all, in Dec'18 I participated in a great discussion from @hazymat, topic Choosing an architecture for Home Automation. I had the same concerns, and since family members asked that I deploy a system to them as well, I realized that I will not be able to handle the added maintenance load of each system deployed in a different way, with my day-job.

By this discussion, I have pencilled an approach, based on research of how AWS's, Apple HomeKit, and others IoT frameworks worked. I call my framework dig2 - for a popular, and now overused word, digital twin. I specifically liked AWS's Registry, and its Thing Shadow.

For those interested, here is a write-up of what I am busy with: iotplay's Dig2 on Github.

I could have used Home Assistant, or Apple's HomeKit only, but what is the fun in that ?

Although I am not yet ready to publish the code, would like your views on this?
Thanks !

1 Like

And here were the requirements to which I worked:

# Requirement Description Req. Name
1 A framework, that created definition of the IoT devices, only in one place. Registry
2 A capability where the complexity of receiving, sending, and managing the underlying IoT devices is hidden from the rest of the framework. Broker
3 Standardized messaging symantics, where messages in the framework, and to other building blocks are standardised, to reduce maintenance. The iotp message protocol
4 Retention of the latest-, and previous state of devices, to determine for instance durations between changes in state, thus the 'Digital Twin' of the Devices. Twin Shadow
5 A rules engine, that can watch the states of devices, and take actions based on a severity of the state Twin Rules Engine
6 The ability to plug in other solutions, (which can run in its own space, which will reduce maintenance), only communicating to the rest through mqtt messages, to provide new functionality, without needing to know the underlying protocols of talking to the IoT devices. Docker containers talking to 'The Broker'
7 A Plug-in to enable Apple HomeKit, where The Broker talks in the Apple HomeKit json format to it, and it talks back to the Broker - and not with the Devices HomeKit Node-RED Docker container

Other solutions can now be 'plugged-in' as well, we are working on a Messenger container.

Interesting! Hope you don't mind, I moved this from general to projects.

You've obviously put a lot of thought into this, it will be very interesting to see it mature. For me personally, I would prefer it not to be in Docker but I can see that may make it simpler to deploy.

What you've done here mirrors some of my own thoughts and ideas though you've articulated them a lot better than I have.

I look forward to seeing more in the future!

1 Like

Docker is not essential, it will work without it. Just easier to have the ā€˜pluginā€™sā€™ work on the same RPi / easy deployment.

1 Like