Welcome • User Guide
ToS • Privacy • Canary
Donate • Bugs • License

©2026 Poal.co

789

So I picked myself up a shiny new Arduino WiFi Rev2 and updated the firmware to the latest 1.2.8.

Trying out some simple sketches. I'd like to set the hostname for my sketch so I use the example:

WiFi.setHostname(“MyArduino”); // attempt to connect to Wifi network: while (status != WL_CONNECTED) { Serial.print("Attempting to connect to SSID: "); Serial.println(ssid); // Connect to WPA/WPA2 network. Change this line if using open or WEP network: status = WiFi.begin(ssid, pass); // wait 10 seconds for connection: delay(10000); }

Of course, the hostname as reported by the router never changes, it's aways "arduino-abcd" with the abcd being the MAC. That's not a deal breaker, but it looks like Arduino has had some problems with this for a while. Anyone use these and get this to work?

edit: Don't suggest I use ESP stuff instead. Those have serious issues with RF noise, and they're not good for my applications.

So I picked myself up a shiny new Arduino WiFi Rev2 and updated the firmware to the latest 1.2.8. Trying out some simple sketches. I'd like to set the hostname for my sketch so I use the example: ` WiFi.setHostname(“MyArduino”); // attempt to connect to Wifi network: while (status != WL_CONNECTED) { Serial.print("Attempting to connect to SSID: "); Serial.println(ssid); // Connect to WPA/WPA2 network. Change this line if using open or WEP network: status = WiFi.begin(ssid, pass); // wait 10 seconds for connection: delay(10000); } ` Of course, the hostname as reported by the router never changes, it's aways "arduino-abcd" with the abcd being the MAC. That's not a deal breaker, but it looks like Arduino has had some problems with this for a while. Anyone use these and get this to work? edit: Don't suggest I use ESP stuff instead. Those have serious issues with RF noise, and they're not good for my applications.

(post is archived)

[–] • 1 pt

try going a layer deeper with tcpip_adapter_set_hostname or try the newer netif APIs with somehting like

my_netif = esp_netif_create_default_wifi_sta(); esp_netif_set_hostname(my_netif, "MyArduino");

edit: not an expert here, but it seems worth trying

[–] • 1 pt (edited )

That only sets the hostname for dhcp. Once dhcp knows something of it, it should work a little better. The esp uCs support mdns which allows for better naming without dhcp or DNS infrastructure. Whereby you can connect with xxx.local. So long as you have a multicast resolver and on the same segment, everything works.

setHostname() Description Sets the hostname of the module, the hostname is sent in WiFi.begin(...) when an IP address is requested from a DHCP server.

[–] • 1 pt (edited )

This ins't an ESP chipset. The device gets a DHCP address, and should, according to bugfixes, set the active hostname as seen by the router. There are various bug reports from firmware dating back a year stating that it won't.

I assume they either broke it again or didn't fix it in the first place.

[–] • 1 pt

Yes, I understand it's not an esp. That's why I suggested looking into them. Their RF stacks are very mature. Which sadly, isn't the case with the arduino core stuff.

One of the issues here is you can't set a hostname without DHCP and DDNS support, unless you use mDNS. If you set a hostname and don't have DDNS support at your DHCP server, the hostname has no visibility. Locally, you're likely addressing the interface as 0.0.0.0 (any), a specific IP, or loopback.

Additionally, a DHCP server is free to ignore the requested hostname. Especially if it does not have a static configuration. Meaning, device says I want info for myname. DHCP server says, the IP for myname is 1.2.3.4. Assuming you also have DDNS functioning with your DHCP server, you can now resolve myname to 1.2.3.4. Which means the device should also have visibility of the name.

There are many factors which can effect what you're seeing. As you acknolwedge, potential bugs may also be a factor. Which is why for networking, I encourage you to look at the esp stuff. Even the older esp8266 in one of the tiny form factors is a very useful addon for otherwise normal arduino projects.

The other advantage of the esp stuff is you can run freertos without the arduino layers, if you're so inclined. This provides lower level access to much functionality, in addition to multitasking and synchronization primitives. While also providing a smaller footprint. The esp devices also have nice flash footprints, which allows for useful web serving and so on.

[–] • 1 pt

Her's what I know about the situation:

The device providing the response to the DHCP request is very good about accepting the hostname in the request, the only time I've found that it will not is if the request is malformed. HOWEVER, the arduino is providing a hostname, that of "arduino-xxxx" so whatever is sending that request (The ublox wifi device) is ignoring the code telling it to change this hostname. This problem was acknowledged in issues raised several firmware revs ago, and was slated as "to be fixed in the next revision." Apparently, it was not.

I've done some intensive development with ESP devices - I had a project where there was a need for a cheap, deployable temp/humidity sensor that would work off of something like an old cellphone charger. This worked, but I rapidly found out the ESP has two big problems:

1 - They had a hard time maintaining communication with bit-banged devices. Never could get this to work properly, I assume it was both the device and the chipset because some would work forever, others would drop comm in a day.

2 - They're VERY noisy. The ESP family spews massive amount of radio interference at 318MHz. This is problematic because many commercial radio devices such as garage door openers operate at 320MHz. With no filtering on the input, the noise emitted by the ESP devices is wideband enough that it kills the signal to the other device. 5 ESP8266 deployed in a 100 foot radius is enough to kill any chance of a 320MHz device operating. A single ESP32 device within 10 feet of my home garage door opener pegs the receive LED signal strength indicator.

I had to abandon these devices as it killed both my customer's systems, and some of the ones in my home area. This wasn't limited to just the -01, I tried 01, 02, 03, 07, and 12. They simply are junk if you're expecting a quiet device.

The ESP family is a great, cheap system, but with that system you have some serious issues that more expensive and better-refined devices don't have. I have a box full of 1s, 2s, and 3s that I've been selling off over the past two years, I'm just about out of them.

[–] • 0 pt (edited )

ESP32s are pretty cool and cheap (~$10). Builtin wifi and bluetooth. Can run at 3v on a LiFePo4 battery. About 100-200ma. Good API. They have LORA ESP32 boards for 1km+ communication for $25 which you can use to connect to the LORA Wan for when the SHTF and you need to setup a low-bandwidth encrypted messaging grid in your general area.

https://www.amazon.com/MakerFocus-Development-Bluetooth-0-96inch-Display/dp/B076MSLFC9/

The new Atmel chips are pretty low in the power consumption department, but once you start adding wifi and other useful peripherals the CPU eats up less of the overall power consumption pie.

ESP32-CAM is also pretty decent if you have a project that required low power and lowish-res video.

This guy is pretty good in the SOC department: https://odysee.com/@AndreasSpiess:2

[–] • 1 pt (edited )

ESP32s also have a problem (like their 8266 cousin) in which they spew out wideband noise right around 318MHz. Since there are things that operate at 320MHz, including my garage door operator, they're absolutely useless for me. This is leaking out of every spot on the device, including the antenna.

I designed a whole range of 8266 devices before figuring out that it was killing everything that ran in the 320MHz area. The Arduino WiFi is expensive, yes, but it's a much better chipset when trying to play nice with other radio-operated devices.