Anslut vattenmätaren till det smarta hemmet

En gång i tiden var hemautomatiseringssystem, eller som de ofta kallas "smart hem", fruktansvärt dyra och endast rika människor hade råd med dem. Idag kan man hitta relativt överkomliga paket på marknaden med sensorer, knappar/brytare och för aktiva enheter för att styra belysning, uttag, ventilation, vattenförsörjning och andra apparater. Och även den mest klumpiga gör-det-själv-entusiasten kan enkelt börja bygga smarta hem-enheter utan att spränga sin budget.

För det mesta är de erbjudna enheterna antingen sensorer eller aktuatorer. De möjliggör enkelt genomförande av scenarier som "när rörelsesensorn aktiveras slås ljuset på" eller "brytaren vid utgången släcker ljuset i hela lägenheten". Men telemetry har inte riktigt funkat. I bästa fall rör det sig om en temperatur- och fuktighetsgraf eller omedelbar effekt i ett visst uttag.

Nyligen installerade jag vattenmätare med impulsausgång. För varje liter som passerar genom mätaren aktiveras en ferromagnet och stänger kontakten. Nu är det bara att ansluta kablarna och försöka få nytta av det. Till exempel att analysera vattenförbrukningen per timme och veckodag. Om det finns flera rör för vatten i lägenheten är det enklare att se alla aktuella värden på en skärm istället för att krypa i svåråtkomliga nischer med en ficklampa.

Under rubriken hittar du min lösning baserad på ESP8266, som räknar impulser från vattenmätarna och skickar läsningar till smart hemservern via MQTT. Vi kommer att programmera i micropython med hjälp av uasyncio-biblioteket. När jag skapade programvaran stötte jag på några intressanta utmaningar, som jag också kommer att berätta om i denna artikel. Låt oss sätta igång!

Diagram

Hjärtat i hela schemat är modulen med mikrokontrollern ESP8266. Ursprungligen var ESP-12 planerad, men min var defekt. Jag fick nöja mig med modulen ESP-07 som fanns tillgänglig. Som tur är är de identiska både vad gäller stift och funktionalitet, skillnaden ligger bara i antennen – ESP-12 har en inbyggd antenn, medan ESP-07 har en extern. Trots allt lyckas WiFi-signalen nå fram bra även utan antenn i mitt badrum.

Anslutningen av modulen är standard:

• reset-knapp med dragning och kondensator (även om både detta och det redan finns inuti modulen)
• Signalen enable (CH_PD) är kopplad till strömförsörjningen
• GPIO15 är kopplad till jord. Detta behövs endast vid start, men jag har inget mer att koppla till den pinnen

För att sätta modulen i programmeringsläge måste GPIO2 kortslutas till jord, och för att göra det enklare har jag försett den med en Boot-knapp. Under normala omständigheter dras denna pinne till ström.

Tillståndet för linjen GPIO2 kontrolleras endast i början av driften — när strömmen tillförs eller omedelbart efter en reset. Så laddas modulen antingen som vanligt eller går in i programmeringsläge. Efter laddning kan detta utgång användas som en vanlig GPIO. Och eftersom det redan finns en knapp kan jag koppla någon användbar funktion till den.

För programmering och felsökning kommer jag att använda UART, som jag har anslutit till skenan. När det behövs kopplar jag bara in en USB-UART-adapter. Det gäller bara att inte glömma att modulen drivs av 3.3V. Om jag glömmer att ställa in adaptern på detta spänning och ger den 5V, så kommer modulen troligtvis att brinna.

Jag har inga problem med elektricitet i badrummet — uttaget ligger ungefär en meter från mätarna, så jag kommer att använda 220V som strömförsörjning. Som strömförsörjning kommer jag att använda en liten block HLK-PM03 från Tenstar Robot. Personligen har jag svårt med analog och kraftelektronik, så här är det en färdig strömförsörjning i ett litet hölje.

För att signalera driftslägen har jag försett en LED kopplad till GPIO2. Jag har dock inte lött dit den, eftersom modulen ESP-07 redan har en LED, som dessutom är kopplad till samma GPIO2. Men på kortet får den gärna finnas — kanske jag vill dra ut denna LED på höljet.

