mFI mPower basic use without cloud and controller

Updated 29 December 2014: With the latest software (currently 2.1.4) there is actually a decent, password-protected standalone web UI. I’d recommend you to factory reset the device, set it up from scratch, and set a new username and password from the web UI. You’ll still be able to log in over SSH and telnet, and while I no longer need to access the device directly, I’m sure most of the article below applies.

To upgrade from 1.x series software, which is what I had, you should use scp to upload the new firmware to /tmp/fwupdate.bin. To upgrade from 2.x series software, which has the nicer web UI, just use the web UI. Details.

Just to note: Of course, while I don’t need to use connectivity over terminal, this seems to be used by software such as this nice Android app. The app seems thirdparty (despite the ID being set to com.ubnt.mpower), so it would have been harder to put together if there was no terminal access. Heck, I can even envision management software using not much more than sshfs and ssh to manage a fleet of mPowers (if you happen to need and have such a fleet)…

Original text follows.


After getting the mFI mPower unit, I saw that it really wasn’t planned for standalone use. I was also surprised at seeing no ethernet port; I’m not sure why I thought it’s going to have one.

This is a wifi IP power strip that seems to be designed neither fully for a consumer (why would a consumer need a IP power strip?) nor for an expert. After plugging it in and waiting for it to boot, you’re greeted with a new completely unprotected wifi network. After connecting to it, you’re hijacked in the same way captive portals technologies work. It seems pretty painless to configure a device to connect to a wifi network, and then either to cloud or to a local controller — a chunk of proprietary software that, based on the quick guide booklet, seems to be written in Java. Booklet mentions versions for Windows and OS X, but the website offers download for Linux as well.

I’m however uninterested in having a home machine run 24/7 and waste electricity just to occasionally control a power strip. I opted for the (for obvious reasons less secure) variant of going into the cloud. Unfortunately, the built-in web UI doesn’t give you an option to register nor a hint on doing so. Quick guide does mention the website, which reveals a login panel but no registration.

At least I could configure wifi connectivity without either controller software or cloud — but that seems to be all.

That’s because in October 2013 the service was shut down for new registrations, with promises of coming back. Seeing that was 10 months ago, I began to think I may have purchased a brick.

Luckily, apart from what’s served to the customer on the surface, the device seems to be rather open. I’m unfamiliar with how free and open source it is, but it seems to be built out of relatively understandable components. BusyBox is there, the usual UNIX-like directory structure is there. I also spotted dropbear, which means aside from a telnet daemon, it’s also providing an SSH service.

Default username and password set is ubnt/ubnt. Ouch. First obstacle: How do we change that?

We can use vi to edit /tmp/system.cfg. There it is! Username and password. But wait — what kind of a password hash is that?

Turns out it’s the output of crypt(3). This gets used to generate /etc/passwd.

PHP has the crypt() function as well. PHP’s numerous flaws are irrelevant for such simple use case, so we’ll be forgiven for using:

php <<< '< ?php echo crypt("my_password", "SL");'

where “SL” is the salt. (In the stock password, it was “KQ”.)

You can add new users as well (although I’d highly advise changing at least the password of the default user), like so:

users.1.name=ubnt
users.1.password=KQiBBQ7dx8sx2
users.1.status=enabled
users.2.name=ivucica
users.2.password=AEPbWtbh7XaS.   
users.2.status=enabled

That’s really nice and flexible. But they could have either documented all this (and in an obvious place), or created a web UI (of course, while letting us deal directly through telnet and ssh, too).

To save these settings, punch in save. (Alternative command seems to be cfgmtd -f /tmp/system.cfg -w.) To give the system a chance to apply the settings, reboot.

While at it, you may want to disable the default unprotected wifi network, which for me was numbered 2:

wireless.2.status=disabled

What I also like in this device is that it seems to have the Linux-friendly Atheros chipset in it.

So next. How do we actually read stats or switch an outlet on or off?

