Google OnHub: the best router I’ve ever owned

My review of the Google OnHub router, and some tips on setting up advanced options like port forwarding.

While in the US for a trip in October, I decided to pick up a Google OnHub router, which is only available in America, and has since been superseded by Google WiFi, also only available in America. There are two different routers available with this brand name – one made by ASUS, the other by TP-Link. I have the TP-Link model.

The OnHub is the best router I’ve ever owned. It’s channel-hopping and will seamlessly switch you between 2.4GHz and 5GHz with a single SSID. My desktop is two floors up from the router and its WiFi connection is solid (just as good as wired), which is really handy. The OnHub’s a little unique, in that there’s no web interface to its configuration – it’s all done within an app. This has its positives and negatives, and had made a lot of nerdy friends of mine shriek at the idea, but it certainly does make things easy. You can add other users to be a “manager” of the hub, which allows them to control it from the app too.

It’s important to note that the OnHub is only a router, not a modem. It only has an Ethernet port for connection in – no DSL/ADSL/VDSL, so you have to use a modem, or another router, plugged into the wall, then connect to that with an Ethernet cable. You can use it to connect directly to your ISP (still via the modem), but that doesn’t seem to be possible at the point of setup. It assumes you have already connected it to the internet at this point – it expects a working internet connection provided by your modem. But if you want to reconfigure it later, you can (that was an important step for me – port forwarding wasn’t possible until I reconfigured).

You start by installing the app, available for Android and iOS (the app is now Google WiFi), and you tell it you want to set up a new WiFi point. The whole setup is done from the app: you connect wirelessly to the hub, choose your SSID name and password and that’s about it. You then manage the hub from the app – via the internet, not via the LAN. So you can manage it remotely using your phone, but you cannot plug an Ethernet cable in and configure it in a browser. It’s a shame configuration is limited to the app – a browser-based version would be really useful – over the internet and locally. The app can tell you the status of your network while you’re away from home too:

I’ve always preferred a wired connection to wireless, as it tends to be faster, and way more reliable. But with the OnHub I’m more than happy not to have had to run Ethernet cables all over my house, because the speed and reliability are spot on – it wouldn’t be worth cabling. It’s also handy as I use a lot of Raspberry Pis day-to-day, and the Pi 3 and the new Pi Zero W both have decent 2.4GHz WiFi so I can easily connect to them without worrying about wiring them all up. This is also the perfect time to mention that the app shows you all the devices on your network, and their IP address (all in the 192.168.86.x range), which makes it easy to connect to a headless Pi I just plugged in:

It’s really easy to reserve IPs for your devices:

The one difficulty I had was with port forwarding. Now, in theory, this is dead simple. The app has a “port forwarding” option in the menu, and it’s completely intuitive. You have to reserve an IP for your device in order to set up port forwarding, but that’s no problem. Any rules I set up just didn’t seem to work, and I didn’t understand why.

Of course, searching online for help only gave me simple instructions using the app – exactly what I’d done. But I figured something was missing. Originally, I’d been using the Plusnet router from my ISP as the modem, and just connecting the OnHub to it directly, but of course this meant that the PlusNet router was handling port forwarding requests. I reconfigured this router into its “modem” mode – but still no luck. I replaced it with a simpler modem, the Netgear DM200. Annoyingly the DM200 had both modem-only and router+modem modes too, so I switched to modem mode and simply couldn’t get it to work.

It was suggested to me (thanks Dave) to see if the OnHub had a PPPoE mode, as that would allow me to configure it with my ISP’s login credentials. Setting up PPPoE mode wasn’t easy, as you have to take the OnHub offline to do it. But the key was that previously, the hub’s own WAN IP was a local IP, given by the Netgear modem, but that in order to deal with outside requests, needed to be an external IP. I needed to give it my ISP’s info.

I tried this, and ended up having to restart the setup procedure on both devices multiple times, but eventually, managed to get it sorted – and port forwarding worked at last! I then had a working SSH gateway, and online tortoise cam:

The app also lets you perform a speed test, both on your internet connection and WiFi speed, and you can see historical data on your average speed each day:

The OnHub only has a single Ethernet port for connecting another device, so if you need to connect more than one wired device, you’ll need a hub.

The OnHub is quite pricey, but you get one hell of a router. I paid about $125 for it. You can’t really buy them any more, but Google WiFi costs about the same. It’s not clear to me what the differences are. People say the WiFi is superior, but they seem to recommend you get 3 of them and mesh them – so 3x the price of the OnHub… but perhaps this isn’t absolutely necessary. If it’s anything like the OnHub then one will reach all corners of a regular sized house just fine.

Python and Raspberry Pi talk at FOSDEM

Earlier this month, I spoke on the Python track at FOSDEM 2017. My talk introduced the Raspberry Pi as a tool for physical computing and IoT to Python programmers in the free & open-source software community.

I talked about the Raspberry Pi Foundation’s mission, our education programmes, introduced the GPIO pinout, HATs, GPIO Zero, Remote GPIO, Picamera, Energenie, Sense HAT, Astro Pi and more. You can view the slides, and watch the video here:

Christmas Coding Challenge – Uno

