🥇Ühendame veemõõdiku nutikoduga

Kunagi olid koduautomaatikasüsteemid, või nagu neid sageli nimetatakse, „nutikodu“, äärmiselt kallid ja neid said endale lubada vaid rikkad. Tänapäeval võib turult leida piisavalt eelarvesõbralikke komplekte anduritega, nuppude/lülititega ja täiturite seadmetega, mis haldavad valgustust, pistikupesi, ventilatsiooni, veevarustust ja teisi tarbijaid. Isegi kõige vähem oskuslik DIY-huviline võib kergesti alustada nutikoduseadmete kokkupanekut odava hinnaga.

Tavaliselt on pakutavad seadmed kas andurid või täiturmehhanismid. Need võimaldavad lihtsalt ellu viia stsenaariume nagu „liikumisanduri aktiveerimisel süüta tuli“ või „ukse kõrval olev lüliti kustutab kogu korteri tuled“. Kuid telemeetria ei õnnestunud eriti hästi. Parimal juhul on see temperatuuri ja niiskuse graafik või hetkmugavus konkreetse pistikupesaga.

Hiljuti paigaldasin endale veemõõtjad pulsiväljundiga. Iga liitri puhul, mis mööda mõõtjast voolab, aktiveerib magnetkontakt ja sulgeb kontakti. Jäänud on väike asi — ühendada juhtmed ja proovida sellest kasu saada. Näiteks analüüsida veetarbimist tundide ja nädalapäevade kaupa. Kui korteris on mitu veetorustikku, siis on mugavam näha kõiki praeguseid näitajaid ühel ekraanil, kui ronida raskesti ligipääsetavatesse niššidesse taskulambiga.

Allpool on minu versioon seadmeid ESP8266 baasil, mis loendab veemõõtjate impulsse ja saadab MQTT kaudu andmed nutikodu serverisse. Programmeerime micropythonis, kasutades uasyncio raamatukogu. Firmware'i loomise käigus sattusin mitmete huvitavate raskuste otsa, millest räägin ka selles artiklis. Alustame!

Schema

Kogu skeemi südameks on ESP8266 mikrokontrolleri moodul. Alguses plaaniti ESP-12, kuid minu oma osutus defektaalseks. Pidin leppima ESP-07 mooduliga, mis oli saadaval. Õnneks on need võrdsed ning väljundite ja funktsionaalsuse poolest, erinevus on ainult antennis — ESP-12-l on sisemine antenn, samas kui ESP-07-l on väline. Tõsi, isegi ilma antennita on WiFi signaal minu vannitoas normaalne.

Mooduli kinnitus on standardne:

reset-nupp koos tõukemehhanismi ja kondensaatoriga (kuigi mõlemad on juba sees moodsul)
signaal enable (CH_PD) on tõmmatud toite külge
GPIO15 on maapinn tõmmatud maapinnale. See on vajalik ainult käivitamisel, kuid mul ei ole rohkem sellele jalale ühendamiseks midagi.

Modi hõivamisrežiimi lülitamiseks peab GPIO2 olema ühendatud maapinnaga ja mugavuse huvides olen ma ette näinud Boot-nupu. Tavalises olekus tõmbab see pin toiteseisu.

GPIO2 olekut kontrollitakse ainult töö alguses — pärast toite sisselülitamist või kohe pärast taaskäivitamist. Seega kas moduleerub nagu tavaliselt või lülitub flashing-režiimi. Pärast laadimist saab seda väljundit kasutada tavalise GPIO-na. Ja kuna seal on juba nupp, siis saab sellele lisada mõnda kasulikku funktsiooni.

Programmeermiseks ja silumiseks kasutan UART-i, mis on väljundis. Kui on vaja, ühendage lihtsalt USB-UART-adapter sinna. Pea meeles, et moodul on toiteks 3,3V. Kui unustad adapteri selle pingele lülitada ja rakendad 5V, siis tõenäoliselt moodul puruneb.

Elektriga vannitoas mul probleeme ei ole — pistik on umbes meetri kaugusel arvestitest, nii et varustan 220V-st. Toiteallikana töötab mul väike HLK-PM03 plokk firma Tenstar Robot. Isiklikult on mul analoog- ja võimsuselektroonikaga kitsas, aga siin on valmis toiteplokk väikese korpuse sees.

