WiFi IoT-temperatuur- en vochtigheidssensor. Deel: 8 IoT, domotica: 9 stappen

2024 Auteur: John Day | [email protected]. Laatst gewijzigd: 2024-01-30 11:19

Preambule

Dit artikel documenteert de praktische robuustheid en verdere ontwikkeling van een eerdere Instructable: 'Pimping' van uw eerste IoT WiFi-apparaat. Deel 4: IoT, Domotica inclusief alle benodigde softwarefunctionaliteit om de succesvolle implementatie in een huiselijke thuisomgeving mogelijk te maken.

Invoering

Zoals hierboven vermeld, beschrijft deze Instructable het samenbrengen van een eerder IoT-voorbeeld met een betrouwbaar systeemontwerp dat de succesvolle afhandeling van praktische use-cases mogelijk maakt, zoals; Catastrofaal stroomverlies, MQTT Broker-storing, WiFi N/W-storing, herconfiguratie van sensoren op afstand, configureerbare rapportagestrategie om netwerkverkeer te verminderen en op maat gemaakte sensorkalibratie.

Er werden in totaal 6 off-apparaten gemaakt (zie foto 1 hierboven) en verspreid over mijn huis om mijn eerste IoT-sensornetwerk te vormen.

De Instructable ziet ook een herziening van de MQTT-naamgevingsconventie zoals gebruikt in de eerste IoT Home Automation-serie, die plaats maakt voor een meer evenwichtige, praktische structuur die eenvoudiger debuggen van IoT-verkeer in een omgeving met meerdere IoT-apparaten mogelijk maakt.

Wat volgt zijn volledige ontwerpdetails van de IoT-sensor, waaronder; constructie, broncode, teststrategie en OpenHAB-configuraties.

Welke onderdelen heb ik nodig?

1. 1 van ESP8266-01,
2. 2 off 1uF elektrolytische condensatoren,
3. 3 off 10K weerstanden,
4. 1 uit 330R-weerstand,
5. 1 van 3 mm dia. LED,
6. 1 van LD1117-33v, 3v3 LDO VReg. (Farnell hier),
7. 1 off DHT22 temperatuur-/vochtigheidssensor,
8. 1 uit Dual 4-way 0.1" Connector,
9. 1 van CAMDENBOSS RX2008/S-5 kunststof behuizing, oppotdoos, ABS, 38 mm, 23 mm (Farnell hier),
10. 1 uit DC-voedingsconnector, stekker, 1 A, 2 mm, paneelmontage (Farnell hier),
11. 1 off TO-220 Heatsink 24,4 °C/W (Farnell hier),
12. Diverse krimpkous (geel, Ebay hier),
13. Diverse lengtes IDC lintkabel,
14. Koellichaam verbinding,
15. Veroboard,
16. ESP8266-01 programmeerapparaat. Kijk hier; Praktische circuitconstructie met stripbord, stap 9 en verder.

Welke software heb ik nodig?

1. Arduino IDE 1.6.9
2. Arduino IDE geconfigureerd om de ESP8266-01 te programmeren. Kijk hier; De Arduino IDE instellen om de ESP8266-01 te programmeren

Welke hulpmiddelen heb ik nodig?

1. Soldeerbout,
2. Boor & diverse bits,
3. bestanden,
4. Metaalzaag,
5. stevige bankschroef,
6. Hitte geweer,
7. DMM.

Welke vaardigheden heb ik nodig?

1. Een minimale kennis van elektronica,
2. Kennis van Arduino en zijn IDE,
3. Rudimentaire fabricagevaardigheden (solderen, zagen, vijlen, boren enz.),
4. wat geduld,
5. Enig begrip van uw thuisnetwerk.

Behandelde onderwerpen

1. Circuitoverzicht
2. Overzicht softwaresysteem
3. Software-overzicht
4. Sensorkalibratie:
5. MQTT Onderwerp Naamgeving Conventie
6. OpenHAB-configuratie
7. Het ontwerp testen
8. Conclusie
9. Gebruikte referenties

Serielinks

