Sporting coding note

總算把原本用 python2 寫的 line bot 改成 python3 了。 有鑑於 python3 的成熟度越來越高，加上許多 library support； 以及目前正悄悄進行的 line bot 新功能 (先賣個關子)。 索性把整個平台轉到 python3 上， 這邊標注一下遇到那一些 python2、python3不同的地方(一小部份) Python2.7 Python3.4 備註 / / → int / → float; // → int urllib urllib.quota urllib.parse.quota urllib urllib.urlopen urllib.request.urlopen urllib urllib.urlencode urllib.parse.urlencode sys sys.maxint sys.maxsize The sys.maxint constant was removed, since there is no longer a limit to the value of integers. However, sys.maxsize can be used as an integer larger than any practical list or string index. It conforms to the implementation’s “natural” integer size and is typically the same as sys.maxint in previous releases on the same platform (assuming the same build options). https://docs.python.org/3.1/whatsnew/3.0.html#integers range xrange range python2 xrange = python3 range，pytho...

來看看 Line 收到訊息的畫面 落落長，不過也就兩種訊息，一個是開發版接上電源並且連上wifi後，會自動發送的初始化訊息，訊息內容展示 IP 位置，可以透過瀏覽器連上此位置做開發版設定，當然初始化訊息是可以客製的，等會會展示設定的頁面。 另一個訊息是當開關被觸發時，發送出來的訊息，罐頭訊息一多起來，連最後一點美感都蕩然無存了，有人有好想法美化罐頭訊息嗎？歡迎跟我分享。 接下來就是設定頁面的展示 首頁 Sensor Behavior 設定門窗開關感測器的行為 AP Configuration 開發版到一個新的wifi環境時，提供 AP 功能用以設定 wifi 環境使用的 SSID、Password、IP 位置 WIFI Configuration 設定接上電源後連接的 wifi 帳號密碼 Line Notification 設定要通知的 Line ID、客製化訊息內容 Chart Display 記得前面一篇架構圖裡有畫到 firebase 的部份嗎？運用資料然後透過 HighChart 做資料的展示 About 就是關於我啦！ Sensor Behavior Name 這個裝置的名字，放在大門口所以叫做 Front Door，可以視放置位置命名，用來辨識哪個裝置發出的訊息 Trigger 門窗開關感測器觸發動作可以有關閉時觸發或是打開時觸發 Power Save 省電設定，裝置作用的過程，最耗電的就是wifi連線，為了省電，可以設定每次觸發Line通知後，隨即斷開wifi。 但是一旦開啟之後會有兩個問題： 一是因為沒有一直連接wifi，所以無法使用頁面設定的功能，如果有設定的需求，必須重啟電源，設計在電源接上的初始階段，會連著wifi，此時就可以使用頁面設定功能。  二是當開關被觸發時，無法隨即送出訊息，必須重新連上wifi再發送訊息，測試會有1~5秒不等的延遲，視當時的網路狀況而定。 Sensitivity 觸發幾次才發送訊息，最左邊的High表示觸發1次就發送訊息 Reset Timer 設定觸發過後一段時間內，不再觸發，以免過多重複訊息的發送，影響體驗（原本在家使用，設定10秒，但是開關門還是各被觸發一次，因為開門之後會摸來摸去，就超過10秒了） AP Co...