Nu kommer vi till det mest intressanta. Vattenmätarna har ingen logik, man kan inte fråga om aktuella avläsningar. Det enda vi har tillgång till är impulser — kontakter som sluter vid varje liter. Utgångarna för reed-kontakterna är kopplade till GPIO12/GPIO13. Jag kommer att aktivera den pull-up-motståndet programmässigt inuti modulen.

Inledningsvis glömde jag att förutse motstånden R8 och R9 och i min version av kortet finns de inte. Men eftersom jag redan lägger upp schemat för allmänheten så är det värt att rätta till detta misstag. Motstånden behövs för att inte bränna porten i fall programmeringen strular och sätter en etta på pinnen, medan reed-kontakten kortsluter denna linje till jord (med motståndet kommer högst 3.3V/1000Ω = 3.3mA att flöda).

Det är dags att tänka på vad man ska göra om strömmen försvinner. Det första alternativet är att begära initialvärden för mätarna från servern vid start. Men detta skulle kräva en betydande förenkling av kommunikationsprotokollet. Dessutom beror enhetens funktionalitet i så fall på serverns tillstånd. Om servern inte startade efter strömavbrottet (eller startade senare), skulle vattenmätaren inte kunna begära initialvärden och skulle fungera felaktigt.

Därför beslutade jag att implementera lagring av mätvärden i ett minneschip anslutet via I2C. Jag har inga speciella krav på storleken på flashminnet — det cần bara spara två nummer (antal liter för varmt och kallt vatten). Även den minsta modulen fungerar. Men vi måste ta hänsyn till antalet skrivcykler. För de flesta moduler är det 100 tusen cykler, och för vissa upp till en miljon.

Det verkar som om en miljon är mycket. Men under mina fyra år i min lägenhet har jag förbrukat lite mer än 500 kubikmeter vatten, det är 500 tusen liter! Och 500 tusen poster i flashminnet. Och det är bara kallt vatten. Man kan självklart löda om chipet varannat år, men det finns faktiskt FRAM-chips. Ur programmeringsperspektiv är det precis som I2C EEPROM, men med ett oändligt stort antal omskrivningscykler (hundratals miljoner). Men jag har fortfarande inte kommit iväg till affären med sådana chip, så för tillfället får en vanlig 24LC512 duga.

Kretskort

Inledningsvis planerade jag att göra kortet hemma. Därför designades kortet som ett enkelsidigt kort. Men efter att ha kämpat i en timme med en laserstrykjärn och lödmask (utan den fungerar det inte riktigt bra), bestämde jag mig ändå för att beställa kort från Kina.

Strax innan jag skulle beställa kortet insåg jag att utöver flashminneschipet kan jag även koppla något annat användbart till I2C-bussen, som en skärm. Vad exakt som ska visas på den — det är fortfarande en fråga, men det måste göras på kortet. Eftersom jag ska beställa kortet från fabriken var det egentligen meningslöst att begränsa mig till ett enkelsidigt kort, så I2C-linjerna är de enda på baksidan av kortet.

Enkelriktad layout hade också en stor nackdel. Eftersom kretskortet designades som en enkelriktad, var vägarna och SMD-komponenterna planerade att placeras på ena sidan, medan utgående komponenter, kontakter och strömförsörjning skulle vara på den andra sidan. När jag efter en månad fick korten, glömde jag den ursprungliga planen och lödde alla komponenter på framsidan. Och först när det var dags att löda strömförsörjningen upptäckte jag att plus och minus var ombytta. Jag fick improvisera med jumpers. På bilden ovan har jag redan ändrat layouten, men jorden löper från en del av kortet till en annan via knappen Boot (även om man kunde ha dragit en väg på det andra lagret).

Det blev så här

Chassi

Nästa steg är chassit. Med en 3D-skrivare är det inte ett problem. Jag lade inte ner så mycket tid på det — jag ritade bara en låda av rätt storlek och gjorde urtag på rätt ställen. Locket fästs i chassit med små skruvar.

