Свързваме водомера към умния дом

Някога системите за домашна автоматизация, известни още като "умния дом", бяха изключително скъпи и само богатите можеха да си ги позволят. Днес на пазара могат да се намерят доста бюджетни комплекти с датчици, бутони/ключове и изпълнителни устройства за управление на осветлението, контакти, вентилацията, водоснабдяването и други потребители. И дори най-неспособният в DIY може да се потопи в невероятното и за малко пари да сглоби устройства за умния дом.

Обикновено предлаганите устройства са или датчици, или изпълнителни механизми. Те позволяват лесно реализиране на сценарии като "при сработване на датчик за движение да се включи светлината" или "ключът до изхода гасява светлината в целия апартамент". Но с телеметрията нещата не се получиха. В най-добрия случай това е графика на температурата и влажността или текущата мощност в конкретен контакт.

Наскоро инсталирах водомери с импулсен изход. Всеки литър, преминал през водомера, активира херкон и затваря контакта. Остава само да се свържа с проводниците и да опитам да извлека полза от това. Например, да анализирам потреблението на вода по часове и дни от седмицата. А ако имам няколко ствола за вода в апартамента, е по-удобно да виждам всички текущи показатели на един екран, отколкото да се мъча с фонарик из труднодостъпни ниши.

По-долу е моят вариант на устройство, базирано на ESP8266, което брои импулсите от водомерите и изпраща показанията на сървъра на умния дом по MQTT. Ще програмираме с micropython, използвайки библиотеката uasyncio. При създаването на фърмуера срещнах няколко интересни затруднения, за които също ще разкажа в тази статия. Да започваме!

Схема

Сърцето на цялата схема е модулът на микроконтролера ESP8266. Първоначално беше планиран ESP-12, но моят се оказа дефектен. Прихода да се задоволя с модула ESP-07, който беше на разположение. За щастие те са идентични по изводи и функционалност, единствената разлика е в антената — при ESP-12 тя е вградена, а при ESP-07 — външна. Въпреки това, дори без антена, WiFi сигналът в банята ми се улавя нормално.

Свързването на модула е стандартно:

• бутон за нулиране с подтяг и кондензатор (въпреки че и двете вече ги има в модула)
• Сигналът enable (CH_PD) е свързан към захранването
• GPIO15 е свързан с нула. Това е необходимо само при стартиране, но за мен е без значение, тъй като нямам какво да свържа на този пин.

За да преместите модула в режим на флаширане, трябва да свържете GPIO2 с нула, а за по-голямо удобство предвидих бутон Boot. В нормално състояние този пин е свързан с захранването.

Състоянието на линията GPIO2 се проверява само в началото на работата — при захранване или веднага след нулирането. Така модулът или се зарежда, както обикновено, или преминава в режим на флаширане. След зареждане този изход може да се използва като обикновен GPIO. А щом вече имам бутон, мога да добавя някаква полезна функция към него.

За програмиране и дебъгване ще използвам UART, който е изведен на плочката. Когато е необходимо, просто свързвам USB-UART адаптер. Трябва само да не забравя, че модулът работи с 3.3V. Ако забравя да превключа адаптера на това напрежение и подам 5V, модулът вероятно ще изгоре.

С електричеството в банята нямам проблеми — контакта е разположен на около метър от броячите, така че ще го захранвам от 220V. Като източник на захранване ще използвам малък блок HLK-PM03 от Tenstar Robot. Лично за мен е трудно с аналоговата и силовата електроника, а тук имам готов захранващ блок в малък корпус.

За сигнализиране на работните режими предвидих светодиод, свързан към GPIO2. Все пак не реших да го свързвам, тъй като в модула ESP-07 вече има светодиод, свързан към същия GPIO2. Но на платката нека го има — изведнъж бих искал да изведа този светодиод на корпуса.

Преминаваме към най-интересното. При водомерите няма логика, от която да можем да искаме текущите показания. Единственото, което имам на разположение, са импулсите — затваряне на контактите на херкона на всеки литър. Изводите на херконите са свързани с GPIO12/GPIO13. Поддържащият резистор ще включа програмно вътре в модула.