Naar deel 7: Study Lights Controller (herwerkt). Deel 7: IoT, Domotica

Naar deel 9: IoT-netvoedingscontroller. Deel 9: IoT, Domotica

Stap 1: Circuitoverzicht

Afbeelding 1 hierboven toont het volledige circuitontwerp voor de IoT-sensor.

Het hart van het IoT-apparaat is de ESP8266-01, die via een 10K pull-up-weerstand op GPIO2 is aangesloten op een DHT22-temperatuur-/vochtigheidssensor. Een externe 5v wordt geleverd met een geschakelde voeding en wordt naar het apparaat gevoerd via een 2 mm DC-paneelmontage-aansluiting en lokaal geregeld met een LD1117-33v, 3v3 LDO-spanningsregelaar gemonteerd op een extern koellichaam met een BZP M3 pankopschroef en moer.

Het ontwerp omvat een rode led van 3 mm die is aangesloten op GPIO0 en die wordt gebruikt om een lokale indicatie te geven van de status van het IoT-apparaat tijdens het opstarten of eventuele daaropvolgende foutcondities. Het kan ook worden gebruikt om het apparaat te identificeren door handmatige activering via de openHAB-interface.

Het volledige ontwerp past netjes in een ABS-oppotdoos zoals hierboven weergegeven in afbeelding 2 en is speciaal ontworpen om ervoor te zorgen dat de sensor zo ver mogelijk van de regelaar verwijderd is om vertekening door plaatselijke verhittingseffecten te voorkomen (afbeelding 7 hierboven).

De printplaat is een enkel stuk veroboard, op maat gesneden en gemaakt om in de behuizing te passen (afbeelding 3 hierboven). Dit bord wordt op zijn plaats vastgezet met een M3 verzonken nylon schroef en twee moeren die gelijk met de onderkant van de sensor passen, waardoor deze op een vlakke ondergrond kan worden geplaatst.

Foto's 4 … 6 tonen verschillende bouwtoestanden.

Stap 2: Overzicht softwaresysteem

Dit IoT-apparaat voor temperatuur- en vochtigheidsdetectie bevat zes belangrijke softwarecomponenten, zoals weergegeven in afbeelding 1 hierboven.

SPIFFS

Dit is het ingebouwde SPI Flash Filing System en wordt gebruikt om de volgende informatie te bewaren (zie foto 2 hierboven);

• Pictogrammen en 'Sensor Configuration Home Page' html: Wordt bediend door het IoT-apparaat wanneer het geen verbinding kan maken met uw IoT WiFi-netwerk (meestal vanwege onjuiste beveiligingsinformatie) en biedt de gebruiker een manier om de sensor op afstand te configureren zonder dat dit nodig is om nieuwe SPIFFS-inhoud te herprogrammeren of te uploaden.
• Beveiligingsinformatie: dit bevat de informatie die bij het opstarten door het IoT-apparaat wordt gebruikt om verbinding te maken met uw IoT WiFi-netwerk en MQTT Broker. Informatie die via de 'Sensorconfiguratie-startpagina' wordt verzonden, wordt naar dit bestand geschreven ('secvals.txt').
• Kalibratie-informatie: De informatie in dit bestand ('calvals.txt') wordt gebruikt om de ingebouwde temperatuur-/vochtigheidssensor te kalibreren, mocht dit nodig zijn. Kalibratieconstanten kunnen alleen naar het IoT-apparaat worden geschreven via MQTT-opdrachten van een MQTT-broker.

Opmerking: om het apparaat in eerste instantie in te stellen, zie hier voor volledige details over het gebruik van SPIFFS met de Arduino IDE.

mDNS-server

Deze functionaliteit wordt aangeroepen wanneer het IoT-apparaat geen verbinding kan maken met uw WiFi-netwerk als WiFi-station en in plaats daarvan een WiFi-toegangspunt is geworden, vergelijkbaar met een binnenlandse WiFi-router. In het geval van een dergelijke router zou u er normaal gesproken verbinding mee maken door het IP-adres van iets als 192.168.1.1 (meestal afgedrukt op een label op de doos) rechtstreeks in de URL-balk van uw browser in te voeren, waarna u een inlogpagina zou ontvangen om in te voeren de gebruikersnaam en het wachtwoord waarmee u het apparaat kunt configureren.

