These are chat archives for esp8266/Arduino

16th
Jul 2016
Stavros Korokithakis
@skorokithakis
Jul 16 2016 03:10 UTC
finally, i finished my HTTP OTA server:
you can run that, drop a file called myproject-5.bin into the directory, and all your HTTP OTA ESPs will update to version 5 next time they run
Brendan Smith
@brendanheyu
Jul 16 2016 04:26 UTC
Stavros - so tempted to give It a try. I need to be able to get each of my esp units to come up with a unique identifier (hostname, room, something) so that i can use that unique id in the topic path when talking to Mqtt server. Any pointers? Having a fleet of ESP units with the same code base would be a dream!
Clemens Kirchgatterer
@everslick
Jul 16 2016 08:37 UTC
@brendanheyu do you mean some kind of scheme to build your topic string? there are a view proposals for a quasi standard AFAIK.
Pablo2048
@Pablo2048
Jul 16 2016 08:46 UTC
@brendanheyu Only unique thing, that is already present in ESP8266 is MAC address. So why not using it?
andig
@andig
Jul 16 2016 08:52 UTC
I'm using the chip id plus mac address mangled by md5 has unique id, see andig/vzero for an example
afaik though chip id itself is alteady derived from the mac so thats where the real uniqueness sits
Ivan Grokhotkov
@igrr
Jul 16 2016 08:54 UTC
other way around, actually. MACs (softAP and STA) are derived from chip id.
andig
@andig
Jul 16 2016 08:55 UTC
;)
Clemens Kirchgatterer
@everslick
Jul 16 2016 09:06 UTC
@skorokithakis your ESPOTA-SERVER looks promising, but I find the version number format rather limiting, as the 3 part version string (maj.min.patch) is very common. do you have any plans supporting that as well?
Stavros Korokithakis
@skorokithakis
Jul 16 2016 09:17 UTC
@everslick sure, later on
Clemens Kirchgatterer
@everslick
Jul 16 2016 10:26 UTC
great. keep us posted!
Clemens Kirchgatterer
@everslick
Jul 16 2016 11:22 UTC
@me-no-dev is there any decision on how to deal with sockets that are in TIME_WAIT state, yet?
Ivan Grokhotkov
@igrr
Jul 16 2016 11:51 UTC
@everslick see #2260
with some luck, same change will be added to ESP_IOT_SDK (for all the folks who use xcc-compiled LwIP)
Clemens Kirchgatterer
@everslick
Jul 16 2016 11:54 UTC
ah fine, thx!
Clemens Kirchgatterer
@everslick
Jul 16 2016 12:15 UTC
@igrr we once talked about udp->endPacket(); silently dropping packets if it does overflow the internal send buffer. has there been any change on returning an error?
Clemens Kirchgatterer
@everslick
Jul 16 2016 13:05 UTC
looks like nothing has changed in that regard, so i opened an issue for that.
Ivan Grokhotkov
@igrr
Jul 16 2016 13:09 UTC
Okay
nothing has changed, I don't think this will be fixed soon, as the changes required are pretty massive.
This is something I have on my enhancement list for net80211 refactoring, but right now this is kinda low priority because of esp32 release.
Ivan Grokhotkov
@igrr
Jul 16 2016 13:54 UTC
There's a hacky way to fix this I think, may be good enough for some use cases. But with the current design it's hard to guarantee upfront that the packet will be sent.
Clemens Kirchgatterer
@everslick
Jul 16 2016 14:00 UTC
still maybe not as hacky as my delay(3); every time a send a packet! ;-)
especially because it 'kills' async readyness.
Ivan Grokhotkov
@igrr
Jul 16 2016 14:13 UTC
But doesn't your protocol tolerate packet loss?
Or you assume that delivery is guaranteed?
Clemens Kirchgatterer
@everslick
Jul 16 2016 14:20 UTC
i send debug log lines. so i don't mind if one in a thousand lines is lost. but in certain situations i send about 20 lines really fast, and then only 3 of them arrive.
because they didn't ever make it to the network
Ivan Grokhotkov
@igrr
Jul 16 2016 14:22 UTC
So what are you going to do if send returns false?
Clemens Kirchgatterer
@everslick
Jul 16 2016 14:23 UTC
wait a little and retry
Ivan Grokhotkov
@igrr
Jul 16 2016 14:23 UTC
So you have a place to store the lines which failed to be sent, right?
Clemens Kirchgatterer
@everslick
Jul 16 2016 14:24 UTC
yes
Ivan Grokhotkov
@igrr
Jul 16 2016 14:24 UTC
In that case you can do if (millis()-lastMillis < 3) goto fail;
Clemens Kirchgatterer
@everslick
Jul 16 2016 14:24 UTC
i queue them up and on each main loop iteration i try to send tehm
Ivan Grokhotkov
@igrr
Jul 16 2016 14:25 UTC
And that will make you a sync ready
Same hack, but no blocking.
Clemens Kirchgatterer
@everslick
Jul 16 2016 14:28 UTC
ok, that at least will get rid of the delay for now.
Clemens Kirchgatterer
@everslick
Jul 16 2016 14:59 UTC
that has the benefit that i can even relax the timing a little bit and only send every 10 ms.
ok, i can live with that workaround. thanks @igrr ! :)
Sergey Anisimov
@anisimovsergey
Jul 16 2016 15:02 UTC
Hi @igrr. Do you think it's a good idea to add an event handler to ESP8266WiFiScan so that in the async mode one can receive a notification when the scan is done?
Clemens Kirchgatterer
@everslick
Jul 16 2016 15:11 UTC
there is already a async scan IIRC
Sergey Anisimov
@anisimovsergey
Jul 16 2016 15:12 UTC
IIRC?
Clemens Kirchgatterer
@everslick
Jul 16 2016 15:12 UTC
int8_t scanNetworks(bool async = false, bool show_hidden = false);
IIRC = if i remember correctly
Sergey Anisimov
@anisimovsergey
Jul 16 2016 15:13 UTC
Ah! thanks! Yes it is there
but there is no event when it is completed
I don't want to pull it
I could've gone ahead and implement it but the readme says that it's better to discuss it first here
Clemens Kirchgatterer
@everslick
Jul 16 2016 15:17 UTC
you are right, no callback
one has to poll int8_t ESP8266WiFiScanClass::scanComplete()
Sergey Anisimov
@anisimovsergey
Jul 16 2016 15:18 UTC
exactly but I'd prefer an event
Ivan Grokhotkov
@igrr
Jul 16 2016 15:20 UTC
if you can make a pull request adding void scanNetworks(std::function<void(int)> onComplete);, that will be great. callback function should take number of networks found as an argument
ah, also needs to take bool show_hidden
Sergey Anisimov
@anisimovsergey
Jul 16 2016 15:21 UTC
thanks! I'll do it
ok
np
Ivan Grokhotkov
@igrr
Jul 16 2016 16:41 UTC
@anisimovsergey let it be called scanNetworks, it's kinda obvious that it's async given the arguments...
another problem — you aren't resetting _onComplete member after the call, which means that if you first call an async version and then the blocking version, async callback will be called.
in std::function<void(int)> ESP8266WiFiScanClass::_onComplete = nullptr;
=nullptr is not needed. std::function is empty by default.
apart from that, looks good to me!
Sergey Anisimov
@anisimovsergey
Jul 16 2016 17:48 UTC
Yeah, it was initial intent too to call it scanNetworks, but unfortunately overloading on std::function has some issues.
the compiler is struggling to match the parameters in this case
regarding the sync call, yes I probably should reset it after the call but actually it won't be called in case of the sync call anyway because I'm checking the type of the call before invoking the handler
This message was deleted
Sergey Anisimov
@anisimovsergey
Jul 16 2016 17:55 UTC
if(!ESP8266WiFiScanClass::_scanAsync) {
    esp_schedule();
} else if (ESP8266WiFiScanClass::_onComplete) {
    ESP8266WiFiScanClass::_onComplete(...);
}
But I'm happy to remove the = nullptr and set _onComplete to nullptr after the event propagation.
Sergey Anisimov
@anisimovsergey
Jul 16 2016 19:31 UTC
I recreated the pull request but I'm still not sure how to crate overloaded scanNetworks with std::function<void(int)> as the first parameter. It seems not possible but if you know how, please give me a hint.