수량계를 스마트 홈에 연결합니다.

옛날에는 홈 오토메이션 시스템, 즉 흔히 "스마트 홈"이라고 불리는 시스템은 가격이 너무 비싸서 부자들만이 감당할 수 있었습니다. 오늘날 시장에서는 조명, 소켓, 환기, 물 공급 및 기타 소비자를 제어하기 위한 센서, 버튼/스위치 및 액추에이터가 포함된 상당히 저렴한 키트를 찾을 수 있습니다. 그리고 가장 비뚤어진 DIY 사람이라도 저렴한 가격으로 미용에 참여하고 스마트 홈용 장치를 조립할 수 있습니다.

일반적으로 제안된 장치는 센서 또는 액추에이터입니다. "모션 센서가 작동하면 조명을 켜세요" 또는 "출구 근처의 스위치를 누르면 아파트 전체의 조명이 꺼집니다"와 같은 시나리오를 쉽게 구현할 수 있습니다. 하지만 원격 측정으로는 문제가 해결되지 않았습니다. 기껏해야 온도와 습도 또는 특정 콘센트의 순간 전력 그래프입니다.

최근에 펄스 출력이 있는 수량계를 설치했습니다. 미터를 통과하는 모든 리터에 대해 리드 스위치가 활성화되고 접점이 닫힙니다. 남은 유일한 일은 전선에 매달려 그것으로부터 이익을 얻으려고 노력하는 것입니다. 예를 들어, 시간별, 요일별로 물 소비량을 분석합니다. 글쎄, 아파트에 물 라이저가 여러 개 있으면 손전등을 사용하여 접근하기 어려운 틈새로 올라가는 것보다 한 화면에서 모든 현재 표시기를 보는 것이 더 편리합니다.

컷 아래에는 수량계의 펄스를 계산하고 MQTT를 통해 판독값을 스마트 홈 서버로 보내는 ESP8266 기반 장치의 내 버전이 있습니다. uasyncio 라이브러리를 사용하여 micropython으로 프로그래밍하겠습니다. 펌웨어를 만들 때 몇 가지 흥미로운 어려움에 직면했으며 이 기사에서도 이에 대해 논의하겠습니다. 가다!

계획

전체 회로의 핵심은 ESP8266 마이크로컨트롤러의 모듈입니다. ESP-12는 원래 계획되었으나 결함이 있는 것으로 판명되었습니다. 우리는 사용 가능한 ESP-07 모듈에 만족해야 했습니다. 다행스럽게도 핀과 기능면에서 동일하며 유일한 차이점은 안테나입니다. ESP-12에는 내장형이 있고 ESP-07에는 외부 안테나가 있습니다. 하지만 WiFi 안테나가 없어도 욕실에서는 신호가 정상적으로 수신됩니다.

표준 모듈 배선:

• 풀업 및 커패시터가 있는 재설정 버튼(둘 다 이미 모듈 내부에 있음)
• 활성화 신호(CH_PD)가 전원으로 풀업됩니다.
• GPIO15가 땅으로 당겨집니다. 이것은 처음에만 필요하지만 아직 이 다리에 연결할 것이 없습니다. 더 이상 필요하지 않습니다.

모듈을 펌웨어 모드로 전환하려면 GPIO2를 접지로 단락시켜야 하며, 이를 보다 편리하게 하기 위해 부팅 버튼을 제공했습니다. 정상적인 조건에서는 이 핀이 당겨져 전원이 공급됩니다.

GPIO2 라인의 상태는 작동 시작 시, 즉 전원이 공급될 때 또는 재설정 직후에만 확인됩니다. 따라서 모듈은 평소대로 부팅되거나 펌웨어 모드로 전환됩니다. 로드되면 이 핀을 일반 GPIO로 사용할 수 있습니다. 글쎄, 이미 버튼이 있기 때문에 유용한 기능을 추가할 수 있습니다.

프로그래밍과 디버깅을 위해 빗으로 출력되는 UART를 사용합니다. 필요한 경우 USB-UART 어댑터를 연결하기만 하면 됩니다. 모듈은 3.3V로 전원이 공급된다는 점만 기억하면 됩니다. 어댑터를 이 전압으로 전환하고 5V를 공급하는 것을 잊어버리면 모듈이 소진될 가능성이 높습니다.

욕실의 전기에는 문제가 없습니다. 콘센트는 미터에서 약 220m 떨어져 있으므로 XNUMXV로 전원을 공급받습니다. 전원으로서 나는 작은 것을 가질 것입니다 HLK-PM03 차단 텐스타 로봇에 의해. 개인적으로 아날로그와 전력전자에 어려움을 겪고 있는데 여기 작은 케이스에 기성품 전원 공급 장치가 들어있습니다.

작동 모드를 알리기 위해 GPIO2에 연결된 LED를 제공했습니다. 그런데 납땜을 안 했으니... ESP-07 모듈에는 이미 LED가 있으며 GPIO2에도 연결되어 있습니다. 하지만 이 LED를 케이스에 출력하고 싶다면 보드에 두세요.

가장 흥미로운 부분으로 넘어가겠습니다. 수량계에는 논리가 없습니다. 현재 수치를 요청할 수 없습니다. 우리가 사용할 수 있는 유일한 것은 충동입니다. 매 리터마다 리드 스위치의 접점을 닫는 것입니다. 내 리드 스위치 출력이 GPIO12/GPIO13에 연결되어 있습니다. 모듈 내부에서 프로그래밍 방식으로 풀업 저항을 활성화하겠습니다.