cd /proc/power
# enable outlets we want to read stats from or that we want to control
for i in $(seq 1 3) ; do
  echo 1 > enabled${i}
done
# get current power usage
for i in $(seq 1 3) ; do
  echo "active_pwr$i: ${i}"
done
# turn off and on a slot
echo 0 > relay1
sleep 1
echo 1 > relay1

Other functionality is demonstrated and explained by forum member Sequim.

  • active_pwr – power factor corrected power demand
  • v_rms – RMS voltage – zero if outlet is off
  • i_rms – RMS current, as currently delivered
  • pf – power factor
  • energy_sum – totalized energy in Watt-hours delivered via this outlet, probably since last boot

And the /proc/led directory contains some nice controls for the LED.

Really lovely design. It’d have been even nicer if it had been properly documented and if it had a proper web UI shipped in case you don’t feel like dealing with all the power that these controls exposed as a filesystem provide.


via blog.vucica.net

4 thoughts on “mFI mPower basic use without cloud and controller

  1. BruhAtTheDesk

    So this is a very old thread, but I recently got my hands on one or two of these mFi products.

    Since the controller is EOL, would it not theoretically be possible to build your own controller and web UI that connects to these devices via telnet or SSH? I mean, these ports are open, and we can change the passwords as we choose.

    I am fairly new to this whole side of PC's and security and building stuff like this so I am asking as much as possible to learn as much as possible.

    Reply
    1. Ivan Vučica Post author

      Sorry for the delay in replying — I actually wrote a detailed response on the same day you asked, but I was unable to save it on the phone.

      > would it not theoretically be possible to build your own controller and web UI that connects to these devices via telnet or SSH?

      Yes, that's exactly what I'm doing.

      More specifically, I started off that way — a web UI that was SSHing "directly". I've since reworked this to have an intermediaty service sitting in-between — it happens to talk gRPC, but there's no real reason why it wouldn't be an HTTP-based API.

      The reason for the extra layer is because I plan on introducing additional frontends which will need to subscribe to updates from this intermediary; I want them to talk HomeKit and to talk to Samsung's SmartThings. The point is, they need to be notified when something flips the switch, so they can tell HomeKit/SmartThings that the switch was flipped.

      Reply
    1. Ivan Vučica Post author

      I ended up writing a Go binary that SSHes into the two powerstrips that I own, and interacts with the files in procfs. This binary then exposes a gRPC service which is usable by a web frontend — I didn't get around to generating an API via gRPC-Gateway, but I do have a hack that makes calls to display the current wattage and allows toggling the relay on and off. The SSH connections by the gRPC backend flow into my house via a persistent OpenVPN connection.

      This was all before I heard of Home Assistant and still runs well to this day. I never ended up looking into HA, simply because I still don't have anything that's open + low-enough in power usage that I'm willing to run it 24/7 in-house. Maybe this will finally change this year.

      Running mqtt binary on the device itself feels… unsupported. I already don't like even running the shell scripts I deployed on it. The thing that would make the most sense, were I to install some custom binaries on it, would be an upgraded SSH daemon; dropbear that runs on it is ridiculously outdated.

      Other notes:

      – I never got around to implementing a HomeKit frontend. Maybe it doesn't make sense to do it, if I will place Home Assistant in-between someday.
      – For a while, it looked like SmartThings (bought by Samsung) might be the thing I want to run, but I realized that in my current apartment, none of the sensors make sense to try to run. The hub still runs because of the whole kit, I only have one power outlet that I want to control with SmartThings. But it was enough for me to spend time writing a stack that exposes the aforementioned gRPC backend using SmartThings's "hooks" API.

      None of the aforementioned code is clean enough for me to be willing to go through the approvals with my employer to release it. Maybe someday.

      Reply

Leave a Reply

Your email address will not be published.

 

What is 11 + 13 ?
Please leave these two fields as-is:
IMPORTANT! To be able to proceed, you need to solve the following simple math (so we know that you are a human) :-)

This site uses Akismet to reduce spam. Learn how your comment data is processed.