車牌識別一體機 – 網車牌識別一體機 – 不開閘問題排查指南
車牌識別一體機 – 網車牌識別一體機 – 不開閘問題排查指南
當項目出現不開閘現象，請按照以下步驟進行排查
特殊車牌設置
第一步：查看不開閘車牌類型，并進入到特殊車牌（基本設置/輸出聯動/特殊車牌）查看是否和不開閘車牌類型一致，如一致且沒有使用白名單或特殊業務需把如下頁面的勾選項取掉。
注解：特殊車牌：勾選此處的車牌類型，一體機默認為不開閘。如需特殊車牌放行需在輸出配置（基本設置/輸出聯動/輸出配置）進行配置。
默認GPIO開閘時間過短
第二步：默認GPIO開閘時間（基本設置/輸出聯動/GPIO開閘）設置時間過短。
注解：部分道閘存在默認開閘時間長，一體機發出開閘信號過短，道閘靈敏度不夠會引起不開閘。
觀察日志
如果上面的方法排查都是正確的，那么可以通過技術手段來嘗試排查是否有問題。
我們設備最終的目標是要將識別結果發送給客戶使用，一個算法識別到結果之后，會有四種情況來處理識別結果。
1.有可能是通過SDK使用TCP協議來處理識別結果。
2.有可能是通過HTTP協議來處理識別結果。
3.有可能是通過內部的OpenSDK來處理識別結果。
4.有可能是通過內部的輸出聯動來處理識別結果。
但不管是什么方式處理，他們最終都會產生一個GPIO OUT信息來進行開閘。在日志上就會顯示如下的信息。
如果沒有在日志上面看到這個消息，那么就證明是處理上出現了問題。在這種情況下需要更加深度的排查出現了什么問題。我們先從最簡單的方式查起。
先確定客戶是使用什么方式來進行開閘業務處理，然后按照下面的形式來進行。
OpenSDK
通過admin賬號登錄設備，看看這一臺設備是否存在用戶的userapp，一般有UserApp的設備都會接管系統的GPIO OUT輸出和RS485輸出。這種情況下，雖然看起來一切正常，但是UserApp出了問題沒有發送開閘消息，則就會出現問題。
驗證他的方法就是將UserApp程序刪除，同時重啟設備，使用最基本的輸出聯動的方式來判斷設備是否有開閘輸出。如果還沒有，就證明是我們自己的設備有問題，如果有，就證明是客戶的UserApp引起的問題。
輸出聯動
首先確保以下幾件事情
1.沒有用戶通過SDK連接上設備（可以改一個IP地址）
2.HTTP推送里面也沒有開啟
3.設備內部也沒有UserApp在運行
4.白名單設置是啟用狀態。
這種情況下配置輸出聯動，查看設備是否有GPIO OUT輸出，如果有就證明設備正常，如果沒有證明設備有問題。
HTTP推送
如果用戶是通過HTTP推送的形式來進行的開閘，則通過網頁上面的日志觀察是否HTTP推送服務器是否正常響應命令、是否有正確的返回開閘請求。之后做同樣的判斷。
如果不開閘的情況很難重現一次，可以使用提供的長時間日志收集工具進行日志收集，直到問題出現了，就可以分析哪里出現了問題。
SDK處理識別結果
如果客戶是通過SDK連接的我們設備，這種情況下可以通過日志上面看出來客戶是否連接，是否發送了開閘消息。同樣為了更好的幫助客戶排查問題，我們可以提供長時間的日志收集工具和帶打印的SDK來進行長時間的掛機，以確認客戶是否有問題。
其它可能的現象
上面的情況是一般的現象，但是可能還會有其它的現象。以下是其它現象的一些匯總?？梢砸灰慌挪?。
1.設備是否在有效期內。先檢查手動觸發是否能夠在網頁上面輸出結果。我們設備有一個有效期的功能，如果設備不在有效期內，即使識別到車牌，都不會有識別結果輸出的，這種情況下，自然不會開閘。
2.是否有設備不穩定重啟、掉線的情況發生。如果在使用過程中，設備出現了網絡異常、重啟的現象，那么這中間完全有可能造成客戶端連接不上，無法發送開閘命令的現象。
當項目出現不開閘現象，請按照以下步驟進行排查
特殊車牌設置
第一步：查看不開閘車牌類型，并進入到特殊車牌（基本設置/輸出聯動/特殊車牌）查看是否和不開閘車牌類型一致，如一致且沒有使用白名單或特殊業務需把如下頁面的勾選項取掉。
注解：特殊車牌：勾選此處的車牌類型，一體機默認為不開閘。如需特殊車牌放行需在輸出配置（基本設置/輸出聯動/輸出配置）進行配置。
默認GPIO開閘時間過短
第二步：默認GPIO開閘時間（基本設置/輸出聯動/GPIO開閘）設置時間過短。
注解：部分道閘存在默認開閘時間長，一體機發出開閘信號過短，道閘靈敏度不夠會引起不開閘。
觀察日志
如果上面的方法排查都是正確的，那么可以通過技術手段來嘗試排查是否有問題。
我們設備最終的目標是要將識別結果發送給客戶使用，一個算法識別到結果之后，會有四種情況來處理識別結果。
1.有可能是通過SDK使用TCP協議來處理識別結果。
2.有可能是通過HTTP協議來處理識別結果。
3.有可能是通過內部的OpenSDK來處理識別結果。
4.有可能是通過內部的輸出聯動來處理識別結果。
但不管是什么方式處理，他們最終都會產生一個GPIO OUT信息來進行開閘。在日志上就會顯示如下的信息。
如果沒有在日志上面看到這個消息，那么就證明是處理上出現了問題。在這種情況下需要更加深度的排查出現了什么問題。我們先從最簡單的方式查起。
先確定客戶是使用什么方式來進行開閘業務處理，然后按照下面的形式來進行。
OpenSDK
通過admin賬號登錄設備，看看這一臺設備是否存在用戶的userapp，一般有UserApp的設備都會接管系統的GPIO OUT輸出和RS485輸出。這種情況下，雖然看起來一切正常，但是UserApp出了問題沒有發送開閘消息，則就會出現問題。
驗證他的方法就是將UserApp程序刪除，同時重啟設備，使用最基本的輸出聯動的方式來判斷設備是否有開閘輸出。如果還沒有，就證明是我們自己的設備有問題，如果有，就證明是客戶的UserApp引起的問題。
輸出聯動
首先確保以下幾件事情
1.沒有用戶通過SDK連接上設備（可以改一個IP地址）
2.HTTP推送里面也沒有開啟
3.設備內部也沒有UserApp在運行
4.白名單設置是啟用狀態。
這種情況下配置輸出聯動，查看設備是否有GPIO OUT輸出，如果有就證明設備正常，如果沒有證明設備有問題。
HTTP推送
如果用戶是通過HTTP推送的形式來進行的開閘，則通過網頁上面的日志觀察是否HTTP推送服務器是否正常響應命令、是否有正確的返回開閘請求。之后做同樣的判斷。
如果不開閘的情況很難重現一次，可以使用提供的長時間日志收集工具進行日志收集，直到問題出現了，就可以分析哪里出現了問題。
SDK處理識別結果
如果客戶是通過SDK連接的我們設備，這種情況下可以通過日志上面看出來客戶是否連接，是否發送了開閘消息。同樣為了更好的幫助客戶排查問題，我們可以提供長時間的日志收集工具和帶打印的SDK來進行長時間的掛機，以確認客戶是否有問題。
其它可能的現象
上面的情況是一般的現象，但是可能還會有其它的現象。以下是其它現象的一些匯總?？梢砸灰慌挪?。
1.設備是否在有效期內。先檢查手動觸發是否能夠在網頁上面輸出結果。我們設備有一個有效期的功能，如果設備不在有效期內，即使識別到車牌，都不會有識別結果輸出的，這種情況下，自然不會開閘。
2.是否有設備不穩定重啟、掉線的情況發生。如果在使用過程中，設備出現了網絡異常、重啟的現象，那么這中間完全有可能造成客戶端連接不上，無法發送開閘命令的現象。