Jag har redan nämnt att knappen Boot kan användas som en allmän knapp — låt oss ta ut den på framsidan. För detta ritade jag en speciell "brunn" där knappen bor.

Inuti chassit finns även små utsprång där kortet placeras och fästs med en enda M3-skruv (det fanns inte mer plats på kortet).

Jag valde displayen först när jag hade skrivit ut det första prototypchassit. Den standard tvåradiga displayen fick inte plats, men jag hittade en OLED-display SSD1306 128×32 i förrådet. Den är lite liten, men jag behöver inte titta på den varje dag — den duger.

Med tanke på hur kablarna skulle dras beslöt jag mig för att fästa displayen mitt i chassit. Ergonomin är så klart under all kritik — knappen är upptill, displayen nedtill. Men jag har redan sagt att idén att sätta dit displayen kom för sent och jag hade inte lust att ändra layouten för att flytta knappen.

Enheten är ihopmonterad. Displaymodulen är fäst med varm lim.

Det slutgiltiga resultatet kan ses på KDPV

Firmware

Låt oss gå vidare till programdelen. För sådana små projekt gillar jag verkligen att använda språket Python (micropython)- koden blir mycket kompakt och lätt att förstå. Det är bra eftersom det inte är nödvändigt att gå ner till registernivå för att pressa mikrosekunder — allt kan göras från Python.

Det verkar enkelt men är det inte – enheten ska ha flera oberoende funktioner:

• Användaren trycker på knappen och tittar på skärmen
• Liter tickar och uppdaterar värdena i flashminnet
• Modulen övervakar WiFi-signalen och kopplar om vid behov
• Och utan en blinkande lampa går det överhuvudtaget inte

Det får inte hända att en funktion inte fungerar om en annan av någon anledning strular. Jag har fått nog av kaktusar i andra projekt och ser nu redan buggar i stil med "missade ytterligare en liter eftersom skärmen uppdaterades just då" eller "användaren kan inte göra något medan modulen kopplar upp till WiFi". Självklart kan vissa saker göras via avbrott, men man kan stöta på begränsningar gällande varaktighet, anropens inbäddning eller icke-atomära förändringar av variabler. Och kod som försöker göra allt på en gång blir snabbt rörig.

I ett mer seriöst projekt jag använde klassisk preemptiv multitasking och FreeRTOS, men i det här fallet visade modellen samarbetsprogram (coroutines) och biblioteket uasync . Dessutom är Python-implementeringen av korutiner helt fantastisk – för programmeraren är allt gjort enkelt och bekvämt. Skriv bara din logik och säg bara var man kan växla mellan trådarna.

Skillnaderna mellan preemptiv och konkurrerande multitasking föreslår jag att man studerar som valfritt. Men nu, låt oss äntligen gå vidare till koden.

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

Varje räknare hanteras av en instans av klassen Counter. Först läses det initiala värdet från EEPROM (value_storage) – detta implementerar återställning efter strömförlust.

Pinnen initieras med inbyggd dragning till strömförsörjningen: om reed-strömbrytaren är sluten – noll på linjen, om den är öppen dras linjen upp till strömförsörjningen och kontrolleraren läser en etta.

Dessutom startas en separat uppgift som kommer att utföra avkänning av pinnen. Varje räknare kommer att starta sin egen uppgift. Här är dess kod

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

En fördröjning på 25 ms behövs för att filtrera bort kontakter som skakar, och den reglerar också hur ofta uppgiften väcks (medan denna uppgift sover, arbetar andra uppgifter). Var 25:e ms väcks funktionen, kontrollerar pinnen och om kontakterna på hermetiska brytare är slutna, betyder det att nästa liter har passerat genom räknaren och detta behöver hanteras.

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

        self._value_storage.write(self._value)

Att hantera nästa liter är trivialt – räknaren ökas bara. Det nya värdet skulle också vara bra att spara på flashminnet.

För användarvänlighet finns det "åtkomstrutor".

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

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

Och nu ska vi använda skönheterna i Python och biblioteket uasync och göra räknarobjektet waitable (hur översätter man det till svenska? Den som kan väntas?)

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

        return self.value()

    __iter__ = __await__  