처음에는 저항 R8 및 R9를 제공하는 것을 잊었고 내 버전의 보드에는 저항이 없습니다. 하지만 이미 모든 사람이 볼 수 있도록 다이어그램을 게시하고 있으므로 이러한 실수를 바로잡을 가치가 있습니다. 펌웨어 결함으로 인해 핀이 3.3로 설정되고 리드 스위치가 이 라인을 접지로 단락시키는 경우 포트가 타지 않도록 저항이 필요합니다(저항의 경우 최대 1000V/3.3Ohm = XNUMXmA가 흐릅니다).

정전이 되면 어떻게 해야 할지 생각해 볼 때입니다. 첫 번째 옵션은 시작 시 서버에 초기 카운터 값을 요청하는 것입니다. 그러나 이를 위해서는 교환 프로토콜이 상당히 복잡해져야 합니다. 또한 이 경우 장치의 성능은 서버 상태에 따라 달라집니다. 전원을 끈 후(또는 나중에 시작한 후) 서버가 시작되지 않으면 수량계가 초기값을 요청할 수 없어 제대로 작동하지 않게 됩니다.

그래서 I2C를 통해 연결된 메모리 칩에 카운터 값 저장을 구현하기로 결정했습니다. 플래시 메모리 크기에 대한 특별한 요구 사항은 없습니다. 2개의 숫자(온수 및 냉수 계량기에 따른 리터 수)만 저장하면 됩니다. 가장 작은 모듈이라도 가능합니다. 하지만 녹화 주기 수에 주의해야 합니다. 대부분의 모듈에서 이는 100만 주기이고 일부 모듈에서는 최대 XNUMX만 주기입니다.

백만은 많은 것 같습니다. 하지만 아파트에 사는 4년 동안 저는 500입방미터가 조금 넘는 물을 소비했습니다. 즉 500만 리터에 달하는 물입니다! 플래시에는 500만 개의 레코드가 있습니다. 그리고 그것은 단지 차가운 물입니다. 물론 몇 년에 한 번씩 칩을 재납땜할 수 있지만 FRAM 칩이 있다는 것이 밝혀졌습니다. 프로그래밍 관점에서 볼 때 이는 매우 많은 재작성 주기(수억)만 포함하는 동일한 I2C EEPROM입니다. 아직 그런 초소형 회로를 가지고 매장에 갈 수 없기 때문에 지금은 일반적인 24LC512가 그대로 유지됩니다.

인쇄 회로 기판

처음에는 집에서 보드를 만들 계획이었습니다. 따라서 보드는 단면으로 설계되었습니다. 그러나 레이저 다리미와 솔더 마스크를 사용하여 한 시간을 보낸 후에도(그것이 없으면 전혀 문제가 되지 않습니다), 저는 여전히 중국산 보드를 주문하기로 결정했습니다.

보드를 주문하기 거의 전에 플래시 메모리 칩 외에도 디스플레이와 같이 I2C 버스에 유용한 다른 것을 연결할 수 있다는 것을 깨달았습니다. 정확히 무엇을 출력할지는 여전히 의문이지만 보드에서 라우팅해야 합니다. 글쎄, 공장에서 보드를 주문할 예정이었기 때문에 단면 보드에만 국한할 필요가 없었으므로 I2C 라인은 보드 뒷면에 있는 유일한 라인입니다.

일방향 배선에도 큰 문제가 하나 있었습니다. 왜냐하면 보드가 단면으로 그려져 트랙과 SMD 부품이 한쪽에 배치되고 출력 부품, 커넥터, 전원 공급 장치가 다른쪽에 배치되도록 계획되었습니다. 한 달 후 보드를 받았을 때 원래 계획을 잊어버리고 전면의 모든 구성 요소를 납땜했습니다. 그리고 전원 공급 장치를 납땜할 때만 플러스와 마이너스가 반대로 배선된 것으로 나타났습니다. 점퍼를 가지고 농사를 지어야 했어요. 위 그림에서는 이미 배선을 변경했지만 Boot 버튼의 핀을 통해 보드의 한 부분에서 다른 부분으로 접지가 전송되었습니다(두 번째 레이어에 트랙을 그리는 것이 가능하지만).

이렇게 됐어요

Корпус

다음 단계는 신체입니다. 3D 프린터가 있다면 문제가 되지 않습니다. 별로 신경 쓰지 않고 적당한 크기의 상자를 그리고 적당한 위치에 컷아웃을 만들었습니다. 덮개는 작은 셀프 태핑 나사로 본체에 부착됩니다.

Boot 버튼은 범용 버튼으로 사용될 수 있다고 이미 언급했으므로 전면 패널에 표시하겠습니다. 이를 위해 버튼이 있는 곳에 특별한 "우물"을 그렸습니다.

케이스 내부에는 보드가 설치되고 단일 M3 나사로 고정되는 스터드도 있습니다(보드에 더 이상 공간이 없음).

저는 케이스의 첫 번째 샘플 버전을 인쇄할 때 이미 디스플레이를 선택했습니다. 표준 1306줄 리더기는 이 케이스에 맞지 않았지만 하단에는 OLED 디스플레이 SSD128 32×XNUMX가 있었습니다. 조금 작지만 매일 쳐다볼 필요도 없고 나에게는 너무 과중하다.