Първоначално забравих да предвидя резисторите R8 и R9 и в моя вариант на платката те липсват. Но тъй като вече публикувам схемата на обществено достояние, е уместно да поправя тази грешка. Резисторите са нужни, за да не повредят порта в случай, че флашването забие и постави единица на пина, а херконът затвори тази линия с нула (с резистора ще протече максимум 3.3V/1000Ω = 3.3mA).

Време е да помислим какво да правим, ако електричеството изчезне. Първият вариант - да запитаме сървъра за начални стойности на измервателите при стартиране. Но това би изисквало съществено усложнение на протокола за обмен. Освен това, работоспособността на устройството в такъв случай зависи от състоянието на сървъра. Ако след прекъсването на електричеството сървърът не се стартира (или се стартира по-късно), измервателят на вода не би могъл да поиска начални стойности и щеше да работи неправилно.

Затова реших да реализирам запаметяване на стойностите на измервателите в микрочип с памет, свързан по I2C. Нямам особени изисквания по размер на флаш паметта - нужно е да се запаметят само 2 числа (количеството литри според измервателите за топла и студена вода). Дори и най-малкият модул става. Но трябва да се обърне внимание на броя на циклите на запис. При повечето модули това са 100 хиляди цикъла, а при някои - до милион.

На пръв поглед милионът е много. Но през 4-те години, в които живея в апартамента си, съм изразходвал малко над 500 кубика вода, това са 500000 литра! И 500000 записа във флаш паметта. И това е само студена вода. Разбира се, мога да препоявам микрочипа на всеки две години, но се оказа, че има микрочипове FRAM. От гледна точка на програмирането, това е същият I2C EEPROM, само с огромно количество цикли на презапис (стотици милиони). Само че досега все още не съм успял да стигна до магазина с такива микрочипове, затова в момента използвам обикновена 24LC512.

Печатна платка

Първоначално планирах да направя платката в домашни условия. Затова платката беше проектирана като едностранна. Но след като прекарах час в опити с лазерна ютия и спойка (без нея не е като хората), все пак реших да поръчам платките от китайци.

Почти преди поръчката на платките осъзнах, че освен микрочипа с флаш памет на шина I2C може да се свърже и нещо полезно, например дисплей. Какво точно ще изведа на него - още е въпрос, но трябва да се определи на платката. А тъй като смятам да поръчам платките от фабрика, нямаше смисъл да се огранича до едностранна платка, затова линиите на I2C - са единствените от задната страна на платката.

Свързан с едностранно разпределение имаше и един голям проблем. Тъй като платката беше проектирана едностранно, планирано беше да се разположат пътеките и SMD компонентите от едната страна, а изводите, конекторите и захранването от другата. Когато след месец получих платките, забравих за първоначалния план и запоих всичките компоненти от лицевата страна. И едва когато стигнах до запояването на захранващия блок, разбрах, че положителният и отрицателният контакт са обърнати. Наложи се да импровизирам с jumper-и. На снимката по-горе вече съм променил разпределението, но земята се прехвърля от една част на платката в друга през изводите на бутона Boot (въпреки че можеше да се направи пътечка на втория слой).

Станаха така

Калъф

Следващата стъпка - корпус. При наличието на 3D принтер, това не е проблем. Не се замислих особено - просто нарисувах кутия с необходимия размер и направих изрези на нужните места. Капакът се закрепва към корпуса с малки саморези.

Вече споменах, че бутонът Boot може да се използва като бутон с общо предназначение - ето го и него на предния панел. За целта нарисувах специален 'колодец', където се намира бутона.

Вътре в корпуса също са разположени пеньки, на които се поставя платката и се фиксира с един винт М3 (не остана повече място на платката).

Дисплеят подбрах, когато вече бях отпечатал първия примерен вариант на корпуса. Стандартният двустрочен дисплей не се събираше в този корпус, но в запасите открих OLED дисплей SSD1306 128×32. Малко е, но не трябва да го гледам всеки ден - става.

