Debugging Full Private Server -- How to reset a Wio Node to move from global to private?

I’m trying to deploy a full private server locally, to help remove some timeouts that occur occasionally (I have weather sensors that I have deployed on 4 Wio Nodes).

I am running Raspbian on an X86 server (it’s an HP DL 360 G4P if anybody is interested, dual core Xenon but older generation). It took a bit to get the tool chain working and then a bit to get Apache configured properly for HTTPS.

But I’m now at the point where I’m ready to onboard a device. I was able to create a login via the app. The troubleshooting notes are non-existent for any of the personal server configurations… that’s a big area for improvement, btw.

Anyway, I’m trying to move one device from the global server to my new server. I cannot find any info that would show me the “correct-working-process” for this. There is no documentation for the reset button and how to use it to properly factory reset a node.

Do I have to remove it from the global server first?

Can someone point me towards the process to migrate a node?

Additionally – I have a couple of times been able to join the Wio Node AP (but not sure if it’s really fully reset). The App does ask me for the WiFi SSID and password. After that it says transmitting information, then when “contacting server” it times out with a connection error.

The light on the Wio Node is solid blue. Now I know this node worked on my WiFi network just fine, it was on it 5 min before I started this process…

And, trying to connect back to the global server give “Connection Error”

(the error messages in the Wio App suck… earlier when it couldn’t connect all it said was
“Sorry” with an OK button…)

I’ve tried to reset my password 3 times now. It says it changed it… but no luck going back either.

My customer experience (which until now has been good!) is now heading south fast…

Ok, I think I found a fix for the local problem. By setting the server info to be the IP address rather than a name (even though it should work with XXX.local ) I was able to onboard the node.

Still can’t connect to the global server though…

Ok, now on to compiling…

I selected the items to connect. (had to exit app since the “update firmware” button slide off the bottom of the screen…)

Now I get a wonderfully cryptic : [E 201111 17:44:04 handlers:1509] make: *** [Makefile:342: Main.cpp.o] Error 127

After looking in the user_build folder (where apparently the firmware gets built – after digging thru Python code to follow the build) I found that it wasn’t picking up the folder where the xtensa compiler pieces were.

I had to modify the Makefile.template and add the path to the GCC line:

GCC_PATH = /opt/esp-open-sdk/xtensa-lx106-elf/bin/

That’s my path, you’ll have to adjust accordingly. (again not documented).

Note – perhaps their tar file puts this in a different place that would be in the path somehow.
I had to build the xtensa packages by hand (as my box encountered a few of the known issues in building that as well) But note that the path instructions don’t seem to fix things. I’ve added the compiler path to root’s .profile, .bashrc and /etc/profile. None of which seem to get picked up by the build process.


In the set up instructions for the supervisor, it ASSUMES the the Wio software is in /root/wio. YET the check out would put it in the user home directory under Wio_Link.
I ended up moving what got checked out into /root/wio. It’s unclear what user this stuff needs to run as (but with this configuration file, one would assume that it’s as root…but again not documented).


In the esp8266_sdk/tools, the script assumes that xtensa-lx106-elf-nm is in the path somewhere as well. Again, had to add a path prefix.

if os.getenv(‘COMPILE’)==‘gcc’ :
#cmd = ‘xtensa-lx106-elf-nm -g ’ + elf_file + ’ >’
cmd = ‘/opt/esp-open-sdk/xtensa-lx106-elf/bin/xtensa-lx106-elf-nm -g ’ + elf_file + ’ >’

Now with all of this, I am able to compile and deploy firmware to the WIo Node.


The ‘View API’ button show NO responses.

But if I use Postman and post the example URL’s I see proper data coming back.

That’s the next thing to figure out…

I think the app has a bug, I think it’s now scrolling down in the response window to show the actual text response. For some strange reason, it has split the text from the URL which adds a line of text.