Töörežiimide signalisatsiooniks olen ma ette näinud LED-i, mis on ühendatud GPIO2-ga. Kuigi ma ei hakkanud seda tööle panema, kuna ESP-07 moodulil on juba LED, mis on samuti ühendatud sama GPIO2-ga. Kuid plaadil olgu see — äkki ma tahan selle LED-i korpusele viia.

Liigume kõige huvitavama juurde. Veearvestitel ei ole mingit loogikat, me ei saa küsida hetkeseisundeid. Ainus, mis meile kätte saadav on, on impulsid — kontaktide sulgemine iga liitri kohta. Minu geneetilised kontaktid on viidud GPIO12/ GPIO13. Tõmbav takisti lülitan programmikohas moodulisse.

Alguses unustasin, et peab olema R8 ja R9 takistid ning minu versioonil neid ei ole. Kuid kuna ma juba jagan skeemi üldiseks vaatamiseks, siis tasub see viga parandada. Takistid on vajalikud, et port ei kahjustuks, kui lähteprogramm hakkab takistama ning seadistab pinu, ja geneetilised kontaktid lühistavad selle joone maapinnaga (takisti korral voolab maksimaalselt 3,3V/1000Ω = 3,3mA).

On veidi mõelda, mida teha, kui elekter kaob. Esimene variant on alguses küsida serverilt algseid arve väärtusi. Kuid see tooks endaga kaasa protokolli vahetuse märkimisväärse keerukuse. Veelgi enam, seadmestiku töövõime sõltub sel juhul serveri seisundist. Kui pärast voolu katkestamist server ei käivitu (või käivitub hiljem), ei saaks veearvesti algseid väärtusi küsida ja hakkaks valesti tööle.

Seetõttu otsustasin salvestada arvestite väärtused I2C kaudu ühendatud mälukiipi. Mul ei ole suurusele mälukiibile erilisi nõudeid — tuleb salvestada vaid 2 numbrit (kuupmeetrite arv sooja ja külma vee arvestites). Isegi väikseim moodul sobib. Kuid kirjutamistsüklite arvu tuleks tähele panna. Enamikul moodulitest on see 100 tuhat tsüklit, mõnel kuni miljon.

Tundub, et miljon on palju. Kuid nelja aasta jooksul, mil olen elanud oma korteris, olen tarbinud veidi üle 500 kuupmeetri vett, see on 500 tuhat liitrit! Ja 500 tuhat salvestust mällu. Ja see on ainult külm vesi. Loomulikult võiksin kiipi iga paari aasta tagant ümber jootma, kuid selgus, et on olemas FRAM kiibid. Programmeerimise seisukohalt on see sama, mis I2C EEPROM, ainult väga suure arvu kirjutamise tsüklitega (sadu miljoneid). Siiski pole mul siiani olnud aega poodi minna, kus sellised kiibid on, seega jääb tavaliselt 24LC512.

Trükkplaat

Alguses kavandasin plaadi kodustes tingimustes. Seetõttu projekteeriti plaat ühetasandilisena. Kuid veetnud tunni laserpooniga ja jootmismaskiga (ilma selleta ei ole kuidagi õige), otsustasin siiski tellida plaadid hiinlastelt.

Peaaegu enne plaadi tellimist mõistsin, et lisaks mälukiibile võib I2C bussi ühendada ka midagi muud kasulikku, näiteks ekraani. Mis just sellele kuvada — see on veel küsimus, kuid plaadi peal tuleb see ära teha. Noh, kuna plaanisin tellida plaate tehases, ei olnud enam mõtet end ühetasandilise plaadiga piirata, seega on I2C read plaadi tagaküljel ainukesed.

Ühepoolse kaabliga oli seotud ka üks suur viga. Kuna plaat joonistati ühepoolne, plaaniti rajada takistid ja SMD komponendid ühele poole, samas kui väljundkomponendid, pistikud ja toiteallikas teisele. Kui sain kuu aja pärast plaadid, unustasin algse plaani ja keevitasin kõik komponendid esiplaadi külge. Ja ainult siis, kui jõudsin toiteallika keevitamisele, selgus, et pluss ja miinus on vastupidised. Pidin improviseerima juhtmetega. Ülaltoodud pildil olen juba muutnud jaotust, kuid maa ühendatakse plaadi ühe osast teise läbi Boot-nupu väljundite (kuigi oleks saanud teisel kihil kaala joonistada).

See välja kukkus nii.

Korpus

