Ethernet AC switch

Frequently it’s required to have some way to know whether or not you have AC power, or whether you’re on battery. A common trick on Mikrotik is to monitor the input voltage. When, however, you have a good DC UPS rather than running straight off the batteries this hack simply isn’t available (of course a really good unit will have SNMP and traps hopefully), or if you have some other router which can’t provide you the input voltage.

Enters the Ethernet AC switch, backed by an AC relay.

The idea is very simple. Most routers gives us the ability to either poll, or potentially have trigger events when link comes up/goes down (we can fake the events by polling, Mikrotik, others have asked as well, but an event for link up/down even on Ethernet would be great!).

This may not look like much, and currently, the AC pins aren’t connected. Essentially what you’re seeing is a very simple relay, that when AC is applied to the two large pins towards the top, will close PIN 1/3 and PIN 2/6 independently on the (B-standard crimped) RJ45.

This works because the ethernet port will detect link on itself. You can test this by taking an RJ45 and building a “loop” (10/100Mbps only) whereby you loop PIN1 (striped orange) back to PIN3 (striped green), and PIN2 (solid orange) back to PIN6 (solid green). You will note these are the same pairs that gets swapped around in a standard cross-over cable.

IMPORTANT: This port should not form part of some bridge, or have any other configs associated with it. Any traffic egressing this port, will ingress back on the same port. Which can cause other problem. Fortunately we’re not interested in doing this, we merely care about whether we have AC power or not.

In my case I’ve just plugged this into ether4 on a Mikrotik RB951 (and used the force switch – in yellow in the picture to switch between the AC applied / not applied states). Then this is scripted for the scheduler for running every minute (yea, this means you can miss short lived events, but frankly, for my use case I don’t particularly care, in Mikrotik you can probably close the gap a bit, but frankly, even every 5 minutes is probably fine seeing that the UPS will give us somewhere between 4 and 6 hours).

:global acstate

:local port "ether4"

:local linkup [/interface ethernet get $port running]

:if ([:typeof $acstate] = "nothing") do={
# Inversion is to ensure that if you trigger
# notifications from state-change only it will trigger
# on first run
    :global acstate (!$linkup)
}

:if ($linkup) do={
    :put "Link is up"
    :if (!$acstate) do={
        :put "Link was previously down"
    }
} else={
    :put "Link is down"
    if ($acstate) do={
        :put "Link was previously up"
    }
}

:global acstate $linkup

Running this by hand (from an initial down state, with global environment cleared):

[admin@uls-jkroon-home] /system script> environment print 
 # NAME               VALUE                                                                        
[admin@uls-jkroon-home] /system script> run ac_check 
Link is down
Link was previously up
[admin@uls-jkroon-home] /system script> run ac_check 
Link is down

# Flip the switch to "on"

[admin@uls-jkroon-home] /system script> run ac_check 
Link is up
Link was previously down
[admin@uls-jkroon-home] /system script> run ac_check 
Link is up

# Flip the switch to "off"

[admin@uls-jkroon-home] /system script> run ac_check 
Link is down
Link was previously up
[admin@uls-jkroon-home] /system script> run ac_check 
Link is down

NOTE: I don’t know the reason why, but I did have to remove 1G seeds from Auto Negotiation for the off=>on direction to work reliably. Probably my soldering skills aren’t great (no surprises there). I decided just don’t take chances in production, and I will be disabling auto-negotiation on these ports completely, and forcing them to 10Mbps half. Reasoning being with this being VERY MUCH a hack to begin with we may just as well avoid higher clock frequencies that may cause oddities, after all, we only really want a 1-bit status.

One other question that may well crop up is the question about buttons. This would require us to drill into the chassis to put through a pair of signal wires, and solder onto the board. Warranty instant void. We don’t believe we should pick up such trouble with the above “solution”. Plus as far as we could determine we only get a “button was pressed” script, not a pair of “depressed” and “released” scripts. And this is less effort.

Comments are closed.