HowTo: Ubiquiti mFi mPower

Ubiquiti recently made their 3 port mFi mPower (EU plug only) available in Europe. It provides 3 plug sockets that can be controlled via WiFi using their freely downloadable mFi controller software. Setup is fairly straight forward.

In the first instance the mPower becomes an access point that you can connect your PC/Laptop or in my case my mobile phone to. The access point will have the name of mFi followed by the last 3 octets of its MAC address. There’s no encryption of password required to connect at this point.

Then it’s simply a case of opening your browser and typing http://config.mfi into the address bar.

If your own WiFi network does not appear in the drop down list you can click rescan to attempt to find it. Once you’ve selected your network, and provided any login details for it, you can provide information about your controller, more correctly the PC that it’s running on.

Once again, this mFi device is running linux and this gives us a little scope for having a hack about. The areas of the file system we’re most likely to be interested in are /proc/gpio and /proc/power

# ls /proc/gpio/
antenna          athr_val         input_control    led_status
athr_reg         counter_control  led_freq         output_control

To find out the state of the LED we can simply cat led_status, not only does it tell us the current status but it also tells us how to change it.

# cat /proc/gpio/led_status 
1 (0=OFF, 1=BLUE, 2=YELLOW, 3=BOTH, 4=ALTERNATE)

A simple echo value to the led_status will change it for us, for example

 echo 3 > /proc/gpio/led_status

will give us an orange led. You’ll probably notice, if you haven’t started up your controller that the led will be flashing orange. That’s where the led_freq comes in.

 echo 0 > /proc/gpio/led_freq

The LED will stop flashing. If you replace the 0 (zero) with a value somewhere between 0 and 7 you’ll see the rate of flash change. Although 7 is going to look pretty much like it’s not flashing to most people.

As mentioned, /proc/power is the other area of the file system that we are interested

# ls /proc/power/
active_pwr1      energy_sum3      raw_active_pwr2  reset1
active_pwr2      i_rms1           raw_active_pwr3  reset2
active_pwr3      i_rms2           raw_i_rms1       reset3
cf_count1        i_rms3           raw_i_rms2       target_pwr1
cf_count2        meter_constant1  raw_i_rms3       target_pwr2
cf_count3        meter_constant2  raw_target_pwr1  target_pwr3
clear_ae1        meter_constant3  raw_target_pwr2  v_rms1
clear_ae2        outlet1          raw_target_pwr3  v_rms2
clear_ae3        outlet2          raw_v_rms1       v_rms3
enabled1         outlet3          raw_v_rms2       w_pulse1
enabled2         pf1              raw_v_rms3       w_pulse2
enabled3         pf2              relay1           w_pulse3
energy_sum1      pf3              relay2
energy_sum2      raw_active_pwr1  relay3

and straight off (no pun intended) we can find out the status or the relays

# cat /proc/power/relay3
1   (relay.3) on

Similar to the LED status, we are being told that this relay is on. To turn it off, as expected

 cat echo 0 > /proc/power/relay3

The physical sockets are numbered so it’s straight forward to identify which relay controls which socket. If you cat most of the other files, even with the relay on you’re going to be a little disappointed because all the values are 0.

# cat /proc/power/active_pwr3
0.0

# cat /proc/power/i_rms3
0.0

# cat /proc/power/v_rms3
0.0

# cat /proc/power/w_pulse3
0

# cat /proc/power/energy_sum3
0.0

There’s a little trick, have a look at the enabled1, enabled2 and enabled3 files,

# cat /proc/power/enabled1 
0   (Power.1) off

# cat /proc/power/enabled2
0   (Power.2) off

# cat /proc/power/enabled3
0   (Power.3) off

They all say off. Even if your relay is on, these will say off. So, turn them on.

# echo 1 > /proc/power/enabled3

# cat /proc/power/enabled3
1   (Power.3) on

Leave it for a minute or two with something plugged in to the socket and then have a look

# cat /proc/power/energy_sum3
0.9375

# cat /proc/power/v_rms3
239.908245801

If you take a look at the outlet files, which appear to be a summary of the individual socket ones,

# cat /proc/power/outlet3
Time       = 4411912
callbackT  = 5
v_rms      = 0x3c089a0c
i_rms      = 0x26840
Active Pwr = 0xdd93b0
CF Count   = 0x3
Target Pwr = 0x20cb31ec
Meter Const= 0x6e1
W_PULSE    = 0x4c4b4

The downside of not using a controller is that you’ll need to echo 1 to each enable file for each socket at every boot. You can of course do this with ssh but you’d need to be sure the device was up. You can of course also control the relays over ssh

 ssh ubnt@ip-address-of-device -C 'echo 0 > /proc/power/relay3'

You might want to setup ssh with keys to make this more flexible and not prompt for a password or, if you’re not particularly bothered about security you could use expect, spawn and send. For example, here’s a little expect script to turn relay 3 on. Simply pass the ip address as the first parameter and the password as the second parameter.

#!/usr/bin/expect
#
# Set wait timeout
#
set timeout 5
#
# Make connection, pass ip of mPower to this script
#
spawn ssh [lindex $argv 0] -l ubnt
#
# wait for the password prompt
#
expect "password: "
#
# send password string, passed as 2nd parameter to this script.
# 
send [lindex $argv 1]
send "\r"
#
#
expect "#"
#
# turn on relay 3
#
send "echo 1 > /proc/power/relay3\r"
#
# disconnect from mPower...
#
expect "#"
send "exit\r"

You could use a similar script, for example, to cycle the power to your adsl modem if the connection dropped.