Преценявайки как ще се прокарат кабелите, реших да залепя дисплея в средата на корпуса. Ергономията, разбира се, е под всякаква критика - бутонът е отгоре, дисплеят - отдолу. Но вече казах, че идеята за прикрепване на дисплея дойде твърде късно и нямаше желание да преработвам платката, за да преместя бутона.

Устройството в сбор. Дисплейният модул е залепен с термоклей.

Крайният результат може да се види на КДПВ.

Прошивка

Преминаваме към софтуерната част. За такива малки изделия много харесвам да използвам езика Python (micropython)- кодът се получава много компактен и разбираем. За щастие, няма нужда да се спускам до ниво регистри, за да изстискам микросекунди - всичко може да се направи от Python.

Изглежда всичко е просто, но не съвсем — устройството включва няколко независими функции:

• Потребителят натиска бутона и гледа дисплея
• Литрите тикат и обновяват стойностите във флаш паметта
• Модулът следи сигнала на WiFi и се преконектира, ако е необходимо
• А без мигаща лампичка просто не може

Не може да се допусне, че една функция не работи, ако друга по някаква причина забавя. Вече съм се натъкнал на много проблеми в други проекти и вече виждам глюкове в стил "пропуснат литър, защото в този момент се обновяваше дисплеят" или "потребителят не може да направи нищо, докато модулът се свързва с WiFi". Разбира се, някои неща могат да се реализират чрез прекъсвания, но може да се сблъскаш с ограничения по дължина, вложеност на извиканите функции или неатомарни промени на променливи. А кодът, който се занимава с всичко наведнъж, бързо се превръща в каша.

В проект, по-сериозен използвах класическа вытесняваща многозадачност и FreeRTOS, но в този случай моделът на сопрограми (coroutines) и библиотеката uasync е много по-подходящ. Питоновата реализация на корутините е невероятна — за програмиста е всичко направено просто и удобно. Просто напишете логиката си, само кажете къде можете да превключвате между нишките.

Разликите между вытесняващата и конкурентната многозадачност предлагам да проучите в допълнителни материали. А сега нека, най-накрая, да преминем към кода.

#####################################
# 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) се чете началната стойност на брояча — така се реализира възстановяване след загуба на захранване.

Пинът се инициализира със вградена подтягиване към захранването: ако херконът е замкнат — на линията е нула, ако е разомкнат, линията се подтягива към захранването и контролерът чете единица.

Също така тук стартира отделна задача, която ще извършва опит на пина. Всеки брояч ще стартира своя задача. Ето нейния код

    """ Проверява пина и увеличава стойността, когато премине още един литър """
    async def _switchcheck(self):
        last_checked_pin_state = self._pin.value()  # Получаване на началното състояние

        # Проверка за промяна на пина
        while True:
            state = self._pin.value()
            if state != last_checked_pin_state:
                # Състоянието се е променило: действайте веднага.
                last_checked_pin_state = state
                if state == 0:
                    self._another_litre_passed()

            # Игнориране на по-нататъшни промени на състоянието, докато ключът не се установи
            await asyncio.sleep_ms(Counter.debounce_ms)

Забавянето от 25мс е нужно за филтриране на дребезга на контактите, а също така регулира колко често се събужда задачата (докато тази задача спи – работят другите задачи). На всеки 25мс функцията се събужда, проверява пина и ако контактите на херконата са замкнати, значи през брояча е преминал поредния литър и това трябва да бъде обработено.

    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

А сега ще се възползваме от предимствата на Питон и библиотеката uasync и ще направим обектът на брояча ожидаем (как да го преведем на български? Такъв, който може да се изчаква?)

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

        return self.value()

    __iter__ = __await__  

Това е удобна функция, която изчаква докато стойността на брояча не се актуализира – функцията периодично се събужда и проверява флага _value_changed. Хитростта на тази функция е, че извикващият код може да заспи при извикването на тази функция и да спи до получаване на нова стойност.

