Lytko는 단결합니다

얼마전에 소개해드린 스마트 온도 조절기. 이 기사는 원래 펌웨어 및 제어 시스템을 시연하기 위해 작성되었습니다. 하지만 온도 조절기의 논리와 우리가 구현한 것을 설명하려면 전체 개념을 전체적으로 개괄적으로 설명할 필요가 있습니다.

자동화에 대하여

일반적으로 모든 자동화는 세 가지 범주로 나눌 수 있습니다.
카테고리 1 — 별도의 "스마트" 장치. 다양한 제조업체에서 전구, 찻주전자 등을 구입합니다. 장점: 각 장치는 기능을 확장하고 편안함을 향상시킵니다. 단점: 새로운 제조업체마다 자체 애플리케이션이 필요합니다. 서로 다른 제조업체의 장치 프로토콜은 서로 호환되지 않는 경우가 많습니다.

카테고리 2 — 단일 보드 PC 또는 x86 호환 설치. 이를 통해 컴퓨팅 성능에 대한 제한이 제거되고 스마트 홈 관리를 위한 MajorDoMo 또는 기타 서버 배포판이 이 시스템에 설치됩니다. 따라서 대부분의 제조업체의 장치는 단일 정보 공간에 연결됩니다. 저것들. 스마트 홈을 위한 나만의 서버가 나타납니다. 장점: 단일 센터에서의 호환성으로 향상된 관리 기능을 제공합니다. 단점: 서버에 장애가 발생하면 전체 시스템이 1단계로 돌아갑니다. 조각나거나 쓸모 없게 됩니다.

카테고리 3 - 가장 하드코어한 옵션입니다. 수리 단계에서는 모든 통신이 이루어지고 모든 시스템이 복제됩니다. 장점: 모든 것이 완벽해지며 집이 정말 스마트해집니다. 단점: 카테고리 1 및 2에 비해 비용이 매우 높으며 모든 것을 미리 생각하고 모든 세부 사항을 고려해야 합니다.

대부분의 사용자는 옵션 3을 선택한 다음 옵션 XNUMX로 원활하게 이동합니다. 그리고 가장 끈질긴 사람들은 옵션 XNUMX에 도달합니다.

그러나 분산 시스템이라고 부를 수 있는 옵션이 있습니다. 각 개별 장치는 서버이자 클라이언트가 됩니다. 본질적으로 이는 옵션 1과 옵션 2를 취하고 결합하려는 시도입니다. 장점을 모두 취하고 단점을 제거하여 황금률을 잡으려는 시도입니다.

아마도 누군가는 그러한 옵션이 이미 개발되었다고 말할 것입니다. 그러나 그러한 결정은 초점이 좁습니다. 프로그래밍에 능숙한 사람들을 위해. 우리의 목표는 최종 장치 형태와 기존 장치를 시스템에 통합하는 형태 모두에서 이러한 분산 시스템에 대한 진입 장벽을 낮추는 것입니다. 온도 조절 장치의 경우 사용자는 기존 온도 조절 장치를 제거하고 스마트 온도 조절 장치를 설치한 후 기존 센서를 여기에 연결하기만 하면 됩니다. 추가 단계 없이.

예제를 사용하여 시스템에 통합하는 방법을 살펴보겠습니다.

네트워크에 8개의 Sonoff 모듈이 있다고 가정해 보겠습니다. 일부 사용자의 경우 Sonoff 클라우드(범주 1)를 통한 제어만으로 충분합니다. 일부는 타사 펌웨어를 사용하기 시작하고 원활하게 범주 2로 이동합니다. 대부분의 타사 펌웨어는 데이터를 MQTT 서버로 전송하는 동일한 원리로 작동합니다. OpenHub, Majordomo 또는 기타 다른 목적은 서로 다른 장치를 인터넷이나 로컬 네트워크에 있는 단일 정보 공간으로 통합하는 것입니다. 따라서 서버가 있어야 합니다. 여기서 주요 문제가 발생합니다. 서버가 실패하면 전체 시스템이 자율적으로 작동을 멈춥니다. 이를 방지하기 위해 시스템이 더욱 복잡해지며, 서버 장애 시 자동화를 복제하는 수동 제어 방법이 추가됩니다.

