The diagram above shows how to achieve an isolated IoT environment that has no internet access and devices are running in a local network.

An additional security measure is to isolate IoT devices in their own local wifi network with their dedicated router. This way, even if any IoT device gets hacked, it cannot access the rest of your main router network where you might have open drive shares or unprotected devices, and it cannot access the internet so no privacy concerns. Note that devices might be hacked before being introduced into a local network, and depending on the definition of hacking, some devices might want to report usage statistics or worse private information you would not agree with, such as location, activity, presence,... Note that internet access is equivalent to geo-localisation.

When it comes devices the user would like to trust, such as the shelly smart devices, it is always possible to update their firmware by manually attaching a physical cable between the "isolated domain router" and the "main router" for the upgrade duration and then removing it. Keeping the IoT domain isolated is a better protection from hacks coming from the internet. An open ssh port with a weak or default password on any small iot device should not have consequences involving misbehavior of high power equipment.

TP-Link TL-WR841N N300 WLAN Router

This router is an IoT hero

• Low cost ~ 15 €
• Low Power ~ 1.5 to 1.7 W (yeah, really)

Default DHCP settings can be used and address reservation can be configured in case you'd like to open each shelly device always on the same address. But as shelly devices run on MQTT using their device ID, fixed ip is not required.

Shelly devices configuration

simple and usual as described in the manual. A shelly device creates an access point with open security at first. Once connected to its wifi Access Point, opening the url 192.168.33.1 allows to provide it the "untrusted wifi router" credentials.

Mosquitto server

The raspberry pi MQTT broquer needs through to be in a fixed address, here "192.168.0.110" (no dns used), to be configured in the shelly devices

Below is an example shelly device configuration

Up to here, everything is fine and your shelly starts logging on its MQTT topic but one issue persists and we'll see in the following section how to solve it. The power has a correct value but the energy (kWh or Watt.min) stay at 0.

Explanation

The power is an instant measure, so no time required, but the energy is the accumulation of power over time. Someone could argue that the internal shelly oscillator should be accurate enough for energy accumulation, but admittedly, the energy error would be proportional to the time drift. Long story short, shelly decided to rely on time server for accurate calculation. The Network Time Protocol being too complex and an overkill in this situation, accurate decision was made to use the Simple variant "Simple Network Time Protocol". the protocol has identical queries for the subset it supports, so it can talk to a normal ntp server.

Raspberry pi as time server

sudo apt install ntp
sudo nano /etc/ntp.conf
sudo service ntp status | start | stop | restart

installing and activating a time server is very simple with the commands above. Yet one additional configuration is important when providing the time in a local network

 You do not need google for that, just reading the config file can help

# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
broadcast 192.168.0.255

un commenting the line and adding the correct local network address is enough.

Until here, it still not working as yet another important step is still missing

The time server does not know your time zone

Seriously ? a shelly connects to a time server and still does have no clue what time it is. Practically yes, as depending on which side of the earth you are, it could be 1am or it could be 6pm. As the shelly device is supposed to be on a local network cut from the internet, it start complaining about the time zone which should be configured not to be retried from the internet, simply entered manually, as the user usually knows in which country he lives.

unchecking all boxes that require internet is necessary

• (uncheck) Automatically detect Time zone and approximate geo-location
• (uncheck) Daylight saving time offset AUTO (requires internet connection)

so apparently a time server does not even know if daylight saving is on or off, which makes sense as each coutry have different rules for that. Hopefully the timezone gets deprecated in the near future, until then the shelly devices that needs to be operated in a local network will need to have the daylight on / off set manually when that changes.

Here shelly chould make it with a schedule entry, that would be a last enhancement for an ultimate local user experience.

Power consumption

The smart sockets being used a power monitors have tendency to be used in the power on state most of the time. Therefore shelly made a smart move by opting for the on mode to be the low power consumption state of the relay. Thanks shelly for this smart design move.

device	on (W)	off (W)
Wemo (old version from 2016)	2.3	1.5
Shelly plug s	1.1	1.4

Prevent self kill

In my setup, the untrusted router is itself being monitored with other raspberry pi using a shelly device connected to it. To make the system power loss resilient, it's important to have the default power on behavior set to on. Imagine you monitor the fridge power and you have a short power outage, if this feature is not configured the damage on the fridge food content can be quite significant.

Safer is better

I cannot judge on the safety level of the shelly devices depending on used hw and sw verification measures, but if you have a feature that can activate sometime (hopefully all the time), that makes it already better than not having it.

Imagine a heater, a boiler or any device you know (as you monitor its energy consumption), you can increase its safety by setting the power protection to the lowest possible value. Households should already have protections, but if the usually allowed power is 2500W, that's already dangerous enough, so if it can be lowered on per socket basis, the safety is increased. I can't say how much, but it is.