Järgmine samm on kast. Kui sul on 3D printer, pole see probleem. Ma ei hakanud liiga palju vaeva nägema - lihtsalt joonistasin vajaliku suurusega kasti ja lõikasin vajalikesse kohtadesse avad. Kate kinnitub korpusele väikeste kruvidega.

Olen juba maininud, et Boot-nuppu saab kasutada universaalse nupu kujul - viime selle esipaneelile. Selleks joonistasin spetsiaalse "aukude" koha, kus nupp asub.

Korpuse sees asuvad ka kännud, kuhu plaat paigaldatakse ja mille külge see kinnitatakse ühekordse M3 kruviga (plaadil polnud rohkem ruumi).

Ekraani valisin juba siis, kui printisin esimese prooviversiooni korpusest. Tavaline kahekohaline ekraan ei mahtunud sellesse korpusesse, aga varudest leidsin OLED ekraani SSD1306 128×32. Veidi väike, aga mul pole teda iga päev vaadata - sobib.

Mõeldes ja nii ja naa, kuidas juhtmed sellest läbi viia, otsustasin kleebida ekraani korpuse keskele. Ergonomika on loomulikult madal - nupp ülal, ekraan all. Kuid olen juba öelnud, et idee ekraani kinnitamiseks tuli liiga hilja ja oli laiskus plaati uuesti disainida, et nupp viia.

Seade on kokku pandud. Ekraanimoodul on liimitud kuuma liimiga.

Lõpptulemust saab näha KDPV-l.

Puhversioon

Liigume tarkvaralise osa juurde. Selliste väikeste projektide jaoks meeldib mulle kasutada Python keelt (micropython)- kood on väga kompaktne ja arusaadav. Õnneks pole siin vaja liikuda registrite tasandile, et mikrosekundeid välja pigistada - kõik on võimalik teha Pythonist.

Tundub, et kõik on lihtne, aga tegelikult on seadmes mitu sõltumatut funktsiooni:

Kasutaja vajutab nuppu ja vaatab ekraanile
Liitrid tikuvad ja värskendavad väärtusi flash-mälus
Modul jälgib WiFi-signaali ja vajadusel uuesti ühendab
Aga vilkuva lambita ei saa küll hakkama

Ei saa lubada, et üks funktsioon ei töötaks, kui teine mingil põhjusel jääb seisma. Olen muudes projektides saanud piisavalt kaktuseid, nüüd näen pidevalt tõrkeid nagu "jätsime ühe liitri vahele, kuna just siis värskendati ekraani" või "kasutaja ei saa midagi teha, kuni moodul ühendub WiFi-ga". Muidugi, mõned asjad saab teha katkestuste kaudu, aga võib tekkida piirangud kestuse, pesastamise, või mitte aatomaarsete muutuste tõttu. Ja kood, mis tegeleb kõigega korraga, muutub kiiresti pudruks.

Uues projektis tõsisemalt kasin klassikalist jaotavat mitmeülesandelist töötlemist ja FreeRTOS-i, kuid antud juhul osutus sobivamaks mudel koorfunktsioonide (coroutines) ja uasync teegiga . Ja Python'i kooruide rakendus on lihtsalt suurepärane — arendaja jaoks on kõik tehtud lihtsalt ja mugavalt. Kirjutad lihtsalt oma loogika, lihtsalt ütled, kus kohtades saab vahetada voogude vahel.

Jagatud ja konkurentsivõimeline mitmeülesandeline töötlemine võiks olla valikuline uurimiseks. Aga nüüd, lõpuks, liigutame koodi juurde.

#####################################
# 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

Iga loenduri töötleb Counter klassi eksemplar. Esiteks lugesime EEPROM-ist (value_storage) loenduri algväärtuse — nii teeme energiakatkestuse järgselt taastamise.

Pin initsialiseeritakse sisseehitatud tõmbamisega toite poole: kui reed on suletud — on joon null, kui avatud, tõmbab joon toite poole ja kontroller loeb ühte.

Samuti käivitatakse siin eraldi ülesanne, mis küsib pinni. Iga loendur käivitab oma ülesande. Siin on selle kood

    """ Küsige pinni ja edastage väärtus, kui teine liiter möödus """
    async def _switchcheck(self):
        last_checked_pin_state = self._pin.value()  # Saage algne olek

        # Küsige pinni muutust
        while True:
            state = self._pin.value()
            if state != last_checked_pin_state:
                # Oleku muutus: toimige nüüd.
                last_checked_pin_state = state
                if state == 0:
                    self._another_litre_passed()

            # Ignoreerige edasisi oleku muutusi, kuni lülitus on stabiliseerunud
            await asyncio.sleep_ms(Counter.debounce_ms)

