Servers

• mini-server : We begin with deployment on hardware. The mini server is a x86 ~ 20W silent PC, living room friendly, hosting the main website for a rugged access from the outside, but all smart services (grafana,...) are local network serivces.
• mano : no logic for naming is followed, just friendly host name for management. Raspberry pi have a samba share for easy logs check, the rest is ssh control. Mano has most services, standard ones (Mosquitto broquer, influxDB, Grafana, zigbee2mqtt, miflora2mqtt) and others custom developed within this project (Hue python ruler, nrf2mqtt custom python adapter, mqtt2influx simple python service and heat ruler that controls thermostat reactions)
• hassio / lifo : more experimental raspberry pi servers. Hassio has the hassio service that I find nice as a backup, it is good as interfacing everything, but the rules are more complicated than vanilla python, the viewing is nothing to compare with grafana and the control e.g. lights is quite rudimentary, it is after all hard to do everything and good.
• Hue gateway : used in local network, no account, no internet access enabled. The Hue API is quite clean and simple and python make it usage even easier. The Hue android app is also amazing and one of the main reasons why I kept the light with the Hue gateway although I could controll it through mqtt. Note that given the zigbee standard, all sorts of zigbee light bulbs can be attached to the gateway and not only those of the manufacturer, which is quite fair.
• remote access : all services are remotely used through a vpn access, which relaxes all need for security that should not be mishandled by diy development rather collected in a (relatively) reliable interface.

Wireless networks

One of the most annoying feature of wireless network is the shared resources (the air - or the void). Users can rarely see on which channel is the wifi network, and it is left for automated selection by the router. Especially in case of intensive experimental environment, it is important to allocate frequency space for every network to avoid interference's. Pairing a zigbee device can be much less reliable in case of high interference, also battery usage as the zigbee is an acknowledged protocol (over IEEE 802.15.4) and the simple no-ack protocols would see more data drops.

The wifi has a wider bandwidth, so it's good to leave more than one zigbee channel free around it. The diagram is only illustrative, the bandwidth depends also on the router configuration.

Bluetooth does not appear here although the miflora devices are bluetooth. It is narrower than zigbee (shorter range smaller bandwidth) and always hopping so it freaking disturb a little everywhere. A further analysis could check detailed impact, more info on the matter can be found in references such as : https://help.turningtechnologies.com/PDF/Hardware/RFInteroperabilityDoc.pdf

Devices deployment

Aaround a hundred devices to be managed would make every day life more confusing than helping if not seamlessly integrated in the environment. Changing batteries is also required, luckily devices hold from 6 months (the custom made ones) to around 3 years at least for the others. What is important on the other hand is a low battery alert to avoid having to keep checking batteries level very often.

Philips hue lighting are quire reliable, inter-operable with Innr, and the pure white ones (not colored) are quite cheap. Zigbee include devices association so that the dimmer can talk to the light directly without the gateway, but that is a useless feature. In about two years of usage, I did had a failure once when for some reason I had to re-pair a dimmer. Using independent buttons (aqara) to switch hue light through the hue api have a reliability of Ethernet network, in my case no wifi used for the raspberry pi controlling the light and luckily the hue gateway also has Ethernet plug. So other than de-bouncing bugs from early maturity, the system works quite reliably and is very responsive.

Hue dimmer vs aqara button vs aqara wall switch

The Hue dimmer is elegant, yet misses one point for long press configuration. Having one function for first and one for second press is not practical if first press is most common normal full lighting and second is low level lighting. This issue is solved with aqara single click vs long press for low lighting. The wall switch have similar functions as the button, but is much nicer on the wall, yet the button is more silent in usage.

Eurotronics and aqara contacts

It is practical to set a heating cut when a window is open, see more details on how aqara are notifying the eurotronics thermostat in this log : 

https://hackaday.io/project/124114-nrf52-sensors-mesh-network/log/168774-aqara-and-eurotronics-hand-in-hand-to-save-energy

The Eurotronics thermostats have excellent functionality, still experimenting first weeks of battery life. They do not replace a temperature sensor as they only report the temperature when asked for a function otherwise randomly every few hours. When they report the temperature, they report three of it (see details in zigbee2mqtt wiki).

wifi is still the master of home automation and zigbee interoperability

Let's not forget the basics, zigbee did not invent home automation, rather the corner cases where low power is required. For everything that already has a permanent power access, wifi is much simpler to use. It is true that depending on the network, wifi might have a bad response time which is very likely to happen most of the time, therefore zigbee or custom would have the niche advantage that networks are not so polluted as wifi. But this assumption is less valid every day when zigbee networks get flooded with devices. In theory zigbee get hold millions of devices, in practice with limited memory implementations zigbee2mqtt recommends only 20 to 40.

As conclusion interoperability is of major concerns when relying on zigbee for vital functionalities such as lighting.

wifi devices light and heat

The bed heater is a simple ESP32 with an mqtt interface that takes a percentage (with steps of 10%) and sets the heating accordingly. It also features and mandatory power off after one hour.

The RGB led panel has its own project page on #Neopixels Animations on ESP32 MQTT Json Webapp . It is quite a fancy ambient light with no equivalent on the market, as every LED is addressable and the mqtt commands take requests for wave frequencies and colors, that prevents a huge traffic of an app that would have to download complete LEDs sequences. So the light stays at vectors level and do not involve videos. It has not been deployed for usage with aqara devices yet, but this should be quite simple, e.g. one press for ocean animation, long press for savana animation running one hour.

nRF52 sensors

The nRF52 sensors have their own project entry on #nRF52 Sensors Mesh Network . It is quite remarkable that they have no equivalent on the market yet. The aqara temperature and humidity does not feature light and has a much lower resolution (agreed not always necessary)  but the high resolution can allow new ways of learning events from temperature variation signals not only from rough changes, that high resolution signal can calculate the heat constant or knowing the heat capacity of the room, to calculate the attack vector such as opened window, or opened fridge. This network does not feature any configuration, devices are flashed with their ids. So no pairing pain, but also much less practicle for real use cases as there is no automatic channels selection for example. Also no timing synchronization, even no acknowledge. All of this simplification result in a very simple software stack (one file with few functions).

miflora

I hesitated to add it to the list, as it's not a mesh after all, and bluetooth range is lower than zigbee, but it is a home automation sensor, and it is still possible to compensate than by having one raspberry pi per region of the house.

Applications deployment

... yet to be witten...

how to view and control what, with which app / web app and which technology is used behind