이런 식으로 전선이 어떻게 연결될지 파악하고 디스플레이를 케이스 중앙에 붙이기로 결정했습니다. 물론 인체 공학은 동등 이하입니다. 버튼은 상단에 있고 디스플레이는 하단에 있습니다. 하지만 이미 디스플레이를 부착하려는 아이디어가 너무 늦게 나왔고 버튼을 이동하기 위해 보드를 다시 배선하기에는 너무 게으르다고 말했습니다.

장치가 조립되었습니다. 디스플레이 모듈은 뜨거운 접착제로 콧물에 접착됩니다.

최종 결과는 KDPV에서 볼 수 있습니다.

펌웨어

소프트웨어 부분으로 넘어 갑시다. 이와 같은 작은 공예의 경우 저는 Python을 사용하는 것을 정말 좋아합니다(마이크로파이썬) - 코드는 매우 간결하고 이해하기 쉬운 것으로 나타났습니다. 다행스럽게도 마이크로초를 단축하기 위해 레지스터 수준으로 내려갈 필요가 없습니다. 모든 것이 Python에서 수행될 수 있습니다.

모든 것이 단순해 보이지만 그다지 단순하지는 않습니다. 이 장치에는 여러 가지 독립적인 기능이 있습니다.

• 사용자가 버튼을 누르고 디스플레이를 봅니다.
• 플래시 메모리의 리터 틱 및 업데이트 값
• 모듈은 WiFi 신호를 모니터링하고 필요한 경우 다시 연결합니다.
• 글쎄, 깜박이는 전구 없이는 불가능합니다

어떤 이유로 다른 기능이 작동하지 않는 경우 한 기능이 작동하지 않는다고 가정할 수 없습니다. 나는 이미 다른 프로젝트에서 선인장을 가득 채웠고 지금도 "디스플레이가 그 순간 업데이트되고 있었기 때문에 또 다른 리터를 놓쳤습니다" 또는 "모듈이 연결되는 동안 사용자는 아무것도 할 수 없습니다"와 같은 스타일의 결함이 여전히 보입니다. 와이파이." 물론 일부 작업은 인터럽트를 통해 수행할 수 있지만 기간, 호출 중첩 또는 변수에 대한 비원자적 변경에 대한 제한이 발생할 수 있습니다. 글쎄, 모든 작업을 수행하는 코드는 빠르게 엉성해집니다.

В 더 진지한 프로젝트 저는 클래식 선점형 멀티태스킹과 FreeRTOS를 사용했는데 이 경우 모델이 훨씬 더 적합한 것으로 나타났습니다. 코루틴 및 uasync 라이브러리 . 더욱이 Python의 코루틴 구현은 정말 놀랍습니다. 프로그래머를 위해 모든 것이 간단하고 편리하게 수행됩니다. 자신만의 논리를 작성하고 스트림 간에 전환할 수 있는 위치를 알려주세요.

선제적 멀티태스킹과 경쟁적 멀티태스킹의 차이점을 선택 과목으로 공부하는 것이 좋습니다. 이제 마지막으로 코드로 넘어가겠습니다.

#####################################
# Counter class - implements a single water counter on specified pin
#####################################
class Counter():
    debounce_ms = const(25)
    
    def __init__(self, pin_num, value_storage):
        self._value_storage = value_storage
        
        self._value = self._value_storage.read()
        self._value_changed = False

        self._pin = Pin(pin_num, Pin.IN, Pin.PULL_UP)

        loop = asyncio.get_event_loop()
        loop.create_task(self._switchcheck())  # Thread runs forever

각 카운터는 Counter 클래스의 인스턴스에 의해 처리됩니다. 먼저 EEPROM(value_storage)에서 초기 카운터 값을 뺍니다. 이것이 정전 후 복구가 구현되는 방법입니다.

핀은 전원 공급 장치에 내장된 풀업으로 초기화됩니다. 리드 스위치가 닫혀 있으면 라인이 0이고, 라인이 열려 있으면 전원 공급 장치로 풀업되고 컨트롤러가 1을 읽습니다.

핀을 폴링하는 별도의 작업도 여기에서 시작됩니다. 각 카운터는 자체 작업을 실행합니다. 그녀의 코드는 다음과 같습니다

    """ Poll pin and advance value when another litre passed """
    async def _switchcheck(self):
        last_checked_pin_state = self._pin.value()  # Get initial state

        # Poll for a pin change
        while True:
            state = self._pin.value()
            if state != last_checked_pin_state:
                # State has changed: act on it now.
                last_checked_pin_state = state
                if state == 0:
                    self._another_litre_passed()

            # Ignore further state changes until switch has settled
            await asyncio.sleep_ms(Counter.debounce_ms)

접촉 바운스를 필터링하려면 25ms의 지연이 필요하며 동시에 작업이 깨어나는 빈도를 조절합니다(이 작업이 절전 모드인 동안 다른 작업이 실행 중임). 25ms마다 기능이 활성화되어 핀을 확인하고 리드 스위치 접점이 닫혀 있으면 또 다른 리터가 미터를 통과하므로 이를 처리해야 합니다.

    def _another_litre_passed(self):
        self._value += 1
        self._value_changed = True

        self._value_storage.write(self._value)

