今天距前一篇文章發佈的時間，剛好滿一年。
所以今天就來新增一篇，那似乎可以營造往後每一年的今天只作一篇的假象。
事實上，今天這篇，早在兩三週前就因需要而在製作了。只是選在今天波文會比較特別。
而為何一整年都沒有新動態，新作。。。其實是有的，分散在以前的一些文章的更新追加，即為動態。
並且也因為，前一篇 SPI，筆者是真想把它完善但一直沒有機會把頭洗下去。所以波文的心態上一直卡在這篇，無法釋懷，畢竟，那是攻破 ESP8266 的最後一道高牆。
本篇也攻破了一些次之的關卡。所以本篇也算是重磅的一篇；主題如是，但重點將著重在強大的扣倍使－code base。

此專案大概兩三天就搞好了且即上崗了，但是，code base（初意是整理及 fine tune http client，及解決 wifi recovery but mdns 失效問題）卻前後用了至少兩週，而且當前還不算完成，但相信最終成果將是對往後專案的一大助力，後詳。
本篇前半段是講述本專案，中段是本專案的改寫，而後半段就是 code base 了。想一想不太行，若本篇後又一年才新增文章，那本篇將成首頁，圖多會較耗用頻寬。。。所以 code base 放到下一篇好了。

先上圖

• 圖一，是大顆的。是筆者手上有兩種，大顆的有較多硬體控制設定，而小顆的，只能動烙鐵才能更動例如靈敏度及反應時間等。所以先上了大顆的，結果，無感應物也會發生似乎規律地幾秒就感應反應一次，調整也沒用。
  所以，馬上就被筆者換了下來，換成小顆的如圖二。
• 圖二，令筆者失望了，同大顆的舉止。
• 那。。。本篇還有什麼好嘴的？？？
• 幸而，後來觀察出來，誤動作都在約 1.3 秒內 level high 就會降下來，而實觸者，都會超過 1.5秒以上，且此區隔度可說九成以上。所以因而得解。
• 此産品介紹說，人體與其他物品或熱源，其紅外線的波長是可以區隔的，所以可以特別針對人體作感應；而實測下確實如此。但難免還是會有誤動作産生；約略七成可靠度。
• 那，至此，也埋了一個隱憂了，不知讀者有看出來了嗎？讓我們瞭解一下專案。。。

Human Motion Sensing Client

• 感應的部份如圖一圖二，通常而言是放在門口或人員通過的地方，該處有既存的穩定供電源機率應不大。所以電池驅動應是較高可能採取的做法。
• 透過 gpio 中斷，再由前面提及的暑光，以可分辨是否為有效觸發。然而。。。電池就開始哭泣了，因為前述的暑光原因，ESP 根本無法睡眠僅透過 gpio 喚醒，以節省電力。。。
• 而確立感應到了人員通過後，透過 http request 通知 server 端，server 端再作回應。。。brabra 留給下一段。。。
• 元件：SR602，ESP-M3（ESP8285，唯一不推薦使用的模組），15/3.3 LDO，8V 可充電 dc supply。

Human Motion Sensing Server

• 因此，client 端可能是放在家門前庭外圍的門口或走道，server 端就是放在屋內的客廰的電視旁之類的。。。這又再次展示了 IoT 的無線的便利性。。。
• 因此 server 直接由 wall power 轉 5V 的 ACDC adapter 供電，這正是手邊不想碰都會不小心碰到的最常用電源器。
• 元件：2W8歐 喇叭 x 2，二路放大器 x 1，15/3.3 LDO，ESP-01D（ESP-8285，強烈推薦使用的模組，flawless for DIY in all aspects）
• 上圖
• sorry ac adapter 沒有拍到

敗筆。。。好幾筆。。。

