I use to create code that is reusable accross my sensor-nodes. They simply publish to a topic called 'raw_sensors/<sensor-id>', where <sensor-id> is any unique sensor- or hardware-ID. The inventory is kept on the server side ("Home Assistent" in my case). (edit:) Moving sensors can be handled in the configuration here and is reasonable in my oppinion. (/edited)
There i do also forward the data into my InfluxDB for further visualization.
I will follow this path with my actuators as well (KISS).
Ohhh I am all for KISS and I think our ideas are rather similar. I would like to get a generic piece of code running on the nodes and create a way to configure them via MQTT. E.g. One could set the measurement time interval and averaging on sensor nodes, or additional delay times or something like auto-power-off on actuator nodes. My idea here was to create as much flexibility as possible to "reprogram/reconfigure" the nodes without touching the micropython code. However, further thinking makes me wonder if that is really a good way. It would require to implement a set of commands or even a very simple programming language send over MQTT to the nodes. Albeit, there is already a micropython running on them. Maybe it is better to think of something like automatic OTA-updates?! I like to keep the housekeeping centralized as well to make maintenance easier, however, the power of running micropython on each node allows us to think about more autonomy of each node.
My initial idea what to do with a micropython-based home control:
In principle there are two dominating approaches in the smart home world:
1. Dump nodes and a centralized sever, which defines all the logic, rules and does all the work. Nodes simply receive and send data directly addressed to them, without any further processing. That is what 99% of the commercial smart home market stuff is doing.
2. Decentralized systems (this is what large building services management system often use e.g. KNX) whereas each node reads on a bus system and makes decision by itself how to proceed with the data coming from the bus, or simply send data to the bus.
Whereas 1 is relatively simple and for the home market commercially of bigger interest (most companies try to sell you some sort of cloud service with monthly fees and try to create a gated environment), version 2 is much more robust. Even if parts of the network fails, other parts can still communicate with each other. However, it is usually much more expensive as it requires enough processing power in each and every node.
I believe a MQTT + Micropython gives us the best of both worlds. The MQTT broker is still a centralized service. However, it is rather simple, one could replace/move it within minutes without much reconfiguration. It is also rather resource friendly and can run on the wifi router itself, a Rpi or anything else.
Micropython will allow us, to create easily smart nodes, and the rules/logic could be implemented in the node itself. That is each node reads the MQTT topics and acts accordingly to it.
A simple example: A light should turn on if a light-sensor indicate darkness and a switch is pressed. It should turn off after 10 min. Conventionally, this rule would have been defined in the centralized system.
Read status light-sensor
Read status button
If light-sensor is low and button is pressed send command to actuator
Actuator switches the light on
After 10 min, send actuator to switch the light off.
The problem here, if the actuator is not longer reachable e.g. after the light has been switched on, it will not go off anymore, or one has to deal with complex error handling etc.
With MQTT and micropython the node itself could take care of that rule by itself.
Read last status light-sensor via MQTT
Read last status switch via MQTT
If light-sensor is low and switch is on, pull the relay and hence turn on the light (here I am not sure, see above, if that rule could not be a MQTT payload as well)
Set timer with value from MQTT
Turn off light as timer finishes.
All this would happen in the actuator node and is rather simple to do in micropython.
I would love to hear opinions for such a system.
Finally, I plan to use an extra wifi-network for the nodes with a hidden SSID, just because I want to avoid that many of those little nodes start to pollute my normal wifi network.
Sound over-engineered to me. I will stick with my single WLAN until i need to put stuff in quarantine or a DMZ. The toys i do flash my own are trusted by me. And even if you open up a new SSID, the sensor will still pollute your WLAN frequency!
Well I should have been more precise here, I meant to say I go with an extra (hidden) SSID. Simply to achieve a clean and easy way to manage those nodes. I configured it in a way, that none of the nodes can directly access or being accessible from outside. The only connection here is the server which runs the mqtt broker and the home-assistant software. I have some tools which do network scans and I do not want to see many of strangely named nodes within the list of the usual network clients. It might also add some sort of safety.
Home-Assistant also transforms the payload and pushes it onto my InfluxDB, where I use Grafana to paint graphs of them.Grafana+HomeAssistant.png
(yes, i know we need to air our house asap. We own a passive house and i need to switch on the automatic venting system again. This is my direct motivation for this visulization, btw
)
I'm new to Home-Assistant and never heard of Grafana, I will follow up on this. Are you satisfied with Home-Assistant? I still have problems to understand the concept. BTW. as I saw your graphs, in which part of Germany do you live. If it is close to Aachen, we might can chat about this vis-a-vis