我們在測試的時候都是用手動執行每個節點,現在要新增一個 Schedule Trigger
節點設定自動化。
如此一來,我們就能在每天起床看到準備好的新聞送到手機上。
在最前面(RSS Read
前)新增一個 Schedule Trigger
節點。
設定每天早上八點執行:
Days
1
(一天一次)8am
0
可以根據你起床的時間,或是其他你希望的時間做更改。
❗這邊有一點要注意,雖然我設定早上八點執行,實際上不一定八點整就會收到訊息,
原因包含以下幾點:
Schedule Trigger
的設計並非用於需要極高精準度的應用,而是在一個大約的時間點觸發。Schedule Trigger
會將這個任務放入佇列中,然後等待被執行。也就是說,你如果要它在一個很準確的時間執行,就不能用 Schedule Trigger
來排程,而是要去用外部的排程服務,並透過 Webhook
節點來觸發 n8n。
對我來說,我覺得它延遲個幾分鐘是可以接受的,畢竟自己起床的時間也不一定,它只要在我起床前有傳訊息就好,所以我還是用
Schedule Trigger
來排程。
假如你真的就是想要它有一個精準的執行時間,那你可以先點進下一篇,裡面有我嘗試過的方法和我失敗的原因。
回來設定 Schedule Trigger
節點~
如果現在是下午,那你要等到隔天早上八點左右才會知道這個節點有沒有成功執行,有點太久了。
所以我們先設定短一點的時間來測試看看吧~
設定成每十秒執行一次,現在按下執行鍵,等待十秒 ⋯⋯
是不是怎麼等都等不到訊息?(我當初就是等了很多次等很久等不到訊息)
後來發現是因為沒有啟動工作流,n8n 有兩種主要的執行模式:
Execute Workflow
時,n8n 會以測試模式執行。這種模式只會執行一次,幫助你測試每個節點的輸出是否正確,不會重複執行。Trigger
規則,在背景自動重複執行。這才是你希望它每 10 秒執行一次的模式。點擊中間的開關(Inactive → Active),之後再去執行一次節點,十秒後就能看到訊息成功傳送囉~
現在有一個新問題:「我啟動工作流以後,還要一直開著瀏覽器它才會運作嗎?」
啟動工作流代表這些節點會在背景持續監控和執行。因為我們是用 Docker 安裝 n8n 容器,
只要你的 Docker Container 持續運作,你的 n8n 就會一直自動化。
換句話說,假如你把瀏覽器關掉了,你的 Docker Container 還在運作,那工作流程就會持續運作;再換句話說,假如你把 Docker Container 關掉了,你的工作流程就會停止。
自動化取決於 Docker 容器。
Docker Desktop → 電腦作業系統(Windows / macOS)
n8n → 電腦上的應用程式(Chrome 瀏覽器)
電腦作業系統關閉 → 應用程式關閉
眼尖的你,有沒有發現執行完後右邊輸出的最下面有一個時區欄位。
我們又有新任務要處理了,身處台灣,它的時區怎麼會是美國紐約呢?
n8n 的排程節點會根據它所在的伺服器時區來觸發,由於我的 Docker 容器預設的時區是紐約,所以它會按照紐約時間來執行。
Docker 容器的預設時區不是固定都會是紐約時間,它取決於以下兩個因素:
n8nio/n8n
)是由 n8n 官方團隊建立的。那我們現在的 Docker 時區不在 UTC +8:00 怎麼辦?
只能透過移除現在運行的 n8n 容器,新建一個時區在 UTC +8:00 的容器。
docker stop 你的Container ID # 停止容器
docker rm 你的Container ID # 移除容器
不用擔心移除舊的容器會讓 n8n 的資料都消失,假如你之前是和我用相同的方式安裝,n8n 的資料都會存在你路徑的資料夾中,如果真的想再確認一下,可以去檔案總管中看有沒有 n8n 的資料夾。
如果有看到 database.sqlite 這個資料夾就表示你的 n8n 資料安全。
docker run -d --name n8n -p 5678:5678 -v 你的路徑/.n8n:/home/node/.n8n --env GENERIC_TIMEZONE=Asia/Taipei n8nio/n8n
現在你只要在瀏覽器中打上 http://localhost:5678
就可以看到 n8n 的網頁了,且資料會和你舊容器儲存時的內容一模一樣!
現在再回去執行看看你的 Schedule Trigger
,輸出的時區應該要是台灣的時區。
按下儲存並且確認你有啟動工作流,設定自動化的任務就完成啦~
之後在你設定的時間就會收到來自 AI 摘要後的新聞訊息了!
做到這邊結束了一個段落,我們這個自動化的新聞小編總算是完成了,下一階段要延伸一些進階的功能,增加 LINE Bot 和使用者的互動性,敬請期待吧!
明天(Day 10)的文章算是一個番外篇,我深刻體會到其實一個目標不是只有一條路能抵達 (但我走了其他條路後發現還是主幹道最好走),一起來看看我解決排程延遲問題的血淚史…