다음 리터를 처리하는 것은 간단합니다. 카운터는 단순히 증가합니다. 글쎄, 새로운 값을 플래시 드라이브에 쓰는 것이 좋을 것입니다.

사용의 편의를 위해 "접속자"가 제공됩니다.

    def value(self):
        self._value_changed = False
        return self._value

    def set_value(self, value):
        self._value = value
        self._value_changed = False

자, 이제 Python과 uasync 라이브러리의 장점을 활용하고 대기 가능한 카운터 개체를 만들어 보겠습니다. (이것을 러시아어로 어떻게 번역할 수 있습니까? 기대할 수 있는 개체입니까?)

    def __await__(self):
        while not self._value_changed:
            yield from asyncio.sleep(0)

        return self.value()

    __iter__ = __await__  

이것은 카운터 값이 업데이트될 때까지 기다리는 매우 편리한 함수입니다. 함수는 때때로 깨어나서 _value_changed 플래그를 확인합니다. 이 함수의 멋진 점은 호출 코드가 이 함수를 호출하는 동안 잠들고 새 값이 수신될 때까지 잠들 수 있다는 것입니다.

방해는 어떻게 되나요?예, 이 시점에서 당신은 방해에 대해 스스로 말했다고 말하면서 나를 트롤링할 수 있지만 실제로는 어리석은 핀 투표를 했습니다. 실제로 인터럽트는 제가 처음 시도한 것입니다. ESP8266에서는 에지 인터럽트를 구성하고 Python에서 이 인터럽트에 대한 핸들러를 작성할 수도 있습니다. 이 인터럽트에서는 변수 값이 업데이트될 수 있습니다. 아마도 카운터가 이 값을 요청할 때까지 기다리는 슬레이브 장치라면 이 정도면 충분할 것입니다.

불행하게도(혹은 다행스럽게도) 내 장치가 활성 상태이므로 자체적으로 MQTT 프로토콜을 통해 메시지를 보내고 EEPROM에 데이터를 써야 합니다. 그리고 여기에서 제한 사항이 적용됩니다. 인터럽트에 메모리를 할당하고 큰 스택을 사용할 수 없습니다. 즉, 네트워크를 통해 메시지를 보내는 것을 잊을 수 있습니다. "가능한 한 빨리" 일부 기능을 실행할 수 있게 해주는 micropython.schedule()과 같은 빵이 있지만 "무엇이 중요한가?"라는 질문이 생깁니다. 지금 어떤 종류의 메시지를 보내고 있는데 인터럽트가 발생하여 변수의 값을 망치면 어떻게 될까요? 또는 예를 들어 이전 값을 아직 기록하지 않은 상태에서 서버에서 새 카운터 값이 도착했습니다. 일반적으로 동기화를 차단하거나 다른 방법으로 빠져나와야 합니다.

그리고 때때로 RuntimeError: 스케줄 스택 전체 충돌이 발생하는데 그 이유를 누가 알겠습니까?

명시적 폴링과 uasync를 사용하면 이 경우 어떻게든 더 아름답고 신뢰할 수 있는 것으로 나타났습니다.

EEPROM을 사용한 작업을 소규모 수업에 가져왔습니다.

class EEPROM():
    i2c_addr = const(80)

    def __init__(self, i2c):
        self.i2c = i2c
        self.i2c_buf = bytearray(4) # Avoid creation/destruction of the buffer on each call


    def read(self, eeprom_addr):
        self.i2c.readfrom_mem_into(self.i2c_addr, eeprom_addr, self.i2c_buf, addrsize=16)
        return ustruct.unpack_from("<I", self.i2c_buf)[0]    
        
    
    def write(self, eeprom_addr, value):
        ustruct.pack_into("<I", self.i2c_buf, 0, value)
        self.i2c.writeto_mem(self.i2c_addr, eeprom_addr, self.i2c_buf, addrsize=16)

Python에서는 바이트로 직접 작업하기가 어렵지만 메모리에 기록되는 것은 바이트입니다. ustruct 라이브러리를 사용하여 정수와 바이트 사이의 변환을 차단해야 했습니다.

I2C 객체와 메모리 셀의 주소를 매번 전송하지 않기 위해 작고 편리한 클래식으로 모두 정리했습니다.

class EEPROMValue():
    def __init__(self, i2c, eeprom_addr):
        self._eeprom = EEPROM(i2c)
        self._eeprom_addr = eeprom_addr
        

    def read(self):
        return self._eeprom.read(self._eeprom_addr)


    def write(self, value):
        self._eeprom.write(self._eeprom_addr, value)

I2C 객체 자체는 다음 매개변수를 사용하여 생성됩니다.

i2c = I2C(freq=400000, scl=Pin(5), sda=Pin(4))

가장 흥미로운 부분인 MQTT를 통한 서버와의 통신 구현에 이르렀습니다. 글쎄, 프로토콜 자체를 구현할 필요는 없습니다. 인터넷에서 찾았습니다. 기성 비동기 구현. 이것이 우리가 사용할 것입니다.

가장 흥미로운 모든 사항은 MQTTClient 라이브러리를 기반으로 하는 CounterMQTTClient 클래스에 수집되어 있습니다. 주변부터 시작하자

