Shelly Power Outage Monitoring Solution
This power outage monitoring solution uses a Shelly Plus Plug to run the power-outages script and integrates other constant-powered Shelly devices like relays or plugs. The Plus Plug is linked to an uninterrupted power supply for continuous operation. Connecting it to a UPS with the router ensures consistent power and internet connectivity, enabling effective monitoring of circuits for outages or equipment malfunctions.
Solution Overview
Β
Shelly Plus Plug (Plug 1)
Β
Internet Modem / Router / Gateway
Β
Uninterrupted Power Supply (UPS)
The Modem / Router / Gateway and Shelly Plus Plug are all connected to the Uninterrupted Power Supply
Additional Shelly Device (Device 2)
Using a simple script Plug 1 constantly polls Device 2)'s status
As long as Plug 1 can retrieve a status from Device 2 power is present
When Plus 1 can not obtain the status of Device 2 it executes an action as specified by the script.
The script relies on templates to define messaging options and the devices to monitor, as well as polling time and logging options.
Instructions
Set up a "Script Host" Shelly Plus Plug.
Firmware for this Plug should be updated to the latest version
In the device settings, assign a static IP address, preferably outside of the router's DHCP range.
If possible, set a matching DHCP reservation in the router.
Repeat steps 1-4 for each Shelly device being monitored.
Using a computer on the same VLAN as the Shelly devices, navigate to the "host" plug's IP address.
If using MQTT, navigate to the Settings page, select MQTT, and enter all of the settings for your broker. The plug will require a reboot before proceeding.
In a new browser tab, navigate to the GitHub page linked below:
Click the βRawβ button near the top right. Highlight and copy all of the text on the page using the CTRL-A and CTRL-C keyboard shortcuts.
Highlight and copy all of the text on the page using the CTRL-A and CTRL-C keyboard shortcuts.
Switch back to Shelly Plus Plug's browser tab
Click the < > Scripts menu.
Click Create script.
Enter a name for the script.
example - "power-outages"
Click anywhere in the script's code window (top white box), then press CTRL-V to paste the previously copied code.
Verify that the entire contents of the page in step 6 are now, in the code editor window.
Edit the "notify" section (lines 2-4), "devices" section (lines 6-15), and either of the values in lines 17-19 (if desired).
The configurable sections of the script are explained in greater detail below.
An external editor, like Visual Studio Code, has functions that can help identify syntax errors before adding to the Shelly code editor.
Click Save, then click Start.
If the script should always run, go back to the main scripts page and enable "Run on startup"
Script Functionality and Configuration
Messaging
Messaging options like Webhooks and MQTT are discussed in the text. MQTT notifications can be published to specific topics, allowing users to subscribe and receive push notifications through mobile apps. The versatility of Webhook options is highlighted, with examples ranging from IFTTT applets to custom notification services showcased on GitHub.
Shelly Plus, Pro, and Gen3 products support TLS 1.2 and have a default certificate pre-loaded, allowing use of HTTPs and MQTTs services.
Notify Section Configuration
The notification JSON data block allows as little or as great granularity as desired. The script can support a single notification or dozens. There are two types of notifications - Webhook and MQTT. The examples below use "web-" and "mq-" prefixes, but this isn't a requirement - make sure that the names are unique and use the intended notification with the specific device(s).
Webhook Notifications
As shown below, Webhook notifications have "name" and "url" values:
{ "name": "web-a", "url":"http://192.168.15.203/rpc/Switch.Toggle?id=0" }
{ "name": "web-b", "url":"https://maker.ifttt.com/trigger/Plug_A_Down/with/key/cHsMQkqH7ddKEL7NNWi2v-CW9xzFvoAYf9-V999-Nx0s" }MQTT Notifications
MQTT notifications have "name," "topic," and "message" values:
{ "name": "mq-a", "topic":"updownA", "message":"{device} is {state}"}
{ "name": "mq-b", "topic":"Emergency", "message":"{device} is {state} - power outage detected"}Devices Section Configuration
The devices JSON data block defines one or more Shelly plug or relay products or some device that returns a minimal payload when queried via webhook.
Devices have "name," "enable," "alerts," "url," and "poll_time" values.
{ "name": "plug-a",
"alerts": [ {"notify": "web-a", "dir": "down"},
{"notify": "mq-c", "dir": "down"} ],
"url": "http://192.168.1.180/rpc/sys.getStatus",
"poll_time": 10 },
{ "name": "plug-b",
"enable": false,
"alerts": [ {"notify": "web-b", "dir": "both"} ],
"url": "http://192.168.1.181/rpc/sys.getStatus",
"poll_time": 10 }Β
Required Attributes
Β
Name
Β
Alerts
Β
Β
URL
Β
Β
Poll_Time
The given name must be unique
Options include WebHook, MQTT, or both. You may have multiple alerts of each type. Direction ("dir") can be up, down, or both.
This is the URL queried to determine if a device is online/powered. This can be any reachable URL (internal or external to the network used by the host).
This value determines how often the host checks the URL. A minimum value of 30 is strongly recommended to reduce traffic.
Β
Optional Attributes
Β
Enable
If not specified, the default value is true.
Other Settings
Cycle_Time - This timer checks to determine if it is time to poll the URL for a given device. It defines the minimum usable poll_time. If you set the poll_time to 30s, but the cycle_time is 100s, your poll_time would also be 100s. Also, cycle_time impacts how quickly the script responds to each situation, and how fast it sends subsequent alerts if you use a (long) list of notifications.
Verbose - This determines the level of information sent to logs for debugging.
Testing
Utilizing webhooks to toggle Shelly plugs and relays serves as a valuable tool for validating the proper functionality of your setup. In my testing configuration, I employed four plugs - specifically two power strips. Each power strip was connected to a Shelly Plus Plug (plug-host) that acted as the host for the script, along with plug-c. Additionally, one plug was linked to each power strip for conducting tests (plug-a and plug-b).
For notifications, the aforementioned toggle commands have been utilized, along with IFTTT webhook to email applets, MQTT in conjunction with a free iOS MQTT push notification app, and various other tools.
Notes
The Plus Plug utilized for executing the power-outage script should be connected to a UPS/battery backup, in addition to the router/gateway/modem that offers Internet access and Wi-Fi.
The script can be utilized with a variety of devices, including but not limited to smart TVs, weather stations, computers hosting webservers, remote web services, and other similar items. In such scenarios, it is important to consider the possibility of a power outage or the need for device reboot. It is essential that the other device is capable of responding to http:// or https:// requests rather than just any IP port. By integrating with a Shelly plug or relay, one can configure an "alert" feature to cycle the relay or control the connected device via the plug.
The script can easily run on a low-voltage device, or the Shelly Bluetooth gateway, which as you know is USB powered. That opens up some amazing options to have the always-on device powered in ways far more efficient than an AC/DC/AC style UPS.
With a USB powered bluetooth gateway, any laptop could effectively be the UPS.
AT&T used to ship their DSL router gear with a 12V UPS, which supplied 12V directly into the gear. I have a number of those. They are great because they avoid the crazy number of lossy conversions that a regular UPS incurs: AC to DC to charge the battery, DC back to AC to supply the outlet, and then a wall wart plugged in to get back to the DC voltage to supply the device.