最近在玩聊天機器人，機器人除了在聊天過程中解決前端使用者的需求或問題，沒看到多少人寫主動通知這部份的文章。 還記得幾年前如果要通知前端使用者，大多採用簡訊通知的方案，在 server 端綁個 cgi 程式呼叫電信公司提供的 dll。 這些聊天平台開放了機器人的 api，間接取代傳統的簡訊通知方案，傳統簡訊方案依簡訊量計價，聊天平台訊息卻是幾乎免費，電信公司簡訊業務或是提供簡訊發送平台的未來是可以想像的慘呀！ 目前試了兩個平台，分別是 line 跟 telegram，先不論 webhook server 的建置，單論直接下指令發送訊息就好，兩個平台都可以作到，當然 telegram 方便的多了，telegram 有提供 web api 直接用 http Get method 呼叫，網址打一打就可以了， 如果不考慮台灣聊天平台的使用率 （Line 的台灣使用者很大量呀！），telegram 真的是滿推薦的。 -- 2017/1/25 補充 Line 透過命令列發送訊息如下 curl -X POST -d '{"to":"<USER ID>", \ "messages":[{"type":"text","text":"<MESSAGE 1>"}, \ {"type":"text","text":"<MESSAGE 2>"}]}'  \ -H 'Content-Type:application/json'  \ -H 'Authorization:Bearer <LINE ACCESS TOKEN>' \ https://api.line.me/v2/bot/message/push Telegram 透過 http url 發送訊息如下 https://api.telegram.org/bot<ACCESS TOKEN>/sendMessage?chat_id=<CHAT ID>&te...

 實做了一些平常會用到的功能，有即時訊息通知平台，互動上更加直覺了。 原本我也期待透過一些語意分析的工具，了解語意後再進行處理，但是經過自己使用習慣上的分析，其實用選單方式表達需求更加明確，使用語意分析工具，建立 pattern、分析 intent，偏離了原始的目的。 這改變讓我不需要為了使用工具，還要輸入自己設計的關鍵字來觸發聊天機器人功能。 透過其他 api 提供的功能實做就不提了，花最多時間的是在聊天互動的操作，在聊天室裡每一個訊息都是獨立的發送著，隨著思緒及關卡會產生下一個對話結果，那在程式設計上要怎麼把好幾個訊息組成一個清楚可執行的指令呢？在我設計的對話路徑上，先表達主要目的，例如我要把youtube影像轉成音樂檔，接著 bot 問第一個問題，請輸入youtube 影像網址，依使用者輸入的內容，決定是否可開啟下一個對話，即資料的檢核，檢核成功則進入下一個對話，檢核失敗則可以跳出該對話，或是重新輸入上一個需求內容；直到最後一個問題的答案收集完畢後，再依據這些問題的答案產生結果，回報使用者。 先決定要執行的功能選項 -> 下一個問題 -> 下一個問題 -> 下一個問題 ... -> 產生結果 這裡我們把"問題"用 intent 這個詞來表達。 上面這個循序圖，每一個階段都是獨立的，只是前一個 intent 仰賴的資料都需要透過其他的方式得到資料，聊天機器人就是透過對話，得到需要的資訊。 資料結構使用 stack，每一個 intent 的生命週期是 啟動對話 -> 檢核答案 -> 續問下一個 intent -> 產生結果 在 續問下一個 intent 的這個階段會堆疊到 stack 裡，最後 intent 問完了，再把 intent 一個一個 pop 出來產生結果。 在 user session 的處理上，使用 redis 紀錄單一使用者的對話過程 （redis 是好物呀！）  

    標題不知道要怎麼下，意思是說除了下指令給 bot，bot 會回覆相關資訊之外，還可以主動發訊息給指定的 Line 用戶 (當然，前提是這個 Line 用戶需要加入 bot 為好友）。 Line Messenger API 除了提供 reply_message 的方法之外，還有提供 push_message 的方法。     reply_message 顧名思義是當用戶發出訊息給 bot，bot 針對這一個訊息所作的回覆，經測試發現一個 reply token 只能回覆一次，無法針對同樣一個 reply token 一直傳訊息，意思是一個 reply token，只能用一次 reply_message，不過一次 reply_message 可以傳入多個訊息就是了。     另外一個測試發現 reply token 有它的生命週期，bot 在處理用戶訊息如果過久未回覆，reply token 也會失效；那如果真的需要長時間處理的動作該怎麼辦呢？這邊建議可以使用 push_message 的方式，在用戶發出訊息時，可以取得用戶 ID，在處理完畢後，針對這個用戶 ID 傳送訊息，就會很像 bot 針對訊息回覆的情境。     離題了，這次主動通知系統用了 push_message 做了什麼呢？     其實就是 server 排程作業結果回報通知，排程作業各位可以想看看能做什麼，我是用來做小米商店商品開賣通知，因為小米商店常常缺貨，但是又很想要這商品，又不想從大陸買進來（擔心保固、電壓、插座、運送等問題）。在 web server 上實做了傳訊息給 Line 用戶的 push line api，排程作業透過 curl 呼叫 push line api。 示意圖如下

如題，有興趣試用的可加入或加入再封鎖。 ps. 個人電腦充當Server，效能不彰、隨時無回應，如果能接受就加吧！

繼上上次 FB Messagenger bot   及上次的 Line bot 學習製作的過程， 對於聊天機器人"聊天"這檔事有了一些體悟，所以寫下來供作參考。 先回顧一下 FB Messenger bot 開發經過，首先 FB 在今年年初推出了 Message Platform，自己興致勃勃的找了些教程，用 node.js 開發並佈署在 heroku.com。 FB 提供了一個大～平～台（王大陸～原諒我很想寫這個爛梗)，讓大家可以透過 Messenger，從後台接收訊息及發送訊息到客戶端。 說穿了，這些聊天平台將自己的服務跟各個企業的商業服務做個管道出來，對於聊天平台跟其他運用這服務的企業算是雙贏的局面，一方面替自己衝使用量，佔據社群軟體的榜首，一方面替企業精簡人力、擴大銷售。 聊天平台原本的社群服務加上企業原有服務，透過 "聊天機器人" 這個溝通管道，更加強了雙方的連結。 軟體架構其實是相對的單純，撇除聊天平台原本的溝通界面服務、、各大企業原本也有相應的網路服務，透過 sdk 交換雙方的訊息也不難。 終端消費者在聊天平台提供的界面上打打字，透過 sdk 交換訊息到企業網路服務，企業網路服務接收訊息後回應終端使用者，最終達成終端使用者的目的。 目前看似一切都在既有的服務上作業，sdk 使用上也簡單，那問題在哪裡？ 問題就在 "聊天" 這檔事，如果消費者打了某段訊息，例如"我要買電視"，企業接收訊息後判斷有"電視"兩個字，就推出自家電視產品廣告；那這跟透過指令界面一個口令一個動作有什麼不同？ 萬一消費者打的訊息內容是 "我要買可以當電視的平板電腦"，結果推薦的是電視，那會有多囧，我要是消費者馬上就跳開這個平台，不好玩又亂推薦。 關於 "聊天" 這檔事，雖然日常生活無時無刻都在聊天，認真分析起來，聊天機器人真是呆板的可以，但是還是要努力不要讓他/她變成"它"，我們還是期待機器人是個人呀！ ok google、siri 這樣聰明的個人管家跟聊天機器人的目的性不同，聊天機器人的聊天支線、主題比較可以聚焦。 關於聊天機器人 "聊天" 這檔事，列下四點： 1. 單一時間點的討論只會圍繞單一個主題，...

