IOT系統中利用LED燈來呈現運行中之各種訊息

五月 1

Posted by

IOT系統若使用MCU來傳送或接收訊息，會有許的訊息需要呈現，如果採用4 Pin 的RGB LED來呈現其訊息，我們可以從常開、常關或者閃爍來呈現其訊息，我們將現有的4 PIn的LED可以呈現訊息，分成：
1. 常關 一種
2. 常開RGB 三種
3. 長閃爍RGB 三種 －－ 定義為亮0.5秒及暗0.5秒，
4. 短閃爍RGB 三種 －－ 定義為亮0.1秒及暗0.1秒
這樣以上就共10種的訊息呈現於使用者。

如果是使用micropython 來用在ESP32 MCU中，其程式如下：

from machine import Pin
import time

flash_r = Pin(13, Pin.OUT)
flash_g = Pin(12, Pin.OUT)
flash_b = Pin(14, Pin.OUT)


def long_flash(led_color):
led_color.value(1)
time.sleep(0.5)
led_color.value(0)
time.sleep(0.5)

def short_flash(led_color):
led_color.value(1)
time.sleep(0.1)
led_color.value(0)
time.sleep(0.1)

張貼於行動行銷

發表留言

強電與弱電的區別

三月 22

Posted by

電力系統中，強電與弱電有著不同的特點：

  1. 頻率不同：強電通常運作在60赫茲（Hz）的頻率，被稱為「工作頻率」，而弱電則常使用高頻或特高頻，以千赫茲（KHz）或兆赫茲（MHz）計算。
  2. 傳輸方式不同：強電主要透過電力系統的有線線路傳輸，而弱電則包括有線和無線傳輸，無線通常透過電磁波傳輸。
  3. 功率、電壓及電流大小不同：強電使用千瓦（KW）、兆瓦（MW）計算功率，伏特（V）、千伏（KV）計算電壓，安培（A）、千安（kA）計算電流；弱電則使用瓦特（W）、毫瓦（mW）計算功率，伏特（V）、毫伏（mV）計算電壓，毫安（mA）、微安（uA）計算電流，並且使用印刷電路或集成電路構成電路。
  4. 強電中也有高頻與中頻設備，但電壓和電流較高。現代技術的進步使得弱電技術應用到強電領域，如電力電子器件和無線遙控，但這些僅算是強電中的弱電控制部分，與強電本身仍有所不同。

強電主要傳導電能，而弱電則主要傳導信號。因此，我們可以通過傳導的內容來區分強電和弱電。舉例來說，即使一些設備如電動刮鬍刀或手電筒只需兩節乾電池（3V）供電，我們不能將其視為弱電，因為它們傳輸的是電能而非信號，因此仍屬於強電範疇。

總括的來說，高壓系統一定包括強電，但強電不一定涉及高壓；低壓系統一定包括弱電，弱電一定屬於低壓；低壓不一定代表強電，強電也不一定就是低壓。

張貼於行動行銷

發表留言

標籤： , ,

從Dialogflow到NLU

三月 8

Posted by

Natural-Language-Processing.png

在2018年看到國外Google home的熱銷，引起我對Google Assistant的興趣，進而開始研究Dialogflow。經由Dialogflow串接外部API(用php & node.js 來串接Bitcoin exchange Rate & 新北市即時停車位)，了解到意圖(intent–>想要做什麼)、實體(entity–>)到回應的動作(Action):如:

“我想在新北市的中和路停車"這句話可以分解出意圖及實體，其中"停車"是意圖，而"台北市仁愛路"是實體，那回應的動作則是從新北市即時停車的開放資料(open data) 找到資訊，然後回應的使用者的裝置上。

因為Dialogflow把意圖、實體及回應方式做了整體的處理，開發人員只要專注於Action的介面串接上即可；Dialogflow尚未被Google併購之前，api.ai提供了Api, 讓開發人員可以輕鬆串接到自己的應用程式內，但併購之後，我就沒有用他們的介面，但這也開啓我對中文自然語言理解能力NLU的研究。

意圖、實體及回應對於自然語言理解能力NLU（Natural Language Understanding）是相當重要的訊息，如果要電腦讀懂自然語言，當然要把意圖及實體擷取出來，而回應的部分，可以使用自有資料庫資料、開放資料或者是Google 查詢出來的資訊。