Voor de ESP8266 in AP-modus (Access Point-modus) gebruikt het apparaat standaard het IP-adres 192.168.4.1, maar als de mDNS-server actief is, hoeft u alleen de mensvriendelijke naam 'SENSORSVR.local' in de browser-URL-balk in te voeren om de 'Startpagina sensorconfiguratie'.

MQTT-client

De MQTT-client biedt alle benodigde functionaliteit om; maak verbinding met uw IoT-netwerk MQTT-broker, abonneer u op de onderwerpen van uw keuze en publiceer payloads naar een bepaald onderwerp. Kortom, het voorziet in IoT-kernfunctionaliteit.

HTTP-webserver

Zoals hierboven vermeld, als het IoT-apparaat geen verbinding kan maken met het WiFi-netwerk waarvan de SSID, P/W enz. is gedefinieerd in het beveiligingsinformatiebestand in SPIFFS, wordt het apparaat een toegangspunt. Eenmaal verbonden met het wifi-netwerk dat door het toegangspunt wordt geleverd, kunt u door de aanwezigheid van een HTTP-webserver rechtstreeks verbinding maken met het apparaat en de configuratie wijzigen via het gebruik van een HTTP-webbrowser. Page' webpagina die ook in SPIFFS wordt gehouden.

WiFi-station

Deze functionaliteit geeft het IoT-apparaat de mogelijkheid om verbinding te maken met een huishoudelijk WiFi-netwerk met behulp van de parameters in het beveiligingsinformatiebestand, zonder dit kan uw IoT-apparaat zich niet abonneren op/publiceren op de MQTT-makelaar

WiFi-toegangspunt

De mogelijkheid om een WiFi-toegangspunt te worden, is een middel waarmee u met het IoT-apparaat verbinding kunt maken en configuratiewijzigingen kunt doorvoeren via een WiFi-station en een browser (zoals Safari op de Apple iPad).

Dit toegangspunt zendt een SSID = "SENSOR" + de laatste 6 cijfers van het MAC-adres van het IoT-apparaat uit. Het wachtwoord voor dit gesloten netwerk heeft de fantasierijke naam 'PASSWORD'

Stap 3: Software-overzicht

Preamble Om deze broncode succesvol te compileren heb je de volgende extra bibliotheken nodig;

PubSubClient.h

• Door: Nick O'Leary
• Doel: stelt het apparaat in staat om MQTT-onderwerpen te publiceren of zich erop te abonneren bij een bepaalde makelaar
• Van:

DHT.h

• Door: Adafruit
• Doel: Bibliotheek voor DHT-temperatuur-/vochtigheidssensor
• Van:

Codeoverzicht

De software maakt gebruik van de state-machine zoals getoond in foto 1 hierboven (volledige kopie van de bron hieronder). Er zijn 5 hoofdstaten zoals hieronder;

• IN HET

  Deze initialisatiestatus is de eerste status die wordt ingevoerd na het opstarten

• NOCONFIG

  Deze status wordt ingevoerd als na het opstarten een ongeldig of ontbrekend secvals.txt-bestand wordt gedetecteerd

• IN AFWACHTING NW

  Deze status is van voorbijgaande aard, ingevoerd terwijl er geen wifi-netwerkverbinding is

• IN AFWACHTING MQTT

  Deze status is van voorbijgaande aard en wordt ingevoerd nadat een WiFi-netwerkverbinding is gemaakt en terwijl er geen verbinding is met een MQTT-broker op dat netwerk

• ACTIEF

  Dit is de normale operationele status die wordt ingevoerd zodra zowel een WiFi-netwerkverbinding als een MQTT Broker-verbinding tot stand is gebracht. Het is tijdens deze status dat de temperatuur- en vochtigheidsfunctionaliteit van de sensor wordt gepubliceerd naar de MQTT-makelaar