• 那就再上圖，如下，那就知道接下來要講什麼了：
• Server 沒什麼好講的，就是收到 request 之後，就叫幾聲。
• 後續可能會使用上 DAC，但這又是需要時間 study 且算是另一個不算小的獨立專案了，即 DA，PCM/DPCM/ADPCM，amplifier。
• 不過，server 程式部份用到之前的 MultiTimers，提一下；而 client 並不能睡眠，但能夠把 wifi 關掉，這帶來一個問題，即，server or 使用者被受限了存取 client 的時機，所以解決辦法就是使用者先告知 server，讓它將要去通知 client，wifi keep alive 即可。所以只有等感應器被觸發，通知 server，server 在此時間點告知即成。
• server，client 都是 STA 模式，連接家中 wifi，這可讓距離不成問題，也只消等 client 連上線的時間。
• 截至目前為止的缺點，以下就談 client，
• 如前述，最快要 1.5 秒，才能開啟 wifi，再傳輸，前後大約 6 ~ 3 秒 server 才能嗶聲音出來。所以根本算無預警功能。。。
• 中午要休息，晚上也要休息，不能 24 小時都會嗶嗶叫。所以，code base 中，將 NTP server time 加了進來。實現了時段中才運作的功能（漂亮吧），不過現下的版本只做在 server 上，當將也用到 client 端時，看能不能再省點電（預期無變化） 。
• 用上 LDO 是個醜一，所以耗電量來到 85mA，如下圖，已換成 DCDC converter。但耗電量還是在 65mA 上下。。。
• 所以，原本只有半天，1600mAH 的雙電池供電源就沒電了，
  換掉 LDO，wifi 關掉，目前最好的成績是大約一天半。
  而當 wifi 關掉後，耗電量來到 25mA，強調一下光 wifi 就省了 50mA 以上。換言之，如下圖，520mA 的太陽能板，或許是救星。
• 那塊藍色的，叫 MPPT 吧。紅色的是聲稱高效率的 DCDC 5V converter。
• 至目前為止，還未完整測出上了太陽能板撐了幾天，因為已下崗放一旁，都在搞 code base。

Code Base 先睹為快

• 至今天為止的驗收：
• 可以說，Server code，Client code 都已經 commit 了，抵定了。即 NTP server time 加進去後，如前述整個運作行為，再加上 code base 的第一階段整理，已運作相當順遂了；mdns 失效問題已解。若只要太陽能板搭配上，專案可說 close 了。
• 然而在這兩週當中，又作了 code base 的第二階段整理，且已在今天完成，
  先說，整份最新的 code base 已加在 server/client code 中，以致於原本 0.1 release 版的 server/client code，改為如下的 0.1alpha 版，因有再多塞了一些測試的 code。
• 而就 code base 本身，其實算是 final release 了：
• 新 code base 是基於這份精簡版的 code base，其置於前篇文章 ESP8266’s AP／STA／HTTP／UPDATE（筆者所有的 code base 都放在這篇文章中） 中的 ”WiFi_AP_Station_v_0.2a.zip added Traditional Chinese how-to“ 這份 code base。換言之，此新 code base 將是 v.0.2a 的改版。
• 不過，筆者還有一份完整版的 code base，“Esp8266MyWiFiUnified_v_0.3a_20210609.zip”，是不是應當將它裏面多出來的那些功能再加入此處新 code base；原因是，當前此新 code base 算是 completely hacked，打鐵趁熱，把所剩的全都有條不紊地加入。另外還有，別忘了，
  筆者在那篇 all code base 文章之後，還有接續其他專案，都有增長 code base 的功能但都還未整合進 code base，如語音辨識一文加入列出檔案／目錄及多檔上傳等功能。
  所以，接下來的第三階段預期將耗用更多時間所做的 code base 大整合。
