Web Thing - WIFI Create Hotspot

[Turgut Guneysu]

Hi John,

Thanks a bunch to you and Bernat for fixing the ESP8266 and ESP32 firmware. All devices started connecting without problems.

However, now that they are working, I discovered a strangeness with the HOTSPOT feature.

My Environment is:

• LENOVO Yoga 900 Laptop with Intel I7-6500 CPU @ 2.59Ghz
• WIN10 Home Edition 64bit
• INTEL Wireless adapter: dual band AC 8260

Normally, HOTSPOT settings have a hotspot_Name (SSID) and hotspot_Password, in addition to the connected HOST network related settings: SSID and Password of the actual Internet connectivity, for which a hotspot is created.

In Web Things, the “wifi create hotspot” block has the SSID and password parameters. But these are used to connect to the HOST Internet. And when the hotspot is activated with it’s address, it assumes the SAME NAME as the HOST SSID, yet with it’s own MAC address belonging to the 8266 device. This makes it NOT show on the networks WIFI Scan list in WINDOWS or on any phone. Or maybe it does show, but because the name is a duplicate of the original WIFI network, one cannot select it specifically.

The only way to gain visibility is to use a WIFI Analyzer type software, that is capable of showing all info. There one can see the dual AP’s with the same SSID but different MAC Addresses. However, a connection is NOT possible.

I believe this is in error.

In addition, if one uses an arbitrary SSID name and password for the “wifi create hotspot” block, then it does actually create a hotspot but NOT with the given credentials. In my case, my WEMOS ESP8266-12S resulted in an SSID of “ESP_23FDC8” (acquired the last 3 bytes of the MAC address) and my ESP8266MOD LOLIN resulted in an SSID of “ESP8266”. Both showed up on the WIFI Scans on the PC and Phone. However, neither was connected to anything else, as such it was NOT possible to reach Internet over the host Internet connectivity. Meaning, what is created is really NOT a hotspot, but a STANDALONE APP !

As a final desperate attempt, I tried to use the “wifi connect” block, hoping the created hotspot would access the HOST internet DNS and obtain an address to link to Internet. This did NOT work either, and actually deleted the hotspot and just created a regular WIFI connection with an IP address from the HOST Internet connectivity.

So, it is my belief that HOTSPOT feature is not correctly implemented.

‌

[José García]

Hi Turgut,

We had a similar issue and the problem was the password, it should have at least 8 characters long.

I hope this helps.

[Turgut Guneysu]

Hi José

Thanks for the password pointer. I tried it and it was a bit better. A hotspot with given name and password appeared and I could select it. However, there is no connection possible, as it never allocates an IP address. I still think it is a stand-alone hotspot, unaware of the HOST Internet connectivity details ! How else could it be, and where would it obtain the HOST info?

Still looking for a working solution.

[John Maloney]

I still think it is a stand-alone hotspot, unaware of the HOST Internet connectivity details ! How else could it be, and where would it obtain the HOST info?

You’re correct, the “create hotspot” block creates is a stand-alone, isolated network; it does not connect to another WiFi network or to the wider internet. It’s meant to be used is situations when there is no available WiFi you can use.

You should be able to see the SSID in the network list on your laptop. Selecting that network and typing the password should connect you to the board – but you’ll be cut off from the rest of the internet. However, the feature can be useful for stand-alone appliances that you only want to connect to once in a while.

Perhaps “hotspot” is a misleading name for that block. What’s a better name?

‌

[Turgut Guneysu]

My tests indicated no practical value to having this kind of connectivity. The created “thing”, whatever the name might be is not usable in any shape or form. Even if one connects to it and obtains an IP, there is nothing else to do, since it does not route to Internet. To make it really useful, one would have to provide a way to load HTML , but that would be too elaborate a code change, probably.

A more useful option would be as follows:

• IF THERE IS LOCAL INTERNET:
  Then configure it as a TRUE hotspot, where there needs to be two sets of network-id and password credentials. The first one for the Internet gateway side, the other for the hotspot itself. In this case, the WIFI routine used in the background would first login to the Internet gateway and obtain a local IP and become part of the REAL Internet network.
  Then on second stage, it would configure itself as a SoftAP and disclose another another set of IP address, as well as the second set of network SSID and password.
  Now, a user can actually see the real hotspot SSID and connect to it using the second set of credentials, and gain access to the Internet.