우리는 각 장치가 자급자족하는 다른 경로를 택했습니다. 따라서 서버는 결정적인 역할을 하지 않고 기능을 확장할 뿐입니다.

사고 실험으로 돌아가 보겠습니다. 동일한 8개의 Sonoff 모듈을 다시 가져와서 Lytko 펌웨어를 설치해 보겠습니다. 모든 Lytko 펌웨어에는 다음 기능이 있습니다. SSDP. SSDP는 네트워크 서비스 광고 및 검색을 위한 인터넷 프로토콜 제품군을 기반으로 하는 네트워크 프로토콜입니다. 요청에 대한 응답은 표준이거나 확장될 수 있습니다. 표준 기능 외에도 이 답변에는 네트워크의 장치 목록 생성이 포함되었습니다. 따라서 장치 자체는 서로를 찾고 각 장치에는 이러한 목록이 있습니다. 예시 SSDP 시트:

"ssdpList": 
	{
		"id": 94967291,  
		"ip": "192.168.x.x",
                "type": "thermostat"
	}, 
	{
		"id": 94967282,
		"ip": "192.168.x.x",
                "type": "thermostat"
	}

예제에서 볼 수 있듯이 목록에는 장치 ID, 네트워크의 IP 주소, 장치 유형(이 경우 Sonoff 기반 온도 조절 장치)이 포함됩니다. 이 목록은 2분마다 한 번씩 업데이트됩니다(이 기간은 네트워크에 있는 장치 수의 동적 변화에 응답하기에 충분합니다). 이러한 방식으로 사용자 작업 없이 추가, 변경 및 비활성화된 장치를 추적합니다. 이 목록은 브라우저나 모바일 애플리케이션으로 전송되며 스크립트 자체는 지정된 블록 수로 페이지를 생성합니다. 각 블록은 하나의 장치/센서/컨트롤러에 해당합니다. 시각적으로 목록은 다음과 같습니다.

하지만 다른 무선 센서가 cc8266(ZigBee) 또는 nrf32(MySensors)를 통해 esp2530/esp24에 연결되어 있다면 어떻게 될까요?

프로젝트 정보

시장에는 다양한 분산 시스템이 있습니다. 우리 시스템을 사용하면 가장 인기 있는 시스템과 통합할 수 있습니다.

다음은 서로 다른 제조업체가 서로 호환되지 않는 상황을 변화시키려는 어떤 방식으로든 시도하는 프로젝트입니다. 이는 예를 들어, SLS 게이트웨이, 마이센서 또는 ZESP32. ZigBee2MQTT MQTT 서버에 연결되어 있으므로 예시에는 적합하지 않습니다.

MySensors를 구현하기 위한 한 가지 옵션은 ESP8266 기반 게이트웨이입니다. 나머지 예제는 ESP32에 있습니다. 그리고 여기에서 장치 목록을 감지하고 생성하는 작동 원리를 구현할 수 있습니다.

또 다른 사고 실험을 해보자. ZESP32 게이트웨이, SLS 게이트웨이 또는 MySensors가 있습니다. 단일 정보 공간에 어떻게 결합할 수 있습니까? 우리는 이러한 게이트웨이의 표준 기능에 SSDP 프로토콜 라이브러리를 추가할 것입니다. SSDP를 통해 이 컨트롤러에 액세스하면 연결된 장치 목록이 표준 응답에 추가됩니다. 이 정보를 바탕으로 브라우저는 페이지를 생성합니다. 일반적으로 다음과 같습니다.

웹 인터페이스

PWA 애플리케이션