Detta är en bekväm funktion som väntar tills räknarens värde uppdateras – funktionen väcks då och då och kontrollerar flaggan _value_changed. Det som är fint med denna funktion är att den anropande koden kan sova medan den anropar denna funktion och sova tills den får det nya värdet.

Men vad med avbrott?Ja, här kan ni trolla med mig och säga att jag själv sa något om avbrott, men egentligen satte jag upp en dum polling av pinnen. Egentligen är avbrott det första jag provade. I ESP8266 kan man organisera ett avbrott på en front och till och med skriva en hanterare för det avbrottet i Python. I detta avbrott kan man uppdatera värdet på variabeln. Kanske skulle det räcka om räknaren var en slav-enhet – en som väntar på att någon ska fråga efter detta värde.

Tyvärr (eller kanske lyckligtvis?) är min enhet aktiv, den ska själv skicka meddelanden via MQTT-protokollet och spara data i EEPROM. Här kommer begränsningarna in — man kan inte allokera minne och använda stort stack i avbrott, vilket gör att vi kan glömma att skicka meddelanden över nätverket. Det finns fördelar som micropython.schedule() som låter oss köra en funktion "så snart som möjligt", men frågan är "vad är poängen?". Plötsligt skickar vi ett meddelande, och ett avbrott inträffar som förstör värdena på variablerna. Eller till exempel, ett nytt värde från servern har kommit medan vi ännu inte har skrivit det gamla. Så, antingen behöver vi bygga synkronisering eller hitta ett annat sätt.

Och då och då får jag RuntimeError: schedule stack full och vem vet varför?

Med explicit polling och uasync blir det i det här fallet lite snyggare och mer pålitligt.

Jag har flyttat arbetet med EEPROM till en liten klass.

class EEPROM():
    i2c_addr = const(80)

    def __init__(self, i2c):
        self.i2c = i2c
        self.i2c_buf = bytearray(4) # Undvik att skapa/döda buffern vid varje anrop


    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)

I Python är det ganska komplicerat att arbeta direkt med byte, men det är ju byte som skrivs till minnet. Jag var tvungen att bygga en konvertering mellan heltal och byte med hjälp av biblioteket ustruct.

För att jag inte alltid ska behöva skicka I2C-objektet och minnesadressen har jag allt detta i en liten och praktisk klass.

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)

Själva I2C-objektet skapas med följande parametrar.

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

Vi närmar oss det mest intressanta — implementationen av kommunikationen med servern via MQTT. Man behöver inte implementera själva protokollet — det har hittats en. färdig asynkron implementation.. Den kommer vi att använda.

Allt det mest intressanta samlas i klassen CounterMQTTClient, som baseras på bibliotekets MQTTClient. Vi börjar med periferin.

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

Här skapas och konfigureras stift för lampan och knappen, samt objekt för kallt och varmt vatten.

Initiering är inte så trivialt

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

Inställningarna för mqtt_as-bibliotekets funktioner används genom en stor ordbok med olika inställningar - config. De flesta av inställningarna passar oss som standard, men många inställningar måste anges uttryckligen. För att inte behöva skriva inställningar direkt i koden, lagrar jag dem i en textfil som heter config.txt. Detta gör att man kan ändra koden oberoende av inställningarna, samt skapa flera identiska enheter med olika parametrar.

Den sista kodblocken startar flera korutiner för att hantera olika systemfunktioner. Här är till exempel en korutin som hanterar räknare.

    async def _counter_coro(self, counter, topic):
        # Publicera initialvärdet
        value = counter.value()
        await self.publish(topic, str(value))

        # Publicera varje nytt värde
        while True:
            value = await counter
            await self.publish_msg(topic, str(value))

Korutinen väntar i en loop på ett nytt räknarvärde, och så snart det dyker upp, skickar den ett meddelande via MQTT-protokollet. Den första delen av koden skickar det initiala värdet även när vattnet inte flödar genom räknaren.