• IF THERE IS NO LOCAL INTERNET:
  In this case, the only useful functionality is to act as a local SoftAP, with its own DHCP Address set. Here it would also help a lot if there was a small web server defined on port 80 that displayed a simple “Hello from MicroBlocks!” type of HTML message. Any user who connected to this SoftAP would receive this message on the browser upon successful connectivity.
  By the way, this type of functionality is exactly what is offered in the Arduino world examples using the ESP family of boards (8266 & 32).

I looked at the code for the WIFI and HOTSPOT and saw that the credentials entered into the block were being used for both to login to the Internet and for the SoftAP creation. I think that part might be not quite right. Normally, one needs two sets of credentials at any rate. Even if there were to be NO SUPPORT for the actual Internet connectivity, things should operate as described in second point above.

I am enclosing a short code sample that shows a dual connectivity described in point one above:

/*
 * NodeMCU/ESP8266 act as AP (Access Point) and simplest Web Server
 * Connect to AP "arduino-er", password = "password"
 * Open browser, visit 192.168.4.1
 */
#include <ESP8266WiFi.h>
#include <WiFiClient.h> 
#include <ESP8266WebServer.h>

const char *ssid = "arduino-er";
const char *password = "password";

ESP8266WebServer server(80);

void handleRoot() {
    server.send(200, "text/html", "<h1>Hello! from arduino-er!</h1>");
}

char* htmlBody_help = "<h1>Help</h1><br/>\n"
  "Visit http://192.168.4.1/ to access web server.<br/>\n"
  "Visit http://192.168.4.1/help to access this page.<br/>\n";

void handleHelp(){
  server.send(200, "text/html", htmlBody_help);
}

void setup() {
    delay(1000);
    Serial.begin(9600);
    Serial.println();

    WiFi.softAP(ssid, password);

    IPAddress apip = WiFi.softAPIP();
    Serial.print("visit: \n");
    Serial.println(apip);
    server.on("/", handleRoot);
    server.on("/help", handleHelp);
    server.begin();
    Serial.println("HTTP server started");
}

void loop() {
    server.handleClient();
}

Hope this helps.

[John Maloney]

I agree, it would be great if an ESP board could both provide a hotspot AND be on a WiFi network that is connected to the internet. I don’t think that feature is supported by the ESP WiFi library, but I’d be delighted to be wrong about that!

Does the code you provided actually provide dual connectivity? I haven’t tried it, but reading the code It appears to me that it just implements a server that runs on it’s own, isolated network. As you said, in order to act as a bridge it would need two SSID’s and passwords and I only see one. Have you tried it?

In any case, Bernat or I will explore what’s possible.

An isolated hotspot does have use cases. One involves using a Raspberry Pi with a hardwired Ethernet connection as a bridge to the wider internet. Another is to supply an isolated network you can use to control a robot. Or, you might create your own WiFi network in a place that doesn’t have any internet to enable communication between WiFi-enabled MicroBlocks boards.

We’re looking into the ability to implement your own HTML web server in MicroBlocks. If it works, that would be another use case for an isolated network.

[Turgut Guneysu]

Sorry, you’re right. I provided the example for SoftAP with the built-in mini server responding to with the Hello message.

I’ll add the other one as well, or if you have access to the Arduino ESP8266 examples, it is there. And YES, I have used it and it works great as a SoftAP with ESP8266 and ESP32.

This will do:

https://github.com/martin-ger/esp_wifi_repeater

[John Maloney]

Cool! You can just post a link to the relevant Arduino ESP8266 example. Thanks!

[Turgut Guneysu]

Hi John,

I do not want to take up too much of your time, but could you expand on your answer above:

An isolated hotspot does have use cases. One involves using a Raspberry Pi with a hardwired Ethernet connection as a bridge to the wider internet. Another is to supply an isolated network you can use to control a robot. Or, you might create your own WiFi network in a place that doesn’t have any internet to enable communication between WiFi-enabled MicroBlocks boards.

I tried to understand the workings of the three functionalities you described. However, without any other commands in the microBlocks, I could not figure out how these would be possible. From what I saw in other implementations, one needs access to the WIFI libraries' internals to configure the various functionalities. And microBlocks does not have any, other than what is exposed in the blocks. It seems like there would have to be some messaging primitives to provide send/recv to Internet.

• Raspberry - I looked at https://www.raspberrypi.org/documentation/remote-access/
  This requires port forwarding or using a third-party service from Internet inbound, and routing and NAT outbound and for a WebServer would need code to support it.
• Isolated Robot Network - How would the message exchanges between the robot controller and the mBlocks hotspot occur. Currently, when activated it does not respond to anything.
• Network for WiFi-enabled MicroBlocks boards - This would require routing between many boards, as well as router functionality at the hub device. None of these controls are possible in microBlocks.