• 那麼，目前此新 code base 有何過人之處：有有有有有！有！有！
• （既有的不提，只提修正過或新的）
• 1. ESP-NOW wrapped code，搭配 mdns，能夠輕易地透過 hostname rather than mac address 與多 devices 組網。小測了一下，速度快到跟 LED 能夠可視閃動的速度差不多。（註，其實很慢，約略 10k，傳 9 MB 要約 16 分鐘且會漏失，故結論僅用於控制／就很好用了）
• 2. http client 我忘了舊扣有沒有 bug，但可確定的此新扣不再有卡卡或 connect failed 的問題，約略 2 秒 7 次順順的 http requests。
• 3. 加入 AP+STA mode。
• 4. online 地在 AP，STA，AP+STA，ESP-NOW 四種模式中都只以一行扣切換。並且 keep mode if power off/on。即想要什麼模式隨時切換。
• 5. NTP time，想要 arduino 告訴您今天年月日幾點幾分幾秒，沒問題了。
• 6. 有了中元標準時間了，會不會想要鬧鐘？沒問題了。瞭解 linux crontab 嗎？看得懂它嗎？{＊，＊，15，12，30，＊}，或 {＊，＊，＊，18，00，Wednesday}，從今天起 arduino 也有同樣的功能了，只要一行扣，就能設定複雜的時間排程功能，對於 sensor sensing/reports 將是一大福音。
• 7. Timeout，終於自己說服了自己，承認了其正確性（what?）。說實在的，之前使用都還怕怕的。。。幸而之前的扣也是沒有問題，現在也是延用也新增雙倍時間的。
• 談回 server/client，那麼，也將基於 esp-now 與排程問題進行改寫。（對了，在此附記一下，device mdns hostname 無法産生，主要的可能原因之一跟路由器有關；用某台若有 fail-rate 最好試試另一台）。
• 今天花了很多時間寫這篇，以上，應該都交待清楚了。
• 以下是 code base，還有接續，第三階段的 code base 整理，與 server/client code revision。
• 扣倍使放在下篇文章，改版 server/client code 以期更快響應及更省電又或整點報時／嗶聲（將來若有實作 DAC，就可以用人聲報時了），行程提醒透過 http request 加入等，將於下面更新補充。
• 以上！。。。總會見到有人炮 arduino，輕蔑開放社群所凝聚的力量。於此，我不免想嘴一句來回懟：所以說，Arduino 這隻小朋友的玩具，LOW 不 LOW 丫？嗯，它 LOW 不 LOW，是看人用的。。。。

20230728 緊哦！三缺一了！快來！－四方無線通訊

• 呼，歴時十一天，終於擠出來了XXD。。。。。。。比對一下，真的增刪修了相當多的扣XXD
• 此主題是亂取的，但真的是四方通訊了，
• 看看，原用 http 的方式通訊，那麼我們便能透過 web browser 來與裝置溝通／設定／控制。
• 但，改用了 ESP-NOW，其獨佔地僅透過底層的 wifi 協議中的封包作溝通，輕量，一啟動便快速到位，點對點，無負載速度快，射後不理，且實測其有效距離大大增加（因少了 tcp/ip 高酬載所衍生的誤失重傳）等等，皆是相當多相當大的優勢，但另一方面 tcp/ip/http 的連線便無法建立，請問，這無疑是開了另一扇窗，卻把原先大門給封了，
• 想想，該如何突破此冏境，
• 嗯，答案呼之欲出，不難想到，
• 裝置用完 espnow 再轉回 http，
• 那無疑是脫褲子放肆，且裝置間互搭的時機是個問題等；故這問題連想都不必想，預期想了必頭又大。
• 轉個念，
• 前面提到的，兩方裝置 client and server，永遠處於 espnow mode 下，以 espnow 互傳，
• 第三方，也就是使用者我了，想要跟那兩灶說得上話，
• 何不揪出第四方超人，喔不對是 supervisor，
• 我透過 web browser，與 supervisor 溝通，下達指令後，而 supervisor 便變身成超人，不對，變身成 espnow mode 下，將 commands 傳給 client and server，那，不干擾到 client and server 的連線狀態，只要 supervisor 忙些，
• 目的，也就輕易地／只消十一天，逹成囉。。。。。。。XXD
• 其實，扣很快就寫好了，只用大概超過一週，剩下的就是除錯及最主要的，時間都花在client 的 main loop 及 espnow wrapper code 的修修補補上，因狀態(several states)不少，所以補了相當多的洞。。。。即，以目前的 client main code，至少筆者測試看來是沒問題了，但仍不具信心它不會出錯。
  原本想重寫的，main loop 改以狀態導向的方式來跑扣應確定性就比較高了。。。。。但想想也複雜，如何切割區分不同的獨立或那些具相依性的狀態。。。
  前問題何謂也？client and server 都是在 http & espnow 兩種模式下都可運作的，初始狀態為何，何時切換成工作狀態，若該切了但 mac 還未取得，切換成什麼工作狀態，若找不到對方或若 espnow register device 不成功或成功了再 register 一次行嗎，若 device hostname 還沒取回或若 mac 已取得，對方仍在 http 下還是已切成 espnow，何時 sleep，何時強制不能 sleep，切回 sta mode 及 切成 espnow mode 該伴隨哪些狀態成立，哪些狀態可以成立及必不能成立。。。等等等。。。
