IoT i CIoT-enheter - smarta lösningar

LoRaWAN & GSM - Smart City





iSys - intelligenta system







FÖRSLAG

Innehållsförteckning

1. Introduktion. 3

1.1 @City (IoT / CIoT) Kommunikation 4

1.2. Hårdvaruresurser för IoT / CIoT-enheter 4

0..4 programmerbara binära ingångar 4

0..4 programmerbara binära utgångar 4

0..4 räknaringångar (icke-flyktiga räknare) 4

0..4 dimmerutgångar (PWM eller 0..10V) 5

Infraröd ingång + utgång 5

0..4 mätingångar (ADC) 5

seriella gränssnitt SPI / I2C / UART / CAN 5

1.3. @City GSM-enheter 6

1.4. @City LoRaWAN-enheter 9

Modulen utan LoRaWAN-modem och processor kan fungera som MEMs sensormodul för @City GSM, WiFi, Ethernet och andra eHouse-arkitekturer (3v3..3v6 DC-driven) 10

2. Allmänna användningsvillkor @City (LoRaWAN, GSM) Systems 11

2.1. Exklusiva villkor för @City GSM. 11

2.2. Exklusiva villkor för @City LoRaWAN. 12

3. @City (LoRaWAN, GSM) Controller Configuration 13

3.1. @City Controller Configuration - Tilldela namn 13

3.2. Allmän konfiguration av @City LoRaWAN & GSM-kontroller 14

3.2.1 Allmän konfiguration av @City GSM-enhet 14

3.2.2. Allmän konfiguration av @City LoRaWAN-kontroller 17

3.3. Konfiguration av binära ingångar 18

3.4. Konfiguration av binära utgångar 19

3.5. Konfiguration av ADC-mätingångar och ytterligare sensorer (XIN) 21

3.6. Dimmerkonfiguration PWM / 0..10V 22

3.7. Kalender-schemaläggningskonfiguration 24

4. LoRaWAN-nätverksinfrastrukturkonfiguration 26

4.1. LoRaWAN Gateway-konfiguration. 26

4.1.1. Grundläggande konfiguration av LoRaWAN gateway 26

4.1.2. Semtech Packet Forwarder (SPF) Configuration 27

4.2. LoRaWAN Network / Application Server Configuration 28

4.2.1. LoRaWAN-nätverksserverkonfiguration 29

5. Arbetsvillkor för @City GSM / LoRaWAN-enheter 31


1. Introduktion.

De @Stad systemet stöder ett antal elektroniska enheter (styrenheter) - kallas som nod, mote, enhet. Många typer av kommunikation (trådbunden och trådlös) är tillgängliga beroende på tillgänglig infrastruktur, krav och villkor.

Enhetstyper tillgängliga i @City-systemet:

Alla enheter är integrerade med varandra via @Stad moln och det finns en möjlighet till hybridsamarbete beroende på tillgängligheten av en given kommunikationsinfrastruktur.

För byggnader och tillgänglighet av LAN eller WiFi ansluten till Internet kan vi använda eHouse lösningar via eHouse.PRO server (som kan skicka / ta emot data till @Stad moln):

Följande dokument beskriver GSM och LoRaWAN enheter baserade på en enchipsmikrokontroller (mikroprocessor) och ett externt kommunikationsmodem. Detta gör att systemet kan standardiseras trots skillnaden i kommunikationsmodem.

För andra kommunikationsvarianter hänvisas till eHouse dokumentation.



Detta gör att liknande funktioner och utrustning kan erhållas, liksom enkel migrering till andra kommunikationsvarianter eller versioner.

1.1 @City (IoT / CIoT) kommunikation

@City-systemet använder för närvarande en av de valda kommunikationsmodulerna (modem):

1.2. Hårdvaruresurser för IoT / CIoT-enheter

Hela "intelligens" av systemet finns i mikrokontroller (mikroprocessor) och är inte särskilt beroende av typen av kommunikation. Hårdvaruressurserna för IoT / CIoT-enheter (mikroprocessor) är följande:

1.3. @City GSM-enheter

@City GSM enheter ansluter via GSM-mobiloperatörens mobilnätverk via en eller flera tekniker och tjänster. Dessa tjänster faktureras och beror på operatörerna och tjänsterna individuellt. Tjänsten godkänns på samma sätt som i mobiltelefoner via aktiva SIM-kort:

Tillgängligheten för utvalda tjänster beror på kommunikationsoperatören och det inbyggda GSM-modemet i produktionsfasen:

1) 2G (alla operatörer)

2) 2G / LTE CATM1 (Orange) - det finns 2G reservmöjlighet när CATM1 inte är tillgängligt.

3) 2G / NBIoT (T-Mobile / Deutsche Telecom) - det finns 2G reservmöjlighet när NBIoT inte är tillgängligt och operatören tillåter det.

4) 2G / 3G (alla operatörer)

5) 4G / LTE (alla operatörer)

6) Andra tjänster kan också vara tillgängliga beroende på tillgängligt modem och inställningar.

