Een tijd geleden introduceerden we de . Dit artikel was oorspronkelijk bedoeld als een demonstratie van de firmware en het beheersysteem. Maar om de logica van de werking van de thermostaat en wat we hebben gerealiseerd uit te leggen, is het noodzakelijk om het geheel te schetsen.
Over automatisering
Voor het gemak kunnen we automatisering in drie categorieƫn indelen:
Categorie 1 ā afzonderlijke āslimmeā apparaten. U koopt lampen, waterkokers, enz. van verschillende fabrikanten. Voordelen: elk apparaat vergroot de mogelijkheden en verhoogt het comfort. Nadelen: voor elke nieuwe fabrikant is er een specifieke app nodig. De protocollen van apparaten van verschillende fabrikanten zijn vaak niet compatibel met elkaar.
Categorie 2 ā de installatie van een single-board PC of x86-compatibel. Dit verwijdert de beperkingen qua rekenkracht, en op deze machine wordt MajorDoMo of een andere serverdistributie voor het beheer van het slimme huis geĆÆnstalleerd. Op deze manier worden de apparaten van de meeste fabrikanten verbonden in een enkele informatieomgeving. Dit betekent dat je je eigen server voor het slimme huis hebt. Voordelen: compatibiliteit onder een enkele centrale, wat uitgebreide mogelijkheden voor beheer biedt. Nadelen: als de server faalt, keert het hele systeem terug naar fase 1, dat wil zeggen het wordt onsamenhangend of nutteloos.
Categorie 3 ā de meest hardcore optie. Tijdens de renovatie worden alle communicatiemiddelen voorbereid en alle systemen gedupliceerd. Voordelen: alles wordt tot in de puntjes verzorgd en dan wordt het huis echt slim. Nadelen: extreem hoge kosten in vergelijking met categorieĆ«n 1 en 2, de noodzaak om alles van tevoren te plannen en rekening te houden met elk detail.
De meeste gebruikers kiezen optie Ć©Ć©n en gaan vervolgens geleidelijk over naar optie twee. En de meest volhardende komen uiteindelijk bij optie drie aan.
Maar er bestaat een optie die we een gedistribueerd systeem kunnen noemen: elk afzonderlijk apparaat kan zowel server als cliƫnt zijn. Dit is in wezen een poging om optie 1 en optie 2 te combineren. Het doel is om al hun voordelen te benutten en de nadelen weg te nemen, en zo de gulden middenweg te vinden.
Misschien zegt iemand dat zo'n optie al is ontwikkeld. Maar zulke oplossingen zijn gericht op een specifieke groep; voor mensen die in programmeren zijn onderlegd. Ons doel is de instapdrempel voor dergelijke gedistribueerde systemen te verlagen, zowel in de vorm van eindapparaten als in de integratie van bestaande apparaten in ons systeem. In het geval van de thermostaat haalt de gebruiker gewoon zijn oude thermostaat weg, installeert een slimme thermostaat en sluit de sensoren die hij al heeft aan. Zonder verdere acties.
Laten we de integratie in ons systeem aan de hand van een voorbeeld bekijken.
Stel je voor dat we in ons netwerk 8 Sonoff-modules hebben. Voor sommige gebruikers is beheer via de Sonoff-cloud voldoende (categorie 1). Anderen zullen een externe firmware gebruiken en geleidelijk overgaan naar categorie 2. De meeste externe firmwares werken volgens hetzelfde principe: gegevensoverdracht naar een MQTT-server. OpenHub, Majordomo of een andere oplossing hebben als doel om afzonderlijke apparaten te verenigen in Ć©Ć©n informatieve ruimte, die zich in het internet of in een lokaal netwerk bevindt. Dit betekent dat de aanwezigheid van een server essentieel is. Hieruit ontstaat het belangrijkste probleem ā bij uitval van de server stopt het hele systeem met autonoom werken. Om dit te voorkomen, worden de systemen complexer, worden handmatige bedieningsmethoden toegevoegd die de automatisering dupliceren in het geval van een serverstoring.
Wij hebben echter gekozen voor een andere benadering, waarbij elk apparaat zelfvoorzienend is. Hierdoor speelt de server geen cruciale rol maar breidt deze alleen de functionaliteit uit.
Laten we terugkeren naar het gedachte-experiment. We nemen opnieuw dezelfde 8 Sonoff-modules en installeren de Lytko-firmware erop. In alle Lytko-firmwares is de functie geĆÆmplementeerd . SSDP is een netwerkprotocol dat is gebaseerd op een set internetprotocollen, en dat dient voor het aankondigen en ontdekken van netwerksystemen. Het antwoord op een verzoek kan zowel standaard als uitgebreid zijn. We hebben in dit antwoord, naast de standaardfuncties, het maken van een lijst met apparaten in het netwerk ingebouwd. Op deze manier vinden apparaten elkaar zelf, en heeft elk apparaat zoān lijst. Voorbeeld van een SSDP-lijst:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostaat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostaat"
}Zoals te zien in het voorbeeld, bevat de lijst de id's van apparaten, het IP-adres in het netwerk, en het type blok (in ons geval een thermostaat op basis van Sonoff). Deze lijst wordt elke twee minuten bijgewerkt (dit interval is voldoende om te reageren op dynamische veranderingen in het aantal apparaten in het netwerk). Zo volgen wij het toevoegen, wijzigen en uitschakelen van apparaten zonder enige actie van de gebruiker. Deze lijst wordt naar de browser of mobiele applicatie gestuurd, en het script vormt zelf de pagina met het opgegeven aantal blokken. Elk blok komt overeen met Ć©Ć©n apparaat/sensor/controller. Visueel ziet de lijst er als volgt uit:
Maar wat als er andere radiosensoren zijn aangesloten op de esp8266/esp32 via cc2530 (ZigBee) of nrf24 (MySensors)?
Over projecten
Er zijn verschillende gedistribueerde systemen op de markt. Ons systeem maakt integratie met de meest populaire mogelijk.
Hieronder staan de projecten die op hun manier proberen de situatie met incompatibiliteit tussen verschillende fabrikanten te veranderen. Dit zijn bijvoorbeeld: , of . is gekoppeld aan een MQTT-server, waardoor het niet geschikt is voor dit voorbeeld.
Een van de manieren om MySensors te implementeren is een gateway gebaseerd op de ESP8266. De andere voorbeelden zijn op ESP32. In deze kunnen we ons werkprincipe voor het ontdekken en creƫren van een lijst van apparaten implementeren.
Laten we nog een gedachte-experiment doen. We hebben de gateway ZESP32 of SLS Gateway of MySensors. Hoe kunnen we ze samenbrengen in Ć©Ć©n informatie-omgeving? We voegen een SSDP-protocolbibliotheek toe aan de standaardfuncties van deze gateways. Bij een verzoek aan deze controller via SSDP zal hij aan het standaardantwoord een lijst van apparaten die op hem zijn aangesloten toevoegen. Op basis van deze informatie zal de browser de pagina vormen. In algemene vorm zal dit er als volgt uitzien:
Web-interface
PWA-applicatie
"ssdpList":
{
"id": 94967291, // unieke identifier van het apparaat
"ip": "192.168.x.x", // ip adres in het netwerk
"type": "thermostaat" // type apparaat
},
{
"id": 94967292,
"ip": "192.168.x.x",
"type": "thermostaat"
},
{
"id": 94967293,
"ip": "192.168.x.x",
"type": "thermostaat"
},
{
"id": 13587532,
"type": "schakelaar"
},
{
"id": 98412557,
"type": "rook"
},
{
"id": 57995113,
"type": "contact_sensor"
},
{
"id": 74123668,
"type": "temperatuur_humidity_pressure_sensor"
},
{
"id": 74621883,
"type": "temperatuur_humidity_sensor"
}
Uit het voorbeeld is te zien dat de apparaten onafhankelijk van elkaar worden toegevoegd. Er zijn 3 thermostaten aangesloten met hun eigen IP-adressen en 5 verschillende sensoren met unieke ID's. Als een sensor is verbonden met een Wi-Fi-netwerk, heeft deze een eigen IP; als deze verbonden is met een gateway, dan is het IP-adres van het apparaat hetzelfde als het IP-adres van de gateway.
Voor communicatie met apparaten gebruiken we WebSocket. Dit minimaliseert de belasting van de bronnen in vergelijking met GET-verzoeken en stelt ons in staat om informatie dynamisch te ontvangen bij verbinding of wijziging.
De gegevens worden rechtstreeks van het apparaat gehaald waaraan de module toebehoort, zonder tussenkomst van de server. Dit betekent dat de systeem blijft functioneren bij uitval van een van de apparaten. In de webinterface verschijnt het verdwenen apparaat alleen niet meer in de lijst. Maar een signaal over het verlies kan, indien nodig, als notificatie naar de applicatie van de gebruiker komen.
De eerste poging om deze aanpak te realiseren was een PWA-applicatie. Dit maakt het mogelijk om de database van de modules op het apparaat van de gebruiker op te slaan en alleen de benodigde gegevens aan te vragen. Maar vanwege de structuur van deze optie is deze incompleet. De enige oplossing is een native applicatie voor Android en iOS, die momenteel in actieve ontwikkeling is. Standaard werkt de applicatie alleen binnen het interne netwerk. Indien nodig kan alles naar externe controle worden overgebracht. Dus wanneer de gebruiker het lokale netwerk verlaat, schakelt de applicatie automatisch over naar de cloud.
Externe controle is een volledige duplicatie van de pagina. Bij activatie van de pagina kan de gebruiker inloggen op de server en apparaten beheren via een persoonlijk account. Op deze manier breidt de server de functionaliteit uit, waardoor apparaten kunnen worden beheerd terwijl men zich buiten het huis bevindt, zonder afhankelijk te zijn van poortdoorverwijzingen of een statisch IP.
Op deze manier is de hierboven beschreven optie vrij van de nadelen van de serveraanpak en heeft ook een aantal voordelen, zoals de flexibiliteit om nieuwe apparaten aan te sluiten.
Over de thermostaat
Laten we het beheersysteem bekijken aan de hand van ons voorbeeld van de thermostaat.
Voorgesteld:
- Regeling van de temperatuur van elke thermostaat (weergegeven als een apart blok);
- Instellen van het werkschema van de thermostaat (ochtend, dag, avond, nacht);
- Kiezen van het Wi-Fi-netwerk en aansluiten van het apparaat;
- Update van het apparaat 'over the air';
- Instellen van MQTT;
- De netwerkinstelling waaraan het apparaat is verbonden.
Naast het beheer via de webinterface, is er ook een klassieke optie ā door op het scherm te drukken. Aan boord bevindt zich een Nextion NX3224T024 monitor van 2,4 inch. We hebben voor deze gekozen vanwege de eenvoud in het gebruik van het apparaat. Een eigen monitor op basis van STM32 is in ontwikkeling. De functionaliteit is niet minderwaardig aan die van Nextion, maar zal goedkoper zijn, wat zich positief zal uiten in de uiteindelijke prijs van het apparaat.
Zoals elke serieuze thermostaat beschikt onze Nextion over:
- het instellen van de gewenste temperatuur door middel van knoppen aan de rechterkant;
- het in- en uitschakelen van de werktijd volgens schema (de H-knop);
- het weergeven van de werking van het relais (pijl aan de linkerkant);
- een kindveilige functie (fysieke drukken worden geblokkeerd zolang het slot niet is ontgrendeld);
- weergave van het WiFi-signaalniveau.
Daarnaast kan de monitor:
- het type sensor dat door de gebruiker is geĆÆnstalleerd selecteren;
- de kindveilige functie beheren;
- de firmware bijwerken.
Bij een klik op de WiFi-balk krijgt de gebruiker informatie over het verbonden netwerk. De QR-code wordt gebruikt voor het koppelen van het apparaat in de HomeKit-firmware.
Demo van de werking met het display:
We hebben met drie aangesloten thermostaten ontwikkeld.
U vraagt zich af: "Wat maakt uw thermostaat bijzonder?" Momenteel zijn er op de markt veel thermostaten met Wi-Fi-functie, tijdschema's en aanraakbediening. En enthousiastelingen hebben modules geschreven voor interactie met de meeste populaire smart home-systemen (Majordomo, HomeAssistant, enzovoorts).
Onze thermostaat is compatibel met dergelijke systemen en heeft al het bovenstaande. Maar het bijzondere is dat de thermostaat continu wordt verbeterd, dankzij de flexibiliteit van het systeem. Met elke update zal de functionaliteit worden uitgebreid. Naast de standaard manier om het systeem te bedienen (volgens schema), zullen we een adaptieve manier toevoegen. De app maakt het mogelijk om de locatie van de gebruiker te verkrijgen. Hierdoor kan het systeem dynamisch de werkmodi wijzigen afhankelijk van zijn locatie. En de weer-module maakt het mogelijk zich aan te passen aan de weersomstandigheden.
En uitbreidbaarheid. Iedereen kan de geĆÆnstalleerde conventionele thermostaat vervangen door de onze. Met minimale inspanning. We hebben de vijf populairste sensoren op de markt geselecteerd en hun ondersteuning toegevoegd. Maar zelfs met exclusieve kenmerken van de sensor kan de gebruiker deze aansluiten op onze thermostaat. Dit vereist calibratie van de thermostaat om met de specifieke sensor te werken. We zullen de instructies bieden.
Wanneer u de thermostaat of enig ander apparaat aansluit, verschijnt het tegelijkertijd overal: zowel in de webinterface als in de PWA-app. Apparaten worden automatisch toegevoegd: u hoeft ze alleen maar met het Wi-Fi-netwerk te verbinden.
Ons systeem heeft geen Server nodig, en transformeert niet in een pompoen bij een storing. Zelfs als een van de componenten uitvalt, werkt het systeem niet in de noodmodus. Controllers, sensoren, apparaten ā elk element is zowel Server als klant, en daarom volledig autonoom.
Voor geĆÆnteresseerden ā onze sociale media: , , , , .
E-mail: shop@lytko.com
P.S. We raden niet aan om afscheid te nemen van de Server. We ondersteunen ook MQTT-servers en hebben onze eigen cloud. Ons doel is om de stabiliteit en betrouwbaarheid van het systeem naar een kwalitatief nieuw niveau te tillen. Zodat de Server geen zwak punt is, maar de functionaliteit aanvult en het systeem gebruiksvriendelijker maakt.
Bron: habr.com