De gebeurtenissen die overgangen tussen toestanden regelen, worden beschreven in afbeelding 1 hierboven. Overgangen tussen toestanden worden ook bepaald door de volgende SecVals-parameters;

• 1e MQTT Broker IP-adres. In decimale vorm AAA. BBB. CCC. DDD
• 2e MQTT-makelaarspoort. In geheel getal.
• 3e MQTT Broker-verbinding probeert te maken voordat wordt overgeschakeld van STA-modus naar AP-modus. In geheel getal.
• 4e WiFi-netwerk SSID. In vrije vorm tekst.
• 5e wifi-netwerkwachtwoord. In vrije vorm tekst.

Zoals hierboven vermeld, als het IoT-apparaat geen verbinding kan maken als een WiFi-station met het WiFi-netwerk waarvan de SSID en P/W is gedefinieerd in secvals.txt in SPIFFS, wordt het IoT-apparaat een toegangspunt. Eenmaal verbonden met dit toegangspunt, wordt de 'Sensorconfiguratie-startpagina' weergegeven, zoals hierboven weergegeven in afbeelding 2 (door 'SENSORSVR.local' of 192.168.4.1 in te voeren in de URL-adresbalk van uw browser). Op deze startpagina kan de sensor opnieuw worden geconfigureerd via een

Toegang op afstand in de ACTIEVE status

Eenmaal verbonden met de MQTT Broker is het ook mogelijk om het apparaat zowel opnieuw te kalibreren als opnieuw te configureren via MQTT-onderwerppublicaties. Het bestand calvals.txt heeft R/W-toegang en secvals.txt heeft alleen-schrijftoegang.

Foutopsporing door gebruiker

Tijdens de opstartvolgorde geeft de led van het IoT-apparaat de volgende debug-feedback:

• 1 Korte flits: geen configuratiebestand in SPIFFS (secvals.txt)
• 2 korte flitsen: IoT-apparaat probeert verbinding te maken met wifi-netwerk
• Continue verlichting: IoT-apparaat probeert verbinding te maken met MQTT Broker
• Uit: Apparaat is actief
• Opmerking 1: De 'Sensorconfiguratie-startpagina' gebruikt geen beveiligde sockets en is daarom afhankelijk van de beveiliging van uw netwerk.
• Opmerking 2: Om elk IoT-apparaat te programmeren, moet de MQTT-reeks worden bewerkt voordat deze kan worden gedownload. Dit komt omdat het nummer van de sensor is ingebed in de MQTT-onderwerpreeks. d.w.z. 'WFD/THSen/100/HumdStatus/1' voor mijn 6 apparaten zijn ze respectievelijk genummerd 1…6.

Stap 4: Sensorkalibratie

Wanneer het IoT-apparaat opstart, wordt als onderdeel van de opstartvolgorde een bestand met de naam 'cavals.txt' uit SPIFFS gelezen. De inhoud van dit bestand zijn kalibratieconstanten zoals hierboven aangegeven in pic 1. Deze kalibratieconstanten worden gebruikt om de metingen verkregen van de sensor aan te passen om ze in overeenstemming te brengen met een referentieapparaat. Er is nog een waarde die een rapportagestrategie voor het apparaat definieert en die hieronder wordt beschreven, samen met de procedure die wordt gevolgd om de sensoren te kalibreren.

Rapportagestrategie Deze parameter bepaalt hoe de externe sensor eventuele lokale parameterwijzigingen in de omgeving rapporteert. Als de waarde 0 is geselecteerd, publiceert de externe sensor elke verandering die hij ziet in de temperatuur- of vochtigheidswaarden elke keer dat de sensor wordt gelezen (ongeveer elke 10 seconden). Elke andere waarde vertraagt de publicatie van een wijziging met 1…60 minuten. Door deze parameter te wijzigen, kan het MQTT-netwerkverkeer worden geoptimaliseerd.

Temperatuur kalibratie

Om de sensoren te kalibreren werden ze in fysieke nabijheid van elkaar geplaatst, zoals hierboven in foto 2 te zien is. Naast hen plaatste ik een DMM met een gekalibreerd thermokoppel eraan (Fluke 87 V) en bewaakte vervolgens de uitgangen van elk apparaat via de OpenHAB-temperatuur trendpagina in de loop van een dag om een goede temperatuurschommeling te krijgen. Ik noteerde zowel de statische offset (verhoogde nul 'C') en de snelheid van verandering van elk apparaat (versterking of helling van grafiek 'M') ten opzichte van die van de waarde afkomstig van het gekalibreerde thermokoppel. Vervolgens heb ik de eenvoudige y=mx+c-relatie berekend (ik vond dat deze voldoende lineair was om een goede benadering van een rechte lijngrafiek te zijn) en alle noodzakelijke correcties in de kalibratieconstanten geprogrammeerd via MQTTSpy.

De apparaten werden vervolgens nog eens 24 uur gecontroleerd om er zeker van te zijn dat de kalibratie succesvol was. Een indicatie hiervan was dat de temperatuursporen op de OpenHAB-temperatuurtrendpagina allemaal vrij veel boven elkaar lagen.

Als u alleen geïnteresseerd bent in een benadering van de temperatuur, kunt u natuurlijk alle kalibratiewaarden standaard laten.

Vochtigheidskalibratie

Omdat ik geen middelen heb om de lokale luchtvochtigheid nauwkeurig te registreren of zelfs te regelen, heb ik voor het kalibreren van de sensoren een vergelijkbare benadering gebruikt als hierboven, door alle apparaten in fysieke nabijheid te plaatsen (foto 2) en eenvoudig hun output te bewaken via de OpenHAB Vochtigheid neiging pagina. Ik koos toen apparaat #1 als kalibratiereferentie en kalibreerde alle apparaten ten opzichte hiervan.

Stap 5: MQTT Onderwerp Naamgeving Conventie

Na veel vallen en opstaan kwam ik uit bij de naamgevingsconventie voor onderwerpen zoals beschreven in afbeelding 1 hierboven.

Namelijk 'AccessMethod/DeviceType/WhichDevice/Action/SubDevice'

Het is niet perfect, maar het zorgt er wel voor dat handige filters kunnen worden toegepast om alle sensoruitgangen voor een bepaalde parameterwaarde te zien, waardoor een gemakkelijke vergelijking zoals in foto 2 hierboven met MQTTSpy mogelijk is. Het ondersteunt ook redelijk uitbreidbare logische groeperingen van functionaliteit binnen een bepaald IoT-apparaat.

Bij het implementeren van deze onderwerpen in software heb ik hardgecodeerde onderwerpreeksen met vaste, ingebedde numerieke identifiers voor elk apparaat gebruikt, in plaats van de onderwerpen dynamisch tijdens runtime te genereren om RAM te besparen en de prestaties hoog te houden.

Opmerking: als u niet zeker weet hoe u MQTTSpy moet gebruiken, raadpleegt u hier 'Een MQTT-makelaar instellen'. Deel 2: IoT, Domotica'

Stap 6: OpenHAB-configuratie

Ik heb de OpenHAB-configuratie gewijzigd die in mijn eerdere Instructable (hier) is gegeven en in afzonderlijke vermeldingen is toegevoegd voor;

• Garage,
• Hal,
• Woonkamer,
• Keuken
• Logeerkamer
• Hoofdslaapkamer

In de sitemap zie foto 1 hierboven.

Voor elk van deze items heb ik individuele sitemaps toegevoegd die lokale omgevingswaarden blootleggen (zie foto 2 hierboven);

• Temperatuur
• Vochtigheid
• Hitte-index

Ik heb ook een schakelaar meegeleverd om de lokale led in de sensor te bedienen.

Afbeeldingen 3 … 5 tonen individuele live-sporen gedurende een periode van 24 uur voor temperatuur, vochtigheid en RSSI (Received Signal Strength Indication, in feite een maatstaf voor hoe goed de sensor het WiFi-netwerk kan zien).

Afbeelding 6 geeft een voorbeeld van een langetermijnvochtigheidstrend over de periode van een week.