Bas klassen MQTTClient sköter sig själv, initierar WiFi-anslutningen och återansluter när anslutningen försvinner. När WiFi-anslutningens tillstånd ändras informerar biblioteket oss genom att anropa wifi_connection_handler.

    async def wifi_connection_handler(self, state):
        self.internet_outage = not state
        if state:
            self.dprint('WiFi är uppe.')
            duration = ticks_diff(ticks_ms(), self.internet_outage_start) // 1000
            await self.publish_debug_msg('ÅteranslutenEfter', duration)
        else:
            self.internet_outages += 1
            self.internet_outage_start = ticks_ms()
            self.dprint('WiFi är nere.')
            
        await asyncio.sleep(0)

Funktionen är ärligt kopierad från exemplen. I det här fallet räknar den antalet avbrott (internet_outages) och deras varaktighet. Vid återställande av anslutningen skickas driftstoppets tid till servern.

För att nämna det, den sista sleep är bara för att göra funktionen asynkron — i biblioteket anropas den via await, annars kan endast funktioner anropas där det finns en annan await.

Förutom att ansluta till WiFi måste en anslutning till MQTT-brokern (servern) också upprättas. Det här hanteras också av biblioteket, och vi får möjlighet att göra något användbart när anslutningen är etablerad.

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

Här prenumererar vi på flera meddelanden — servern har nu möjlighet att ange aktuella värden för räknarna genom att skicka motsvarande meddelande.

    def mqtt_msg_handler(self, topic, msg):
        topicstr = str(topic, 'utf8')
        self.dprint("Mottaget MQTT-meddelande 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))

Denna funktion hanterar de mottagna meddelandena, och beroende på ämnet (namnet på meddelandet) uppdateras värdena för en av räknarna.

Ett par hjälpfunktioner

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

Denna funktion skickar ett meddelande om anslutningen är etablerad. Om det inte finns någon anslutning ignoreras meddelandet.

Och det här är bara en praktisk funktion som formar och skickar debug-meddelanden.

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

Så mycket text, och vi har fortfarande inte blinkat med lysdioden. Här är det.

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

Jag har förutsett 2 blinklägen. Om anslutningen är borta (eller bara håller på att etableras), kommer enheten att blinka snabbt. Om anslutningen är etablerad blinkar enheten en gång var 5:e sekund. Vid behov kan andra blinklägen implementeras här.

Men lysdioden är bara en lek. Vi har ju också tänkt på displayen.

    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)

Det här är vad jag pratade om — hur enkelt och bekvämt det är med korutin. Den här lilla funktionen beskriver ALL interaktion med användaren. Korutinen väntar bara på att knappen trycks och slår på skärmen i 3 sekunder. På skärmen visas aktuella räkneverk.

