Översikt
Resten av dokumentationen beskriver vad Yggio gör, funktion för funktion. Det här avsnittet beskriver vad det är till för, genom att gå igenom installationer som finns: vilken fråga som ställs, vilken sensor som besvarar den, och vad som måste hända mellan det att ett mätvärde kommer in och att någon agerar på det.
De är skrivna som mönster snarare än som produktblad. Sensorerna som nämns är de som vanligen används för uppgiften, men ingenting här är beroende av dem - Yggio tar emot vilken leverantörs enhet som helst, och det är installationens form som är värd att kopiera.
Användningsfallen
| Användningsfall | Frågan det besvarar |
|---|---|
| Asset tracking | Hur många finns i den här zonen, och vilka har slutat röra sig? |
| Internpostutdelning | Finns det något i den här lådan, eller hämtar rundan ingenting? |
| Lokalutnyttjande | Vilka ytor används faktiskt, till skillnad från vilka som är bokade? |
| Olja och andra vätskor | Läckte den vätska som spelar roll, till skillnad från vilken vätska som helst? |
| Fastighet | Vad drivs ett fastighetsbestånd av när data väl finns på ett ställe? |
| Lagerställ | Vilka ställ har blivit påkörda, och vilka försämras i tysthet? |
| Vattenläckagedetektering | Har vatten nått någonstans där det inte ska vara, och vem vet om det nu? |
Vad de har gemensamt
Alla följer samma tre steg, och det är i det mittersta som det mesta arbetet ligger:
- Mät på den plats där svaret finns. En läckagesensor i lågpunkten i ett installationsschakt, en närvarosensor under skrivbordskanten. Täckningen är ett designbeslut, inte en produktegenskap.
- Normalisera. Enheter från olika leverantörer beskriver samma sak på olika sätt. En översättare gör om varje nyttolast till samma namngivna fält, så att en dashboard byggd för en sensor fortsätter fungera när nästa är av ett annat fabrikat.
- Agera. Ett mätvärde som ingen ser är inte värt att samla in. Regelmotorn avgör vem som får besked, hur brådskande det är, och vad som händer om ingen kvitterar.
Förutsättningen under alla tre
Sensorn måste nå nätet från exakt den plats där frågan ställs. Den platsen väljs av problemet, inte av radion - lågpunkten i ett installationsschakt, botten av en hissgrop, insidan av en utkorg i stål, en gång långt in i ett lagerställ - och det är just där täckningen är sämst.
Det är den vanligaste orsaken till att en väl utformad installation presterar sämre än väntat, och det är billigt att utesluta: verifiera förbindelsen vid varje sensorposition under idrifttagningen i stället för att härleda den ur en gateways nominella räckvidd, och fortsätt övervaka länkkvaliteten efteråt, så att en sensor som tystnat larmas som ett fel i stället för att läsas som goda nyheter. En läckagesensor som inte rapporterar något och en läckagesensor som inte når nätet ser likadana ut i en dashboard.
Planera gatewayerna efter de besvärliga positionerna snarare än de bekväma. Se LoRaWAN.
Varje sida här förutsätter att plattformen under är densamma som beskrivs i användarguiden: samma enheter, åtkomsträttigheter, dashboards, regler och rapporter. Ett användningsfall är ett sätt att arrangera dessa, inte en separat produkt.
Att komma igång med ett
Mönstret som fungerar är smalt och underbyggt snarare än brett och planerat:
- Välj den minsta installation som skulle avgöra en verklig fråga. En byggnad, ett våningsplan, en säsong.
- Hämta frågan från något som redan är dokumenterat - en skadehistorik, andelen uteblivna bokningar i ett bokningssystem - så att resultatet kan jämföras med vad man trodde innan.
- Testa hela kedjan, inklusive den del där någon väcks klockan tre på natten, innan ni litar på den.
- Bygg ut på vad den första säsongen visade, inte på en checklista.
Plattformen är densamma vilket användningsfall som än kommer först, och det är därför en läckagepilot och en närvaropilot hamnar i samma Yggio-instans i stället för i två system.