-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mqtt server doesn't work with DNS names, only IPs #266
Comments
I personally haven't observed this particular issue - I'm using a CNAME in my fork of this project and it works fine. That said, I've diverged a bit so YMMV 🤷. But I don't remember this ever being an issue.
How are you determining sluggishness? There's some inherent slowness just from the way the HTTP responses are built up in this project (for example, sending all the JS with every response).
I don't think that bug can be an issue for this project, because this project passes a string pointer that's kept in scope by a global (
|
Your fork looks cool! I'll check it out.
I mean, the HTTP response often times out. Like, something is occupying those ESP cycles rather aggressively. Under normal conditions the web UI loads in under 1 second.
Well, then please disregard that diagnosis. Specifically I have a pihole setup that assigns my mqtt server the inventive name of 'mqtt.local' |
@laviddichterman i have a similar setup, using pi-hole to provide local DNS. One thought is that using |
Hi! First of all, this project is great and thanks for doing it.
My issue: I can't use my DNS name for my mqtt server and instead need to enter the IP address. Not a huge deal, but the page should indicate that the IP address is required.
Additionally, in the case that the DNS name is used, the ESP board seems to get very sluggish. I assume this is from constantly retrying the MQTT connection?
Easy fix is just to indicate (or even validate) that the mqtt server input is an IP address.
Seems like this could be related to this issue in the underlying PubSub client library: knolleary/pubsubclient#375
The text was updated successfully, but these errors were encountered: