找出port tcp 8888是否被佔用 1 fuser -n tcp -k 8888 -n --namespace search in this name space (file, udp, or tcp) -k- --kill kill processes accessing the named file

原文 Choosing The Right Device Role 出自Meshtastic官方blog，使用gemini進行翻譯並整理 Meshtastic 設備角色配置指南 (Device Roles Guide) 最後更新： 2025 年 9 月 24 日 在設置 Meshtastic 網路時，為每個設備配置正確的角色 (Role) 至關重要。這不僅能優化網路效能，確保通訊可靠，還能避免因角色選擇錯誤而導致的網路擁塞和性能下降。 本指南將詳細介紹 Meshtastic 中常見的設備角色，幫助您根據實際需求做出最佳選擇。 📋 什麼是設備角色 (Device Role)？ 設備角色定義了該設備在 Meshtastic 網路中的主要功能。每個角色針對不同的使用場景進行優化，有助於更有效地管理網路和設備行為。 1. 客戶端 (Client) 定義： 這是設備的事實標準角色。 功能： 一個靈活、通用的角色。它會重複 (Repeat) 和路由 (Route) 訊息。 建議： 如果您不確定該選擇什麼角色，請直接選擇 CLIENT。這是大多數使用場景的安全選擇。 注意： 雖然在技術語境中 “Client” 通常指不轉發訊息的用戶端，但在 Meshtastic 中，CLIENT 確實會重複和路由訊息。請不要因此誤以為它不轉發。 2. 靜默客戶端 (Client Mute) 定義： 類似於 CLIENT，但有一個關鍵區別。 功能： 不重複 (Repeat) 也不路由 (Route) 訊息。 建議： 適合用於網路流量極高的區域，避免額外轉發造成擁塞。 適合擁有多台設備的網格愛好者：將其中一台設置為 CLIENT 或 CLIENT_BASE，其餘設備設置為 CLIENT_MUTE。這可以確保您的空中時頻 (Airtime) 使用更負責任，避免不必要的轉發流量。 3. 基礎站客戶端 (Client Base) 定義： 類似於 CLIENT，但在轉發訊息時具有優先權。 功能： 會優先重複來自或發往其「收藏 (Favorite)」節點的訊息。 建議： 適合用作您的主要基地站 (Base Station)，例如放置在屋頂或閣樓的設備。 將您的主要基地站設置為 CLIENT_BASE。 將其他設備（通常是 CLIENT 或 CLIENT_MUTE）設置為該基地站的「收藏節點」。 這能確保您的強勁、位置優越的基地站能優先處理附近節點的轉發需求。 📡 路由與重複角色 (Router & Repeater) ⚠️ 警告：請謹慎使用！ ...

history指令方便查找輸入過的指令，因預設只有流水號，若要回想是什麼時間下過的，無從參考，因此加上時間戳 bash 在~/.bashrc加入 1 echo 'export HISTTIMEFORMAT="%F %T "' >> ~/.bashrc 執行source ~/.bashrc立即生效，或登出再登入 時間格式，可以參考這裡 zsh zsh不使用HISTTIMEFORMAT變數，直接在history加上引數(argument)即可 單次 1 2 3 history -i history -f history E 永久紀錄 在~/.zshrc加入 1 setopt EXTENDED_HISTORY 執行source ~/.zshrc後生效

專案總結 這是一個使用 ESP32 開發板製作的 網路校時電子鐘。它透過 WiFi 連接到 NTP (網路時間協定) 伺服器來自動獲取並同步標準時間，然後將時間（小時和分鐘）顯示在一個 TM1637 4位數7段顯示器上。 整個專案是基於 PlatformIO 和 Arduino 框架開發的。 https://github.com/IZUMO-F303/ESP32_TM1632_simple_NTP_clock 成果 核心功能分析 從 src/main.cpp 的程式碼來看，這個時鐘實現了以下主要功能： 自動時間同步 (Time Sync): 啟動時同步：裝置啟動後會立即嘗試連接 WiFi 並從 NTP 伺服器（優先使用 ntp.nict.jp）獲取時間。 定時重新同步：每隔一小時 (syncInterval = 3600000 毫秒) 會自動重新進行一次時間同步，以確保時間的準確性。 節省資源：在成功同步時間後，程式會主動斷開 WiFi 連線 (WiFi.disconnect(true); WiFi.mode(WIFI_OFF);)，這是一個很好的實踐，可以降低功耗和網路佔用。 錯誤處理：程式包含基本的超時機制。如果 WiFi 連線或 NTP 同步在10秒內未完成，它會放棄本次同步並在序列埠監控視窗（Serial Monitor）中印出錯誤訊息。 時間顯示 (Time Display): 以「小時:分鐘」的格式顯示在 TM1637 顯示器上。 小時和分鐘之間的分號 (:) 會被持續點亮 (segment_data[1] |= 0x80;)。 亮度自動調整 (Brightness Adjustment): 程式會根據當前時間自動調整顯示器的亮度。 白天 (7:00 - 18:59)：亮度設定為較亮的 0x0f。 夜間 (其他時間)：亮度設定為較暗的 0x08。 專案結構分析 ...

openssl 使用 openssl Base64 編碼 1 openssl rand -base64 32 Hex 編碼 1 openssl rand -hex 32