А какво ще кажем за прекъсванията?Да, в този момент можете да ме тролите, че сам казах за прекъсванията, а всъщност направих глупаво запитване на пина. Всъщност прекъсванията бяха първото, което опитах. В ESP8266 може да се организира прекъсване по фронта и дори да се напише обработчик на това прекъсване на Питон. В това прекъсване може да се обновява стойността на променливата. Вероятно това би било достатъчно, ако броячът беше ведомо устройство – такова, което чака, докато не го попитат за стойността.

За съжаление (или за щастие?) устройството ми е активно, то трябва само да изпраща съобщения по протокола MQTT и да записва данни в EEPROM. И тук вече влизат ограниченията — в прекъсванията не може да се заделя памет и да се използва голям стек, а значи можем да забравим за изпращането на съобщения по мрежата. Има плюсове, като micropython.schedule(), които позволяват да стартираме някоя функция „веднага щом е възможно“, но възниква въпросът „а какъв е смисълът?“. Може би точно сега изпращаме някое съобщение, а тук идва прекъсване и разваля стойностите на променливите. Или, например, от сървъра е пристигнало ново значение на брояча, докато все още не сме записали старото. В общи линии, нужно е да се направи синхронизация или да се намери начин да се справим по друг начин.

Понякога излиза и RuntimeError: schedule stack full и кой знае защо?

С явен опрос и uasync в този случай става някак по-красиво и надеждно.

Работата с EEPROM я изнесох в малък клас.

class EEPROM():
    i2c_addr = const(80)

    def __init__(self, i2c):
        self.i2c = i2c
        self.i2c_buf = bytearray(4) # Избягвайте създаването/унищожаването на буфера при всяко извикване


    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)

В питона е трудно да се работи директно с байтове, а именно байтове се записват в паметта. Пришлось да се направи конверсия между цяло число и байтове с използване на библиотеката 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. Не е нужно да реализираме самия протокол — в интернет се намери готова асинхронна реализация.. И ще я използваме.

Всичко най-интересно е събрано в класа CounterMQTTClient, който е базиран на библиотечния MQTTClient. Да започнем с периферията.