Det finns fortfarande några småsaker kvar. Här är funktionen som (åter)startar allt detta. Huvudloopen skickar bara olika felsökningsinformation en gång i minuten. Jag ger det som det är — det behövs nog inga särskilda kommentarer.

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

    async def _connect_to_WiFi(self):
        self.dprint('Ansluter till WiFi och 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('Ansluten!')
        self.internet_outage = False

    async def _run_main_loop(self):
        # Loopa för alltid
        mins = 0
        while True:
            gc.collect()  # För RAM-statistik.
            mem_free = gc.mem_free()
            mem_alloc = gc.mem_alloc()

            try:
                await self.publish_debug_msg("Uptid", mins)
                await self.publish_debug_msg("Repubs", self.REPUB_COUNT)
                await self.publish_debug_msg("Avbrott", 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("Ett fel inträffade: ", e)
            mins += 1

            await asyncio.sleep(60)

Några fler inställningar och konstanter för att komplett beskriva.

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

Detta startas så här

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

Något har hänt med mitt minne.

Så, hela koden finns här. Jag laddade upp filerna med hjälp av verktyget ampy — det låter mig ladda upp dem till det interna (den som sitter i ESP-07) flashminnet och sedan få tillgång till dem från programmet som vanliga filer. Dit laddade jag också de bibliotek jag använder: mqtt_as, uasyncio, ssd1306 och collections (som används inuti mqtt_as).

Vi startar och... får MemoryError. Ju mer jag försökte förstå var minnet läcker, desto tidigare uppstod det här felet. En snabb googling ledde mig till insikten att mikrokontrollern i princip har 30kB minne där 65kB kod (inklusive bibliotek) definitivt inte får plats.

Men det finns en lösning. Det visar sig att micropython inte kör koden direkt från .py-filen — den här filen kompileras först. Den kompileras faktiskt direkt på mikrokontrollern och omvandlas till bytekod som sedan lagras i minnet. Dessutom behövs en viss mängd RAM för att kompilatorn ska fungera.

Tricket är att frigöra mikrokontrollern från resurskrävande kompilering. Man kan kompilera filer på en kraftfull dator och sedan ladda den färdiga bytekoden till mikrokontrollern. För detta behöver man ladda ner micropython-firmware och bygga verktyget mpy-cross.

Jag skrev inte ett Makefile, utan gick istället manuellt igenom och kompilerade alla nödvändiga filer (inklusive bibliotek) ungefär så här

mpy-cross water_counter.py

Det återstår bara att ladda upp filerna med .mpy-ändelse, och kom ihåg att ta bort de motsvarande .py-filerna från enhetens filsystem först.

All utveckling utförde jag i programmet (IDE?) ESPlorer. Det låter oss ladda upp skript till mikrokontrollern och köra dem direkt. I mitt fall ligger hela logiken och skapandet av alla objekt i filen water_counter.py (.mpy). Men för att allt ska köras automatiskt vid start behövs även en fil med namnet main.py. Det måste vara just en .py, inte en förkompilerad .mpy. Här är dess triviala innehåll

import water_counter

Vi kör— allt fungerar. Men det finns en oroande lite ledigt minne — cirka 1 kB. Jag har fortfarande planer på att utöka enhetens funktionalitet, och den här kilobyten kommer definitivt att vara för lite för mig. Men det visade sig att det finns en lösning på det också.

Här är saken. Även om filerna har kompilerats till bytekod och ligger i det interna filsystemet, laddas de ändå in i RAM-minnet och körs därifrån. Men det visar sig att micropython kan köra bytekod direkt från flashminnet, men för detta måste man bygga in det direkt i firmwaren. Det är inte svårt, även om det tog lite tid på min netbook (jag hade Linux där).

Algoritmen är följande:

• Ladda ner och installera ESP Open SDK. Den här saken bygger kompilatorn och biblioteken för program för ESP8266. Den byggs enligt instruktionerna på projektets startsida (jag valde installationen STANDALONE=yes)
• Ladda ner källkod för micropython
• Lägg de nödvändiga biblioteken i ports/esp8266/modules i micropython-strukturen
• Bygg firmwaren enligt instruktionerna i filen ports/esp8266/README.md
• Laddar in firmware i mikrokontrollern (jag gör det på Windows med program som ESP8266Flasher eller Pythons esptool).

Nu kommer 'import ssd1306' att hämta koden direkt från firmware och inte använda RAM för detta. Med det här trickset har jag laddat in endast bibliotekskoden i firmware, medan huvudkoden för programmet körs från filsystemet. Detta möjliggör enkelt modifiering av programmet utan att behöva omkompilera firmware. Jag har för närvarande cirka 8,5 kB RAM kvar. Detta gör att jag kan implementera mycket mer användbar funktionalitet i framtiden. Om minnet blir helt otillräckligt kan jag också trycka in huvudprogrammet i firmware.

Och vad ska jag göra med detta nu?

Okej, hårdvaran är lödd, firmware är skriven, lådan är utskriven, enheten är fastsatt på väggen och blinkar glatt med en lampa. Men hittills är detta fortfarande en svart låda (både bokstavligt och bildligt) och det finns fortfarande inte så mycket nytta av den. Det är dags att göra något med MQTT-meddelanden som skickas till servern.

Mitt "smart hem" körs på Majordomo-systemet.. MQTT-modulen finns kanske redan från början, eller så kan den lätt installeras från tilläggsmarknaden – jag minns inte riktigt varifrån jag fått den. MQTT är inte självförsörjande – en så kallad broker behövs – en server som tar emot, sorterar och vidarebefordrar MQTT-meddelanden till klienterna. Jag använder mosquitto, som (liksom majordomo) körs på samma netbook.

Så fort enheten skickar ett meddelande, dyker värdet genast upp i listan.

Dessa värden kan nu kopplas till systemets objekt, de kan användas i automatiseringsscenarier och genomgå olika analyser – allt detta ligger utanför denna artikels omfattning. För de som är intresserade av majordomo-systemet kan jag rekommendera kanalen Elektronik i Linsen – en vän som också bygger ett smart hem och tydligt förklarar hur man konfigurerar systemet.

Jag kommer att visa bara några grafer. Detta är en enkel graf över värden under en dag.

Det är tydligt att ingen använde vatten på natten. Några gånger har någon gått på toaletten, och det verkar som om omvänd osmosfilter drar några liter under natten. På morgonen ökar förbrukningen avsevärt. Vanligtvis använder jag vatten från beredaren, men här ville jag ta ett bad och tillfälligt bytte till kommunalt varmvatten – det syns tydligt på den nedre grafen.

Från den här grafen har jag lärt mig att toalettbesök motsvarar 6-7 liter vatten, att duscha – 20-30 liter, att diska ungefär 20 liter, och att ta ett bad kräver 160 liter. Under en dag förbrukar min familj ungefär 500-600 liter.

För särskilt nyfikna går det att kika på registreringarna för varje specifikt värde.

Härifrån lärde jag mig att vatten rinner med en hastighet av ungefär 1 liter var 5:e sekund med öppet kran.

Men i sin nuvarande form är statistiken kanske inte så lätt att titta på. I majordomo finns det även möjlighet att se vattenförbrukning i grafer per dag, vecka och månad. Här är till exempel en stapeldiagram över vattenförbrukningen.

För tillfället har jag data endast för en vecka. Om en månad kommer den här grafen att vara mer representativ – varje dag kommer att ha en egen stapel. Värdena som jag manuellt matar in stör tyvärr bilden lite (den största stapeln). Och det är fortfarande oklart om jag felaktigt ställt in de första värdena nästan en kub mindre, eller om det här är en bugg i mjukvaran och inte alla liter registrerades. Jag behöver mer tid.

Grafikerna själva behöver fortfarande lite arbete, kanske måla och pyssla. Jag överväger också att bygga en graf över minnesanvändning av felsökningsskäl – kanske det läcker något där. Jag funderar på att på något sätt visa perioder när internet var frånvarande. Just nu är allt detta på idéstadiet.

Slutsats

Idag har min lägenhet blivit lite smartare. Med en så här liten enhet kommer det att vara lättare för mig att övervaka vattenförbrukningen i huset. Om jag tidigare klagade på "återigen för mycket vatten denna månad", så kommer jag nu kunna identifiera källan till den förbrukningen.

Någon kanske tycker det är konstigt att se mätvärden på skärmen om den är en meter från mätaren. Men i en inte så avlägsen framtid planerar jag att flytta till en annan lägenhet där det kommer att finnas flera vattenstammar och där mätarna förmodligen kommer att vara placerade på trapphuset. Så en enhet för fjärravläsning av mätvärden kommer att vara mycket användbar.

Jag planerar också att utöka enhetens funktionalitet. Jag kollar redan på motoriserade ventiler. Just nu behöver jag vrida tre kranar i en svåråtkomlig nisch för att växla mellan boiler-stadsvatten. Det skulle vara mycket bekvämare att göra det med en knapp med motsvarande indikation. Och självklart är det värt att implementera läckageskydd.

I artikeln presenterar jag min version av en enhet baserad på ESP8266. Enligt min åsikt har jag lyckats skapa en ganska intressant firmware-lösning med micropython som använder korutiner — enkelt och snyggt. Jag har försökt att beskriva många aspekter och misstag som jag stötte på under vägen. Kanske har jag beskrivit allt för detaljerat, personligen som läsare är det lättare för mig att bläddra igenom det onödiga än att senare försöka lista ut vad som inte blev sagt.

Som alltid är jag öppen för konstruktiv kritik.

Källkod
Schema och kort
Modell av hölje

Källa: habr.com