"ssdpList": 
{
   "id": 94967291, // уникальный идентификатор устройства
   "ip": "192.168.x.x", // ip адрес в сети
   "type": "thermostat" // тип устройства
},
{
   "id": 94967292,
   "ip": "192.168.x.x",
   "type": "thermostat"
},
{
   "id": 94967293,
   "ip": "192.168.x.x",
   "type": "thermostat"
},
{  
   "id": 13587532, 
   "type": "switch"  
},
{  
   "id": 98412557, 
   "type": "smoke"
},
{  
   "id": 57995113, 
   "type": "contact_sensor"
},
{  
   "id": 74123668,
   "type": "temperature_humidity_pressure_sensor"
},
{
    "id": 74621883, 
    "type": "temperature_humidity_sensor"
}

이 예에서는 장치가 서로 독립적으로 추가되는 것을 보여줍니다. 고유한 IP 주소를 가진 3개의 온도 조절기와 고유한 ID를 가진 5개의 센서가 연결됩니다. 센서가 Wi-Fi 네트워크에 연결된 경우 자체 IP를 갖게 되며, 게이트웨이에 연결된 경우 장치의 IP 주소는 게이트웨이의 IP 주소가 됩니다.

우리는 WebSocket을 사용하여 장치와 통신합니다. 이를 통해 요청을 가져오는 것과 비교하여 리소스 비용을 최소화하고 연결하거나 변경할 때 동적으로 정보를 가져올 수 있습니다.

데이터는 서버를 거치지 않고 블록이 속한 장치에서 직접 가져옵니다. 따라서 장치 중 하나에 오류가 발생하더라도 시스템은 계속 작동됩니다. 웹 인터페이스는 목록에서 누락된 장치를 표시하지 않습니다. 그러나 필요한 경우 손실에 대한 신호는 사용자 애플리케이션에 알림 형식으로 제공됩니다.

이 접근 방식을 구현하려는 첫 번째 시도는 PWA 애플리케이션이었습니다. 이를 통해 사용자의 디바이스에 블록 기반을 저장하고 필요한 데이터만 요청할 수 있습니다. 그러나 구조의 특성으로 인해 이 옵션은 불완전합니다. 그리고 탈출구는 단 하나뿐입니다. 현재 활발히 개발중인 Android 및 IOS 용 기본 애플리케이션입니다. 기본적으로 애플리케이션은 내부 네트워크에서만 작동합니다. 필요한 경우 모든 것을 외부 제어로 전송할 수 있습니다. 따라서 사용자가 로컬 네트워크를 떠나면 애플리케이션이 자동으로 클라우드로 전환됩니다.

외부 제어 - 페이지 복제를 완료합니다. 페이지가 활성화되면 사용자는 개인 계정을 통해 서버에 로그인하고 장치를 관리할 수 있습니다. 따라서 서버는 기능을 확장하여 집 밖에서도 장치를 관리할 수 있으며 포트 전달이나 전용 IP에 얽매이지 않습니다.

따라서 위의 옵션에는 서버 접근 방식의 단점이 없으며 새로운 장치를 연결할 때 유연성이 있다는 형태의 여러 가지 장점도 있습니다.

온도 조절기 정보

온도 조절 장치를 예로 들어 제어 시스템을 살펴보겠습니다.

제공됨:

1. 각 온도 조절 장치의 온도 제어(별도의 블록으로 표시됨)
2. 온도 조절기 작동 일정 설정(아침, 오후, 저녁, 밤)
3. Wi-Fi 네트워크를 선택하고 여기에 장치를 연결합니다.
4. "무선으로" 장치 업데이트
5. MQTT 설정;
6. 장치가 연결된 네트워크를 구성합니다.

웹 인터페이스를 통한 제어 외에도 디스플레이를 클릭하여 클래식 인터페이스를 제공했습니다. 보드에는 Nextion NX3224T024 2.4인치 모니터가 있습니다. 장치 작업이 쉽기 때문에 선택이 그에게 떨어졌습니다. 하지만 우리는 STM32를 기반으로 자체 모니터를 개발하고 있습니다. 기능은 Nextion보다 나쁘지 않지만 비용은 저렴하므로 장치의 최종 가격에 긍정적인 영향을 미칠 것입니다.

자존심이 강한 온도 조절기 화면과 마찬가지로 Nextion은 다음을 수행할 수 있습니다.

