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.
Do you have any info on how to interpret the contents of /proc/power/outletX ?
For example, I have this output:
MF.v1.2.3# cat /proc/power/outlet1
Time = 71582
callbackT = 4
v_rms = 0x1e53106f
i_rms = 0x6f8cf
Active Pwr = 0x103fff0
CF Count = 0x1
Target Pwr = 0x11def774
Meter Const= 0x3bf
W_PULSE = 0x4c4b4
How do I correlate v_rms hex value to the decimal value? (and so on for the other parameters too).
In addition, how often do these values get updated?
I am writing a standalone script for power measurement. Any information would be really helpful. Thanks!
I haven’t had the chance to sit down and look at this as yet, sorry