#####################################
# 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):
        # Публикувай началната стойност
        value = counter.value()
        await self.publish(topic, str(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 е активен.')
            duration = ticks_diff(ticks_ms(), self.internet_outage_start) // 1000
            await self.publish_debug_msg('ВъзстановенСлед', duration)
        else:
            self.internet_outages += 1
            self.internet_outage_start = ticks_ms()
            self.dprint('WiFi е неактивен.')
            
        await asyncio.sleep(0)

Функцията е взета от примери. В този случай тя брои броя на прекъсванията (internet_outages) и тяхната продължителност. Когато връзката бъде възстановена, на сървъра се изпраща времето на неработоспособността.

Струва ми се, че последният sleep е необходим само за да направи функцията асинхронна — в библиотеката тя се извиква с await, а така могат да се извикват само функции, в които има друг await.

Освен връзката с 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("Получено MQTT съобщение 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))

Толкова много текст, а ние все още не сме мигали с светодиода. Ето го.

    # 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 секунди. При необходимост тук може да се реализират и други режими на мигане.

Но светодиодът е просто играчка. Вместо това направихме и дисплей.

    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 секунди. На дисплея се показват текущите показания на броячите.

Остаха още няколко малки неща. Ето функция, която (пре)започва всичко това. Основният цикъл изпраща различна отладъчна информация на всеки минута. В общи линии, предлагам го такъв, какъвто е — не мисля, че има нужда от особени коментари.

   async def main(self):
        while True:
            try:
                await self._connect_to_WiFi()
                await self._run_main_loop()
                    
            except Exception as e:
                self.dprint('Глобална комуникационна грешка: ', e)
                await asyncio.sleep(20)

    async def _connect_to_WiFi(self):
        self.dprint('Свързване с WiFi и 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('Свързано!')
        self.internet_outage = False

    async def _run_main_loop(self):
        # Цикъл вечно
        mins = 0
        while True:
            gc.collect()  # За данни за RAM.
            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("Появи се изключение: ", 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 и collections (използва се вътре в mqtt_as).

Стартираме и… получаваме MemoryError. И с всеки опит да разбера къде точно изтича паметта, с всеки следващ дебъг принт, тази грешка се появяваше все по-рано. Кратко търсене в Google ми показа, че в микроконтролера има само 30kB памет, в която 65kB код (включително библиотеките) не могат да се поберат.

Но изходът съществува. Оказва се, че micropython не изпълнява кода директно от .py файла — този файл първо се компилира. Освен това, той се компилира директно на микроконтролера, преобразува се в байткод, който след това се съхранява в паметта. И за работа на компилатора също е необходим определен обем оперативна памет.

Трикът е да се избавим от ресурсоемката компилация на микроконтролера. Може да се компилират файловете на голям компютър, а в микроконтролера да се зареди вече готовият байткод. За целта е нужно да свалим фърмуера на micropython и да го компилираме. Утилита mpy-cross..

Не написах Makefile, а ръчно преминах и скомпилирах всички нужни файлове (включително библиотеки) по следния начин:

mpy-cross water_counter.py

Остана само да заредя файловете с разширение .mpy, като предварително не забравя да изтрия съответните .py от файловата система на устройството.

Цялата разработка извършвах в програмата (IDE?) ESPlorer. Тя позволява да се зареждат скриптове в микроконтролера и веднага да се изпълняват. В моя случай цялата логика и създаването на всички обекти се намират във файла water_counter.py (.mpy). Но за да се стартира всичко автоматично, на старта трябва да има файл с име main.py. И това задължително трябва да е .py, а не предварително компилиран .mpy. Ето простото му съдържание:

import water_counter

Стартираме — всичко работи. Но свободната памет е заплашително малко — около 1 кб. Имам още планове за разширяване на функционалността на устройството, и този килобайт явно ще ми бъде недостатъчен. Но се оказа, че и за този случай има решение.

Работата е в това. Дори когато файловете са компилирани в байткод и се намират на вътрешната файлова система, в действителност те все пак се зареждат в оперативната памет и се изпълняват оттам. Но се оказва, че micropython може да изпълнява байткод директно от флаш памет, но за това е нужно да го вградим директно във фърмуера. Това не е сложно, въпреки че на моя нетбук отне прилично време (само там се оказа, че имам линукс).

Алгоритъмът е следният:

• Свалете и инсталирайте ESP Open SDK. Тази неща компилира компилатора и библиотеките за програми за ESP8266. Компилира се според инструкциите на главната страница на проекта (избрах инсталация STANDALONE=yes).
• Изтеглете източниците на micropython.
• Необходимите библиотеки добавете в ports/esp8266/modules в дървото на micropython.
• Компилираме фърмуера според инструкциите в файла ports/esp8266/README.md.
• Качваме фърмуера в микроконтролера (аз го правя на Windows с програмите ESP8266Flasher или Python esptool)

Всичко, сега ‘import ssd1306’ ще зарежда кода директно от фърмуера и оперативната памет няма да се използва за това. С този трик заредих във фърмуера само кода на библиотеките, докато основният код на програмата се изпълнява от файловата система. Това позволява лесна модификация на програмата без повторна компилация на фърмуера. В момента имам около 8.5kB свободна RAM. Това ще позволи реализирането на още доста полезна функционалност в бъдеще. А ако паметта стане съвсем недостатъчна, може да се включи и основната програма във фърмуера.

И какво да правим сега?

Ок, хардуерът е сглобен, фърмуерът е написан, кутията е отпечатана, устройството е прикрепено на стената и радостно мига с лампичка. Но все още това е черен кутия (в буквален и преносен смисъл) и ползата от него е малка. Време е да направим нещо с MQTT съобщенията, които се изпращат на сървъра.

Моят “умен дом” работи на системата Majordomo. MQTT модул или е наличен по подразбиране, или лесно се инсталира от магазина за добавки — вече не помня откъде го взех. MQTT не е самостоятелно решение — необходим е т.н. брокер — сървър, който приема, сортира и пренасочва клиентите MQTT съобщения. Аз използвам mosquitto, който (както и majordomo) работи на същия нетбук.

След като устройството изпрати съобщение, стойността веднага ще се появи в списъка.

Тези стойности сега могат да се свържат с обектите на системата, да се използват в автоматизационни сценарии и да подлежат на различен анализ — всичко това е извън обхвата на тази статия. На заинтересованите от системата majordomo мога да препоръчам канала "Електроника В Обективе" — другарят също строи умен дом и обяснява подробно как да настроите системата.

Ще покажа само няколко графика. Това е прост график на стойностите за един ден

Лесно е да се види, че през нощта почти никой не е ползвал вода. Няколко пъти някой е ходил до тоалетната и, изглежда, филтърът за обратна осмоза е изсмукал няколко литра през нощта. Сутринта потреблението значително нараства. Обикновено ползвам вода от бойлера, но тук реших да взема вана и временно преминах на градска топла вода — това също е добре видимо на долния график.

От тази графика разбрах, че за ходене до тоалетна се използват 6-7л вода, за душ — 20-30л, за миене на съдове около 20л, а за вана са нужни 160л. През деня моето семейство консумира около 500-600л.

За особено любопитните можете да се запознаете с записите за всяка отделна стойност

Оттук разбрах, че при отворен кран водата тече със скорост от около 1л за 5с.

Но в този вид статистиката, вероятно, не е много удобна за преглед. В majordomo има още възможности да се гледат графици на консумацията по дни, седмици и месеци. Например, това е график на консумацията в колони.

В момента имам данни само за седмица. След месец този график ще бъде по-показателен — всеки ден ще бъде представен с отделна колона. Малко картината развалят корекциите на стойностите, които въвеждам ръчно (най-голямата колона). И все още не е ясно, дали аз неправилно зададох най-първоначалните стойности почти на куб по-малко, или това е бъг в фърмуера и не всички литри са отчетени. Нуждавам се от повече време.

Още трябва да поработя върху самите графици, да ги избелвам, боядисвам. Може би също така ще изградя график на консумацията на памет за отстраняване на трудности — може би там нещо изтича. В момента всичко това е на етап идея.

Заключение

Днес моят апартамент стана малко по-умен. С това малко устройство ще ми бъде по-удобно да следя консумацията на вода в дома. Ако преди това съм се учудвал “отново много вода похарчихме за месеца”, сега ще мога да намеря източника на тази консумация.

Някои може да намерят странно да гледат показания на екрана, когато той е на метър разстояние от самия измервател. Но в не много далечното бъдеще планирам да се преместя в друг апартамент, където ще има няколко вертикални тръби за вода, а самите измервателни уреди, вероятно, ще бъдат разположени на стълбищната площадка. Така че устройството за дистанционно измерване на показанията ще бъде много удачно.

Функционалността на устройството също планирам да разширя. Вече разглеждам моторизирани вентили. В момента за превключване между бойлер-общинска вода ми се налага да завъртам 3 крана в труднодостъпен ъгъл. Щеше да е много по-удобно да го правя с един бутон с подходяща индикация. И, разбира се, би било добре да внедря защита от протечки.

В статията описах моето решение на базата на ESP8266. Според мен, получи се доста интересен вариант на фърмуер на micropython с използването на корутини - просто и приятно. Опитах се да опиша множество нюанси и грешки, с които се срещнах по време на работата. Може би съм описал всичко твърде детайлно; за мен, като читател, е по-лесно да прегледам ненужното, отколкото да се опитвам да допълня нещата, които не са били споменати.

Както винаги, съм отворен за конструктивна критика.

Изходен код
Схема и платка
Модел на корпуса

Източник: habr.com