Building an iot architecture with cloud dependent devices can be risky:
- the cloud service may stop its service before you thought your devices are end of life (c.f. https://forum.mysensors.org/topic/5212/why-ioyt-matters)
- your internet connection may not be available, when you need the cloud service
- the cloud service may change the api
- fees may change not to your advantage 🙂
But there may be reasons to use them nevertheless, e.g. my netatmo devices are
- can measure co2, temperature and humidity battery powered
- look nice
As my heating regulation is dependant on temperature values, I had to take precautions against failure:
- only rooms with co2 sensors may use netatmo, in the other rooms I use cloud independent devices like mysensors, homematic or z-wave
- if a device doesn’t measure new temperature values for some time, my heating regulation algorithm determines, if the majority of the valves for the floor heating on the same floor are open or closed and sets the valves accordingly
This strategy does work really well for me. If the netatmo devices brake one day, I may change them against mysensor devices. I have built one for my living room https://forum.mysensors.org/topic/4355/mh-z14a-co2-sensor/5.
As my iot architecture is designed with flexibility in mind, I don’t want to be restricted to one frontend. As I have a generic mapping for my devices, I want to have interfaces, that allow me to use all my devices without having to add every device manually to every frontend element. Here are some frontends I tried and my experiences with them:
|fhem||+||++||Gateway in my iot architecture and not a frontend.||via mqtt
|grafana||+++||never tried||No mongo integration yet.||mongo not yet supported, used with influx
|imperihome||+||+++||No webapp (ios/android apps).||node-red flow
|metabase||++||-||Steep learning curve. 🙂 Restricted in automatic labeling. Not as intuitive as grafana.||mongo
|node-red-ui||++||+++||Access management insufficient (solved with nginx).||node-red 🙂
|thingsboard.io||++||++||To big in my opinion to be used at home, large memory footprint.||Flow with gateway to thingsboard.io, has its own storage (cassandra).
The physical implementation of my logical iot architecture is heavily based on mqtt and node-red:
The gateways have usually two parts:
- outer part: bridges the devices to mqtt, rest or telnet protocol
- inner part: flow in node-red communicating with the outer part
As outer part really important are fhem (zwave and buderus) and homegear (homematic).
Long, long ago, when I first played with home automation devices (X10) I soon wanted devices with different technologies and protocols. With more and more devices (homematic, zWave…) I designed an architecture for my IOT devices, which allowed me to mix and match different devices and technologies.
- device tier: sensor and actuators
- gateway tier: communication layer to the different technologies
- generic mapping tier: standardise all the messages from the gateways (inspired by mysensors serial gateway)
- applications tier: business logic, using the standardised protocol from the generic mapping tier
- persistence tier: store all the data from the sensors/actuators and the apps