If your Shelly Pro 3EM device notifications not working issue is leaving you without alerts, the problem is usually traceable to configuration, network, app, or firmware settings.
This guide walks through the most common causes and the fastest ways to restore dependable notifications without guesswork.
Why Shelly Pro 3EM notifications stop working
The Shelly Pro 3EM is a Wi-Fi energy meter used for monitoring three-phase power usage, solar export, consumption, and circuit behavior.
Notifications depend on more than just the device being online; they also rely on cloud connectivity, local automation rules, app permissions, and thresholds that must be correctly configured.
When alerts fail, the issue is often one of these:
- The notification rule is disabled or misconfigured in the Shelly app or web interface.
- The device has lost stable internet access or is switching between weak Wi-Fi signals.
- Cloud services, push notifications, or mobile OS permissions are blocked.
- Energy thresholds, hysteresis, or trigger conditions are set too narrowly.
- Firmware or time-sync problems prevent automations from firing as expected.
Check whether the alert rule is actually active
Start with the simplest possibility: confirm the notification rule is enabled.
In the Shelly app and the local device web UI, rules can be turned off, saved incorrectly, or set to conditions that never occur.
Verify the following:
- The rule or scene is switched on.
- The trigger condition matches the current behavior of the load or solar system.
- The action is set to send a push notification, webhook, MQTT message, or cloud event.
- Any schedule or automation window is still active.
If you are using a local automation platform such as Home Assistant, openHAB, or Node-RED, confirm the trigger is reaching that platform before looking at the Shelly app itself.
Confirm the Shelly Pro 3EM is connected to a stable network
Notification delivery fails frequently when the device has intermittent Wi-Fi.
The Shelly Pro 3EM may still appear online in the app while missing short outages, reconnect loops, or packet loss that break alert delivery.
What to inspect in the network setup
- RSSI signal strength in the Shelly device status page.
- Router logs showing reconnects, DHCP renewals, or authentication failures.
- Whether the device is on a crowded 2.4 GHz channel with interference.
- Whether a mesh system is handing off the device too aggressively.
For best reliability, give the Shelly Pro 3EM a strong 2.4 GHz signal, a reserved IP address, and a stable DHCP lease.
Avoid placing it where signal strength is borderline, especially inside metal enclosures or near high-noise electrical equipment.
Review push notification permissions on your phone
Even when the device and cloud are working correctly, the phone may block the alert. iOS and Android both have notification settings that can silently suppress messages from the Shelly app.
Check these settings on your mobile device:
- Push notifications are enabled for the Shelly app.
- Do Not Disturb, Focus Mode, or Battery Optimization is not blocking alerts.
- Background app refresh is enabled where applicable.
- The app is updated to the latest version.
If you recently reinstalled the app, logged out, or changed phones, re-authenticate and confirm the app is still allowed to send alerts.
Some users also need to reselect the correct device after switching accounts or regions.
Inspect firmware and app versions
Outdated firmware can cause notification logic, cloud sync, or API behavior to fail.
The Shelly Pro 3EM supports regular firmware updates, and new releases often improve stability, automation behavior, and compatibility with app features.
Update and verify:
- Shelly Pro 3EM firmware version.
- Shelly app version on your phone or tablet.
- Any integration plugins or home automation add-ons.
After updating, reboot the device and test a simple alert rule.
If the issue started immediately after an update, check release notes or temporarily compare behavior with a basic local trigger to isolate the problem.
Make sure the trigger conditions are realistic
One of the most common reasons Shelly Pro 3EM device notifications not working is that the threshold is set too high, too low, or too tightly.
Energy meters measure real-world loads that fluctuate constantly, so a trigger that looks correct on paper may never activate in practice.
Examples include:
- Power threshold set above actual peak load.
- Current alert tied to a short spike instead of sustained demand.
- Voltage or frequency condition with unrealistic tolerances.
- Solar export trigger that does not account for inverter ramp-up.
Use a temporary test threshold that is easy to hit, then observe whether the notification arrives.
If it does, refine the threshold gradually until it matches the real use case.
Test cloud, local, and automation paths separately
Shelly notifications can fail at different layers, so testing one path at a time is important.
A cloud notification failure does not necessarily mean the device cannot trigger locally, and an automation failure may be unrelated to Shelly cloud services.
Run these tests in order
- Trigger a basic local action on the device, such as a relay or scene event.
- Test a simple cloud notification if your setup uses Shelly Cloud.
- Trigger a webhook or MQTT message if you use an external controller.
- Verify receipt in the app, browser, or automation platform logs.
This approach helps identify whether the failure is in the device, the Shelly account, the internet path, or the third-party automation layer.
Check time, timezone, and synchronization settings
Incorrect time settings can break schedules and event-based rules.
The Shelly Pro 3EM may depend on accurate time for timed automations, log timestamps, and certain notification windows.
Verify that:
- The correct timezone is selected.
- NTP synchronization is active.
- The device clock matches current local time.
- Daylight saving time changes were applied properly.
If the clock is wrong, alerts may appear to fail when they are actually being suppressed by a schedule or misaligned by an offset.
Look for account, cloud, and device ownership issues
Notification problems can also happen after account changes.
If the Shelly Pro 3EM was moved to a new owner, added to a different home, or shared across multiple users, permissions may not carry over cleanly.
Review:
- Which Shelly account owns the device.
- Whether the correct home or location is selected in the app.
- Whether shared users have permission to view notifications.
- Whether the device was factory reset and re-added without recreating automations.
Shared setups often work for monitoring but fail for alerts because only one account has push access or the original automation references an old device ID.
Use the device logs to narrow down the failure
Logs are one of the fastest ways to diagnose recurring notification issues.
In the Shelly Pro 3EM interface, look for Wi-Fi disconnects, reboot loops, rule execution failures, and cloud registration errors.
Useful log clues include:
- Repeated reconnect attempts to the router.
- Failed DNS resolution or gateway reachability.
- Automation events that fire but do not complete the notification action.
- Unexpected restarts after power disturbances.
If logs show no trigger event at all, the problem is upstream in the trigger logic.
If the trigger fires but the notification does not, focus on the action destination, app permissions, or cloud connectivity.
Best practices to keep Shelly Pro 3EM alerts reliable
Once notifications are restored, a few configuration habits can prevent the issue from returning.
Reliable alerts depend on stable networking, simple rules, and periodic verification.
- Reserve a static DHCP lease or fixed IP address.
- Keep firmware current on the device and app.
- Use moderate thresholds with a small buffer for real-world variation.
- Test every alert after router changes, power work, or app updates.
- Document which automation platform sends each notification.
For energy monitoring and automation use cases, the most dependable setup usually combines strong Wi-Fi, conservative triggers, and a monthly test routine.
That makes it much easier to spot changes before a missed alert becomes a real problem.