De första tre lösningarna fungerar på samma modem (NBIoT / CATM1 + reserv 2G). Vid användning "plast" Nano-SIM-kort är det möjligt att byta ut kortet och fjärrkonfigurera enheten så att den fungerar korrekt i en annan tjänst. När det gäller MIM (SIM-kort i form av ett chip (IC)) fattas beslutet i produktionsstadiet för enheten och det är inte möjligt att byta operatör eller tjänst. NBIoT ägnar sig åt en mycket liten mängd överförda data ~ 512 kB per månad (vänligen förhandla detta värde till operatören), vilket är ett betydande hinder för vissa CIoT / IoT-lösningar.

Lösningar 4, 5 kräver installation av andra modem i produktionsfasen.

Enhetens strömförbrukning beror på tjänsten och visas från lägsta till högsta:

- NBIoT

- CATM1

- LTE

- 3G

- 2G / SMS / USSD / GPRS / EDGE

Dataöverföringshastighet från lägsta till högsta:

- NBIoT

- CATM1

- 2G / SMS / USSD / GPRS / EDGE

- 3G

- LTE



Alla @City GSM-enheter kan utrustas med en GPS-mottagare för geolokalisering och automatisk positionering på kartor. De kan också fungera mobilt när det finns behov av mätningar eller arbeta i rörelse.




1.4. @City LoRaWAN-enheter

LoRaWAN är en långväga kommunikationslösning (upp till ca. 15 km) som arbetar i öppna ISM-band (t.ex. 433MHz, 868MHz, etc. ). Mycket stora intervall kräver emellertid en signifikant minskning av överföringshastighet och datapaketlängd (t.ex. för det högsta intervallet upp till 250 bitar per sekund och högst 51 byte data - nyttolast). Överföring med upprepningar och bekräftelser kan ta mycket lång tid, vilket kan eliminera LoRaWAN i vissa lösningar. Antalet LoRaWAN-gateways är också viktigt för att säkerställa ett bra utbud av enheter, vilket gör att du kan arbeta i högre hastigheter, färre fel och mindre repetitioner.

LoRaWAN-enheter kommunicerar med @City moln via LoRaWAN Gateways, som måste ge täckning på önskad nivå för alla tillgängliga LoRaWAN-enheter. Dessutom måste dessa gateways vara anslutna till LAN eller Internet via vilken länk som helst för att kunna skicka data till LoRaWAN-nätverket / applikationsservern (NS / AS).

Webbservern används för tvåvägskommunikation med LoRaWAN-gateways och för att skicka information till / från LoRaWAN-enheter.

Nätverks- / applikationsservern kan lokaliseras på den lokala LAN eller i tjänsteleverantörens datacenter. Data från enheterna skickas från nätverket / applikationsservern via integrationsprotokoll till @City moln (via webbhook). Detta möjliggör direkt integration av @City LoRaWAN system med @City databaser.



Applikationsservern kan dessutom implementera utökad logik & BIM (informationsmodellering) för systemet, bearbeta data vid mottagning och skicka kontrollkommandon (händelser) till enskilda enheter som svar.

@City LoRaWAN-enheter innehåller ytterligare funktioner som:


Modulen utan LoRaWAN-modem och processor kan fungera som MEM-sensormodul för @City GSM-, WiFi-, Ethernet- och andra arkitekturer (3v3..3v6 DC-driven)

2. Allmänna användningsvillkor @City (LoRaWAN, GSM) -system

UPPMÄRKSAMHET! Felaktig inställning av de viktigaste parametrarna för kommunikationsgränssnitt kan orsaka förstörelse eller permanent blockering av enheten (som vi inte har någon fysisk åtkomst till).

Varje styrenhets uppdatering av en firmware och slutlig konfiguration måste utföras och testas (för alla enheter och i minst en vecka för flera enheter) innan de installeras på destinationsplatsen.

Tillverkaren ansvarar inte för felaktig konfiguration / mjukvaruuppdatering utförd av obehöriga personer, såväl som för utförande på platser för installation av enskilda styrenheter.

Alla kostnader för avinstallation, tjänster, reparation, utbyte, ominstallation bärs av systemanvändaren (inte tillverkaren).

För att uppdatera den fasta programvaran och konfigurationen är det nödvändigt att säkerställa en tillräcklig signalnivå och tillgängligheten för de tjänster som krävs. Ovanstående aktiviteter kan vara omöjliga vid regulatorernas slutliga installationsplatser och i deras inneslutningar. De kan också bero på säsong, väder och radiovågsutbredning.

Alla kostnader för tjänster relaterade till konfiguration / firmwareändring bärs av användaren (extra avgifter för dataöverföring, eventuell avinstallation, installation av enheter, upplåsning, utbyte etc. ).

Det maximala intervallet är rent teoretiskt, mätt under ideala radioutbredningsförhållanden och hänvisar till användning av enheter (med externa och matchade antenner) i synfältet (utan hinder i signalstrålbanan). Beroende på områdets urbanisering, träd, väder, läge och installationsmetod kan räckvidden vara sämre flera hundra gånger än ovanstående data.

2.1. Exklusiva villkor för @City GSM.

Användaren bär kostnaderna och är ansvarig för snabb betalning av GSM-operatörsabonnemanget och @City-serverhostningen. Brist på kontinuitet i tjänsten kan orsaka irreversibla förändringar av kritiska överföringsparametrar och blockera hela systemet (t.ex. ändring av statisk IP-adress, förlust av internetdomän, förlust av data / konfiguration på servern, förlust av programvara, säkerhetskopior etc. ).