• 其實最主要的是，espnow 中，enable & add-peer 加上自己引入 mdns，所附加造成的混亂狀況。。。
• 扣先放上，此四方通訊專案用法與功能，慢慢補充。
• 對了，此精簡版 code base 自從 cAlarm 加了 add minutes，且加上了 espnow 的 supervisor code，可說已臻完善；supervisor 的扣，後續應可直接納入成 espnow wrapper code base。
• 才改個版，以上吐那麼多。。。嗯，就知道此次改版不是人過的。。。。。（雖然扣內有寫，該列於下）
• 重測了一次，Client，active 下，58.8mA，關掉 wifi，降成 15.71mA，一行盡量 idle 的扣，偶爾還會降成 12.75mA
• 功能及用法：

• Client 感應到有人經過，便透過 espnow or http 通知 server 叫個三聲來聽聽。功能就這麼簡單。
• 反應時間，從原本 http 的 6-3 秒，減至 espnow 最少只要／約略固定在 1.4 秒，server 就能接收到。
• client & server 可以在 http mode 下工作，亦可在 espnow 下。預設 espnow，若要改為 http，則由 supervisor 下指令變更。
• 1. server 在啟動後，硬性處於 sta mode 下 3 分鐘。在那 3 分鐘當中，由 client & supervisor 透過 http 取得 mac，並由 client 通知進入 espnow，若有通知，則 3 分鐘一過，server 便進入 espnow mode。若無通知，則再在 3 分鐘後，即啟動後 6 分鐘後無條件自動進入 espnow mode。
• 2. client 在啟動後，有 2 分鐘時間會強制處於 sta mode 下，因扣流程的關係，其間僅通知 server 進入 espnow mode，只有在 2 分鐘過後，才會將從 server 取得的 mac 存下並進入 espnow mode。也就是說 server & client 一起啟動，只有第 2-3 分鐘之內，client 能夠與 server 建立連繫。錯過，也只能關機重來。重點，該保證，server 處於 sta 下時，client 該是處於上電 2 分鐘之後的狀態，才有機會取得 server mac。而，一旦成功存下 mac，同下述 supervisor，以後三者便無須一起上電啟動的問題了；或說三者都是即上電即用。（除外，server 必上電 3 分鐘後才可能被使用／進入 espnow，但又，那 3 分鐘中 http 是可以的）
• 3. supervisor，一上電，便會抓取 server & client 的 mac 並存下。當它存有二者 mac 後，main loop 中屬它的扣便不再跑，否則只要有一沒抓到，會持續跑但這非重點。其後，它只用來以 web browser 來，僅透過 /query 查詢提供哪些指令，及 /query?c=cmd 來發送指令。supervisor 的功能作用就這麼簡單，無關乎 server & client 處於何種模式下。web browser 有可能 timeout，refresh 即可得結果；注意最前頭的數字，有更動代表有更新。
• 4. server 同 client 在所指定的時段內，是 inactive 的。例如每天的中午 12:00 to 13:30；但不包含週六及週日。益加地，client 於這些時段中硬性 idle，即大部份時間都處於 delay 下；使得 power consumption 可從 15mA 降為 12mA。
• 5. client 於預設 active 20 秒／可調；後即會進入睡眠模式／關掉 wifi（此處二者等同）。由 sensor 觸發喚醒，若持續觸發便持續保持在 active，但前提是 continue-time 有關掉，若無關掉，則表示，例如 100 秒，若 sensor 觸發後 100 秒內還被觸發將被忽略觸發。此外，continue-time 與 active time 是無關聯的；active time 只被 true-positive triggers 影響／歸零。
• 6. server & client 可在 sta mode & espnow mode 由 supervisor 下指令往復切換。其他功能指令，/query 查看之。例如強制 client 不再進入睡眠模式。
• 7. client 跑扣模式，目前設定在 “formal test”，即，毌需 sensor。只需三張 wemos d1 mini 小板便能完整測試。注意一下，前述的所有行為，都是 client 以 “formal code” 的模式在跑；其在 loop() 內可作切換。”formal test” 只是便於一拿到扣即可測試而毌需 sensor 存在。
• 8. 提醒一下，易明，工作狀態下，client 絕大部份時間是不工作的／連繫不到的。只有觸發後的那 20 秒 wifi 是 active 的。所以 client 的罩門就是在傳 true-positive trigger 給 server 的那個時間點，有看懂吧。若要加 cmd 給 client，就是 supervisor -> server -> client。
• 程式有加另外兩份 lib，請自行於前文抓。其中 filedb 應是必要的（文：ESP8266 使用 LittleFS／SPIFFS 儲存與載入 變數／參數／資料）。hardware-timer（文：MultiTimers）則可將內扣摘除便可以不使用它。
• 總結，
• 我手上的裝置將會依此版上線。除非實際運行上有問題，不然若有小爸哥應不會再修。
• code base，在下一篇文章確定是有的。且如上述當前真已臻完善了，不過，翻了那份完整版，有不少卻步XXD。搞不好只會整理當前精簡版就好。。。
• 好問題！馬上 ken 哥就發問了：若真不再改版的前提下，請問，
• 我的一對 server & client 已上線使用了並也算符合預期盡責地工作著／二者皆一直處於 espnow 工模下。哪天我想對二者做存取溝通，但，我總不可能原先就已備著一顆 supervisor 吧不合常理。一旦後來 gen 出的 supervisor 板子，除非去把 server/client 斷電重啟，否則也不可能再有方法可得知二者的 mac 吧！哈！若拿紙抄備下來就 LOW 掉了！！！
• ken 弟答：嗯，確實，這部份可以改進改版。但，真不想改版，那麼，有解法仍可只從 main code 中下手，就留給各位讀者當習題吧。
• 筆者提示一下，只要加兩行扣問題就解了，server code 中，
• -1, -1, -1, 7, 30, -1; enable_esp_now=true; // to espnow mode.
• -1, -1, -1, 18, 32, -1; adjust_wifi_espnow_mode=2;(這個可能不被懂，換成) EspNowEnd(); WiFiToSTAOnline(); // to sta mode.
• 同理 client 也可加但不建議，因為 client 最大的重點就是在省電。而 client 不加能使嗎，能丫，那不就是 supervisor/espnow wrapper 中的一大重點嗎。
• 承上，（有完沒完？？？）
• 所以 code base 將會加入可 http 排程，並搭配預先列好的函式列表，使得便可哪天想到要排程執行某函式，就只要一次 http request。
• 對了補充一下，使用 cAlarm，務必瞭解一下 void FixMyStaticAlarms() 這支函式的背景，扣內搜一下就有，與之相關的說明只有幾行而已應不難掌握。

20230806 改版

• 當然 main code 及 code base 都有修改；不過主要重點還是放在 code base，前聲稱都已完善，但就既有的東西仍改了不少XD
• 先說 main code，
• 前面提到，後到的 supervisor 取不到 mac 的問題，筆者再三想了想，似乎前面提到的解法也是當前僅想到的解法。故，扣未就此點更動。倒是現在 server & client 都設定了在 14:45 to 15:15 之間轉為 sta mode；此似乎可行，乃因為此時太陽最大。
• 另外 supervisor 在 switch modes 間，會造成 sta mode 失效乃因忽略了 transition 需要時間，故就此點修正。
• client 則加了當 force wifi active 三十分鐘後，會自動強制 disable 掉，以避免使用者忘了切回來而耗電。（補充：這條的 Timeout 中的第二個 true 要拿掉；我沒注意到。而應還要再加個 ntp query 的 command，以使得使用 local time 哪天有網路便可更新時間。）
• main code 的部份大概就改了這些。
• code base，
• 筆者現有手上的精華全都加進去了。所以，完善了，剩可能 supervisor 行為及 espnow 的部份要細修以使得這兩部份更像扣倍使。
• 它真的完備了^_^，（修正萬年暦有些狀況未考慮到），增修包含，
• mDns full version，
• ping／斷線自動重連
• Time functions 的使用彈性及運用深度，online/offline 的時鐘，可自定時間等（via http）
• alarms 的可新增／移除排程（via http）
• file system utilities，包含 list dir，format，remove，copy，download，upload 等。
• 應該這麼說，若有哪一份 code base 有比此份涵蓋更多實用功能的，尚請讀者們介紹給筆者參考與改進。
• 以上，筆者的漚心𤁋血的花費大量時間寫作整理的這份扣倍使，歡迎愛用及幫忙戡錯批評指教改進，謝謝。

20230808 更新。終版 1.0 了。放到下篇文章 TMPC-ESP8266-G1 codebase。其中角色互換，將此專案納為 codebase 的範例。

20231103 v.1.2 release

• 這是筆者自己在用的版本，僅是 ssid，pw，及一些巨集設定不同罷了，有加密。
• 請至下一篇文章 codebase 下載 codebase v.1.2 版 release，是當中的範例 3。

這是欲更新成 1.2 版的 server 的最終身影，是不斷電不當機不重啟跑了 83 天的壯舉，時間誤差為快了 1 minute 10 seconds。

20231103 補充 爸哥 XD

• 剛把 v1.2 版的 bin file 刷上去到一半，就瞬間肚子餓了起來，想起了糟糕。
• 扣，後來，加入了可外部啟動更新 ntp time，也 set rule，the existing schedules 只要是有未定時間，就會把它們給刪除掉；這是必要的否則必會留下 zombie 浪費 heap memory。況且，使用者尚且可於任意時刻於外部設定任意過去或未來的時間。至此沒有問題。
• 不過，我們應用上的扣的需要，通常會在 setup() 內加入 schedules/cAlarm，如此 project。也就是所謂的靜態設定的 schedules。但問題就發生在於接下來才會跑的 loop_IoT()，其內的，
• 因為 syncMyTime() 執行早於 sta 上線，故一定會先取得歸零的時間，即 2001 年起始的。這無可厚非。只要之後扣或外部再視需要取 ntp time 即可。這表示，靜態排程及當下時間都已被決定，換言之當使用上 ntp time，一定是之後了，靜態排程必會被刪除。至此亦沒有問題。
• 故無論如何，靜態排程總是無辜被刪。
• 故而，正解應該是，只要是設定／修改時間，就必須再一次重新設定靜態／既定排程。故我們必須新加的扣是，當有完善的維護靜態排程的扣。（非未定時間要嘛將來執行要嘛自動被刪除；故所維護者若有之，執不執行有無被刪除是使用者該注意的）。
• 該再一次讚嘆 Timeafter 了。。。看看。。。。。自從筆者生出了它之後，便遭到筆者濫用到一愣一楞的。可憐的 Timeout 被筆者濫用了幾年後於此被筆者打入了冷宮了。。。
• 除了要有個 flag 看是不是要 sta 上線即更新 ntp time 外，只要在幾處取得或修改 time 的地方，Timeafter of the 靜態排程函式即可；其允許未定或非未定排程且若有 AddMinutes() 也可以。僅當留意 setup() 時刻與其他時刻是否具一致性。
• 這真的是分隔線
• 為何 ken 哥的程式也好，筆記也好，總是廢話一堆／程式註解一堆呢？想必是 ken 哥太厚畫虎爛時間太多太閒也或是太積極好進現技炫耀耍帥吧！！！
• 唉，
• 理解過體驗過真正的程式設計，便無此疑問！
• 難道您看不出來，廢話愈多，表示愈無奈嗎！！！
• 若是使用者動態加入排程，我是該假定使用者絕不會加入無效的排程或是我該去檢測該筆是否無效呢？前者即收工，而後者，會不會多此一舉浪費運算資源呢？進而，檢查了，問題是使用者可動態改變系統時間；今之所以會檢查就是為了保留有效者，問題是，使用者反覆更改時間，有效者當可能變成無效，既無效者若有意未刪尚可回成有效者（保不保留佔不佔記憶體又是另一個考量分支），那麼我的檢查有意義嗎？換言之就是不做事就是好事／不檢查；但因此而可能出現一堆 zombies；故，決策而為全刪可能為較適切者！試問，一開始提出疑問的那屬人等，會不會轉而有蔑視的眼光，說，檢查之是做得到的怎沒想到要去做，刪光了，使用者還得再設定一次，程設動指而已，面面俱到做不到嗎？？？？？？？？？？？
  這。。。。。。。。。。。。。
  就算是前面的考量我也想到了，面面俱到做不到嗎？？？？？？？？？？
  那。。。。。。。。。。。。。
  我該怎麼做？