Opmerking 1: Als u niet zeker weet hoe u OpenHAB moet gebruiken, zie dan hier 'OpenHAB instellen en configureren. Deel 6: IoT, Domotica'

Opmerking 2: Een kopie van de gewijzigde sitemap, regels en itemsbestanden, pictogrammen enz. wordt hieronder gegeven.

Stap 7: het ontwerp testen

Voor het grootste deel heb ik het IoT-apparaat getest via de MQTT-verbinding met MQTT Spy, het monitoren van led-uitvoer en debuggen van verkeer op de seriële interface. Hierdoor kon ik alle beschikbare geabonneerde onderwerpen oefenen en de gepubliceerde reacties controleren. Hoewel dit handmatig werd bereikt en soms een beetje vervelend werd, was 100% dekking mogelijk.

De main state-machine bleek echter een beetje lastig te testen, omdat deze afhankelijk was van de aan- of afwezigheid van een wifi-netwerk, waarvoor toegang specifieke parametersets vereist. Het was gewoon niet praktisch om hiervoor het thuisnetwerk te gebruiken.

Om dit probleem te omzeilen heb ik mijn eigen set dummy-netwerken gemaakt met behulp van ESP8266-01 geconfigureerd als toegangspunten (foto 1) met respectievelijk SSID's van 'DummyNet1' en 'DummyNet2'. Met behulp van het circuit in foto 2 hierboven gaf de led een indicatie of er een IoT-apparaat op was aangesloten. Hoewel dit geen perfecte testoplossing was (dwz elk van deze dummy WiFi-netwerken bevatte geen MQTT-server), was het mogelijk om de statusmachine volledig te testen.

Ik heb een kopie van de broncode hieronder bijgevoegd.

Stap 8: Conclusie

Algemeen

De software in de IoT-apparaten werkt al vele maanden betrouwbaar en is nu herstellende van stroomuitval in huis (voornamelijk veroorzaakt door mezelf). Over het algemeen zijn het behoorlijk robuuste apparaten die consistente en nauwkeurige gegevens geven.

Verbeteringen

Bij het ontwikkelen van softwareroutines om SPIFFS te lezen en te schrijven, heb ik code geschreven die achteraf gezien misschien iets geavanceerder is dan ik had bedoeld, met behulp van lege aanwijzers, herschikkingen en verwijzingen naar aanwijzers. Hoewel het erg flexibel is en het werk goed doet, kan ik de volgende keer JSON gebruiken in de trant van ConfigFile.ino om het een beetje eenvoudiger te houden.

• Arduino GIT HUB-kern

  https://github.com/esp8266/Arduino

• ConfigFile.ino Bron

  https://github.com/esp8266/Arduino/tree/master/libraries/esp8266/examples/ConfigFile

Verlanglijst

Ik was van plan een mDNS-client te gebruiken om verbinding te maken met de Broker, maar de bibliotheek was te zwak. Daarom is het nodig om het MQTT Broker IP-adres op te geven in plaats van 'MQTTSVR.local'. Mocht de mDNS-bibliotheek in de toekomst stabieler worden, dan zal ik deze mogelijkheid aan het apparaat toevoegen.

Het zou leuk geweest zijn om een middel te hebben om zowel de luchtvochtigheid nauwkeurig te bewaken als te regelen om de sensoren tegen te kalibreren. Dat gezegd hebbende, geeft de gekozen kalibratiemethode goede relatieve metingen en lijkt redelijk nauwkeurig in overeenstemming met de specificatie in het DHT22-gegevensblad.

Ten slotte vond ik, gezien de complexiteit van de software, het volledig testen van de code na een grote wijziging tijdrovend. Ik kan op een later tijdstip geautomatiseerd testen overwegen.

Stap 9: Gebruikte referenties

Ik heb de volgende bronnen gebruikt om dit Instructable samen te stellen;

PubSubClient.h

• Door: Nick O'Leary
• Van:

DHT.h

• Door: Adafruit
• Van:

DHT22-gegevensblad