各位大神好，
我在使用 espnow 面臨到難題了，
假設有 A, B, C 三支 devices，各有其他二者的 mac addresses 且都各已 add-to-peer，三者設定在互為多對多且雙向通訊的 combo 模式下。
那麼如何當我在 A-C 間互相通訊時，禁用 B 對 A 或 C 的訪問？因為在下目前的程式，會因 B 的訪問，而多了幾亳秒，這對當前程式功能性上影響很大，所以一定得避免。
想請問 espnow 有支援這樣的禁用功能嗎？硬體設定方面？API 支援方面？其他繞路的建議方面？。。。。。
我也嘗試過，將 A 轉設成 controller 模式，單向出，然而，不管我再做其他可能上的嘗試，結果一定都是，
對方一旦擁有我方的 mac address 那麼我便無法不理采對方／它一定會讓我方的 receiver callback 呼叫到。
倘若只能以軟體方法排除，即，先通知 B 叫他歇會，那當然是可以實現，不過就建議請官方 API 是否加入禁用能力（esp32 & esp8266 一併更新，8266超級簡單好用懇請也更新它）。
懇請各位大神為在下解答，謝謝。
請問 espnow 的功能性問題（請官方升級）
Re: 請問 espnow 的功能性問題（請官方升級）
承上，補充一下細節（我實際用上 1+6 devices，誰對誰／多對多之通訊都能掌握）簡化起見只有 A, B, C 三方，
A 是主發送端。
除了將 A 從 combo 改設成 controller, esp_now_set_self_role() 以外，另外也嘗試過將 A 的列表都刪除 esp_now_del_peer()，只留接收端 C，但也是接收到 B 的送入。
也試過將 A 的 peer 列表中除了 C，都改設成 ESP_NOW_ROLE_IDLE, or ESP_NOW_ROLE_SLAVE, esp_now_add_peer(mac_addr, role, 0, 0, 0)，也全都無效。
該提的是，因為一些原因我也只能使用上舊版的 non-os-sdk（Arduino::esp8266 esp8266-2.7.4 nonos-sdk 2.2.1+100-190703）。所以如果在下以上的陳述，有違各位的經驗，請不吝告知，即或許是我使用的版本太舊，新版的不會有這些現象。
此外若 espnow 真還未完善（即 peer list 所記錄的 role 無實際效用），在下前面有提到，與其新增 "禁用的功能"，那若 devices 有 20 支，那 peer list 便有 19 個物件要巡訪一遍，會平白浪費很多運算，不如就是新增 "專用功能"，即若某指標不為零，就承認僅與它通訊，而不用再去巡訪該 peer list 了。真的，當俱有長列表但某時刻獨佔地與某 device 通訊有其存在性與必要性。以上在下拙見供參考。
A 是主發送端。
除了將 A 從 combo 改設成 controller, esp_now_set_self_role() 以外，另外也嘗試過將 A 的列表都刪除 esp_now_del_peer()，只留接收端 C，但也是接收到 B 的送入。
也試過將 A 的 peer 列表中除了 C，都改設成 ESP_NOW_ROLE_IDLE, or ESP_NOW_ROLE_SLAVE, esp_now_add_peer(mac_addr, role, 0, 0, 0)，也全都無效。
該提的是，因為一些原因我也只能使用上舊版的 non-os-sdk（Arduino::esp8266 esp8266-2.7.4 nonos-sdk 2.2.1+100-190703）。所以如果在下以上的陳述，有違各位的經驗，請不吝告知，即或許是我使用的版本太舊，新版的不會有這些現象。
此外若 espnow 真還未完善（即 peer list 所記錄的 role 無實際效用），在下前面有提到，與其新增 "禁用的功能"，那若 devices 有 20 支，那 peer list 便有 19 個物件要巡訪一遍，會平白浪費很多運算，不如就是新增 "專用功能"，即若某指標不為零，就承認僅與它通訊，而不用再去巡訪該 peer list 了。真的，當俱有長列表但某時刻獨佔地與某 device 通訊有其存在性與必要性。以上在下拙見供參考。
Re: 請問 espnow 的功能性問題（請官方升級）
NOOS-SDK 处于只维护状态，官方 API 不会再在 NOOS-SDK 上添加新的 Feature，建议按照上述方式实现。另推荐切换到 ESP32C3/ESP32C2 上，新的需求会评估更新。
Re: 請問 espnow 的功能性問題（請官方升級）
好的，以上已無任何問題了，也已經繞路解決掉所遇到的關卡了。
在下於此也分享一下使用 espnow，所測得的數據（arduino::esp8266 2.7.4）：
當 peer 只有登錄一支，即 peer list 長度 1，
A-to-B 傳輸延遲，從應用層到應用層（send() to recv_cb()），1-byte 是 162us。似乎已是最小值了。
當 peer list 為 6，傳輸延遲是約莫 175us。
當 peer list 長度 7，來到 180~200 us 之譜。
廣播實為循序地巡訪列表再發送，這也是為什麼我會另外實作同步機制／底下會提到。
否則，只要一次廣播，所有 clients 皆以相同的最小的誤差延遲以同步，會是多麼漂亮。
因此現況上，若以廣播作同步，則 clients 間誤差有機會超過一秒。
資料巨量傳輸，250bytes-max/次，連續，傳輸速度來到 10kbytes/s 似乎已是最佳。
若廣播，則資料經常性漏收，不意外。
若指定對象，測資大小 60k bytes 則約九成九的成功正確率；十次可能最多有一次發生資料誤失。
recv_cb() 以類中斷機制觸發，所以原則上不擔心程序的時序或須等待之問題。
傳輸距離似優於 wifi/tcp，cpu 的負擔比 tcp 小得多。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
espnow 有著極短時間的啟動傳輸延遲，init -> send -> recv，僅費時最低 160us 。
因此，欲實作兩裝置間的時間上的同步，若說時間精確度只要求 ms 等級，則根本也毌須多加什麼扣，
僅需靠 espnow 一次 send 便能達所求兩者間的同步，這正是 espnow 呈現的極大優勢。
不過若是要求 us 等級，則必須要再加一些同步上的檢校機制或演算法，佐以修齊時脈。
那麼今假設 espnow 傳輸延遲只有 10us，結果就算同步演算法再怎麼不理想，
espnow 的 10us，也將不會造成結果數據上多大的拖累；
或說僅僅單靠 espnow，就有 <10us 的精確度了。。。。
（理論上，同步無關乎傳輸延遲；減掉而已。但迴文，延遲 1us 和延遲 1 year 有著誤差上的迥異）
espnow 於 MAC 層的規範與資料傳輸，有其相當多的優點及被需求的場合，
因此除了 espnow roles 若還未完善將可能評估再改版外，
是否趁此也新增第二種模式，為獨佔模式，也不需要 peer list 了，而當只有所指定的單一對象存取，才會傳回應用層；
其餘的都在 mac addr 確認後隨即忽略它們以不浪費 cpu clocks。
以最大化突顯 espnow 的盡可能短的響應時間（啟動傳輸）的優勢。。。。這點是 TCP/UDP 無法做得來的！！！
（以及第三種實廣播模式／以輕易實現同時性？）
之所以對 espnow 有這麼大的興趣，是因在下當前實作裝置間同步，8 deivces 已有 <50us 精確度
及 45ms/13hr 累積偏差的不錯成果，全賴 espnow 之助。
以上經驗供各位參考。
感謝官方的回覆及評估考量以上的建議，以讓 ESP 更強大。
在下於此也分享一下使用 espnow，所測得的數據（arduino::esp8266 2.7.4）：
當 peer 只有登錄一支，即 peer list 長度 1，
A-to-B 傳輸延遲，從應用層到應用層（send() to recv_cb()），1-byte 是 162us。似乎已是最小值了。
當 peer list 為 6，傳輸延遲是約莫 175us。
當 peer list 長度 7，來到 180~200 us 之譜。
廣播實為循序地巡訪列表再發送，這也是為什麼我會另外實作同步機制／底下會提到。
否則，只要一次廣播，所有 clients 皆以相同的最小的誤差延遲以同步，會是多麼漂亮。
因此現況上，若以廣播作同步，則 clients 間誤差有機會超過一秒。
資料巨量傳輸，250bytes-max/次，連續，傳輸速度來到 10kbytes/s 似乎已是最佳。
若廣播，則資料經常性漏收，不意外。
若指定對象，測資大小 60k bytes 則約九成九的成功正確率；十次可能最多有一次發生資料誤失。
recv_cb() 以類中斷機制觸發，所以原則上不擔心程序的時序或須等待之問題。
傳輸距離似優於 wifi/tcp，cpu 的負擔比 tcp 小得多。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
espnow 有著極短時間的啟動傳輸延遲，init -> send -> recv，僅費時最低 160us 。
因此，欲實作兩裝置間的時間上的同步，若說時間精確度只要求 ms 等級，則根本也毌須多加什麼扣，
僅需靠 espnow 一次 send 便能達所求兩者間的同步，這正是 espnow 呈現的極大優勢。
不過若是要求 us 等級，則必須要再加一些同步上的檢校機制或演算法，佐以修齊時脈。
那麼今假設 espnow 傳輸延遲只有 10us，結果就算同步演算法再怎麼不理想，
espnow 的 10us，也將不會造成結果數據上多大的拖累；
或說僅僅單靠 espnow，就有 <10us 的精確度了。。。。
（理論上，同步無關乎傳輸延遲；減掉而已。但迴文，延遲 1us 和延遲 1 year 有著誤差上的迥異）
espnow 於 MAC 層的規範與資料傳輸，有其相當多的優點及被需求的場合，
因此除了 espnow roles 若還未完善將可能評估再改版外，
是否趁此也新增第二種模式，為獨佔模式，也不需要 peer list 了，而當只有所指定的單一對象存取，才會傳回應用層；
其餘的都在 mac addr 確認後隨即忽略它們以不浪費 cpu clocks。
以最大化突顯 espnow 的盡可能短的響應時間（啟動傳輸）的優勢。。。。這點是 TCP/UDP 無法做得來的！！！
（以及第三種實廣播模式／以輕易實現同時性？）
之所以對 espnow 有這麼大的興趣，是因在下當前實作裝置間同步，8 deivces 已有 <50us 精確度
及 45ms/13hr 累積偏差的不錯成果，全賴 espnow 之助。
以上經驗供各位參考。
感謝官方的回覆及評估考量以上的建議，以讓 ESP 更強大。
Who is online
Users browsing this forum: No registered users and 61 guests