A place users can post their projects. If you have a small project and would like your own dedicated place to post and have others chat about it then this is your spot.

User avatar
By DrG
#40014 Recently, I purchased an Orvibo S-20 WiFi Socket – ($18 and free shipping from the US) http://www.banggood.com/WiWo-S20-Wi-Fi-Smart-Remote-Control-Timing-Socket-USEU-Plug-p-953743.html


The socket is meant to be controlled by a free android app. Basically, you use the app to pair up the socket with your router and the android app can turn it on and off and set it to go on or off at certain times – those kinds of functions. Well, I was not terribly interested in the android app, although I did use to test whether the S-20 was functional because I did not want to go forward only to learn later that the one I had was defective. That part went smoothly, so forward on to the project.

I wanted to use an ESP8266 to act as the access point for the S-20, thereby eliminating the router completely. The hope was to have some inexpensive control of something plugged into the mains (for me that is the 120 V, 60 Hz, AC line). That line can be lethal, so being known to solder my fingers together on occasion; I thought it best to try an indirect route. Still, one needs to be very careful with the mains and you should read on at your own risk.

First off, a search of ESP8266 + Orvibo produced absolutely nothing for me to steal. I was truly surprised. But, a search for Orvibo produced a great deal of information that I found essential. So much so that I want to list some reference links at this point and encourage you to see how much has already been done with these WiFi Warts.

https://stikonas.eu/wordpress/2015/02/2 ... 20-socket/
https://www.domoticz.com/forum/viewtopi ... =11&t=8212
https://github.com/franc-carter/bauhn-w ... r/bauhn.pl

All of these references were helpful, but all of them assumed the standard, go-through-the-router, method. Nevertheless, they contained critical protocol information that was essential for what I wanted to do. So, as usual, others had done a lot of the work for me and were willing to share.

Basically, the steps I took were:

1. Pair the S-20 with an ESP8266 AP so that it would search for and connect to my ESP8266 AP instead of my normal router. This can be done through broadcast packets, but the easy way is to do it with the android app. First, change the name and password for your router (you will change it back when you are done). For my example code, I used a router name (ssid) of WIWO and a password of HIHO001. This also afforded me the opportunity to make sure that the S-20 was functional. The directions that came with the S-20 and in the app make this step a cinch. Once that pairing was accomplished, I changed the router back to its normal SSID and password and did not use it with the S-20 again.

From this point on, when the S-20 is plugged into an AC socket, it will search for a network ssid of WIWO and, if found, will try to log on with password HIHO001.

2. Next, I had to “discover” the S-20 by sending a specific packet using a UDP socket, port 10000 and a broadcast address. Sending multicast UDP packets was problematic and it took me a while to get it functional. At some point, there may have been a bug in the Arduino IDE or something similar as I read lots of reports of frustration getting multicast implemented. In the end, I think that I updated what I could and also used code in the project here https://www.hackster.io/rayburne/tardis ... gps-6b5d2a as a guide. It worked and the returning packet had useful information such as the MAC address of the S-20, which is needed to send commands.

When the ESP8266 is set up as an AP, it will default to an IP of Clients that connect are then assigned consecutive IP address. So, the first client is assigned, then and so on. Since I knew I was only using one S-20, I could make use of this information, although further processing beyond what is in the test code would need to be used if there were multiple devices that would all, if paired, send a response packet.

3. Now, I can “subscribe” the S-20 and, finally send it commands. The subscribe command contains the S-20 MAC address and other information (see the references) and is sent on a UDP socket to the S-20 IP address using port 10000. The return packet includes the device’s MAC address and the power state (on or off). The test code uses the simple “on” and “off” commands. Those commands are also sent as a UDP packet using port 10000 and differ only in the last byte (0 for off and 1 for on). There is a return packet, but my experience is that the return packet does NOT contain the power state as has been reported. I’m not sure what is going on there and I may have a newer version of the S-20 or, again, I may be doing something wrong. The return packet after a subscribe packet, however, does accurately contain the power state.

Every once in a while, the reply to a subscribe command would result in a much larger packet than normal. This confused me and still does (see screenshot below). Apparently, a discovery packet has been sent at these times instead of the normal reply to the subscribe command. I don’t know if the S-20 is indicating an error in this manner or whether I am missing something. As far as I can tell, however, it does not interfere with the “on” or “off” command that is subsequently sent.


That’s basically where I am at with the project and I have only scratched the surface of what the S-20 can, apparently do. The attached programs are 1) A simple discovery program and 2) a simple on/off program. If you have been struggling with ESP8266 and UDP, you might look at them for some guidance. I used the Arduino IDE (1.6.5) with the current staging version of the ESP8266 boards and 2.1.0-rc2 within the board manager. You will definitely need to consult the references on the S-20 to better understand the programs, but all-in-all, they seem to work ok for me. Be forewarned that I am using dedicated send and receive UDP sockets. This was the only way I could get it to work. If you can see what I am doing wrong that would allow the use of a single UDP socket for send and receive (which is what I always thought was the “correct” way), please do let me know.

My impressions of the S-20 are mixed. It uses an HF-LPB100 Wi-Fi chip and you can read all about that here (http://www.hi-flying.com/products_detai ... 5cf22.html). I didn’t take mine apart, but you can see some nice close up pics of what is inside here (http://blog.slange.co.uk/orvibo-s20-wifi-power-socket/). Notably, it uses an electromechanical relay – I guess I was hoping for an SSR.

Finally, and I think I deserve this, I am including the ubiquitous, gratuitous and just plain silly, movie of the board switching an, admittedly ugly, lamp, on and off here:https://vimeo.com/153624780 .


You do not have the required permissions to view the files attached to this post.
Last edited by DrG on Sat Jan 30, 2016 9:12 pm, edited 1 time in total.
User avatar
By DrG
lethe wrote:If you are using the ESP as AP, you probably could skip the discovery procedure. You can get the IPs & MACs of connected devices using wifi_softap_get_station_info() (and use the first 3 bytes of the MAC to filter for Orvibo devices).


You may not have noticed that the test code that I attached (OrviboDiscoveryTest.ino) in my initial post is using wifi_softap_get_station_info();

I would not suggest that anyone rely only on this routine and skip the discovery command as it is more definitive and it is the intended way to locate all devices capable of responding. No need for a shortcut.