SOHO규모의 mqtt시스템 구축하고 있습니다.

MQTT 브로커는 mosquitto를 쓰고,  디바이스는 라즈베리파이, ESP32, ESP8266을 쓰고 있습니다.

1.

라즈베리파이+ESP32를 시리얼로 결합해서 게이트웨이로 구성했습니다.

라즈베리파이는 MQTT 구독,발행,토픽과 JSON(페이로드)처리를 담당하고 

ESP32(마스터)는 ESP-NOW통신을 담당합니다.

말단 노드(슬레이브)는 거의다가 ESP8266을 씁니다.

2.

그리고 이번에는 좀더 간략화된 토폴로지를 구축하고자
(시리얼 송수신 처리가...파고들수록 은근... 어렵습니다.ㅠ)

ESP32단독+W5500(이더넷 모듈)로 게이트웨이를 구성해서 MQTT접속은 W5500으로 하고

말단 노드들(슬레이브)과의 ESP-NOW통신은 ESP32가 담당하도록 했습니다.(보안 최대 10개, 비보안 최대 20개까지)

이렇게 하면 라즈베리파이의 강력한 성능(파이썬의 전광석화같은 개발속도, 멀티프로세서,멀티쓰레드 등등)을

포기해야 하지만 대신 시리얼 송수신 처리가 없어지므로 한결 맘 편합니다.

결국 1번은 좀 더 유연하고 고성능이 필요한 경우

2번은 간단한 코드로 구성하고자 할 경우로 역할 분담을 하고자 합니다.

1번은 좀더 디테일한 설계가 필요해서 지금 진행중이고(PCB완성되는대로 사진 올려보겠습니다)

2번은 PCB주문해서 슬롯 삽입방식으로 멀티 스택으로 구성했습니다.

슬롯카드별로 하나의 ESP32가 들어가 있고, W5500은 메인보드에 장착했습니다.

슬롯카드에 LoRa(시리얼 방식의 E220-900T22D 모델)를 수직 거치하끔 해서

경우에 따라서는 LoRa게이트웨이로도 사용가능하도록 했습니다.

ESP-NOW 통신,  LoRa통신, W5500을 통한 이더넷 통신 셋다가 동시 동작이 가능하다면

멀티게이트웨이로도 사용가능할 듯 보입니다.(아직 이건 테스트 전)

어차피 이 시스템은 CPU부하위주가 아닌 IO 입출력 부하위주라서 현재 예상으로는 가능도 할 것 같습니다만...

멀티 스택을 쓰는 이유가 역할 분담인데, 굳이 그렇게까지 쓸까 싶네요.

이번에 1번과 2번에 대한 설계에 RESTFUL API 개념을 도입한다고는 했는데,

지금으로서는 영~ 짝퉁스러워 보일 뿐입니다.

코딩이야 chatGPT가 거의 99% 해주고 있어서 큰 어려움은 없습니다만.

JSON설계가 젤로 어렵네요.

이번 작업을 하면서 느낌점은,

앞으로 초인공지능 시대에 인간은 결국 설계디자인쪽으로 가야 하는것 같습니다.

향후 시간이 나면(대기중인 프로젝트가 많이 있다는 건 안비밀...ㅠ) 

지금 처박혀 있는 9세대 i7 컴퓨터에  우분투 설치하고

RabbitMQ라든지 AMQP를 설치해서 한번 쪼물딱거려보고 싶네요.
mosquitto는 AMQP에 비하면 거의 유치원생 수준입니다.

하지만 라즈베리파이3B에 mosquitto를 올려서 써보니 SOHO규모에서는 차고도 넘치네요.

mosquitto도 한꺼번에 들이닥치는 토픽을 대체적으로 잘 처리는 해주나

시스템 자체에서 큐잉 처리기능은 없는 것으로 알고 있습니다.

그래서 게이트웨이에서 토픽 발행할시 큐에 일단 넣어놓고 100ms~300ms의 간격으로

발행해 주는 가욋일까지도 해주고 있습니다.(혹시나 몰라서...ㅋ)

XMPP도 있으나 요건 살짝 개념이 다르고...

기존의 것들은 비동기식, 요건 실시간 개념...

게다가 이건 XML기반이라서

여태껏 JSON으로 모든걸 설계해온 제 입장에서는 일단 이런게 있다...정도로만 해서 말려구요.

아래는 도착한 PCB로 카드 5장 만들어서(슬롯카드는 추가 10장 주문, W5500도 7개 추가 주문)

테스트해 본 결과입니다.

6개짜리 멀티스택을 두개 만들면 게이트웨이가 총 12개 생기는것이라서

당분간 MQTT 클라이언트 숫자가 늘어나도 두다리 쭉  뻗고 자겠네요. ㅎ

(PS)

대다수가 ESP8266에서 바로 WiFi를 통해 mosquitto에 접속하면 될 일을 

왜 저리 일을 복잡하게 만드냐고 하실지 모르겠습니다.

일단 제가 이렇게 구성하는 이유는

첫째, 말단 노드(ESP8266)와 게이트웨이의 ESP32는 SD(Software Define)개념과 RESTFUL API으로 가기 위해서입니다.

TCP/IP(LTE,WiFi,ethernet)기반에서

MQTT client(사용자앱) <-> MQTT broker 혹은

게이트웨이 <-> MQTT broker

간에는 토픽구조 중심으로,

ESP-NOW통신프로토콜 기반에서

게이트웨이(1) <-> 슬레이브(N,최대 20)은

슬레이브의 mac address가 포함된 JSON오브젝트 중심으로

SD과  RESTFUL API개념을 도입하기 위해서입니다.

(개념을 차용할 뿐 짝퉁 수준입니다. ㅎ)

둘째, WiFi 접속 디바이스의 급증으로 인한 공유기 부담문제입니다.(현재 대략 110여개 정도입니다.)

게이트웨이화 하면 최대 20개의 WiFi접속이 ethernet 1개로 대폭 줄어듭니다.

셋째,

기상관측장비, 야적장의 물류관리 등 NON-TCP/IP환경에 있어야 하는 

슬레이브 노드(게다가 흔하게 배터리 동작이라는 제약조건까지)들은 

거리가 된다면 ESP-NOW로, 이걸 벗어나는 영역은 LoRa통신으로 

말단 토폴로지를 구성할수 있어 

상황에 따른 토폴로지 구현이 굉장이 유연합니다.

넷째,

있어보이ㄱ....아...아닙니다. ㅎ

잡설이 길었습니다.

아래는 사진들입니다.

마지막 사진은 ESP-NOW의 송수신 거리를 벗어나는 상황에서는 LoRa(최대 5km)로도 쓸수 있는 장면입니다.