#####################################
# Class handles both counters and sends their status to MQTT
#####################################
class CounterMQTTClient(MQTTClient):

    blue_led = Pin(2, Pin.OUT, value = 1)
    button = Pin(0, Pin.IN)

    hot_counter = Counter(12, EEPROMValue(i2c, EEPROM_ADDR_HOT_VALUE))
    cold_counter = Counter(13, EEPROMValue(i2c, EEPROM_ADDR_COLD_VALUE))

여기서 전구 핀과 버튼은 물론 냉수 및 온수 계량기 개체를 만들고 구성할 수 있습니다.

초기화를 사용하면 모든 것이 그렇게 사소한 것은 아닙니다.

    def __init__(self):
        self.internet_outage = True
        self.internet_outages = 0
        self.internet_outage_start = ticks_ms()

        with open("config.txt") as config_file:
            config['ssid'] = config_file.readline().rstrip()
            config['wifi_pw'] = config_file.readline().rstrip()
            config['server'] = config_file.readline().rstrip()
            config['client_id'] = config_file.readline().rstrip()
            self._mqtt_cold_water_theme = config_file.readline().rstrip()
            self._mqtt_hot_water_theme = config_file.readline().rstrip()
            self._mqtt_debug_water_theme = config_file.readline().rstrip()

        config['subs_cb'] = self.mqtt_msg_handler
        config['wifi_coro'] = self.wifi_connection_handler
        config['connect_coro'] = self.mqtt_connection_handler
        config['clean'] = False
        config['clean_init'] = False
        super().__init__(config)

        loop = asyncio.get_event_loop()
        loop.create_task(self._heartbeat())
        loop.create_task(self._counter_coro(self.cold_counter, self._mqtt_cold_water_theme))
        loop.create_task(self._counter_coro(self.hot_counter, self._mqtt_hot_water_theme))
        loop.create_task(self._display_coro())

mqtt_as 라이브러리의 작동 매개변수를 설정하려면 다양한 설정이 포함된 대규모 사전인 config가 사용됩니다. 대부분의 기본 설정은 우리에게 적합하지만 많은 설정을 명시적으로 설정해야 합니다. 코드에 직접 설정을 쓰지 않기 위해 텍스트 파일 config.txt에 저장합니다. 이를 통해 설정에 관계없이 코드를 변경할 수 있을 뿐만 아니라 서로 다른 매개변수를 사용하여 여러 개의 동일한 장치를 리벳할 수 있습니다.

마지막 코드 블록은 시스템의 다양한 기능을 제공하기 위해 여러 코루틴을 시작합니다. 예를 들어, 다음은 카운터를 서비스하는 코루틴입니다.

    async def _counter_coro(self, counter, topic):
        # Publish initial value
        value = counter.value()
        await self.publish(topic, str(value))

        # Publish each new value
        while True:
            value = await counter
            await self.publish_msg(topic, str(value))

코루틴은 루프에서 새 카운터 값을 기다리고 값이 표시되자마자 MQTT 프로토콜을 통해 메시지를 보냅니다. 첫 번째 코드 조각은 카운터를 통해 물이 흐르지 않더라도 초기 값을 보냅니다.

기본 클래스 MQTTClient는 자체적으로 서비스를 제공하고 WiFi 연결을 시작하고 연결이 끊어지면 다시 연결합니다. WiFi 연결 상태에 변화가 있으면 라이브러리는 wifi_connection_handler를 호출하여 이를 알려줍니다.

    async def wifi_connection_handler(self, state):
        self.internet_outage = not state
        if state:
            self.dprint('WiFi is up.')
            duration = ticks_diff(ticks_ms(), self.internet_outage_start) // 1000
            await self.publish_debug_msg('ReconnectedAfter', duration)
        else:
            self.internet_outages += 1
            self.internet_outage_start = ticks_ms()
            self.dprint('WiFi is down.')
            
        await asyncio.sleep(0)

이 기능은 예제에서 정직하게 복사되었습니다. 이 경우 중단 횟수(internet_outages)와 기간을 계산합니다. 연결이 복원되면 유휴 시간이 서버로 전송됩니다.

그건 그렇고, 마지막 절전 모드는 함수를 비동기식으로 만드는 데만 필요합니다. 라이브러리에서는 대기를 통해 호출되며 본문에 다른 대기가 포함된 함수만 호출할 수 있습니다.

WiFi 연결 외에도 MQTT 브로커(서버)에 대한 연결도 설정해야 합니다. 라이브러리도 이 작업을 수행하며 연결이 설정되면 유용한 작업을 수행할 수 있는 기회를 얻습니다.

    async def mqtt_connection_handler(self, client):
        await client.subscribe(self._mqtt_cold_water_theme)
        await client.subscribe(self._mqtt_hot_water_theme)

여기서는 여러 메시지를 구독합니다. 이제 서버는 해당 메시지를 전송하여 현재 카운터 값을 설정할 수 있습니다.

    def mqtt_msg_handler(self, topic, msg):
        topicstr = str(topic, 'utf8')
        self.dprint("Received MQTT message topic={}, msg={}".format(topicstr, msg))

        if topicstr == self._mqtt_cold_water_theme:
            self.cold_counter.set_value(int(msg))

        if topicstr == self._mqtt_hot_water_theme:
            self.hot_counter.set_value(int(msg))

들어오는 메시지를 처리하며, 주제(메시지 제목)에 따라 카운터 중 하나의 값을 업데이트하는 기능입니다.