Am I missing something? Please don’t think that I am being obnoxious, just trying to comprehend the capabilities, so I can make use of them as well.

‌

[John Maloney]

Raspberry - I looked at https://www.raspberrypi.org/documentation/remote-access/
This requires port forwarding or using a third-party service from Internet inbound, and routing and NAT outbound and for a WebServer would need code to support it.

Since the Pi has separate network interfaces for WiFI and hardwired Ethernet, it can (in theory, at least) be connected to a WiFI hotspot provided by an ESP board while at the same time being connected to the outside internet via hardwired Ethernet. However, this may be tricker to set that up than I thought. See:

https://www.raspberrypi.org/forums/viewtopic.php?t=213957

It’s possible that the Mozilla WebThings gateway supports this mode, although I haven’t seen that feature documented anywhere.

Isolated Robot Network - How would the message exchanges between the robot controller and the mBlocks hotspot occur. Currently, when activated it does not respond to anything.

When you use the Web Thing library on an ESP board, the ESP board runs a little HTTP server. Here’s an example:

If you run this, you can connect your laptop to the “m5” network and view http://192.168.4.1 in the browser to see the “Thing” definition. You can read the current tilt value at http://192.168.4.1/properties/tilt. You could also interact with the Thing using Snap!, running Snap! from your local file system, since you’ll unable to reach the Snap! website while connected to the m5 network.

Your robot could be a “Thing” with properties such as “left wheel speed” and “right wheel speed” that you could control from a Snap! project.

Network for WiFi-enabled MicroBlocks boards - This would require routing between many boards, as well as router functionality at the hub device. None of these controls are possible in microBlocks.

In hotspot mode (or “access point” mode), an ESP32 acts like a WiFi router. See, for example:

https://randomnerdtutorials.com/esp32-access-point-ap-web-server/

So, you’d have one ESP board running the access point and all the others would connect to the WiFi network it provides. That would allow the other boards to talk to each other. It might take some cleverness for them to discover the IP address of the other boards, of course. This use case is not yet supported by MicroBlocks, but Bernat is working on adding some simple HTTP blocks that could be used.

[Turgut Guneysu]

Thank You John,

Using the M5 example, I was able to achieve a reasonable local server operation and communicate with it to/from SNAP!

However, there is one difference or (should I say glitch): The WebThings Library blocks that are loaded to SNAP to read and write to vars/properties etc do NOT function correctly if the destination is the HOTSPOT server (http://192.168.4.1). The info is still there but the built-in blocks do not retrieve it correctly unless the destination is the microBlocks Mozilla Server (http://localhost:6473).

One has to revise the “properties of thing” block to make the “set property” and “get property” blocks to work with the HOTSPOT version of data exchange.

Original “properties of WebThing@6473” with URL: http://localhost:6473

‌

My Rendition of “properties of Thing @HotSpot” with URL: http://192.168.4.1

‌

OR

One has to enable the Mozilla Web Thing Server on the microBlocks.

This second option has two caveats; one documented in issue #81: All WTS are using the same port number and unless there is only one device in use, one cannot utilize the second or nth devices.
And the other is, while the HOTSPOT works untethered to the PC, the WTS does not work unless the device is plugged into the PC.

I think I am going to stop commenting on this issue, until the network related changes are finalized by Bernard. I am occupying too much of your time with unfinished feature problems. When you notify that it’s done, I’ll go back and test.

‌

‌

[John Maloney]

Using the M5 example, I was able to achieve a reasonable local server operation and communicate with it to/from SNAP!

That’s great!

There is definitely a glitch. WTS was intended to be compatible with the Mozilla Web Thing protocol but apparently there are some differences.

Good idea to wait until Bernat has some time to look into this. FYI, he just bought a house but it needed work so he’s taking time to get it into livable shape so he and his family can move into it. Thus, it may be a few weeks before he has time to check into this.

Many thanks for doing all those experiments and uncovering a number of issues.

[John Maloney]

Bernat: I believe the issue is in netPrims. The hardwired MicroBlocks WiFi Thing server is not responding to the /properties path with a list of properties. Apparently the Gateway doesn’t need that feature. We could either implement that or change the Snap! library to extract the property list from the overall Thing description as Turgut’s code does.

[Bernat Romagosa]

Yep. I didn’t implement that endpoint. The right thing to do would be to strip netPrims from all this functionality and move it all to the library. I’m working on implementing the basic HTTP primitives now, so that’s a step in that direction

[Bernat Romagosa]

This should be fixed. Our friends at the Citilab have been using the hotspot feature for months now without a problem :)