25 ms viivitus on vajalik kontaktide krahhi filtreerimiseks ning reguleerib, kui sageli ülesanne ärkab (kui see ülesanne magab, töötavad teised ülesanded). Iga 25 ms funktsioon ärkab, kontrollib pinni ja kui hermeetilised kontaktid on suletud, tähendab see, et läbi arvesti on läbinud järgmine liiter ja see tuleb töödelda.

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

        self._value_storage.write(self._value)

Järgmise liitri töötlemine on triviaalne — lihtsalt suurendatakse arvestit. Ja uus väärtus oleks hea ka mälule salvestada.

Kasutusmugavuse huvides on ette nähtud "juurdepääsud"

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

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

Aga nüüd kasutame Pythoni ja uasynci raamatukogu eeliseid ning teeme arvesti oodatavaks (kuidas seda eesti keelde tõlkida? Seda, mida saab oodata?).

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

        return self.value()

    __iter__ = __await__

See on mugav funktsioon, mis ootab, kuni arvesti väärtus uuendatakse — funktsioon ärkab aeg-ajalt ja kontrollib _value_changed lippu. Selle funktsiooni eripära on see, et väljakutsuv kood võib selle funktsiooni kutsumise ajal uinuda ja magada, kuni uus väärtus on saadud.

Aga kuidas on katkestustega?Jah, sel hetkel võite mind naljatada, sest ma ütlesin katkestuste kohta, kuid tegelikult tegin ma lolli pinni küsitlust. Tegelikult on katkestused esimesed, mida ma proovisin. ESP8266-s on võimalik korraldada katkestust tõusul ja isegi kirjutada katkestuse töötleja Pythoni keeles. Selles katkestuses saab muuta muutuja väärtust. Ilmselt oleks sellest piisavalt, kui arvesti oleks alluv seade — selline, mis ootab, kuni temalt küsitakse seda väärtust.

Kahjuks (või õnneks?) on minu seade aktiivne, see peab ise sisaldama sõnumeid MQTT protokolli kaudu ja salvestama andmeid EEPROM-i. Siin tulevad mängu piirangud — katkestustes ei saa mälu eraldada ega kasutada suurt steki, mistõttu võib unustada sõnumite saatmise võrgus. On selliseid kasulikke funktsioone nagu micropython.schedule(), mis võimaldavad käivitada mõnda funktsiooni “niipea kui see on võimalik”, kuid tekib küsimus “kui palju sellest kasu on?”. Äkki me saadame just praegu mõne sõnumi, ja siis sekkub katkestus ja rikub muutujate väärtused. Või näiteks, serverilt on tulnud uus arvu väärtus, kui me ei ole veel eelmist salvestanud. Ühesõnaga, tuleb ehitada sünkroniseerimine või leida mõni muu lahendus.

Ja aeg-ajalt tuleb ette RuntimeError: schedule stack full, ja kes seda teab, miks?

Kuid otsese küsitluse ja uasync-iga tundub see sel juhul kuidagi ilusam ja usaldusväärsem.

EEPROM-i töötlemise viis on välja viidud väikese klassi.

class EEPROM():
    i2c_addr = const(80)

    def __init__(self, i2c):
        self.i2c = i2c
        self.i2c_buf = bytearray(4) # Vältige puhverdamise loomist/ hävitamist iga kõne jaoks


    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)

Pythoni keeles on otse baitidega töötamine keeruline, kuid just baitidesse salvestatakse mälu. Tuli välja mõelda konversioon täisarvu ja baitide vahel, kasutades ustruct raamatukogu.

Et iga kord mitte edastada I2C objekti ja mäluaadressi, olen selle kogu kokku pakkinud väikese ja mugava klassina.

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 objekt loomine toimub järgmiste parameetritega.

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

Jõuame kõige huvitavamani — MQTT serveriga suhtlemise rakendamine. Protokolli ennast pole vaja rakendada — internetis on leidunud valmis asünkroonne teostus.. Seda me hakkame kasutama.

Kogu huvitav osa on koondunud klassi CounterMQTTClient, mis põhineb raamatukogu MQTTClient-l. Alustame periferiast.

#####################################
# 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))