몇 가지 도우미 기능

    # Publish a message if WiFi and broker is up, else discard
    async def publish_msg(self, topic, msg):
        self.dprint("Publishing message on topic {}: {}".format(topic, msg))
        if not self.internet_outage:
            await self.publish(topic, msg)
        else:
            self.dprint("Message was not published - no internet connection")

이 함수는 연결이 설정되면 메시지를 보냅니다. 연결이 없으면 메시지가 무시됩니다.

그리고 이는 디버깅 메시지를 생성하고 전송하는 편리한 기능일 뿐입니다.

    async def publish_debug_msg(self, subtopic, msg):
        await self.publish_msg("{}/{}".format(self._mqtt_debug_water_theme, subtopic), str(msg))

텍스트가 너무 많아서 아직 LED를 깜박이지 않았습니다. 여기

    # Blink flash LED if WiFi down
    async def _heartbeat(self):
        while True:
            if self.internet_outage:
                self.blue_led(not self.blue_led()) # Fast blinking if no connection
                await asyncio.sleep_ms(200) 
            else:
                self.blue_led(0) # Rare blinking when connected
                await asyncio.sleep_ms(50)
                self.blue_led(1)
                await asyncio.sleep_ms(5000)

2가지 깜박임 모드를 제공했습니다. 연결이 끊어지면(또는 연결이 막 설정되는 중) 장치가 빠르게 깜박입니다. 연결이 완료되면 장치가 5초마다 한 번씩 깜박입니다. 필요한 경우 여기에서 다른 깜박임 모드를 구현할 수 있습니다.

그러나 LED는 단지 애지중지합니다. 디스플레이도 목표로 삼았습니다.

    async def _display_coro(self):
        display = SSD1306_I2C(128,32, i2c)
    
        while True:
            display.poweron()
            display.fill(0)
            display.text("COLD: {:.3f}".format(self.cold_counter.value() / 1000), 16, 4)
            display.text("HOT:  {:.3f}".format(self.hot_counter.value() / 1000), 16, 20)
            display.show()
            await asyncio.sleep(3)
            display.poweroff()

            while self.button():
                await asyncio.sleep_ms(20)

이것이 제가 말하고자 했던 것입니다. 코루틴을 사용하는 것이 얼마나 간단하고 편리한지입니다. 이 작은 기능은 전체 사용자 경험을 설명합니다. 코루틴은 버튼이 눌릴 때까지 기다렸다가 3초 동안 디스플레이를 켭니다. 디스플레이에는 현재 미터 판독값이 표시됩니다.

아직 몇 가지 작은 것들이 남아 있습니다. 이 전체 기업을 (재)시작하는 기능은 다음과 같습니다. 메인 루프는 1분에 한 번씩 다양한 디버깅 정보를 보냅니다. 대체적으로는 있는 그대로 인용합니다. 너무 길게 코멘트할 필요는 없을 것 같습니다.

   async def main(self):
        while True:
            try:
                await self._connect_to_WiFi()
                await self._run_main_loop()
                    
            except Exception as e:
                self.dprint('Global communication failure: ', e)
                await asyncio.sleep(20)

    async def _connect_to_WiFi(self):
        self.dprint('Connecting to WiFi and MQTT')
        sta_if = network.WLAN(network.STA_IF)
        sta_if.connect(config['ssid'], config['wifi_pw'])
        
        conn = False
        while not conn:
            await self.connect()
            conn = True

        self.dprint('Connected!')
        self.internet_outage = False

    async def _run_main_loop(self):
        # Loop forever
        mins = 0
        while True:
            gc.collect()  # For RAM stats.
            mem_free = gc.mem_free()
            mem_alloc = gc.mem_alloc()

            try:
                await self.publish_debug_msg("Uptime", mins)
                await self.publish_debug_msg("Repubs", self.REPUB_COUNT)
                await self.publish_debug_msg("Outages", self.internet_outages)
                await self.publish_debug_msg("MemFree", mem_free)
                await self.publish_debug_msg("MemAlloc", mem_alloc)
            except Exception as e:
                self.dprint("Exception occurred: ", e)
            mins += 1

            await asyncio.sleep(60)

설명을 완성하기 위한 몇 가지 설정과 상수가 더 있습니다.

#####################################
# Constants and configuration
#####################################


config['keepalive'] = 60
config['clean'] = False
config['will'] = ('/ESP/Wemos/Water/LastWill', 'Goodbye cruel world!', False, 0)

MQTTClient.DEBUG = True

EEPROM_ADDR_HOT_VALUE = const(0)
EEPROM_ADDR_COLD_VALUE = const(4)

모든 것은 이렇게 시작된다

client = CounterMQTTClient()
loop = asyncio.get_event_loop()
loop.run_until_complete(client.main())

내 기억에 무슨 일이 일어났어

그럼 모든 코드가 거기에 있습니다. 나는 ampy 유틸리티를 사용하여 파일을 업로드했습니다. 이 유틸리티를 사용하면 해당 파일을 내부(ESP-07 자체에 있는 플래시 드라이브) 플래시 드라이브에 업로드한 다음 프로그램에서 일반 파일로 액세스할 수 있습니다. 또한 mqtt_as, uasyncio, ssd1306 및 내가 사용한 컬렉션 라이브러리(mqtt_as 내부에서 사용됨)를 업로드했습니다.