During this Christmas break I decided to have a go at implementing the card game Uno in Python. It’s a fun and simple game for all ages, and the rules are easy to pick up and follow – but there’s quite a challenge in implementing the rules in a program! I spent a few hours over a few evenings working on it and now have a completed version, and wanted to share some of the interesting bits of the code.


Uno is played with a bespoke card deck (not a normal deck of playing cards). Uno cards have a colour and a card type (a number or a symbol). There are four regular colour cards, and there are special cards which are black.

Each player is dealt a hand of 7 cards, and they take turns to play a card, trying to become the first player to get rid of all their cards. A player can only play a card if it has the same colour or card type as the last played card. If they cannot play a regular card but have a special black card, this can be played instead. Some cards have consequences, such as the next player having to pick up extra cards, players skipping turns or reversing order of play.

Unit tests

I used a test-driven development (TDD) approach to further my progress in building up the game from simple isolated card logic all the way to simulating gameplay in a multi-player game. I used pytest for its ability to verify exceptions were raised, but otherwise simply used Python’s built-in assert statement.

An Uno Card

I started by writing some tests to check errors were thrown if you tried to create an invalid card, then proceeded to creating valid cards. The card was implemented as an UnoCard class, whose objects stored a colour and a card type.

Card rules

As well as validation on init, I added a method to determine whether a given card was playable on another card. The card playing rules are quite straightforward: you can place a card o

The deck

I started building up an UnoGame class, where a deck of UnoCard instances was created. The deck needed to contain a complete set of Uno cards, which I determined from this image on Wikipedia:

So it turns out there are digit cards 0-9 (and then 1-9 repeated) for each of the four colours, and two of each special card in each colour. There are also four of each of the two types of black cards.

I started by creating lists defining the colours and card types, and initially created the deck by combining these lists in a number of for-loops. However, I later refactored this to use product, repeat and chain from itertools in the standard library, which made it much neater:

color_cards = product(COLORS, COLOR_CARD_TYPES)
black_cards = product(repeat('black', 4), BLACK_CARD_TYPES)
all_cards = chain(color_cards, black_cards)
deck = [UnoCard(color, card_type) for color, card_type in all_cards]

The UnoGame’s deck was then simply a list containing UnoCard objects.


In order for there to be a game, there needed to be players. I made UnoGame initialise with a given number of players. This meant a new UnoPlayer class. Each player would be dealt a hand of 7 cards from the shuffled deck. But first, I wrote tests and made sure that an UnoPlayer object could be created with 7 cards, and couldn’t be created without them.


In order for gameplay to take place, I needed to work out how I would designate a player as being the currently active player (whose turn it is). My first thought was itertools.cycle – a handy tool for infinitely iterating over an iterable object like a list, and just starting back at the beginning of the list once all items have been exhausted. However, Uno has a reverse card, meaning the order of play can be reversed at any moment.

I thought it through, and decided to design a new ReversibleCycle class to implement something like a cycle which could be reversed, as specified by the Uno rules. It took me quite a while to figure this out exactly, and get all my tests passing, but I was quite happy with the implementation I ended up with. A tricky part was the edge-case of what happens if the first card drawn (not played by a player – just the starting card) is a reverse card. According to the rules, play will start with the player to the right of what would have been the first player (i.e. the last player). Otherwise, in normal circumstances, the first player will play first, naturally.

I implemented the class as an iterator, so you could loop over it or manually next() it. Example usage of my ReversibleCycle class:

>>> rc = ReversibleCycle(range(3))
>>> next(rc)
>>> next(rc)
>>> rc.reverse()
>>> next(rc)
>>> next(rc)

I wrote tests of the ReversibleCycle in an isolated fashion. It works with any iterable, and I simply created an attribute within my UnoGame class which referred to an instance of ReversibleCycle, where the iterable was a list of UnoPlayer objects. I used a property to make it easy to look up which was the current player at any given moment.

More gameplay

Back to testing the gameplay, now I had a working model for cycling through players, with the ability to reverse order of play once a reverse card was played, I tested that players could play cards only when it was their turn, and that they could only play valid cards. I then tested that players playing cards would cause the correct consequences (e.g. the next player picks up 2, the new current player is the right one if a skip/reverse/etc. card is played, and so on).

The winner

I began testing gameplay by allowing the deck not to be shuffled, so that I had a predictable, testable order of cards. Looking back, I should have used a random seed instead (thanks for the tip, Dave). I took this game all the way to a player being designated the winner and the game ending.

Automated play

I then proceeded to write some code, similar to my test code for the gameplay, which would automate play for all players, and end at some point declaring one of the players the winner. There was nothing clever about the way the players played – no strategy – I just determined whether they had any playable cards, and made them play the first playable one in their hand.


The last thing I did was to take the automated play code and embed it inside an AIUnoGame class, allowing for a single player to be controlled by the user using text input on request. The playable player would be shown their hand each round, and asked which card they would like to play. All actions of other players would be displayed (e.g. “Player 2 plays Red 5”, “Player 4 picks up 2”), and the winner would be declared as before. Again, nothing smart in the AI, but that’s something I may add later.


I had wondered when I started whether it would be feasible for me to create this as a GUI – a real visual playable game. I obviously wanted to start from a text-based interface, and get the logic of the game down before I worried about graphics, but again, it’s something I would like to look at next. I wonder if PyGame Zero or guizero would be suitable. Watch this space!

The code

You can find my code on GitHub.