I händelse av att användaren betalar ovan nämnda belopp som schablonbelopp till producenten av @City-systemet, är Producenten inte ansvarig för ändringarna av erbjudandet eller avslutandet av tjänster som utförs av externa enheter.

Systemtillverkaren ansvarar inte för kvaliteten på tjänster som tillhandahålls av tredje part, inklusive GSM-operatören, extern @City-värd. Tillverkaren ansvarar inte för försämringen av radiovågsutbredningsområdet (t.ex. på grund av skapandet av nya byggnader, förändringar i placeringen av GSM-sändningsstationer (BTS), träd etc. ).

När det gäller dataöverföringsgränser (särskilt för NBIoT) bör programvarukonfiguration och uppdatering utföras i början av prenumerationsperioden, med lägsta möjliga dataförbrukning. Annars är det möjligt att blockera enheten fram till slutet av faktureringsperioden på grund av blockeringar i samband med överskridande av överföringsgränsen.

GSM-operatören ansvarar för kvaliteten på GSM-anslutningen, inte tillverkaren av @City-systemet.

Användaren förklarar att han / hon accepterar följande information och samtycker till den.

2.2. Exklusiva villkor för @City LoRaWAN.

Användaren bär kostnaderna och ansvarar för snabb betalning av hyres- och installationsavgifter för LoRaWAN-gateway, LoRaWAN Network / Application Server och @City serverhosting. Brist på servicekontinuitet kan orsaka irreversibla förändringar av kritiska överföringsparametrar och permanent systemblockering (t.ex. ändring av statisk IP-adress, förlust av domän, förlust av data / konfiguration på servern, förlust av programvara, säkerhetskopior etc. ).

I händelse av att användaren fastställer ovanstående skyldigheter till schablonbelopp till @City-producenten, är producenten inte ansvarig för att ändra villkoren eller avsluta de tjänster som tillhandahålls av externa enheter.

Systemtillverkaren ansvarar inte för tjänster som tillhandahålls av externa enheter, inklusive någon LoRaWAN-operatör, som är värd för LoRaWAN-nätverk / applikationsserver, extern @City-serverhosting. Tillverkaren ansvarar inte för försämringen av radiovågsutbredningsområdet (t.ex. på grund av skapandet av nya byggnader, förändringar i LoRaWAN-gateways placering, skador på LoRaWAN-gateways, strömavbrott, träd, störningar, signalförluster etc. ).

Vid dataöverföringsbegränsningar bör programvarukonfiguration och uppdatering utföras i början av prenumerationsperioden, med minst aktuell dataförbrukning. Annars är det möjligt att blockera enheten fram till slutet av faktureringsperioden på grund av blockeringar i samband med överskridande av överföringsgränsen. Uppdateringen ska utföras en styrenhet från början till slut och testa riktigheten av arbetet. Om du kör uppdateringen för alla styrenheter kan radiobandet blockeras helt under många dagar.

LoRaWAN använder allmänt tillgängliga "öppna radioband" (433 eller 868 MHz för EU), som kan störas eller upptas av andra enheter som arbetar på samma frekvenser. Tillverkaren ansvarar inte för kvaliteten på kommunikationen i ovanstående fall.

Användaren är ansvarig för att täcka området med lämpligt antal LoRaWAN-grindar och deras placering för att erhålla lämplig signalnivå för alla enheter och hela @City LoRaWAN-systemet.

@City GSM-enheter kan användas på platser som är mycket utsatta för signalstörningar.

Användaren förklarar att han / hon accepterar följande information och samtycker till den.

3. @City (LoRaWAN, GSM) Controller Configuration

Systemkonfiguration utförs via webbgränssnittet. Konfiguration är mycket kritisk för @City-styrenheter och felaktiga inställningar kan få systemet att blockeras helt. Vi rekommenderar att hela mallkonfigurationen (standardinställningar) utförs och testas av systemtillverkaren @City.

3.1. @City Controller Configuration - Tilldela namn