실행하고... MemoryError가 발생합니다. 더욱이, 메모리가 정확히 어디에서 누수되고 있는지 이해하려고 노력할수록 더 많은 디버그 인쇄를 배치할수록 이 오류가 더 일찍 나타났습니다. 짧은 Google 검색을 통해 마이크로 컨트롤러에는 원칙적으로 30kB의 메모리만 있고 65kB의 코드(라이브러리 포함)는 들어갈 수 없다는 사실을 알게 되었습니다.

그러나 탈출구가 있습니다. micropython은 .py 파일에서 직접 코드를 실행하지 않는 것으로 나타났습니다. 이 파일이 먼저 컴파일됩니다. 또한 마이크로컨트롤러에서 직접 컴파일되어 바이트코드로 변환된 후 메모리에 저장됩니다. 글쎄, 컴파일러가 작동하려면 일정량의 RAM도 필요합니다.

비결은 리소스 집약적인 컴파일로부터 마이크로컨트롤러를 저장하는 것입니다. 대형 컴퓨터에서 파일을 컴파일하고 미리 만들어진 바이트코드를 마이크로컨트롤러에 업로드할 수 있습니다. 이렇게 하려면 micropython 펌웨어를 다운로드하고 빌드해야 합니다. mpy-cross 유틸리티.

저는 Makefile을 작성하지 않고 다음과 같이 필요한 모든 파일(라이브러리 포함)을 수동으로 살펴보고 컴파일했습니다.

mpy-cross water_counter.py

남은 것은 .mpy 확장자를 가진 파일을 업로드하는 것뿐입니다. 먼저 장치의 파일 시스템에서 해당 .py를 삭제하는 것을 잊지 마십시오.

저는 모든 개발을 프로그램(IDE?) ESPlorer에서 했습니다. 이를 통해 스크립트를 마이크로컨트롤러에 업로드하고 즉시 실행할 수 있습니다. 제 경우에는 모든 객체의 모든 로직과 생성이 water_counter.py(.mpy) 파일에 있습니다. 하지만 이 모든 것이 자동으로 시작되려면 시작 시 main.py라는 파일도 있어야 합니다. 또한 미리 컴파일된 .mpy가 아닌 정확히 .py여야 합니다. 사소한 내용은 다음과 같습니다

import water_counter

우리는 그것을 시작합니다 - 모든 것이 작동합니다. 그러나 여유 ​​메모리는 놀라울 정도로 작습니다(약 1kb). 아직 장치의 기능을 확장할 계획이 있는데 이 킬로바이트로는 충분하지 않습니다. 하지만 이 경우에도 탈출구가 있다는 것이 밝혀졌습니다.

여기에 문제가 있습니다. 파일이 바이트코드로 컴파일되어 내부 파일 시스템에 상주하더라도 실제로는 여전히 RAM에 로드되어 거기에서 실행됩니다. 그러나 micropython은 플래시 메모리에서 직접 바이트코드를 실행할 수 있지만 이를 위해서는 펌웨어에 직접 빌드해야 합니다. 내 넷북에서는 꽤 시간이 걸렸지만 어렵지는 않습니다(그곳에서만 Linux를 사용하게 되었습니다).

알고리즘은 다음과 같습니다.

• 다운로드 및 설치 ESP 오픈 SDK. 이것은 ESP8266용 프로그램용 컴파일러와 라이브러리를 조립하는 것입니다. 프로젝트 메인 페이지의 지침에 따라 어셈블했습니다(저는 STANDALONE=yes 설정을 선택했습니다).
• 다운로드 마이크로파이썬 정렬
• micropython 트리 내부의 ports/esp8266/modules에 필수 라이브러리를 배치하세요.
• 파일의 지침에 따라 펌웨어를 조립합니다. 포트/esp8266/README.md
• 펌웨어를 마이크로컨트롤러에 업로드합니다(Windows에서는 ESP8266Flasher 프로그램 또는 Python esptool을 사용하여 이 작업을 수행합니다).

이제 'import ssd1306'이 펌웨어에서 직접 코드를 들어올리며 이를 위해 RAM이 소비되지 않습니다. 이 트릭을 사용하여 라이브러리 코드만 펌웨어에 업로드하고 기본 프로그램 코드는 파일 시스템에서 실행됩니다. 이를 통해 펌웨어를 다시 컴파일하지 않고도 프로그램을 쉽게 수정할 수 있습니다. 현재 약 8.5kb의 여유 RAM이 있습니다. 이를 통해 우리는 앞으로 매우 다양하고 유용한 기능을 구현할 수 있게 될 것입니다. 글쎄, 메모리가 전혀 충분하지 않으면 기본 프로그램을 펌웨어에 푸시할 수 있습니다.

그렇다면 이제 우리는 어떻게 해야 할까요?

좋아, 하드웨어가 납땜되고, 펌웨어가 작성되고, 상자가 인쇄되고, 장치가 벽에 붙어서 행복하게 전구를 깜박입니다. 그러나 지금은 이 모든 것이 문자 그대로나 비유적으로나 모두 블랙박스일 뿐이며 여전히 거의 쓸모가 없습니다. 이제 서버로 전송되는 MQTT 메시지로 작업을 수행할 시간입니다.

