Limit in the number of devices? #712
Comments
|
There is major memory improvement done in the 1.8.1-dev branch, done as part of #684. |
|
I will try and let you know, thank you @frankonski |
|
so I tested both: 1.8.0 (current) and 1.8.1-dev dev version 1.8.1: stable version 1.8.0: |
|
ok, apparently I don't need the physical devices to see the errors - I created again 10 remote devices and the outcome is: ... so I expect the missing data again on the bridge, right? |
|
unfortunately ESP32-S3 with 8MB did not help at all - same errors - any remote device above 6 is not working even though free heap is 268564 bytes: |
|
Can you type 'm' into the serial monitor when using the new 1.8.1-dev branch. This will report the free heap as well as the status of the NVS. Want to check that the NVS is not filling up to capacity. |
|
|
Thanks. It does not seem to be a problem with the NVS (plenty of room), but the stack size seems low. Can you run this with different cases for the number of SpanPoints to see how the numbers vary? |
|
I just reviewed the ESP-NOW documents from Espressif and it seems that the IDF limits the number of encrypted peers that can be added. This is hardcoded into the IDF and cannot be changed in the Arduino-Esp32 library without it being recompiled (which can't be done via just using HomeSpan). |
|
6 devices and all is OK: 7 devices and the last device is NOT OK: 8 devices (and so on... - NOT ok): |
|
just found it out: |
|
so, we are practically done here... and I have also another project, that is NOT for HomeKit, just ESPnow to MQTT and I have more than 50 devices working. |
|
Unfortunately I don't think there is an easy workaround for this. |
|
or another approach: do we NEED encryption between the bridge and the remote device? |
|
It's something I can explore in a future release, but probably not in the short term. |
|
with your permission I will try to do it in your code - if I am not mistaken it is just one parameter in the ESP function:
here: |
|
Yes, feel free to experiment. |
|
it seems to work without encryption turned ON but let me test it further - at least there is no initial error: ESP NOW is full |
|
no luck still:
but maybe it requires recompile on the sensor as well? |
|
YES YES YES!!!!!! after recompilation of the remote device with encryption off it seems to work:
|
|
I am yet to check in my friend's house, where I deployed 7 devices, and 7th is not working now - all above tests are from my house, with just 1 device working and 1 bridge (testing only). And if that works (I am very positive it will work with both sides):
I would suggest, as the fastest workaround to bring some configuration parameter in your library to be controlled by the end user, i.e.:
and then in HomeSpan.cpp this way you give the end user possibility to go up to 20 end devices without really redoing your library - also, my change in the HomeSpan.cpp will only survive until I pull the update from your github ;) |
|
Unfortunately, #defines don't pass through to libraries (they appear to do so in VSCode, but that's only because VSCode recompiles all of HomeSpan each time - it's not really being accessed as if were a true C library). Instead, to be consistent with other SpanPoint methods, I created a new class-level method I also added logic to the Serial Monitor output that lets you know if SpanPoint encryption is on or off, as well as provides a warning message if any of the SpanPoint instances exceed the maximum allowed. Rather than hardcode limits, HomeSpan checks each SpanPoint to see if was properly stored after creation. With encryption turned on, the limit is 7 peers. Without encryption the limit is 20. These limits are consistent with the ESP-NOW documentation. These features have been checked into the 1.8.1-dev branch. Please give it a try and let me know how it works. If successful, I'll update the SpanPoint documentation to reflect the new |
|
I was 100% you would implement it different way - your way ;-) |
|
so I am testing and I found kind of strange things: outcome (as expected): and then, when remote sends data, bridge is showing it: so far so good - both bridge and remote have encryption OFF so they talk and understand each other. 3- next test: turned encryption ON ONLY on bridge - expected behaviour:
however outcome is different a bit - this part below shows: all are encrypted but we exceeded the number, right? but then, the last sensor - with MAC = 1A:01:01:01:01:42 - is still being received and understood by the bridge! but when I move the same sensor to be 1st in the list (or in the first 7), the bridge does not even print anything - no error no nothing. So for me it looks like this: Do I get it right? |
|
next scenario:
5- bridge using encryption but the test remote is the FIRST position on the list - so on the position number 1
|
|
So my summary now:
|
|
For me the topic is closed, unless you want me to test more, I would appreciate if you merge the dev into the main branch - right now I have your code on my lib folder (I am using PlatformIO of course) |
|
one more thing: as I mentioned before one can use unlimited amount of remotes in ESPnow, if you consider every connection to be temporary and then delete the peers - this way I have it done in my project (the "non HomeKit" one). |
|
I have tested with more devices and the outcome (if you wanted to know) is (all unencrypted) - on top of your part of the library I have also bridge connecting to InfluxDB and pushing the data for Grafana (HomeKit is seriously limited with historical data):
So all in all it would probably work well with 20 devices if not my addition of InfluxDB connector I shall test now with MQTT (instead of InfluxDB) |
|
it seems it can be 17 encrypted devices as per https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/network/esp_now.html - just that default is 7:
|
|
Yes, but it's not possible to change this default unless you re-compile the Arduino-ESP32 library directly from the IDF using the IDF tool chain. There are many such variables like this where the folks at Espressif hardcoded a value or process into the Arduino-ESP32 library that is more flexible when using the full Espressif IDF. It is possible to create an Arduino-style library directly from the IDF, but I have not yet tried since the results are chip-specific, and I would need to create multiple versions of HomeSpan. |
|
I am very interested in this, as I have a contact sensor hub with only 2 devices at the moment under test for battery life, and eventually want to have humidity/temp and contact sensors all on this hub. So the device number limit is important to me. Would you guys @homonto and @HomeSpan agree with this summary below? Without considerations of extras like external databases, just a plain HomeKit device, you can have up to up to 20 spanpoint remote devices, but encryption must be off at both ends, and you need 1.8.1 or later codebase with the |
|
@YouCanNotBeSerious I am doing nearly 20 now with encryption OFF |
Hi,
So I've built a bridge with 8 remote sensors - ESPnow.
Each provides: temperature, humidity, light, charging and battery.
Bridge provides only charging and battery.
What I am seeing is: the moment I add 8th sensor I am not getting the result I wanted.
Is there any limitation?
this is the beginning of the run with all info:
and the always the same error:
that is the received message from device number 8.
If I delete any device (1 to 8) there is no more problems (initially I thought device 8 is wrongly configured - but no, when I delete device 7, then device 8 is properly reporting).
Thank you for info.
The text was updated successfully, but these errors were encountered: