This is not a secure way to communicate. There are many things that can go wrong.
Like mentioned before, if you can, just use a TLS connection. You should be able to use the same certificate you use for your HTTPS server. So just get a websocket server that supports TLS and you're done. However, I want to focus on your question about using AES, and go through some basic attacks.
Taking a look at the websocket handshake, we see that some data is always the same (like "HTTP/1.1 101 Switching Protocols"):
This allows for known plaintext attacks. For example, an attacker knows that that specific plaintext is converted to the observed ciphertext. Also, you're schema doesn't seem to protect against replay attacks, where I re-send some observed packet.
AES is a block cipher that converts a plaintext block of data to a ciphertext block of the same length. There are multiple ways to send a bunch of blocks over the line. See:
The most simple is ECB. Here you just send block after block. This means that any block that contains the same plaintext will contain the same ciphertext. So if I know the plaintext for some ciphertext block, and I see the same ciphertext somewhere else, I know that it contains the same plaintext. Also, with ECB, an attacker can also just exchange one block for another, which will exchange the plaintext blocks after decryption.
A more common use of block chaining is CBC. This will chain blocks together with an IV, such that no two plaintext blocks (or bunch of blocks) will turn into the same ciphertext blocks. However, this is also full of danger. If you look closely at the decryption schema for CBC, you can see that xor'ing a byte in a ciphertext block will result in an xor of the same value for the plaintext one block after that. There are all types of bitflipping attacks and things you can do. Also, if the server responds differently when AES padding is correct or not, parts of the plaintext can be recovered with a padding oracle attack.
The above attacks work because I don't see anything about integrity checking (with an HMAC for example) that doesn't prevent an attacker from tampering with the ciphertext.
These are just some examples of things that can go wrong. Also check out timing attacks if you want to get into it and are looking for some cool reads. Please don't implement your own crypto.
And aside from getting the password on the device like Mike mentioned, I see great trouble in letting users chose a password for encrypting data. Without some key expansion algorithm, I might just brute force the password for some ciphertext.