내 '스마트 홈'이 돌아가고 있어요 마조도모 시스템. MQTT 모듈은 기본적으로 제공되거나 추가 기능 시장에서 쉽게 설치됩니다. 어디서 얻었는지 기억이 나지 않습니다. MQTT는 자급자족이 아닙니다. 소위 말하는 것이 필요합니다. 브로커 - MQTT 메시지를 수신하고 정렬하여 클라이언트에 전달하는 서버입니다. 저는 (majordomo와 마찬가지로) 동일한 넷북에서 실행되는 모기를 사용합니다.

장치가 메시지를 한 번 이상 전송하면 해당 값이 즉시 목록에 나타납니다.

이러한 값은 이제 시스템 개체와 연결될 수 있으며, 자동화 스크립트에 사용될 수 있으며 다양한 분석이 가능합니다. 이 모든 내용은 이 기사의 범위를 벗어납니다. 관심 있는 누구에게나 majordomo 시스템을 추천할 수 있습니다. 채널 전자 제품 렌즈 — 친구도 스마트 홈을 구축하고 있으며 시스템 설정에 대해 명확하게 이야기합니다.

몇 가지 그래프를 보여드리겠습니다. 이것은 일일 가치의 간단한 그래프입니다.

밤에는 물을 사용하는 사람이 거의 없다는 것을 알 수 있습니다. 몇 번 누군가 화장실에 갔는데 역삼투압 필터가 하룻밤에 몇 리터를 빨아들이는 것 같습니다. 아침에는 소비가 크게 증가합니다. 저는 보통 보일러의 물을 사용하는데 목욕을 하고 싶어서 일시적으로 도시 온수로 전환했습니다. 이는 하단 그래프에서도 명확하게 표시됩니다.

이 그래프를 통해 화장실에 가려면 6~7리터, 샤워를 하려면 20~30리터, 설거지를 하려면 20리터 정도, 목욕을 하려면 160리터가 필요하다는 사실을 알게 됐다. 우리 가족은 하루에 약 500~600리터를 소비합니다.

특히 궁금하신 분들은 개별 값별 기록을 보시면 됩니다.

여기에서 나는 수도꼭지가 열리면 물이 1초당 약 5리터의 속도로 흐른다는 것을 배웠습니다.

그러나 이런 형태의 통계는 보기에 그리 편리하지 않을 수도 있습니다. Majordomo에는 일별, 주별, 월별 소비 차트를 볼 수 있는 기능도 있습니다. 예를 들어 막대 단위의 소비 그래프는 다음과 같습니다.

지금까지는 일주일 동안의 데이터만 가지고 있습니다. 한 달 후에는 이 그래프가 더 많은 정보를 제공할 것입니다. 매일 별도의 열이 표시됩니다. 수동으로 입력한 값(가장 큰 열)을 조정하면 그림이 약간 손상됩니다. 그리고 내가 첫 번째 값을 거의 큐브보다 적게 잘못 설정했는지, 아니면 이것이 펌웨어의 버그이고 모든 리터가 계산되지 않았는지 여부는 아직 명확하지 않습니다. 시간이 더 필요합니다.

그래프 자체에는 여전히 마법, 화이트워싱, 페인팅이 필요합니다. 아마도 디버깅 목적으로 메모리 소비 그래프를 작성할 수도 있습니다. 거기에서 뭔가가 누출되는 경우를 대비해서 말이죠. 아마도 인터넷이 없었던 시대를 어떻게든 표시하게 될 것입니다. 현재로서는 이 모든 것이 아이디어 수준에 있습니다.

결론

오늘 내 아파트는 조금 더 똑똑해졌습니다. 이렇게 작은 장치를 사용하면 집안의 물 소비량을 모니터링하는 것이 더 편리할 것입니다. 이전에는 “또 한 달에 물을 많이 썼다”고 분개했다면 이제는 그 원인을 찾을 수 있다.

어떤 사람들은 미터 자체에서 1미터 떨어진 곳에 있는 화면의 판독값을 보는 것이 이상하다고 생각할 수도 있습니다. 그러나 그리 멀지 않은 미래에 나는 여러 개의 물 라이저가 있고 계량기 자체가 층계참에 위치할 가능성이 가장 높은 다른 아파트로 이사할 계획입니다. 따라서 원격 판독 장치는 매우 유용할 것입니다.

또한 장치의 기능을 확장할 계획입니다. 저는 이미 전동 밸브를 보고 있습니다. 이제 보일러를 수돗물로 전환하려면 접근하기 어려운 틈새에 수도꼭지 3개를 돌려야 합니다. 해당 표시가 있는 하나의 버튼으로 이 작업을 수행하는 것이 훨씬 더 편리할 것입니다. 물론 누출 방지 기능을 구현하는 것이 좋습니다.

기사에서 나는 ESP8266을 기반으로 한 장치 버전을 설명했습니다. 제 생각에는 코루틴을 사용하는 매우 흥미로운 버전의 마이크로파이썬 펌웨어를 생각해 냈습니다. 간단하고 훌륭합니다. 캠페인을 진행하면서 느낀 많은 뉘앙스와 단점을 설명하려고 노력했습니다. 아마도 나는 모든 것을 너무 자세하게 설명했을 것입니다. 개인적으로 독자로서 말하지 않은 내용을 나중에 생각하는 것보다 불필요한 내용을 건너 뛰는 것이 더 쉽습니다.

언제나 그렇듯, 저는 건설적인 비판에 열려있습니다.

소스 코드
회로 및 보드
케이스 모델

출처 : habr.com