因為看了平行線交通&旅行頻道介紹JR九州高速船QUEEN BEETLE（目前因傳出船艙進水等等各種醜聞，該航線於2025年2月28日停業），有了想體驗搭船入境日本的計畫。 目前韓國釜山前往日本有兩條航線，一條是抵達日本福岡市博多港的新山茶花號，以及抵達日本山口縣的下關市的關釜渡輪。 關釜渡輪航線上有兩艘船，分別是日籍的はまゆう(HAMAYUU)以及韓籍的SEONG HEE(星希)，每晚間出發，隔日早晨抵達，此次是搭乘韓籍的SEONG HEE前往日本下關 航線資訊 下關 19:45 出發 -> 隔日 08:00 抵達釜山 釜山 21:00 出發 -> 隔日 07:45 抵達下關 旅行登船手續受理時間 下關出發 15:00~18:00 釜山出發 14:30~17:30 最新資訊請參考關釜渡輪官網 購票方式 至關釜渡輪官網線上購票 票價可以參考這 除了船票外，還有附加費用，訂票時不用付，在報到時要使用現金繳納 燃油附加費(下關出發 JPY1,100，釜山出發 KRW11,000) 國際觀光旅客稅JPY 1,000(只有下關出發有，釜山出發沒這筆) 搭乘紀錄 從釜山站有空中步道可以直接步行至釜山港國際客運碼頭，途中都有電動步道，還有遮陽的設計，雨天也不用擔心。 比較早期的資料會建議在草梁站下車，出站後步行前往，現在這個方式已經不建議這麼做，難度都比從釜山站前往還高 釜山站外觀 釜山站旅客大廳 要前往釜山港客運碼前，請往釜山站10號出口 前方棚子就是前往釜山港國際客運碼頭的步道 釜山站與步道的連接處 往釜山港國際客運碼頭的路上 已經能看到客運碼頭與要搭乘的星希號了 抵達釜山港國際客運碼頭 回頭看剛才走過來的路，右上方那就是釜山站 碼頭與釜山港大橋 新山茶花號的櫃台 釜關（關釜）渡輪的櫃台，在此報到，以現金繳交燃油附加費與旅客稅（只有下關出發有這筆稅） 自行車也能上船，也有搭船至日本騎車的人 超大背包客 往下關與福岡的登船時間 ...

緣起 因為接觸 maker 領域後，發現各類端子規格，而且混用混搭的頻率很高，怕自己忘記還可以來這查 電子訊號類 HY2.0 HY 2.0（有時也寫作 HY-2.0）是一種針距為 2.0mm 的線對板 (Wire-to-Board) 連接器。它並沒有一個像 JST 或 Molex 那樣的單一、權威的標準制定者，更像是一種在特定領域（尤其是在中國市場的電子模組、小型鋰電池、風扇等）被廣泛採用的「通用型號」。 主要特點： 外觀：通常是白色或米色的塑膠外殼，外形相對簡單、方正。 固定方式：依賴塑膠外殼上的側邊摩擦斜坡來提供固定力，沒有明顯的卡扣。 應用：非常常見於小型鋰電池的接頭、小型散熱風扇、以及一些開發板模組上。 JST JST(日本圧着端子製造株式会社)推出的一系列對應不同間距的端子 Wire-to-Board Connectors JST series 間距 列數 電流 電壓 lock shroud XH 2.50mm (0.098 in) 1 3 250 NO YES PH 2.00mm (0.079 in) 1 2 100 NO YES GH 1.25mm (0.049 in) 1 1 50 YES YES SH 1.00mm (0.039 in) 1 1 50 NO YES 常用的 JST 端子如下 ...

server 都有提供嵌入式的系統來管理及監控主機，HPE 有 iLO(HPE Integrated Lights-Out)，而 DELL 有 iDRAC(Integrated Dell Remote Access Controller)，除了能以網頁進行管理，同時也提供 API，兩家都使用Redfish這個 API 標準，減少不同品牌間 API 不相容的問題 iLO/iDRAC 登入機制 使用 Redfish API 對 iLO/iDRAC 進行存取時，首先要通過認證，授權用戶才能進行後讀操作，認證方式有兩種 Basic authentication 每次存取 API 時都要帶上帳號與密碼，適合簡單存取 Session-based authentication 先取得 token(X-Auth-Token)，接下來的操作都使用這組X-Auth-Token，最後再結束前再DELETE token，釋放資源 下面以REST Client這個 VS code 工具來測試 API Basic authentication 每次在執行 get mothod 時，在 header 加上Authorization Base <帳號>:<密碼>的內容 1 2 GET https://{{host}}/redfish/v1/SeesionService/Sessions HTTP/1.1 Authorization Base <帳號>:<密碼> cURL版本 1 2 3 4 5 6 HOST="10.10.10.10" # iDRAC或iLO IP USER="username" # iDRAC username PASS="password" # iDRAC password curl --request GET \ --url "https://$HOST/redfish/v1/SeesionService/Sessions" \ --header 'authorization: Basic $(echo -n "$USER:$PASS" | base64)' Session-based authentication 取得 token Basic authentication 是把帳密塞在 header，而這裡是塞在 payload ...

緣由 在使用ESPhome加入SPG30 TVOC sensor時，在元件設定說明頁面看到參數說明 compensation (Optional): The block containing sensors used for compensation. Both values must be supplied in order to be able to generate the absolute humidity to be reported to the sensor. temperature_source (Optional, ID): Give an external temperature sensor ID here. The data must be in Celsius. This can improve the sensor’s internal calculations. humidity_source (Optional, ID): Give an external relative humidity sensor ID here. This can improve the sensor’s internal calculations. ...