Siin luuakse ja seadistatakse lambipirni ja nupu pins, samuti külma ja kuuma vee arvestite objektid.

Alguses ei ole kõik nii triviaalne

    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 teegi seadete määramiseks kasutatakse suurt sõnastikku erinevate seadistustega — config. Enamik vaikeseadeid sobib meile, kuid paljusid seadeid tuleb määrata selgesõnaliselt. Et mitte seadeid otse koodis määrata, hoian need tekstifailis config.txt. See võimaldab muuta koodi sõltumatult seadistustest ning luua mitu sama seadet erinevate parameetritega.

Viimane koodiblokk käivitab mitu korutiini erinevate süsteemi funktsioonide teenindamiseks. Näiteks korutiin, mis teenindab loendureid.

    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))

Korutiin ootab tsükli jooksul uut loenduri väärtust ja niipea, kui see ilmub — saadab sõnumi MQTT protokolli kaudu. Esimene koodilõik saadab algväärtuse isegi siis, kui vesi loenduri kaudu ei voola.

Põhiklass MQTTClient teenindab ennast ise, alustab WiFi ühendust ja uuendab ühendust, kui see katkeb. WiFi ühenduse oleku muutustest teavitab meid raamatukogu, kutsudes üles wifi_connection_handler.

    async def wifi_connection_handler(self, state):
        self.internet_outage = not state
        if state:
            self.dprint('WiFi on püsti.')
            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 on maas.')
            
        await asyncio.sleep(0)

Funktsioon on ausalt öeldes kopeeritud näidetest. Antud juhul loendab see interneti katkestuste (internet_outages) arvu ja nende kestust. Ühenduse taastumise korral saadetakse serverisse seisaku aeg.

Muide, viimane sleep on vajalik ainult selleks, et funktsioon muutuks asünkroonselt — raamatukogus kutsutakse seda välja läbi await, samas võivad kutsuda ainult funktsioonid, mille kehas on teine await.

Lisaks WiFi-le tuleb luua ühendus ka MQTT vahendajaga (serveriga). Sellega tegeleb samuti raamatukogu, ja meil on võimalus teha midagi kasulikku, kui ühendus on loodud.

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

Siin registreerime end mitmete sõnumite jaoks — serveril on nüüd võimalus määrata jooksvad arvesti väärtused, saates vastava sõnumi.

    def mqtt_msg_handler(self, topic, msg):
        topicstr = str(topic, 'utf8')
        self.dprint("Saadud MQTT sõnumi teema={}, 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))

See funktsioon töötleb saabunud sõnumeid, ja sõltuvalt teemast (sõnumi nimest) uuendatakse ühe arvesti väärtuseid.

Paari abifunktsiooni

    # 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")

See funktsioon tegeleb sõnumi saatmisega, kui ühendus on loodud. Kui ühendust pole — sõnumit ignoreeritakse.

Ja see on lihtsalt mugav funktsioon, mis koostab ja saadab silumiseks mõeldud sõnumeid.

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

Nii palju teksti, ja me pole siiani LED-d vilkuma pannud. Siin on see.

    # 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)

Olen ette näinud 2 vilkumise režiimi. Kui ühendus kadus (või see alles luuakse), vilgub seade kiiresti. Kui ühendus on loodud — seade vilgub korra 5 sekundi jooksul. Soovi korral saab siia rakendada ka teisi vilkumise režiime.

Aga LED on see lihtsalt lõbutsemine. Oleme siiani tahvelarvuti peale ka läinud.

    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)

See, this is what I was talking about — how simple and convenient it is with coroutines. This small function describes ALL interaction with the user. The coroutine simply waits for a button press and activates the display for 3 seconds. The current readings of the counters are shown on the display.

There are still a couple of small things left. Here’s the function that (re)starts all of this. The main loop is merely responsible for sending various debug information once a minute. In general, I'm providing it as is — I don't think it needs much commentary.

   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)

Well, a couple more settings and constants for completeness of description.

#####################################
# 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)

This is how it all starts.

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

Something has happened to my memory.

So, the entire code is here. I uploaded the files using the ampy utility — it allows uploading them to the internal flash storage (the one in the ESP-07) and then accessing them from the program like regular files. I also uploaded the libraries mqtt_as, uasyncio, ssd1306, and collections (used within mqtt_as).