了解了NLU之後，你會發現中文自然語言理解能力，還需要做中文的斷詞(使用Jieba)及斷詞後字的向量(word2vec)做處理，對於大量中文訊息的來源，最佳選擇應該就是wiki；將wiki約將1.8G的資料轉換成可用的資料。

為了進一步了解NLU，當然，對於python在AI上的許多分析套件，就必須要有一些了解，尤其對中分文字的分類方法CNN neural network…等等；

經歷許久的測試，我即將把中文NLU轉換成可應用的程式呈現網路上…可能串接到臉書及LINE等等應用….，敬請期待…..

 

 

張貼於行動行銷

發表留言

PHP laravel程式與會計系統&電子發票

PHP laravel程式與會計系統&電子發票

二月 22

Posted by

創業初期的人，都會有一個很大的困擾，就是記帳的問題!

大多數創業者，都不想花時間在理解會計在什麼，所以，會把這樣的工作交得記帳士來處理，有時遇到好的記帳士，可以幫你解決許多的問題，如果遇到不好的記帳士，那一堆的苦水………

去年，我花了一些時間在看不同的會計軟體，後來找到一款以PHP laravle 架構撰寫的開源免費的會計軟體—https://akaunting.com/。accounting-online.png

因為自己對於不懂會計，所以應用程式安裝之後，也很少動它；最近因為有朋友談到電子發票的問題，才想，如果，我把這個應用程式加上一個模組，也應該可以把它做成轉換成電子發票可以用的應用程式! 所以，花了一些時間，寫了一個模組，將這個會計的應用程式生成的訂單，轉換成可以上傳到則政部電子發票的格式(目前是串接在某一電子發票加值中心)。如果，您想要有可以100%掌控您自的財務資料的人，您可以使用這個會計軟體，若是您需要上傳電子發票，那我也可以協助您。

雲端伺服器: DigitalOcean (LAMP)
程式語言: PHP + MYSQL 
框架: Laravel 5.2
網址: https://akaunting.com/ (提供App的廠商, 可以到網站下載, 有繁體中文)
dd

張貼於行動行銷

發表留言

PM與寫Code工程師

二月 22

Posted by

我以前的工作的角色偏多於業務及專案經理，也就是規劃網站內容及與客戶溝通，然後交付工作給寫CODE的工程師，請工程師按照我規劃的內容，用程式方式呈現出來!

我在規劃網站時，會花許多時間在研究市場上類似的服務或相關的應用及技術!所以，只要我在網路上可以Google到的技術且符合專案的需求，在規劃網站時，就會以剪貼方式，把參考的技術或網站標註於規劃書中，雖不是有創意，但可以讓工程人員從規劃文件中，看到系統想要呈現的模樣!

當規劃內容交付給工程師之後，大多工程師都會以常會要求這裏要改改那裏要改改，因為這些修改，大多是片段的需求而做的調整，而這個片段的調整，未做全盤性的深入探究，到最後專案完成後，專案的結果與文件上預期結果有所差異，這也常常造成PM與寫CODE人之間的對立。

後來，因為工作的需要，也開始扮演起寫CODE的工程師角色(對程式的掌握度較差)，所以，自己是PM之外，也是程式人員，就好像一個專案，從左手交給右手，讓左右手於大腦間做深度溝通! 在這樣的工作過程中，發現:

規劃的內容，因為大多數的功能操作流程都是Google來的，也就是說，只要有人曾經做過，自家的工程師，也應該可以完成這樣的功能及流程；但，自家的程式人員，或許對規劃文件的中的某一流程及功能可能不熟悉，或者他們專注於其它領域; 而PM人員常常為了要求工程人員達成某一特定功能的流程，讓程式人員花了很多時間在Google及嘗試，耗費專案的許多的時間。

  • 有些專案，它在意的是功能是否達成，而不是要特定流程所達成之功能；就像從台北到高雄，可以搭車、坐高鐵，也可以騎腳踏車，如果，只要到可以到高雄，什麼方法都不在意時，從時間及效益，就可以找到一個適切的平衡點。
  • 有些專案，它在意是流程及功能，如果沒有在規劃文件的操作的過程，就算功能達到也沒有意義。

如果寫Code的工程師與PM可以在相同的認知及理解下工作，應該會有不錯的成果….

dd.jpg

 

張貼於行動行銷

發表留言

← Older Posts