.jpg)
Giải pháp bao gồm Thingy:91 của Nordic Semiconductor với phần mềm tùy chỉnh dựa trên mẫu nRF Connect SDK (ncs). Thiết bị đã có tất cả các thành phần phần cứng cần thiết, vì vậy nó thực sự là phần cứng có sẵn. Thiết bị gửi dữ liệu tần số cao đến đám mây ThingsBoard qua CoAP và truyền dữ liệu tần số thấp đến đám mây nRF qua MQTT.
Đây là một dự án DIY vì nó phù hợp với các kỹ năng bạn có, phần cứng bạn có và những gì bạn cần cho công việc. Có nhiều cách khác để đạt được cùng một mục tiêu.
Như với bất kỳ dự án nào, chúng ta phải bắt đầu bằng các yêu cầu của dự án.
nhu cầu
Tôi đang tìm cách xây dựng một giải pháp có các tính năng sau:
- Thiết bị bao gồm:
- Cảm biến có thể đo độ rung
- Modem di động
- Giá cả không đắt.
- Sử dụng pin (có thể sử dụng trong nhiều ngày mà không cần sạc)
- Hãy độc lập
- Có thể lưu kết quả đo lường (mẫu) và tải chúng lên máy chủ (đám mây).
- Tần suất lấy mẫu là 1 mẫu sau mỗi 1-20 giây.
- Độ trễ phải dưới 10 phút, tốt nhất là dưới 1 phút.
- Một giao diện web nơi kết quả có thể được xem dưới dạng biểu đồ theo thời gian thực.
- Một backend có thể lưu trữ dữ liệu trong ít nhất một tuần
- Khối lượng công việc tối thiểu
- Khối lượng tái sử dụng tối đa (phần mềm, phần cứng, bộ phận, v.v.)
- Một lần
Các trường hợp sử dụng sẽ là:
- Lắp đặt thiết bị cảm biến rung động trên thiết bị đang thử nghiệm
- Xác minh dữ liệu trực tuyến và thời gian thực
- Sau một vài ngày, hãy rút phích cắm hoặc sạc thiết bị.
- Di chuyển cảm biến đến vị trí khác và lặp lại.
Thiết kế kỹ thuật
Tùy thuộc vào yêu cầu, sẽ có một số thành phần được kết nối với nhau:
- Thiết bị vật lý
- Giao thức truyền thông
- Máy chủ phụ trợ
- Giao diện người dùng
thiết bị
Đối với thiết bị này, tôi đã chọn Thingy:91, đây là nền tảng tạo mẫu cho Nordic nRF9160 SiP (hệ thống trong gói). nRF91 là bộ vi xử lý có modem di động được thiết kế cho các ứng dụng IoT và công suất thấp. Thingy bổ sung thêm cảm biến, pin và vỏ bọc cho nRF91 để tạo ra một thiết bị có khả năng lập trình để thực hiện nhiều chức năng khác nhau. Cần đề cập rằng có những thiết bị khác trong dòng sản phẩm Thingy, chẳng hạn như Thingy:52 và Thingy:53, tập trung vào Bluetooth, Zigbee và Matter. Bất cứ khi nào Thingy được đề cập trong bài viết này, tôi đang ám chỉ đến Thingy:91 di động.
Tôi đã chọn Thingy vì nó đã có tất cả các bộ phận tôi cần cho dự án và tôi không cần phải kết nối các mô-đun riêng biệt hoặc hàn bất cứ thứ gì. Thingy đi kèm với hai máy đo gia tốc, ADXL362 và ADXL372, nhưng 372 là cảm biến va chạm mạnh, vì vậy tôi đã sử dụng 362, nhạy hơn với va chạm. Thingy cũng đi kèm với một vỏ bọc, pin, đèn LED và một loạt các ví dụ về mã nguồn mở. Thingy có giá khoảng 120 đô la, nhưng tôi đã lấy cái này từ một dự án khác giúp tôi đưa ra quyết định dễ dàng hơn. Nếu bạn chưa có Thingy, đây có thể là một khoản đầu tư tốt, vì nó rất linh hoạt, bạn có thể sử dụng nó như một cảm biến rung động ngày hôm nay và thứ gì đó khác vào ngày mai.
Giao thức truyền thông
Nhiều thiết bị IoT báo cáo các số liệu thay đổi chậm theo thời gian, như nhiệt độ hoặc chỉ báo cáo các sự kiện như đóng/mở cửa. Đây không phải là trường hợp ở đây. Trong trường hợp này, tôi đang hướng đến một giải pháp có thể theo dõi các số liệu thường xuyên như 1 Hertz, có thể chuyển thành rất nhiều dữ liệu có thể gây ảnh hưởng đến kết nối, kế hoạch dữ liệu, máy chủ phụ trợ, v.v.
Một vấn đề khác khi bạn chủ yếu dựa vào phần mềm có sẵn là bạn bị giới hạn ở các giao thức mà thiết bị, phần phụ trợ và phần mềm của bạn hỗ trợ. Tất cả các tùy chọn này cuối cùng đều có mối quan hệ với nhau.
Các giao thức tôi đang cân nhắc là:
Trong đó tải trọng có thể là JSON, Protobuf hoặc mã hóa nhị phân tùy chỉnh.
Vì dữ liệu chính là một chuỗi dữ liệu liên tục chứ không phải là luồng dữ liệu gửi lệnh hoặc sự kiện, tôi quyết định rằng không cần truyền dữ liệu đáng tin cậy. Tôi cũng quyết định không sử dụng mã hóa vì lý do tương tự. Ngoài ra, đây là phương pháp tự làm, không phải là sản phẩm thương mại. Tất cả những điều này giúp giảm chi phí và chúng ta có thể từ bỏ HTTPS, sử dụng MQTT thay cho TLS và CoAP thay cho DTLS, nếu không thì chúng ta sẽ cần.
Băng thông
Nếu chúng tôi báo cáo một mẫu sau mỗi 10 giây, sau một tháng sẽ là 260.000 mẫu. Chi phí chung cho mỗi mẫu tạo ra sự khác biệt lớn trong trường hợp này. Nếu một mẫu yêu cầu 50 byte, tổng cộng sẽ là 13MB/tháng. Tuy nhiên, nếu một mẫu yêu cầu 1.000 byte, tổng cộng sẽ là 260MB/tháng, có thể tốn kém đáng kể tùy thuộc vào gói dữ liệu của bạn. Gửi nhiều byte hơn cũng làm giảm tuổi thọ pin và khiến việc sử dụng ở những khu vực có tín hiệu kém trở nên khó khăn hơn.
Phân chia hàng loạt và độ trễ
Một cách có thể để giảm băng thông là đo hàng loạt cùng nhau, điều này cải thiện tỷ lệ dữ liệu trên chi phí chung, điều này quan trọng hơn đối với các cảm biến được sử dụng trong suốt cả năm thay vì sử dụng thỉnh thoảng. Nhược điểm là nó làm tăng độ trễ cho dữ liệu trong UI, do đó bạn có thể không thấy phép đo mới nhất đã xảy ra. Tôi quyết định không sử dụng phép đo hàng loạt, nhưng đây là điều có thể được thêm vào trong tương lai nếu cần.
Phần cuối và giao diện người dùng
Để dự án này có ý nghĩa về mặt thời gian, tôi phải sử dụng giải pháp hiện có cho phần phụ trợ và phần giao diện người dùng (UI), tốt nhất là giải pháp được tích hợp. Điều này cũng áp dụng cho các dự án thương mại. Phát triển thứ gì đó đã tồn tại dưới dạng dịch vụ chung với mức giá cạnh tranh là không hợp lý.
Tôi cũng đang cân nhắc xem có nên sử dụng dịch vụ đám mây hay lưu trữ một số gói trên tài nguyên máy tính của riêng tôi không. Cả hai chiến lược đều là lựa chọn, nhưng tôi nghiêng về dịch vụ đám mây vì hai lý do. Đầu tiên, tôi không muốn để lộ các dịch vụ trên mạng riêng của mình ra Internet và thứ hai, sử dụng các dịch vụ đang được sử dụng sẽ yêu cầu ít công việc cài đặt và cấu hình hơn.
Tôi đã cân nhắc các giải pháp sau:
- AWS – Các dịch vụ được cung cấp ở mức quá thấp đối với dự án này, nhưng lại là giải pháp tốt cho các sản phẩm thương mại yêu cầu mức độ tùy chỉnh cao.
- InfluxDB + Grafana – Giao thức cụ thể, phức tạp, dựa trên kết nối
- Home Assistant – Cần phải phát triển một số loại bộ điều hợp/bộ nhập để chuyển tiếp dữ liệu từ internet đến mạng cục bộ vì đây là một phiên bản cục bộ.
- ThingsBoard – Mặt trước và mặt sau trong một, bảng điều khiển đẹp, hỗ trợ CoAP, chức năng demo tốt
- nRF Cloud – Nhiều mẫu sẵn sàng sử dụng, đồ thị hạn chế, tập trung vào vị trí và FOTA, gói miễn phí rất hạn chế
Tôi đã chọn ThingsBoard cho luồng dữ liệu chính (tần suất cao) của mình vì nó có thể sử dụng CoAP không kết nối và vì nó có giao diện người dùng được tùy chỉnh tốt. Vui lòng gửi cho tôi tin nhắn riêng nếu bạn muốn đề xuất các dịch vụ khác cho mục đích này.
Ví dụ về bảng điều khiển ThingsBoard
Như một tác dụng phụ, như chúng tôi sẽ giải thích trong phần tiếp theo, giải pháp này cũng báo cáo dữ liệu tần số thấp (khoảng 15 phút một lần) cho nRF Cloud. Ngoài dữ liệu rung, việc thu thập trạng thái pin, vị trí thiết bị và các thông số khác không thay đổi nhiều cũng rất hữu ích. Tích hợp nRF Cloud được gửi qua kênh MQTT an toàn và (tùy chọn) cho phép lệnh modem "AT" được gửi từ máy chủ đến thiết bị.
Thực hiện
Cho đến nay, tôi đã mô tả thiết kế kỹ thuật và tìm thấy một số thành phần có sẵn mà chúng ta có thể sử dụng để triển khai giải pháp mong muốn. Tất cả phần cứng cần thiết đã sẵn sàng để sử dụng. Phần phụ trợ và phần giao diện đã sẵn sàng để sử dụng. Tôi đã chọn các giao thức truyền thông được hỗ trợ thông qua ngăn xếp giải pháp. Phần duy nhất mà tôi không có là phần mềm cho Thingy để thực hiện những gì cần thiết cho nó. Phần mềm cho các thiết bị nhúng vi điều khiển được gọi là phần sụn.
Phần mềm
Phần mềm cơ sở cho nRF91, cốt lõi của Thingy, được phát triển bằng cách sử dụng " nRF Connect SDK ", một bộ công cụ phát triển phần mềm từ Nordic Semiconductor. NCS dựa trên Zephyr , một hệ điều hành thời gian thực (RTOS) mã nguồn mở. Việc kế thừa chức năng nRF Cloud từ mã nguồn cơ bản cho phép tôi phát triển phần cảm biến riêng biệt với phần giao tiếp. Ban đầu, tôi đã thêm hỗ trợ cho việc lấy mẫu cảm biến và tính toán số liệu rung. Số liệu rung chỉ đơn giản là tổng của sự khác biệt 3 trục trong giá trị gia tốc kế giữa hai mẫu liên tiếp. Sau khi tính toán được giá trị đó, tôi có thể tải nó lên nRF Cloud để xác nhận rằng nó hoạt động và để có một POC nhỏ. Sau khi hoàn tất, tôi sẽ thêm hỗ trợ cho việc gửi số liệu ở tần số cao hơn đến máy chủ ThingsBoard bằng giao thức CoAP. Mã nguồn cho dự án có sẵn trên github.
Tích hợp cảm biến
Các cảm biến trong Zephyr được tách thành các API. API cảm biến cho phép sử dụng các cảm biến khác nhau thông qua một giao diện duy nhất, giữ logic kinh doanh, định nghĩa và logic trình điều khiển riêng biệt. API cho phép đọc tùy ý, cũng như phản hồi cho các kích hoạt (chuyển động, ngắt, v.v.). Việc thêm hỗ trợ cho máy đo gia tốc (và các cảm biến tương tự) bao gồm ba bước:
- Kích hoạt và cấu hình các thành phần trong Kconfig. Kconfig định nghĩa các tùy chọn cấu hình cho trình điều khiển, chẳng hạn như phạm vi, tốc độ lấy mẫu, v.v. Trong dự án của chúng tôi, điều này được thực hiện trong một tệp cấu hình cụ thể của Thingy.
- Xác định thành phần trong devicetree Devicetree xác định trình điều khiển, loại kết nối vật lý, chân cắm, v.v. Trong dự án của chúng tôi, thành phần này đã được xác định trong tệp DTS của Thingy. Đối với các bo mạch tùy chỉnh, bạn sẽ cần xác định thành phần này trong DTS tùy chỉnh của riêng bạn.
- Gọi các hàm sensor_* từ API cảm biến, mà bạn sẽ có trong mã c của dự án hoặc trong trường hợp của chúng tôi là vibration.c.
Mô hình này có vẻ lạ đối với những người đã quen với các mô hình đơn giản hơn, "phẳng" hơn, chẳng hạn như các mô hình bạn có trong khuôn khổ Arduino, nơi mọi thứ chỉ là mã. Mô hình Zephyr phức tạp hơn và giúp dễ dàng chuyển sang các mô hình IC, cảm biến hoặc bo mạch khác mà không cần phải thay đổi mã hoặc phân nhánh trong mã. Chi phí chính của tính mô-đun này là đường cong học tập dốc hơn, nhưng nó có nhiều lợi thế, đặc biệt là đối với các dự án lớn hơn.
Tích hợp CoAP
Đối với CoAP, có hai API khả dụng: API CoAP cấp thấp hơn là một phần của Zephyr và API tiện ích CoAP cấp cao hơn mà Nordic đã thêm vào như một phần của nRF Connect SDK. API cấp cao hơn có chức năng cần thiết cho dự án này và sẽ giúp chúng ta tiết kiệm rất nhiều thời gian. Tôi đã triển khai một số mã c để gửi dữ liệu đến ThingsBoard bằng API tiện ích CoAP. Tôi đã sử dụng ThingsBoard Telemetry CoAP Upload Endpoint Definition để biết chi tiết về cách định dạng uri và payload.
Kết nối mọi thứ lại với nhau
Một số mã bổ sung trong mạch logic kinh doanh cốt lõi giúp liên kết mọi thứ lại với nhau, lấy giá trị từ các thành phần quản lý rung động và pin và gửi chúng lên đám mây theo các khoảng thời gian đều đặn.
kết quả
Theo quan điểm của người dùng cuối, kết quả là một thiết bị nhỏ, di động mà bạn có thể gắn vào bất kỳ máy móc hoặc đường ống nào, sau đó mở trang web và xem kết quả theo thời gian thực.
Bằng cách xem biểu đồ, bạn có thể xác định xem có điều gì đó đang xảy ra không và khi nào nó xảy ra. Phân tích chính xác sẽ phụ thuộc vào trường hợp sử dụng chính xác. Ví dụ, trong biểu đồ bên dưới, bạn có thể thấy hai loại hoạt động định kỳ trong hệ thống. Loại đầu tiên là khoảng thời gian một giờ xảy ra sau mỗi 5-6 giờ và loại thứ hai là khoảng thời gian 10 giờ xảy ra vào ban đêm.
Một tác dụng phụ của việc sử dụng mẫu nRF Cloud là chúng ta có thể có dữ liệu vị trí và nhiệt độ tùy chọn.
Pin 1400mAh có thể sử dụng trong hơn 2 ngày, gửi mẫu rung động cứ sau 20 giây. Pin có thể được sạc đầy trong 3 giờ từ nguồn điện USB. Mỗi gói có kích thước khoảng 60-70 byte. UDP không yêu cầu bất kỳ kết nối nào.
tóm tắt
Tôi đã mô tả quá trình xây dựng một thiết bị IoT di động DIY, bắt đầu bằng một tập hợp các yêu cầu và xây dựng một giải pháp tùy chỉnh để đáp ứng các yêu cầu đó. Phần lớn bao gồm các thành phần có sẵn. Một số thành phần là phần cứng, một số là chương trình cơ sở, một số là dịch vụ trực tuyến, nhưng khi kết hợp lại, có thể phát triển một giải pháp chi phí thấp. Chi phí duy nhất trong dự án này là thời gian và tôi ước tính rằng tôi đã mất 10-20 giờ để nghiên cứu và triển khai các tùy chọn. Vì tôi đã phát hành dự án dưới dạng mã nguồn mở nên lần tới khi người khác thử một cái gì đó tương tự, các rào cản sẽ còn thấp hơn nữa.
Về mặt kỹ thuật, một số cải tiến có thể được thực hiện, chẳng hạn như làm cho truyền dữ liệu hiệu quả và an toàn hơn. Ví dụ, mỗi phép đo N có thể được nhóm lại và gửi trong một gói CoAP duy nhất, có thể yêu cầu dịch vụ phân loại ở phía sau.
Một số vấn đề vẫn xảy ra, chẳng hạn như các chỉ số gia tốc kế khác nhau khi thiết bị được cấp nguồn bằng USB và bằng pin. Nguyên nhân của vấn đề này cần được điều tra và có thể liên quan đến sự khác biệt về điện áp, nhiễu từ các thành phần khác hoặc sự khác biệt về đồng hồ ở trạng thái công suất thấp. Tuy nhiên, hiện tại, cảm biến hoạt động như tôi muốn và vì đây là dự án tự làm nên tôi không gặp vấn đề gì.