• 這真的又是分隔線
• （所以，）至於動態加入的排程，承稍前靜態的陳述，拾棄掉，即，當改變系統時間全刪後，僅重新巡訪靜態排程。（您會提問為什麼嗎？ken 哥已面面俱到地讓您不提問了！）

20231105 revision

改版這期間，曾針對 system-time 的 polling time 作過調整，有改岔，今修正之。human-motions 的部份也進版為 v.1.3

記錄，實際運行後的維護記錄。
version: 1.3

lion battery 18650 x 2, solar battery x 1 x 9v10w x 220mm x 340mm
（註，當前結論，此太陽能板呎吋與規格算是至少需求了，即，比它小的[嘗試過兩片]，都不足以供應 client 永久運作，
且是在 client 維持在約 20mA idle 才有此永久平衡態。簡言之，此太陽能板，在台南僅提供 20mAH@3.3V 的生存能力[全時]）

# 20231107
    1. server & client restarted.

# 20231229
    0. so far behaved expected.
    1. Server
        bootcnt=58
        52 days 19 hours 35 minutes 56 seconds
        bootcnt reset to 0.
        did not reboot.
    2. Client
        bootcnt=17
        4 days 16 hours 49 minutes 19 seconds
        bootcnt reset to 1.
        rebooted.
    3. batteries seem to remain sufficient.
            but via client::bootcnt, maybe depleted and everyday charged back few.
    known issue: sometimes(maybe 1time/10days, the 1-time lasts 2hr), sensor periodically sensed(per 100seconds) and server beeped.