請參考我的 github WebServLineBotDocker

上次在不清不楚的情況下，實做了 facebook messenger bot，做是作起來了，當下也了解到平台實做不是最大的問題，問題在客戶（使用者）在表達什麼意思，如果是文字對話，就是自然語言的辨識，也就是 AI 的問題，網路上有許多 bot ai 製作工具，我沒用過，倒是這幾天有看到微軟出的 bot framework，似乎也是個方法。 這兩天再接觸了 Line Messenger API，對照之前使用 facebook bot api 的經驗，可以發現各家對於 messenger api 作法都很相近，似乎對於這樣的架構頗有共識。 不多說，從使用 bot api 的經驗去想像整體架構，用一張圖來表達

如果各位是跟我一樣，對新平台、技術有高度興趣，這次看到了 Facebook F8 開發者大會，對 Facebook messenger bot 有興趣， 想實作自己的機器人，卻沒有相關背景、Know how 的人，來這就對了，我花了一兩天的時間，確確實實的把這服務建置起來。 網路上絕大部份都是以 node.js 為範例，當然還有其它的像是python django，對於這些名詞(node js. python. django)僅止於知道的我來說， 等到學會上手都不知道幾年後了，我還是習慣作中學，雖然過程坎坷，但是中間產生的問題，會擴大自身對各技術的初步了解； 扯遠了，重點是平台的選擇，對我來說還是選最多資源的教程，也就是 node.js。 ps. 好歹要知道這些技術名詞在作什麼，才有辦法繼續往下作吧。 對這議題我的背景程度大概是 ndoe.js: server side javascript. (全知全能的 javascript) python: script language. (有在網路上學過 tutorial) django: python's web framework. (有裝過這個 framework) 一開始對這個 facebook messenger bot 的架構不清楚，不知道應該具備什麼技術或是平台或是套件才能建起來。 作完之後，再回頭看才比較清楚整個架構，也知道在這些點上，需要的資源是什麼。 就讓我大略把架構畫出來，有經驗的人一看就知道在那些點會需要那些服務跟資源。 到這裡，各位已經比我當時不清不楚、傻傻就決定要花時間作一個自己的機器人還站在更有利的位置了。 所以需要的東西有什麼呢? 1. 提供網頁服務的主機 (我一開始傻傻的以為只需要將代碼寫在 facebook 的開發者平台上就好了) 2. 接收/回應 facebook 送過來訊息的代碼 就這麼簡單，可是 facebook 的官方教程對我這樣非網頁開發背景的人來說，實在很難理解，跟著教程走還是會有問題。 所幸找到一個更完整的教程，雖然我已經花半天的時間了。 分享給大家 messenger-bot-tutorial 這篇太讚了，非常完整的教程。 這樣還要寫正文嗎? 大家直接看 github 就好了...XD 那....