If you can have end-to-end TCP, then use end-to-end TLS (e.g. with HTTPS).
Don't reinvent the wheel, especially when it comes to cryptography — most people get it wrong. Unless the device is too resource-constrained to support TLS, if you get down to the level of AES, you're doing it wrong. #1 mistake is to encrypt and forget to authenticate — if you have an encrypted channel between your server and a man-in-the-middle, instead of an encrypted channel between your server and your device, then encryption hasn't provided any benefit. If you can't use TLS, make sure that whatever protocol you're using authenticates everything, and encrypts what needs to be confidential.
To use TLS securely, think about what guarantees you need to have, from the point of view of each participant. Generally the device needs to know that it's talking to the legitimate server. That means that it must check the server's certificate. The device must have the X.509 certificate of a certificate authority recorded as trusted; this requires storage that can't be modified by an attacker, but it doesn't require any confidentiality of the storage. Note that you shouldn't hard-code the server's certificate directly, because that wouldn't let you easily replace that certificate if it's compromised. Instead, the device stores the expected identity (host name) of the server, and the certificate of a certificate authority that guarantees that a certain public key belongs to the expected host name. Once again, don't reinvent the wheel, rely on the certificate checking provided by your TLS library or application.
If the server needs to know that it's talking to a legitimate client, then each client needs to have its own client certificate. That requires confidential storage on the client. Pass the client certificate to the TLS session opening function from your TLS library, or set it in the application configuration.
That takes care of securing the communication between your server and your device. If the mobile application can talk to the device directly (e.g. to allow disconnected operation while it's on the local wifi network), you need to first perform pairing between the smart switch and the mobile phone. Pairing means an exchange of keys, preferably an exchange of public keys if resources permit, otherwise an agreement of secret keys. The goal of this pairing is to ensure that each device knows who it's talking to.
You'll need to secure the control channel as well, whether it goes directly from the mobile device to the smart switch or via a server. Think about authorization: are there different levels of access to the switch, e.g. a control level that allows doing reconfiguration and a basic channel that just allows on/off switching? This is generally handled by an authentication step after establishing the secure channel (TLS if possible).
Another consideration is firmware updates. That's a tricky one: on the one hand, there's no such thing as absolute security, so you will have security patches to apply now and then. On the other hand, a firmware upgrade mechanism is a complex thing and might itself have bugs. At the very least, make sure that your firmware upgrades are signed. Relying purely on the security of the communication channel for upgrades is dodgy, because the trusted based for a secure channel is larger than for a static security verification, and sometimes you might want to apply firmware updates without a network connection. In addition to verifying the signature, ideally you should have some protection against rollback, so that an adversary can't just push an “update” to version 1 on a system running version 2 and then exploit the security hole that version 2 patched.