Styrenhetsadress 000000000000000 (15 nollor för GSM / 16 för LoRaWAN) är standardadressen som gäller alla regulatorer i familjen (dvs. för samma Leverantörskoder och Filkodoch samma typ av LoRaWAN / GSM-styrenhet. Om regulatorn inte har en egen konfiguration definierad laddas standardkonfigurationen in i den.

För GSM-kontroller motsvarar denna adress det unika IMEI-numret (15 tecken) som tilldelats av tillverkaren av GSM-modemet.

För LoRaWAN-styrenheter motsvarar denna adress det unika "Dev EUI" nummer som ges av tillverkaren av LoRaWAN-modemet (16 tecken i hexadecimal kod).

Leverantörskoder - är en unik parameter för kunden (användaren)

Filkod - är en parameter som anger typen av firmware (beror på utrustningen och tillgängliga algoritmer)

I de flesta fall är det tillräckligt att konfigurera den här enheten (standard) för hela systemet eller som en mall för andra drivrutiner. När du skapar en ny kontrollerkonfiguration kopieras dessa inställningar från mallen.

Både firmware och konfigurationer för alla installationer (instanser) finns på servrarna från @City-systemtillverkaren som är tillgängliga via WWW, som användaren kan ha begränsad åtkomst till. Den korrekta konfigurationen är dock mycket kritisk och det rekommenderas inte att göra ändringar utan att testa på flera enheter med full fysisk åtkomst (på skrivbordet). För mer information, se de allmänna villkoren för @City-systemet och de specifika villkoren för ett visst kommunikationssätt.

3.2. Allmän konfiguration av @City LoRaWAN & GSM-styrenheter

3.2.1 Allmän konfiguration av @City GSM-enhet

Innan du startar konfigurationen, läs de allmänna villkoren för @City-systemet och systemspecifika villkor för @City GSM.




Leverantörskoder - innehåller 8 tecken lagrade i hexadecimal kod tillägnad en kund (användare). Det beviljas vid tillverkarens produktionsstadium. Ett försök att ändra kan orsaka permanent skada på styrenheten.

Filkod - innehåller 8 tecken lagrade i hexadecimal kod, tillägnad en styrenhetsversion av firmware. Det beviljas vid kontrollproduktionsstadiet och kan bero på typen av kommunikation (GSM / LoRaWAN) och ytterligare utrustning, t.ex. sensorer, antalet ingångar / utgångar och individuella algoritmer. Ändringen kan orsaka permanent skada eller blockering av styrenheten.

PIN-nummer - 4-siffrigt PIN-nummer om det är inställt på SIM-kortet. Det går inte att ställa in PIN-koder. För SIM-kort av plast kan du ta bort dem från din mobiltelefon. Introduktionen av ett felaktigt SIM-kort kan orsaka permanent blockering av kortet i enheten (som vi i slutändan inte kommer att ha fysisk åtkomst till).

SMS-nr - SMS-nummer när du skickar status via SMS. Detta alternativ är tillgängligt beroende på tjänsten och operatören (2G / CATM1 / NBIoT). Det kräver också att man slår på flaggan: SMS aktiverat.

USSD Str - USSD-kommando för att skicka status via USSD. Detta alternativ är endast tillgängligt för utvalda typer av GSM-modem (2G / 3G + GPS). Alternativet: USSD Aktivera krävs. Operatören måste tillhandahålla och aktivera USSD-tjänsten.

APN - Access Point Name. Namnet på internetåtkomstpunkten, t.ex. internet (för specialtjänster som LTE-M1 eller NB-IoT kan den tilldelas individuellt av operatören).

WWW-adress - webbadress (domän eller IP) för HTTP-åtkomst.

WWW-sida - webbsideadress, där styrstatus och kommandon skickas.

HTTP aktiverad - Aktiverar HTTP-dataöverföring. Den här metoden genererar många gånger mer dataöverföring än alla andra kommunikationsmetoder, vilket kan leda till ökade kostnader, som överskrider överföringsgränsen eller oförmåga att använda vissa tjänster, såsom NBIoT.

TCP / UDP-adress - IP-adressen till @City-servern för mottagning och överföring av data mellan molnet och enheterna. Vi rekommenderar att du använder en fast IP-adress, inte en internetdomänadress.

TCP-port - TCP / IP-port för kommunikation

TCP Enable - Låter dig aktivera TCP / IP-överföring. Överföringsramar och TCP-bekräftelser ökar mängden data i förhållande till UDP-överföringar, men de säkerställer korrekta uppgifter, bekräftelser och garanterar att de levereras, om kommunikation är tillgänglig.

UDP-port - Port för mottagning av status via UDP

UDP Aktivera - Slå på överförings-UDP

Aux-adress, Aux-port, Aux-aktiverad - framtida applikationer

Aux2-adress, Aux2-port, Aux2 aktiverad - framtida applikationer

Aktivering av sensorstöd (de måste vara fysiskt monterade på @City-modulen). Annars kan enheten fungera mycket långsammare och mindre stabil. Sensorer installeras i produktionsfasen för hela produktionsserien.

Temp, tryck, luftfuktighet, gas - integrerad sensor för temperatur, tryck, luftfuktighet och luftkvalitet

Temp + Presure - Integrerad temperatur- och tryckgivare

Gyroskop - Gyroskopsensor i 3 axlar (X, Y, Z)

Magnetometer - Magnetisk sensor i 3 axlar (X, Y, Z)

Accelerometer - Acceleration / vibrationssensor i 3 axlar (X, Y, Z)

Färg - Färgsensor (R, G, B, IR, G2)

Ambient + proximeter - integrerad ljusnivå och (10 cm räckvidd) proximetersensor

GSM-kommandon - ytterligare kommandon för initialisering av modem

Hash-kod - En ytterligare krypteringskod. Ändra inte.

HTTP-överföring - Ytterligare HTTP-kommunikationsalternativ

Global adress - Styrenhetens globala adress för enhet-till-enhet-kontroll.

GSM-läge - GSM-kommunikationsläge (endast 2G, endast LTE, CATM1, NBIoT, 2G + CAT M1, LTE 800, LTE 1800). Felaktig inställning av kommunikationsläge kan leda till permanent blockering av enhetskommunikation.

3.2.2. Allmän konfiguration av @City LoRaWAN-styrenheter

De flesta alternativen är desamma som i GSM-styrenheten. I princip används inte alla fält relaterade till GSM-kommunikation under drift av LoRaWAN-styrenheten. LoRaWAN-enheter har olika firmware som stöder LoRaWAN-modulen istället GSM.

På @City LoRaWAN enhetssidan är konfigurationen väldigt enkel:

Ansökan EUID - Applikations-ID för LoRaWAN-server (16 tecken i hex-kod) - applikation definierad på LoRaWAN-nätverket / applikationsservern som vi skickar data till.

Programnyckel - programbehörighetsnyckel för LoRaWAN-servern (som ovan)

Inaktivera adaptiv datahastighet - Inaktiverar val av adaptiv hastighet. Detta gör att du kan tvinga enhetens konstanta hastighet. I vissa situationer kan detta orsaka stora kommunikationsproblem. Det bör tas i beaktande att när RSSI- och SNR-parametrarna förbättras i det adaptiva läget ökar hastigheten avsevärt. Detta minskar signifikant tiden för dataöverföring via radio "På sändningstiden" och mycket oftare kan information överföras mellan enheten och servern och vice versa.

Datahastighet (DR) - Val av LoRaWAN-länkhastighet. Denna hastighet gäller inte Bootloader. Om regulatorn arbetar i det adaptiva hastighetsinställningsläget är det bara startvärdet, eftersom styrenheten efter flera överföringsförsök väljer autonomt den optimala hastigheten för att begränsa tiden för meddelandeöverföring i luften.

Uppdatera inställningarna - sparar startkonfigurationen för styrenheten - alla inställningar



Resten av @City LoRaWAN-konfigurationen finns i de återstående delarna av LoRaWAN-konfigurationsskärmarna i kapitel 4.

3.3. Konfiguration av binära ingångar




Binära ingångar har ett antal funktioner och parametrar som möjliggör autonom drift av styrenheten:

Invertera - ingångsnegation när sensorer "normalt ansluten" (NC) är anslutna.

Larm - aktivering av larmfunktionen.

Larmfördröjning - Larmfördröjningstid. Om ingångstillståndet återgår till sitt ursprungliga tillstånd innan denna tid har löpt ut aktiveras inte larmet.

Kom ihåg staten - Dags att komma ihåg förändringen av ingångstillståndet.

Inaktivera körning - Blockering av löpande händelser relaterade till ingången.

Springa - Kör kommandot för ingångskonfiguration (Ad-Hoc)

Kopiera - Kopiera ingångskonfigurationskommandot till Urklipp

Event On - Beskrivning av hur man kör evenemanget för hög inmatningsnivå (1)

Direkt händelse på - Händelsekod som ska köras när ingången är på (0 => 1)

Event Off - Beskrivning av händelseaktivering för låg ingångsnivå (0)

Direkt händelse av - Händelsekod som ska köras när ingången är avstängd (1 => 0)

Larmhändelse - Beskrivning av larmhändelsen.

Direktlarmhändelse - Händelsekoden som ska utlösas när ett larm inträffar

Uppdatera inställningarna - sparar startkonfigurationen för alla inställningar

3.4. Konfiguration av binära utgångar




Intelligenta binära utgångar kan fungera som enkla eller dubbla. I formuläret kan du skapa en startkonfiguration för styrenheten (om du bekräftar det med knappen Uppdatera).

Formuläret fungerar också som en händelseskapare för utgångar som kan startas genom att trycka på Run-knappen eller kopieras till klippbordet för användning i kontrollerkonfigurationen, t.ex.



Konfiguration av enstaka utgångar:

Inaktivera - Blockera utgången i enstaka läge (t.ex. om den används för att styra drivenheter för att inte oavsiktligt skada rulljalusier, grindar, ställdon)

Administration - En administrativ flagga krävs när du ändrar kritiska inställningar

stat - tillståndsval (initial konfiguration eller start av händelsen med "run" knapp)

Upprepar - Antal repetitioner (cykliska förändringar)

Starta tiden - Tid för utgångsaktivering

Time Off - Tid för att stänga av utgången (det är viktigt när du upprepar händelser)

Springa - Kör evenemanget för avslutning

Kopiera - Kopiera händelsen till Urklipp

Uppdatera inställningarna - sparar startkonfigurationen för alla inställningar

Konfiguration med dubbel utgång:

Inaktivera - Lås ut ett par utgångar i dubbelt läge (t.ex. om de används som enstaka ingångar)

Administration - En administrativ flagga krävs när du ändrar viktiga inställningar som körläge

Somfy - körläge (markerat => Somfy / avmarkerat => Direkt servo)

stat - tillståndsval (för initial konfiguration eller lunchning av evenemanget med "run" knapp)

Upprepar - Antal repetitioner (cyklisk tillståndsförändring)

Starta tiden - Tid för att slå på det givna tillståndet

Inaktivera tid - Dags att blockera utgångar (minsta tid mellan utgångsändringar) för att skydda enheter mot skador.

Time Off - Tid för att stänga av utgången (det är viktigt när du upprepar händelser)

Springa - Kör evenemanget för enheten

Kopiera - Kopiera händelsen till Urklipp

Uppdatera inställningarna - sparar startkonfigurationen för alla inställningar

3.5. Konfiguration av ADC-mätingångar och ytterligare sensorer (XIN)




Invertera - inverterad skala (100% -x) för ADC-ingången

Larm L - Aktivering av alternativet att generera ett larm när värdet sjunker under min. tröskel

Larm H - Aktivering av alternativet att generera ett larm när värdet överstiger max. tröskel

Larmfördröjning - Larmfördröjningstid. Om ingångsstatus återgår till "OK" nivå innan tiden går, aktiveras inte larmet.

Händelse inaktiverad - Blockering av händelsekörning

Administration - adminflagga som möjliggör ändring av mätingångskonfigurationen

LÅG händelse - beskrivning av händelsen som utfördes när det låga tröskelvärdet överskreds

LÅG direkt - händelsekod som ska köras efter att ha sänkt värdet under det lägre tröskelvärdet

Låg nivå - Nivå för nedre tröskel (min)

OK händelse - Beskrivning av "OK" händelse

OK direkt - händelsekod som ska köras efter att du har angett "OK" räckvidd

HÖGT evenemang - Beskrivning av händelsen för den övre tröskeln

HÖG direkt - händelsekod som ska köras efter att ha överskridit det övre tröskelvärdet

Hög nivå - Nivå för övre tröskel (max)

Springa - kör konfigurationshändelsen (ändring av ADC Ad-Hoc-konfiguration)

Uppdatera inställningarna - sparar den ursprungliga konfigurationen för ADC-ingångarna

3.6. Dimmerkonfiguration PWM / 0..10V




Invertera - Vändning av dimmerpolaritet (100% - x)

Administration - En administrativ flagga som låter dig ändra kritiska alternativ

Inaktivera - Blockering av dimmerutgången

En gång - Ändra dimmerinställningarna en gång (stoppa sedan dimmer)

Värde Min - minimivärde för dimmerinställningar

Värde - dimmerns målvärde

Läge - Dimmerinställningsläge (Stopp / - / + / Set)

Steg - Steg för att ändra dimmernivåvärdet

Värde Max - det maximala värdet för dimmerinställningen

Springa - Kör dimmerhändelsen

Kopiera - Kopiera händelsen till Urklipp



RGBW-dimmern hämtar inställningsvärdena från enskilda färger.

Dessutom gör det att du kan aktivera det kontinuerliga färgbytesläget med förinställningarna för enstaka dimmer.

Uppdatera inställningarna - sparar startkonfigurationen för alla inställningar





Knappar:

Uppdatera inställningarna - sparar konfigurationen i @City-systemet

Alla styrenheter - en lista över alla styrenheter

inställningar - inställningar för aktuell styrenhet

Ändra namn - ändra namnet på den aktuella styrenheten

Schemaläggare - schemaläggarkalenderredigeraren för den aktuella styrenheten

Skrivkonfig * - skicka ett kommando för att ladda ner konfigurationen av styrenheten

Uppgradering av fast programvara * - skicka ett kommando för att ladda ner firmware från styrenheten

Återställ styrenhet * - skickar återställningskommandot för nedladdning av styrenheten

Återställ styrenhet - Kopiera - kopia av regulatorns återställningshändelse till Urklipp

Logga ut - avloggning av användaren (av säkerhetsskäl bör du också stänga alla öppna instanser av webbläsaren som kan lagra inloggningsparametrarna i cachen).

* - att skicka kommandot innebär att lägga till i händelsekön. Vid anslutning av styrenhet till @City-systemet hämtar styrenheten dessa händelser.

3.7. Kalender-schemaläggningskonfiguration


Kalenderplaneraren tillåter autonom utlösning av repetitiva eller schemalagda händelser (kommandon). Ett exempel kan till exempel vara att sätta på gatlyktan klockan 17 och stänga av klockan 7 (på vintern).

Del (Radera) - raderar schemaposten helt.

En. (Gör det möjligt) - Aktivera schemalagd post (endast de positioner kommer att köras som har Enable-flaggan inställd)

namn - Händelsens namn (du kan beskriva händelsen på ett igenkännbart sätt)

Händelsekod - händelsekod i hexadecimal kod (kopieras från urklipp när du skapar kommandon)

Månadsfält (Ja, Fe, .., Nej, De) - månader januari ... December då evenemanget kommer att startas

Dag - Dag. Du kan välja vilken dag i månaden som helst eller "*" för alla (kör evenemanget varje dag).

Veckodagar (Mo, Tu, .. Su) - du kan välja de veckodagar som evenemanget ska utföras.

Timme - Timmen. Du kan välja vilken timme som helst eller "*" för alla (kör evenemanget varje timme).

Min - Minut. Du kan välja vilken minut som helst eller "*" för alla (kör evenemanget varje minut).



Logisk "och" algoritm implementeras mellan alla fält (utom namn ), så de måste alla vara uppfyllda för att händelsen ska genomföras.



T.ex. Tända gatlyktor ( November, december, januari, februari ) vid 17.01 utan Söndagar.

En - vald

Event code - 00002101010000000000 // körning av den första binära utgången

Månadsfält - bara Nej, De, Ja, Fe är markerade

Dag - vald "*" för varje dag i månaden

Timme - vald tid är 17

Min - vald minut 01

Veckodagar - allt utom Su vald

4. LoRaWAN-nätverksinfrastrukturkonfiguration

Detta kapitel gäller endast LoRaWAN-kommunikation. När det gäller system som arbetar med andra överföringsmetoder kan det utelämnas.

Enligt LoRaWAN-nätverksspecifikationen ansluter styrenheten till @City-molnet indirekt genom:

4.1. LoRaWAN Gateway-konfiguration.

Det finns många LoRaWAN-gateways på marknaden som samtidigt kan innehålla ett antal ytterligare alternativ:

4.1.1. Grundläggande konfiguration av LoRaWAN gateway

LoraWAN-gatewayen ska vara tillgänglig från minst en konfigurationsstation.

När du installerar via Ethernet / WiFi och endast konfigurerar från ett lokalt LAN / WLAN är gatewayens säkerhet inte särskilt kritisk (såvida vi inte ger åtkomst till gatewayen utifrån, dvs. Internet).

Om LoRaWAN-gatewayen endast är ansluten via GSM / LTE är det nödvändigt att säkra gatewayen mot åtkomst och olika typer av attacker.

- Om vi ​​vill kunna ansluta till LoRaWAN-gatewayen på distans måste den ha en offentlig + statisk IP-adress och SSH-tjänst tillgänglig. Annars måste du fysiskt ansluta till gatewayen via ett Ethernet- eller WiFi-gränssnitt.

- det är nödvändigt att ställa in komplicerade åtkomstlösenord för alla användare på enheten.

- inaktivera alla oanvända tjänster som Telnet, FTP, POP, SMTP, IMAP, WWW etc. det kan vara målet för attacker "ockuperar" porten med andra processer som inloggningsförsök.

- du kan begränsa möjligheten att logga in, endast från stationer med utvalda statiska IP-adresser, vilket är ganska effektivt skydd mot hacking. Detta gäller även till synes obetydliga tjänster som ICMP (ping), HTTP, FTP, etc.

- efter fullständig konfiguration och många veckors systemtest kan vi blockera alla externa tjänster och fjärråtkomst, vilket dock kommer att hindra tjänsten, söka och kontrollera gateway-loggarna.

4.1.2. Semtech Packet Forwarder (SPF) -konfiguration

SPF: s uppgift är att skicka LoRaWAN-paket till LoRaWAN-nätverksservern via IP-nätverket (UDP-protokoll) till den önskade adressen till LoRaWAN-nätverksservern.

LoRaWAN Gateway med SPF är transparent och skickar alla paket i båda riktningarna.

Det behandlar eller auktoriserar inte datapaket i någon riktning.

Konfigurationen av SPF är mycket enkel och involverar "regi" den till den LoRaWAN-nätverksserver som krävs.

Logga in via SSH till LoRaWAN-gatewayen med det användarnamn och lösenord som anges av enhetstillverkaren.

Installera SPF enligt tillverkarens instruktioner från LoRaWAN gateway.

SPF-konfigurationskatalogen är "/ användare / spf / etc /" beroende på tillverkaren av LoRaWAN-gatewayen kan den dock finnas på andra platser.

Huvudkonfigurationen för SPF finns i filen "/user/spf/etc/global_conf.json", som ska redigeras med den tillgängliga redigeraren (t.ex. vi eller nano). Vi ändrar värdet på parametern: "server adress" genom att ange den fasta IP-adressen till nätverksservern eller domännamnet (Kräver en ytterligare korrekt konfigurerad DNS-klienttjänst).

Standardkommunikationsporten för retur är 1700 (om du planerar att ändra dem måste du göra detsamma på LoRaWAN-nätverksservern) genom att ange identiska värden.

Loggar för SPF-paketet finns i "/ användare / spf / var / loggar /" katalog i spf.log filen och dess arkivkopior.

Nätverkskonfigurationen för LoRaWAN-gatewayen på Linux OS finns normalt i katalogen "/etc/", där du kan aktivera / inaktivera standardnätverkstjänster och säkra servern.

Du bör också ändra lösenorden för alla användare som är tillgängliga i systemet med passwd kommando för att skydda mot obehörig åtkomst av obehöriga personer. Du måste också ändra användarlösenordet för webbaserad support.

Det är också bäst att inaktivera WiFi-kommunikation, eftersom inkräktare kan försöka använda attacker via detta överföringsmedium.

Efter att ha slutfört denna konfiguration, återställ gateway med starta om kommando.



4.2. LoRaWAN Network / Application Server Configuration

Det finns många lösningar för nätverks- och applikationsservrar (inklusive gratis). Var och en av dem har sitt eget sätt att integrera med externa tjänster och system (t.ex. moln som @Stad ). Av denna anledning @Stad systemet måste ha ett gränssnitt för integration med den installerade LoRaWAN NS / AS-servern.

I fallet med ett produktionssystem kan vi använda den kostnadsfria tjänsten "The Things Network", så länge vi är inom mycket stora dagliga gränser definierade för varje enhet {särskilt "På sändningstiden" (30s **) och ett litet antal kommandon som skickas till enheten (10 **)}.

** vägledande aktuella dagliga enhetsgränser kan ändras.

Om du behöver ladda ny firmware och konfiguration är det nödvändigt att använda din egen LoRaWAN-server (nätverk + applikation).

Detta ger oss flera alternativ:

I vissa system är firmware + -konfigurationen fixerad (för alla tillgängliga styrenheter i systemet) och initieras vid den initiala systemkonfigurationsfasen, vilket förenklar valet.

(*) - i dessa fall är det nödvändigt att ha en andra LoRaWAN-gateway inställd på den andra servern för konfiguration och firmwareuppdatering för att produktionsmiljön ska fungera kontinuerligt. För lågkritiska applikationer kan du ändra konfigurationen för en LoRaWAN-dedikerad LoRaWAN-server, vilket emellertid kommer att leda till förlust av kommunikation med produktionsmiljön och felaktig användning av dessa enheter.

Det bör inses att programuppdateringen för en enda LoRaWAN-kontroller tar ungefär en timme, med bra räckvidd (DR> = 4), så det är värt att använda en extra gateway för att uppgradera firmware och konfiguration. Vid låg täckning (DR <4) är konfiguration och uppdatering av firmware inte möjlig och kräver en gateway med LTE-kommunikation nära de uppdaterade enheterna.

4.2.1. LoRaWAN-nätverksserverkonfiguration

Lägg till LoRaWAN-kommunikationsgatewayen på LoRaWAN-nätverksservern (adressen finns på omslaget eller i filen "användare / spf / etc / local_conf.json"eller visas i loggarna "/user/spf/var/log/spf.log". Kontrollera i webbserverloggarna att kommunikationsgatewayen ansluter till servern.

Nästa steg är konfigurationen av applikationsservern (den finns vanligtvis på samma enhet som nätverksservern).

Nästa steg som ska utföras beror på vilken applikationsserverlösning som används och tillgängligheten för gränssnittet Back-End / Front-End. Gränssnittet förenklar "första stegen" och systemkonfiguration.

Generellt bör du:

 







5. Arbetsvillkor för @City GSM / LoRaWAN-enheter

Temperatur - 40C .. + 65C

Luftfuktighet 0..80% RF ingen kondens (enhet)

GSM Strömförsörjning 5VDC @ 2A ±0,15 V (för PPM-sensor och vid anslutning av reläer)

3.5VDC..4.2VDC @ 2A (i andra fall)


LoRaWAN power supply 5VDC @ 300mA ± 0,15 V (för PPM-sensor och vid anslutning av reläer)

3VDC..3.6VDC @ 300mA (i andra fall)


GSM + GPS-enheter:

Antenningång 50ohm

SIM nano-SIM eller MIM

(val i produktionsfasen - MIM påtvingar en nätoperatör)

Modem Approval Orange (2G-CATM1), T-Mobile / DT (2G-NBIoT), 2G Andra operatörer


BANDS (Europa) Känslighet för klassutgångseffekt

B3, B8, B20 (CATM1 - 800MHz) ** 3 + 23dB ±2 < -107.3dB

B3, B8, B20 (NB-IoT - 800 MHz ) ** 3 +23dB ±2 < -113.5dB

GSM850, GSM900 (GPRS) * 4 + 33dB ±2 <-107dB

GSM850, GSM900 (EDGE) * E2 + 27dB ±2 <-107dB

DCS1800, PCS1900 (GPRS) * 4 + 30dB ±2 < -109.4dB

DCS1800, PCS1900 (EDGE) * E2 +26dB ±2 < -109.4dB

När du använder en extern smalbandig antennfrekvensmatchad för ett givet band.


* endast för Combo-modem: 2G, CATM1, NB-IoT

Certifikat:



GPS / GNSS:

arbetsfrekvens: 1559..1610MHz

antennimpedans 50ohm

maximal känslighet * -160dB stationär, -149dB navigering, -145 kallstart

TTFF 1s (varm), 21s (varm), 32s (kall)

A-GPS ja

Dynamik 2g

minimal uppdateringsfrekvens 1 Hz


* matchad extern smalbandantenn



LoRaWAN-enheter 1.0.2 (8 kanaler, TX-effekt: + 14dBm) Europa (863-870MHz)

DR T modulation BR bit / s Rx Sensitivity Rx Tester

0 3 min SF12 / 125kHz 250 -136dB -144dB

1 2 min SF11 / 125 kHz 440 -133,5 dB

2 1min SF10 / 125kHz 980 -131dB

3 50-talet SF9 / 125kHz 1760 -128.5dB

4 (*) 50-talet SF8 / 125kHz 3125 -125.5dB

5 (*) 50-talet SF7 / 125kHz 5470 -122.5dB

6 (*) 50-talet SF7 / 250kHz 11000 -119dB

7 FSK 50 kbs 50000 -130dB

(*) Parametrar som krävs för att uppgradera systemets firmware via OTA

(DR) - Datahastighet

(BR) - Bithastighet

T - Minsta period av datauppdatering till @City-molnet




LoRaWAN praktiska täckningstest:


Testvillkor:

LoRaWAN Kerlink ifemtocell Intern gateway

passiv utomhus bredbandsantenn placerad ute på en höjd av ~ 9m över marknivå Wygoda gm. Karczew (~ 110 m över havet).

LoRaWAN-enhet med tvingad DR0 med en extern bredbandsmagnetisk antenn placerad 1,5 meter över marken på biltaket.

Landsbygdsområden (ängar, åkrar med små träd och sällsynta byggnader)


Det längsta resultatet var Czersk ~ 10,5 km (~ 200 m över havet) med RSSI lika med -136dB (dvs. med den maximala känsligheten för LoRaWAN-modemet som garanteras av tillverkaren)