Commit d15e1b0e [1] in the 2.0.0 pull request #4996 introduced a filter
to connect only to WiFi networks with a RSSI of -75 or better. This
results in strage behaviour, as a scan still shows networks, that can't
be connected to, even though with older versions, connecting to those
networks was possible and the connection (albeit slow) was stable.
Remove the RSSI filter for now by setting the threshold to -127, i.e.
the lowest possible value. Maybe in the future the filter threshold
could be exposed to users, to allow filtering out nearly unreachable
networks.
[1] github.com/espressif/arduino-esp32/pull/4996/commits/d15e1b0
When iterating through APlist from first to the last element, a corrected password for already known SSID is not used. Therefore, I propose to iterate from the back of the list. With iterating from the back through the vector, an already known SSID with a corrected password is used instead.
Proposed fix to #4627 as a remediation to PR #3995#3995 introduced that a device detected on BLE would not be entered in vector if a callback has been defined.
By doing so, it was not possible anymore to have a counter in a call back (AND device in vector) to limit the number of detected device in a single scan, which could crash ESP32 as a result.
* add onMtuChanged to BLEServerCallbacks
Add method onMtuChanged to the BLEServerCallbacks so the application can be notified if the MTU size changes.
* Correct missing semicolon and misspelled method.
Correct missing semicolon and misspelled method.
Thi may happen if read() gets called repeatedly (such as in HttpClient to parse response headers) and the connection is closed unexpectedly or the remote peer may have unexpected behavior that causes the underlying socket to report an error. In that case read() itself calls stop(), which invalidates the receive buffer object. Then when read() is called again without checking, such as inside readStringUntil(), the _rxBuffer is null and ESP32 crashes.
Pull request #4999 added setMTU function to BLEClient.cpp/.h, this line provides implementation of this added functionality to the BLE client example to resolve cases in which data from notifyCallback exceeds 20 characters (3 bytes for command type and attribute ID, 20 bytes for attribute data (char*)pData).
Added new BLE5 features to use on C3/S3 family:
extended scan,
extended/multi advertising
New code is not fancy (no feedback from events), but i think it is functional. To get feedback from events i am suggesting to use custom GAP callback, which is already implemented in BLEDevice.
- Use Serial.print instead of log_i for QR code helper information,
so that it is always printed by default.
- Expose the RainMaker factory reset and wifi reset APIs.
- Simplify example to have only a Switch device. Create another example for custom device.
- Enable push button based Factory reset and Wi-Fi reset.
- Added support for the TimeZone service.
- Moved API doc to RainMaker library's top level README.
- Other minor doc changes.
Hey guys,
so I wanted to do a BtClassic Discovery without the need to call connect
and to list all found devices on a display and continue work with that list.
I wasn't capable to test the example code with my file structure, but I did use the discovery already in some different situations.
However when I noted that the Bluedroid stack won't let me enforce an RfComm SPP connection to a GPS Device (Skytraxx 2 plus, I guess its interface is built so simple that it doesn't advertise its SPP over SDP), I will probably have to switch to BtStack (BlueKitchen) and stop on this side meanwhile
The current implementation has a getMTU function which returns the mtu sent in a message.
This function allows you to set the MTU value on the connected device, it first sets the MTU locally by calling esp_ble_gatt_set_local_mtu. It then calls esp_ble_gattc_send_mtu_req to have the connected device also change its MTU size.
This adds support for the KSZ8081 ethernet phy.
Only the IDF 4+ specific code is modified, as the phy support was only
added recently:
espressif/esp-idf@aecfbf96
This is very much still work in progress and much more will change before the final 2.0.0
Some APIs have changed. New libraries have been added. LittleFS included.
Co-authored-by: Seon Rozenblum <seonr@3sprockets.com>
Co-authored-by: Me No Dev <me-no-dev@users.noreply.github.com>
Co-authored-by: geeksville <kevinh@geeksville.com>
Co-authored-by: Mike Dunston <m_dunston@comcast.net>
Co-authored-by: Unexpected Maker <seon@unexpectedmaker.com>
Co-authored-by: Seon Rozenblum <seonr@3sprockets.com>
Co-authored-by: microDev <70126934+microDev1@users.noreply.github.com>
Co-authored-by: tobozo <tobozo@users.noreply.github.com>
Co-authored-by: bobobo1618 <bobobo1618@users.noreply.github.com>
Co-authored-by: lorol <lorolouis@gmail.com>
Co-authored-by: geeksville <kevinh@geeksville.com>
Co-authored-by: Limor "Ladyada" Fried <limor@ladyada.net>
Co-authored-by: Sweety <switi.mhaiske@espressif.com>
Co-authored-by: Loick MAHIEUX <loick111@gmail.com>
Co-authored-by: Larry Bernstone <lbernstone@gmail.com>
Co-authored-by: Valerii Koval <valeros@users.noreply.github.com>
Co-authored-by: 快乐的我531 <2302004040@qq.com>
Co-authored-by: chegewara <imperiaonline4@gmail.com>
Co-authored-by: Clemens Kirchgatterer <clemens@1541.org>
Co-authored-by: Aron Rubin <aronrubin@gmail.com>
Co-authored-by: Pete Lewis <601236+lewispg228@users.noreply.github.com>
This enables customizing HTTP headers which adds some extra flexibility.
This does not break anything of course because this change introduces a new constructor with a new additional HTTPClient argument for HTTPUpdate class.
In some use cases getting rssi signal from one channel is more stable (less variance) than rssi from the three advertising channels.
This change allows you to specify which channels are used to advertise.
In case you have multiple APs with the same SSID/password and WiFi.begin(ssid, pwd) is called, ESP32 defaults to connect to THE FIRST AP FOUND matching ssid - according to:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/network/esp_wifi.html#_CPPv418wifi_scan_method_t
This can cause situations that ESP32 is trying to connect to AP which is far away from it (weak signal) even there is AP close to it, just as in my house - I have AP on channel 6 which is in the 1st floor (quite far from room where I do the programming) and AP on channel 13 in the same room I do the programming (which is in the 2nd floor) - result: ESP32 is trying to connect to the AP on channel 6 because it finds it first and never try the AP on channel 13 in the same room, result of this is very unreliable WiFi connection.
When scan_method is set to WIFI_ALL_CHANNEL_SCAN, ESP32 scans all channels and choose the nearest / strongest AP (matching the ssid of course) as expected - result is no connection problems at all.
Therefore I propose adding this parameter into WiFi.begin, connection problems as described above are quite confusing (especially for beginners), I can imagine that for example Schools there are usually using mutliple APs and this can cause intermittent connection problems without obvious reason.
