Yeelink 上傳數據在 00:00 突然中斷

Super169

最近測試 物聯網系統, 由於找到了一個 yeelink 的簡單例子, 就改成自己的傳感作測試.

測試了一星期左右, 發覺有個怪現象, 就是執行一段時間後, 會自動停止了.
再三檢查數據, 發覺有問題的都是在 00:00, 但並非每日的 00:00 都會出問題.
而且只要停了後, 斷電再來, 又可以再執行幾天.

為免是自己的程式出問題, 嘗試直接用官網的例子 (http://blog.yeelink.net/?p=34), 改成自己的 API, DEVICEID, SENSORID, 上傳一系統 random number.
由於不涉及傳感, 而且全是官網的程式, 心想應該沒問題吧.  最少不會因為程式或傳感出錯而停止.
豈料還是會在晚上 00:00 停止了上傳.




由於程式沒有輸出裝置, 只好細心研究程式,   發覺最大可能出現 停止是這部份:

1. if(!client.connected() && (millis() - lastConnectionTime > postingInterval)) {
   
2.     // read sensor data, replace with your code
   
3.     int sensorReading = readLightSensor();
   
4.     //send data to server
   
5.     sendData(sensorReading);
   
6. }

复制代码

時間過了, 但 client.connected() 成立, 因為 如果 client.connected 一直成立, loop() 內就只有不斷更新 lastConnected 的狀態, 而不再傳送.
而 client.connected 一直成立, 很可能是伺服器沒有 close connection.  難道每日 00:00 伺服器會有什麼特殊行動, 影響了連線?

請問有沒有其他朋友在使用 yeelink 中, 遇到類似問題?

darkorigin

这种问题最好自己DEBUG
比如连接到电脑 然后同步输出数据给电脑 包括状态信息。
这样就可以分析出来到底是哪个环节出了问题
比如是套接字 client.connected 出的问题还是什么
有个小问题 就是路由器设置的IP租用时间 如果时间过短 到了租用时间后 需要重新获取IP 。
你用上面的方法就会发现 发送到网站错误。
还有可能就是网站突然卡了 数据就断了。也有可能
一般单片机不同于常见的电脑 宕机会自动重启的（软件狗功能）

Super169

darkorigin 发表于 2014-9-21 21:25
这种问题最好自己DEBUG
比如连接到电脑 然后同步输出数据给电脑 包括状态信息。
这样就可以分析出来到底是 ...

謝謝.

但奇怪的是, 每次都是 00:00.  已經不是一兩天的事, 而且我用另一塊 mega 板試, 也是一樣.
由於我沒加上時鐘模塊, 對 arduino 板而言, 根本不知現在是什麼時間, 但每次也是 00:00, 應該是其他地方出事.

本來想修改程式, 加入 顯屏, 但由於加入了 網路後, 記憶體已幾近淘空了, 嘗試再加上 OLED 的庫, 每次執行不久就會重啟, 應該是 SRAM 不足出現問題了.
我亦嘗試了幾晚, 在 11 時許轉由 PC 連線, 收取 Serial.print 的 debug 訊息, 但就在我測試的幾天, 都可以順利過渡 00:00.
已訂了一片 串口的屏 (唉...可惜中港通關近日出了問題, 還未送到), 希望可以不用再加庫, 只作串口輸出而發出 debug 訊息, 將來就可以較容易地長時間監察問題了.

darkorigin

Super169 发表于 2014-9-22 09:39
謝謝.

但奇怪的是, 每次都是 00:00.  已經不是一兩天的事, 而且我用另一塊 mega 板試, 也是一樣.

一般来说
这种问题 如果2块板子都出问题 那么排除法来说 2块板子同时硬件故障的可能极小。
软件问题 出问题的可能性最大的还是在网络方面
因为单纯运行 即便是寄存器溢出只会是得到错误的值而不会出现你说的这类问题。
寄存器溢出会导致内部计时归零。

简单的模块 没必要使用屏幕来DEBUG 直接用上位机串口工具进行分析即可。这样代码也简单 调试也容易
屏幕则麻烦不少。而且DEBUG代码太多 效率就低了。
串口工具有能显示时间的 也可以自行定制。其实都很方便的

Super169

darkorigin 发表于 2014-9-25 12:09
一般来说
这种问题 如果2块板子都出问题 那么排除法来说 2块板子同时硬件故障的可能极小。
软件问题 出 ...

謝謝你的提議.

簡單的方法都試過了, 就是找不出問題來.
如果連上電腦, 都沒有問題, 就是讓它自己去跑, 就會突然出問題.
而且, 不是每天都出問題的, 但出問題的時間, 就一定是 00:00.
整個系統沒有裝上時鐘模塊, 而每次啟動的時間也不定, 單從系統中, 是無法知道是什麼時間的.
就是要寫一個程式, 令它每天 00:00 做某件事, 也是不可能的.  
所以, 由系統或程式出問題而造成的可能性極低.

有點懷疑是網路上出了問題, 而導致系統長期在等待某些訊息.
因此才會想到接上屏幕, 讓它自己去跑, 看看出問題之前在做什麼.
當然, 我也不能肯定, 裝上屏幕後, 會不會再出問題.

現在每分鐘上傳一次資料, 每次上傳後有 30 秒以上的等待時間, 所以加入 debug code 對效率的影響可以忽略.  
昨天總算解決了 TFT 屏的另一個古怪問題, 幸好用 USB 火牛供電可用.
昨晚開始執行不斷更新 random number 的程式, 同時不斷在 TFT 中輸出 時間資料.  今早起來一切正常, 讓它多跑幾天看看, 希望可以找出問題所在.