We run it and… get a MemoryError. The more I tried to understand where exactly the memory was leaking, the earlier this error occurred as I placed debug prints. A quick Google search led me to realize that the microcontroller has only 30KB of memory, while 65KB of code (including libraries) simply cannot fit.

Kuid väljapääs on olemas. Tõepoolest, micropython ei käivita koodi otse .py failist — see fail kompileeritakse esmalt. Veelgi enam, see kompileeritakse otse mikrokontrolleril, muutudes byte-koodiks, mida seejärel säilitatakse mälus. Ja kompilatori tööks on samuti vajalik teatud hulk operatiivmälu.

Trikk seisneb selles, et vabastada mikrokontroller ressursimahukast kompileerimisest. Failid saab kompileerida suurel arvutil, ja mikrokontrollerisse laadida juba valmis byte-kood. Selleks tuleb alla laadida micropythoni püsivara ja koguda utiliit mpy-cross.

Ma ei hakanud kirjutama Makefile'i, vaid käisin käsitsi kõik vajalikud failid (sealhulgas teegid) umbes nii kokku:

mpy-cross water_counter.py

Jäänud on ainult laadida failid .mpy laiendiga, unustamata eelnevalt kustutada vastavad .py seadme failisüsteemist.

Kogu arendust tegin programmiga (IDE?) ESPlorer. See võimaldab skripte mikrokontrollerisse laadida ja neid kohe käivitada. Minu puhul on kogu loogika ja kõigi objektide loomine failis water_counter.py (.mpy). Kuid et kõik see automaatselt käivituks, peab olema ka fail nimega main.py. See peab olema just .py, mitte eelnevalt kompileeritud .mpy. Siin on selle triviaalne sisu.

import water_counter

Käivitame — kõik töötab. Kuid vaba mälu on ähvardavalt vähe — umbes 1kb. Mul on veel plaane seadme funktsionaalsuse laiendamiseks ning sellest kilobaidist jääb mulle selgelt väheks. Kuid selleks on samuti lahendus.

Asi on selline. Isegi kui failid on kompileeritud byte-koodiks ja asuvad sisemises failisüsteemis, laaditakse need ikkagi operatiivmälu ja täidetakse sealt. Kuid osutub, et micropython oskab byte-koodi täita otse flash-mälust, kuid selleks tuleb see otse püsivara sisse ehitada. See ei ole keeruline, kuigi minu netbookil võttis see palju aega (seal oli mul Linux).

Algoritm on järgmine:

Laadi alla ja installi ESP Open SDK. See asi kogub ESP8266 jaoks mõeldud tarkvara kompilaatorit ja teeke. See kogutakse projekti peamise lehe juhiste järgi (valisin STANDALONE=yes installatsiooni).
Laadi alla micropythoni allikafailid
Vajalikud teegid tuleb asetada ports/esp8266/modules kausta micropythoni puus.
Kogume püsivara vastavalt instruktsioonile failis ports/esp8266/README.md
Laadime püsivara mikrokontrollerisse (teen seda Windowsis programmide ESP8266Flasher või Pythonis kirjutatud esptool'iga)

Nüüd, kui ‘import ssd1306’ käivitab koodi otse püsivara seest, ei kulu selleks enam operatiivmälu. Nii sain püsivara salvestada ainult teeki koodi, samal ajal kui peaeesmärk programmi käivitatakse failisüsteemist. See võimaldab mul programmi hõlpsasti muuta ilma püsivara uuesti kompileerimata. Praegu on mul vabalt umbes 8,5 kB RAM-i. See võimaldab tulevikus lisada veel palju kasulikku funktsionaalsust. Kui mälu peaks tõeliselt väheks jääma, siis saan ka põhikoodi püsivara sisse suruda.

Ja mida nüüd sellega teha?

Okei, riistvara on kokku löödud, püsivara on kirjutatud, karp on välja trükitud, seade on seina külge kinnitatud ja rõõmsalt vilgub lamp. Aga kuni see on lihtsalt must kast (nii sõnasõnalises kui ka kujundlikus tähenduses), on sellest veel vähe kasu. On aeg tegeleda MQTT sõnumitega, mis saadetakse serverisse.

Minu 'nutikodu' töötab süsteemi Majordomo. MQTT modul on kas juba karbis olemas või kergesti paigaldatav lisade turult — ei mäleta, kust see mul tuli. MQTT on ise piisav ainult siis, kui on olemas nn maakler — server, mis võtab, sorteerib ja suunab MQTT sõnumid klientidele. Kasutan mosquitto, mis (nagu ka majordomo) töötab kõik samal netbook'il.

Pärast seda, kui seade vähemalt korra sõnumi saadab, ilmub väärtus kohe nimekirja.

Need väärtused saab nüüd siduda süsteemi objektidega, neid saab kasutada automatiseerimise stsenaariumites ja läbi viia erinevaid analüüse — kõik see ei kuulu selle artikli, fookuse alla. Kes on huvitatud majordomo süsteemist, sellele soovitan kanalit Elektronika Objektiivis — sõber, kes samuti ehitab nutikat kodu ja selgitab süsteemi seadistamist arusaadavalt.

Näitan vaid paar graafikut. See on lihtne ööpäevase väärtuste graafik

On näha, et öösel ei kasutanud keegi vett. Korduvalt käidi tualetis ja tundub, et pöördosmoosi filter imeb paar liitrit öö jooksul. Hommikuks suureneb tarbimine oluliselt. Tavaliselt kasutan vett boilerist, aga seekord soovisin vanni võtta ja lülitasin ajutiselt sisse linna kuuma vee — see on samuti alumisel graafikul hästi nähtav.

Sellelt graafikult sain teada, et tualetti minek on 6-7 liitrit vett, duši all käimine 20-30 liitrit, nõude pesemine umbes 20 liitrit ja vannitamseks on vaja 160 liitrit. Minu perel on päevas tarbimist umbes 500-600 liitrit.

Eriti uudishimulikele on saadaval kirjed iga eraldi väärtuse kohta.

Siit sain teada, et avatud kraanist voolab vesi kiiresti umbes 1 liiter 5 sekundi jooksul.

Kuid sellisel kujul on statistikat ilmselt ebamugav vaadata. Majordomos on veel võimalusi vaadata tarbimist graafikute järgi päevade, nädalate ja kuude kaupa. Näiteks, siin on tarbimise grafika veergudena.

Praegu on mul andmeid ainult nädalaks. Kuu aja pärast on see graafik informatiivsem — igale päevale vastab eraldi veerg. Andmete käsitsi korrektsioonid rikkusid natuke pilti (suurim veerg). Ja praegu ei ole selge, kas ma valisin esialgsete väärtuste koha pealt liiga madala arvu või on see tarkvara viga ja mitte kõik liitrid arvesse ei läinud. Vajatakse rohkem aega.

Graafikute kallal tuleb veel töötada, valgendada ja värvida. Võib-olla hakkan ka mälutarbimise graafiku koostamisega tegelema — äkki seal lekib midagi. Võib-olla kavatsen kuvada ka perioode, mil internetti ei olnud. Praegu on kõik see ideetasemel.

Kokkuvõte

Täna muutus mu korter natuke nutikamaks. Sellise väikese seadmega on mul mugavam jälgida veetarbimist kodus. Kui varem hädasin, et "taas palju vett tarbitud", siis nüüd suudan leidmiseks selle tarbimise allika.

Mõned võivad leida kummalisena vaadata näidikute ekraanilt, kui see on arvestist meetri kaugusel. Kuid mitte väga kauges tulevikus plaanin ma elada teises korteris, kus on mitu veetoru ja arvestid asuvad tõenäoliselt trepikojas. Seega on kaugloetav seade tõeliselt teretulnud.

Seadme funktsionaalsust kavatsema ka laiendada. Olen juba silmas pidanud mootorsulge. Praegu pean boileri- ja linnavee vahetamiseks kolme kraani keerama raskesti ligipääsetavas nišis. Oluliselt mugavam oleks seda teha ühe nupuvajutusega koos vastava märgutulega. Ja muidugi on mõistlik rakendada ka lekkekaitset.

Artiklis kirjeldan oma varianti seadme kohta, mis põhineb ESP8266-l. Minu arvates on mul saanud üsna huvitav variant firmware'ist micropythoniga koos korutinate kasutamisega - lihtne ja kena. Olen püüdnud kirjeldada paljusid nüansse ja vigu, millega ma kohtusin. Võib-olla kirjeldasin ma kõike liiga detailselt, isiklikult nagu lugeja oleksin ma pigem soovinud üle vaadata liigset, kui pärast järeldama, mida öelda ei jõutud.

Nagu alati olen ma avatud konstruktiivsetele kriitilistele märkustele.

Allika kood
Scheem ja plaat
Korpuse mudel

Allikas: habr.com