• 사용자가 요구하는 온도를 설정합니다(오른쪽 버튼 사용).
• 예약된 작동 모드를 켜고 끕니다(버튼 H).
• 디스플레이 릴레이 작동(왼쪽 화살표);
• 어린이 보호 기능이 있습니다(잠금 장치가 제거될 때까지 물리적 클릭이 차단됩니다).
• WiFi 신호 강도를 표시합니다.

또한 모니터를 사용하여 다음을 수행할 수 있습니다.

• 사용자가 설치한 센서 유형을 선택합니다.
• 어린이 잠금 기능을 관리합니다.
• 펌웨어를 업데이트하세요.

WiFi 바를 클릭하면 연결된 네트워크에 대한 정보를 확인할 수 있습니다. QR 코드는 HomeKit 펌웨어에서 장치를 페어링하는 데 사용됩니다.

디스플레이 작업 데모:

우리는 개발했습니다 데모 페이지 3개의 온도 조절 장치가 연결되어 있습니다.

“온도 조절 장치의 특별한 점은 무엇인가요?”라고 물을 수도 있습니다. 현재 시중에는 Wi-Fi 기능, 예약 작동, 터치 제어 기능을 갖춘 온도 조절 장치가 많이 나와 있습니다. 그리고 매니아들은 가장 인기 있는 스마트 홈 시스템(Majordomo, HomeAssistant 등)과 상호 작용하는 모듈을 작성했습니다.

당사의 온도 조절 장치는 이러한 시스템과 호환되며 위의 모든 기능을 갖추고 있습니다. 그러나 독특한 특징은 시스템의 유연성 덕분에 온도 조절 장치가 지속적으로 개선되고 있다는 것입니다. 업데이트할 때마다 기능이 확장됩니다. (일정에 따른) 표준 시스템 관리 방법에 적응형 방법을 추가할 예정입니다. 이 애플리케이션을 사용하면 사용자의 지리적 위치를 얻을 수 있습니다. 덕분에 시스템은 위치에 따라 작동 모드를 동적으로 변경합니다. 날씨 모듈을 사용하면 기상 조건에 적응할 수 있습니다.

그리고 확장성. 누구나 기존의 기존 온도 조절 장치를 당사의 온도 조절 장치로 교체할 수 있습니다. 최소한의 노력으로. 우리는 시장에서 가장 인기 있는 센서 중 5개를 선택하고 이에 대한 지원을 추가했습니다. 하지만 센서에 고유한 특성이 있더라도 사용자는 이를 온도 조절 장치에 연결할 수 있습니다. 이렇게 하려면 특정 센서와 작동하도록 온도 조절기를 보정해야 합니다. 우리는 지침을 제공할 것입니다.

온도 조절기나 기타 장치를 연결하면 웹 인터페이스와 PWA 애플리케이션 모두에 동시에 나타납니다. 장치 추가는 자동으로 수행됩니다. Wi-Fi 네트워크에 연결하기만 하면 됩니다.

우리 시스템에는 서버가 필요하지 않으며, 실패하더라도 호박으로 변하지 않습니다. 구성 요소 중 하나에 오류가 발생하더라도 비상 시나리오에서는 시스템이 작동을 시작하지 않습니다. 컨트롤러, 센서, 장치 - 각 요소는 서버이자 클라이언트이므로 완전히 자율적입니다.

관심 있는 분들을 위해 당사의 소셜 네트워크를 소개합니다: 텔레그램, 인스타그램, 전보 뉴스, VK, 페이스북.

이메일 : [이메일 보호]

PS 우리는 귀하가 서버를 포기하도록 권장하지 않습니다. 우리는 또한 MQTT 서버를 지원하고 자체 클라우드를 보유하고 있습니다. 우리의 목표는 시스템의 안정성과 신뢰성을 완전히 새로운 수준으로 끌어올리는 것입니다. 서버가 약점이 아닌 기능을 보완하고 시스템을 더욱 편리하게 만들어주기 위해서입니다.

출처 : habr.com