Remote Cable Modem Reset Plug

With the addition of PING in RM 5.1 (under, I successfully built a set of rules which checks my internet connection on a periodic basis, and if down, cycles an AEOTEC smart switch 7 OFF. I mention the switch, only because that particular switch has an Auto-On setting which you can set a timer (1 minute is the shortest) to automatically cycle the switch ON when turned off. This makes it a very effective reset option.

I broke the rule into 4 separate rules, primarily for ease of development and testing. I also have several virtual switches and strings (with connectors) which allow you to both test the rule actions, and to manually trigger portions of the rule separately. I've detailed everything in the section below for anyone interested.


Hub Variables

CronPingRate - a String to set a variable Period trigger (minutes) using Cron. Added in .140, still not fully implemented and requires a little extra code to pick up when the string is changed. Sample shows a Period of 1 minute, I start with 10 or 15 when the network is up, and go to 1 when it is down.

DownRate - A number with connector to allow you to change the Network Test rate (Cron) when the network is down. I use 1 (1 minute) by default.

UpRate - A number with connector to change the Network Test rate (Cron) when the network is up. I use 15 minutes by default.

InternetTest; ModemTest - strings with connectors to set IPs for Ping test locations. This just allows you to easily change the Ping IP from a dashboard vice going into the RM code itself. The routines ping both an external internet IP, and an internal Modem IP (explained in the Network Test code).

PingLoss - a number to capture the %value% result of the Ping.

PingRate - a number to set the current testing frequency - the starting point to change the CronPingRate.

PingText - a text to capture the %text% result of the Ping.

Virtual Switches. The following virtual switches are used:

Auto Reset - Used as a predicate to suspend the rules when auto-action is not desired.

Cable Modem Reset - Used as a manual trigger to reset the modem (cycles the power plug).

CronReset - Virtual switch with 2 sec auto-on to reset the Cron routine when PingRate and CronPingRate (Cron Period) are changed. Used as a work-around, explained further in Cron Update / Cron Trigger routines.

Internet Down / Modem Down - Two virtual switches to indicate the respective Pings was unsuccessful and trigger the reset routine.

Internet Ping - Virtual switch with 1 sec auto-off to trigger the Network Test routine. Used both manually, and by the Cron Trigger routine.

Network Down Simulator - simulates a loss of Internet as an added conditional in the Network Test routine, also disables the Cable Modem Reset routine through a predicate condition to avoid power cycling the modem. Used for testing.

Cron Update
Captures a change in rate (UpRate, DownRate, or PingRate). Applies the change to PingRate if applicable, updates the Cron String CronPingRate, then triggers the CronReset switch to restart Cron Trigger with the new rate (period).

Cron Trigger

The primary timer routine using a Cron period timer. This triggers Network Test through the virtual switch Internet Ping. The Test Trigger is just another virtual switch I used in testing (500ms auto off) and just haven't removed.

The CronReset Predicate resets the Cron timer when the Cron String is updated through a virtual switch with 2 second auto-off. This is a current work-around as updates to the Cron String otherwise are not captured by the timer.

Network Test

Primary Network Test rule:

PREDICATE: Auto Reset is a virtual switch which controls all the Network Test / Reset apps.

TRIGGER: Triggered by a virtual switch INTERNET PING with a 1 sec auto-off. This allows the routine to easily be triggered manually or by other apps.


Two separate tests are included - an Internet Test (currently using DNS lookup IP address), and an internet network MODEM test using the Modem IP. While a single Internet test would be sufficient, I've had issues where my particular modem HTML admin script was not responding, even though the internet connection was working fine. Therefore this test routine checks both.

Both checks are similar:

PING the address using a string variable, the variable just allows me to set a different IP address without changing the app itself.

Capture the %text% and %value% responses in Hub Variables and log them. I noticed that the responses weren't logged otherwise and I wasn't sure if the Ping was initially working. You can skip the hub variable and just log %text% %value% directly, added when I was building the routines and didn't end up using them anywhere else.

I've been getting PingLoss responses (%value% of 0 or 100). 3 pings, either all go through (0) or none (100).

If 100% loss, then turn ON INTERNET DOWN virtual switch which triggers the network reset routines. Also set PingRate to DownRate which is increased testing (set to every minute currently) when the network is down until it comes back up. Also sends a notification to my phone which understandably will not get through with the network down.

ALSO a second conditional virtual switch 'Network Down Simulator' also triggers the routine and allows me to test the routines remotely without taking down the network.

ELSE - if InternetDown was ON, meaning the network just came back up, then notify my phone the network was restored, which will (should) happen. Reset Virtual Switch InternetDown to OFF.

The ModemTest Ping actions work the same, except I only added the simulator switch on the InternetTest routine.

Finally, If both Internet Down and Modem Down virtual switches are off, reset the PingRate to the UpRate (less frequent polling when network is up).

This is placed at the end separate from the two test routines to otherwise avoid possible looping. If you opt for only a single test routine, then you can place it with the ELSE actions.

Cable Modem Reset

Main reset routine.

Cable Modem is a z-wave switch which has an 'auto-on' setting after 1 minute (a built-in switch setting). After you turn it off, it will automatically turn back on after 1 minute, which removes a possible error of lost z-wave transmission, hub is also down/etc. This is the plug that power-cycles the modem.

Alternatively you can build a separate rule that is triggered on Plug Off and turns it back on after a suitable delay.

PREDICATE CONDITIONS: Auto Reset is a virtual switch that allows me to turn all associated Network Test / Reset rules on or off. Network Down Simulator is another virtual switch that simulates a downed network that I used to test the Cron routines. This disables this routine, which actually power cycles the plug, to keep the network up during testing. It is also used in the Network Test routine as a separate conditional. This was especially important since these routines were built for a remote location.

TRIGGERS: Main trigger is virtual switch CABLE MODEM RESET. Also triggered by either INTERNET DOWN (ID) or MODEM DOWN (MD) virtual switches. The only difference between ID and MD is that ID pings Googles DNS lookup, MD pings the local cable modem IP. Both are described in more detail in NETWORK TEST.

The routine turns off the modem plug, then waits for switches 'Modem Down' and 'Internet Down' to turn off, which indicates the network is back up, and finally resets the Cable Modem Reset switch.


This shows the various switches/connectors in a dashboard which brings most together. A couple other switches are included for my VPN (FireWalla) and a presence detector which I used previously but wasn't working as reliably.


I found that during a reset with no IP address, PING returns transmitted 0, received 0 with a loss of 0 which equated to the network being up in my routines. Additionally, checking both external and internal networks created a partial loop which resulted in 3 separate resets before the network came back up. I made some adjustments to correct both these conditions.

I also modified my NETWORK DOWN SIMULATOR switch so that it DOES reset the modem (I removed the predicate from the Cable Modem Reset routine), but it automatically turns off after the first reset to also simulate the network coming back up. This allows me to actually test the routine by taking down the network and going through the modem reboot routine.

Details here.

NETWORK TEST Changes in Bold Italics with additional remarks in [ ].
Ping %InternetTest%
Set PingLoss to %value% as integer
Set PingText to '%text%'
Log: 'Internet %PingLoss% %PingText%'
IF (Variable PingLoss = 100 OR
Variable PingText contains 'Transmitted: 0'
Network Down Simulator is on) THEN
IF (Network Down Simulator is on) Off: Network Down Simulator
IF (Internet Down is off) Notify Dave’s iPhone: '%date% %time% Everett Dr. Internet is down.'
[moved the notification above the switch and added the conditional to prevent repeat notifications each time through the test.]

On: Internet Down.
Set PingRate to DownRate
IF (Internet Down is on) Notify Dave’s iPhone: '%date% %time% Everett Dr. Internet was reset.'
Off: Internet Down
Ping %ModemTest%
Set PingLoss to %value% as integer
Set PingText to '%text%'
Log: 'Modem %PingLoss% %PingText%'
IF (( Variable PingLoss = 100 OR
Variable PingText contains 'Transmitted: 0'
Modem Down, Internet Down all off) THEN
[added conditional to only take action on internal network if external network is up.]

On: Modem Down
Set PingRate to DownRate
Notify Dave’s iPhone: '%date% %time% Everett Dr. Cable Modem is unreachable.'
IF (Modem Down is on) Notify Dave’s iPhone: '%date% %time% Everett Dr. Modem was reset.'
Off: Modem Down
IF (Modem Down, Internet Down all off) Set PingRate to UpRate[/details]


Removed the trigger to run on a change in ChronPingRate which was generating an unnecessary additional test cycle each time the network went up or down.

Cable Modem Reset
I removed the Network Down Simulator switch OFF predicate which prevented the reset routine from running during a test cycle.


interesting.. have to figure out how to use it. My problem myinternet hub is on a separate wifi network on an at&t access point so i can reboot it remotely when house is empty and main internet is down.. there are drivers for it as it is a kasa/tplink switch but i dont believe it is reacheable with the hub drivers as obviously it is not on the same network as the hub.. i dont want to install cloud kasa drivers as i prefer everything to be local..

I think there is a cloud versoin of the driver ... i could setup a whole separate kasa account for just that one switch, but then i could see it on my phone.. hmmm

1 Like

You have a better solution which is another full backup network. These routines are designed to run autonomously. The dashboard is primarily for adjusting and monitoring when the network is up. I'm running on a rental property currently under renovation, even though I have a small backup battery, some power losses and such have recently taken the network down.

Additionally, I have a fully separate wifi switch (Gosund from Amazon) on the HE which allows me to power cycle that in the event it locks up.

I either need one or the other up, and the location is only two hours away with a relative nearby in case both fail, which happened before I got this routine working. Sufficient for my requirements.

You should only need to put the control plug on the z-wave (zigbee/whatever) network that is running on your HE hub, doesn't matter what network that refers to. You could also put a plug on both networks, or even stack two plugs connected to two separate home automation networks if you wanted to run redundant routines, etc.


ya one house or the other is always empty and i have hubitats in both.. an extra 20 a month for the att access pt. in each house is worth it for me.. they are 1300 miles apart.. and have saved my butt a few times..

B ut automated monitoring of when down would be nice at laast even if i dont reboot.. So i think i can integrate some of this.. Obviously, if my main network is down though I dont see how to get a notification out. I do also reboot my main wifi router once a week at 4 am sunday morn.

The kasa switches are nice as they actually restore to last state (many i tested do NOT) after power outage, even though all main equip are on up's.. I also have schedules in them to turn on every few hours just in case the restore to last state fails for some reason.


That's where I really like the auto-on feature over the power restore. You have to find them in the detailed documentation, and set them using the Basic Z-Wave Tool (a user device - think it is detailed higher in this post if I recall). One of the Zooz plugs (the double plug) has it, along with this AEOTEC. Not all plugs, even from the same manufacturer, have it though.
They restore automatically whether turned off physically, digitally, through power-loss, etc. Have proven very reliable. As long as I'm connected somehow, I can just cycle the switch off, and it will come back on it's own. With your redundant network, that would be an easy manual reset option as long as your hub was still connected to your back-up network.

the hub is on the main network with a smt 1500 ups and a wifi switch, with about 5 hours of backup run time. Maybe i should put a second wifi switch on the backup network inline with the hub as well, but I forgo this as if the main wifi is down and the house is empty it doesnt really matter if i can reboot the hub or not!

the only thing with a wifi switch on the backup netowrk is my cable modem,main firewall router, and wifi router both on separate switches .

i actually had to have a neighbor come in and fix an issue recently.. one of the ups's battery died apparently even with monthly self tests .. There was no warning it just died.. luckly he saw main firewall router was down and just swapped which ups it was plugged in to and i swapped batteries when i got home.. I sent him a case of wine lol.

1 Like

Then it's probably easiest just with a simple wifi plug directly connected to your back-up network - assuming that has a separate wifi router. In fact you could stack two wifi plugs, one attached to each network, on other critical devices. Have to be careful with loops there when using automation, but for manual reset they would work well.

As long as the device you are cycling, is powered through a switch (plug) that is connected to your other wifi which isn't impacted by the power-cycle, you're in good shape. You could run it on both sides, each connected to the other network, if that makes sense. They will all come up together in the wifi control app, you just have to have them labeled accordingly to keep them straight.

Most wifi plugs (like I said, I found Gosund on Amazon, those have been reliable) have their own dedicated app, and I've found that works well for me to reset devices outside of HE or other automation networks.

I use them on my mother-in-law's Echo Show devices she uses to talk with my wife, when my wife can't get through to her. She's in assisted living, no compelling reason to set up a full automation HE network.

I revised my Network Reset routine above:

A couple points:

1 - current RM Cron trigger doesn't initialize automatically when changed under current firmware bravenel is aware and it will be fixed in the next major release.
This means when changing from the up-rate to the more frequent down-rate, the trigger stops working until you go in and open/save the CRON TRIGGER routine.

2 - I found that occasionally my network would return 0 responses (both internet, and local, modem ping) even though the network was not really completely down, which causes the routine to do a full power reset. Due to the current CRON problem (#1), this causes the routine to stop triggering. I added a repeat loop to run through a ping at 10 sec intervals a set number of times (user adjustable, I'm using 5). As soon as a valid ping is received then the loop completes. If it goes through all 5 without a valid response, then it goes through the reset routines. I have found this to be a much more stable routine.

Details of the changes are included here:

Addition of "PingAttempts" number variable and variable connector to set a user-selectable number of tries. A user selectable time variable could also be added, but I opted to just set it at 10 secs due to the formatting required to put a user variable input in the proper time format.

The only required routine change is to the NETWORK TEST actions. I've added a 10 second (stoppable) repeat loop around both the internet (external) and modem (internal) ping routines. A conditional checks for a valid response to jump out of the loop, where the previous conditional follows to check for an invalid response to conduct reset actions/increase ping frequency (down rate), etc.

The full NETWORK RESET actions are below with changes are identified in red.

Final version of the Network Reset routine is copied below.

Firmware 2.3.2 (currently .125) fixed the usage of the Cron Trigger with a variable that caused the rule to stop triggering above.

KEY POINT: You need to remove the CronReset virtual switch and Predicate (REQUIRED CONDITION) from the routines. With the current firmware the Cron Timer updates as designed and changes in the trigger timing are captured and continue working. Furthermore, I have found that using a REQUIRED CONDITION that stops and restarts the app during a change in the Cron periodicity is causing unpredictable results.


  • CronPingRate - STRING - used to set the Cron trigger
  • DownRate - NUMBER - minutes to ping when network is down
  • InternetTest - STRING - IP address for Internet Ping
  • ModemTest - STRING - IP address for internal network modem test (gateway)
  • PingAttempts - NUMBER - number of cycles to check network down before resetting network and registering as DOWN.
  • PingLoss - NUMBER - value returned from Ping (100 = 100% loss; 0 = 0% loss)
  • PingRate - NUMBER - minutes in current Cron Trigger timer (set to either UPRATE or DOWNRATE)
  • PingText - STRING - full response from Ping
  • UpRate - NUMBER - minutes to check when network is up

CRON TRIGGER - Triggers the test based on a Cron timer

CRON UPDATE - Updates the Cron Timer when Network tests up or down

![Screen Shot 2022-06-12 at 4.12.56 PM|607x500]

CABLE MODEM RESET - Resets the Modem

INTERNET TEST - Ping Routine


Virtual Switches. The following virtual switches are used:

Auto Reset - Used as a predicate to suspend the rules when auto-action is not desired.

Cable Modem Reset - Used as a manual trigger to reset the modem (cycles the power plug).

Internet Down / Modem Down - Two virtual switches to indicate the respective Pings was unsuccessful and trigger the reset routine.

Internet Ping - Virtual switch with 1 sec auto-off to trigger the Network Test routine. Used both manually, and by the Cron Trigger routine.

Network Down Simulator - simulates a loss of Internet as an added conditional in the Network Test routine, also disables the Cable Modem Reset routine through a predicate condition to avoid power cycling the modem. Used for testing.

Modem Reset Sim - when ON used with a conditional to bypass power cycling the modem plug to off. Used for testing.

Variable virtual switches are used for most of the Hub Variables to allow user modification through a dashboard.

1 Like