SIA Connect – Integrationsdokumentation

---

Innehållsförteckning

1. Verktyg och åtkomst
2. Hårdvaruinstallation i kundens IT-miljö
3. Allmän konfiguration – SIA till Yggio
4. Tag-konfiguration i SIA
5. Vidarebefordringskonfiguration till Yggio
6. Konfiguration mot NODA Energy View
7. Watchdog – metoder och fallgropar
8. Felsökning
9. Begränsningar
10. Rekommendationer

---

1. Verktyg och åtkomst

1.1 VPN

SIA Connect installeras inuti kundens byggnadsnätverk och är normalt inte nåbart direkt från internet. Fjärråtkomst tillhandahålls via ett VPN, som upprättar en krypterad peer-to-peer-tunnel till enheten. Vilken VPN-lösning som helst kan användas.

Förutsättningar:

• VPN-klient installerad på SIA-enheten vid driftsättning
• Enheten tillagd i rätt VPN-nätverk (organisation/kund)
• Åtkomst till VPN-lösningens hanteringsgränssnitt för att registrera nya enheter

Utan fungerande VPN-åtkomst är fjärrfelsökning i praktiken omöjlig. Verifiera alltid att VPN-anslutningen fungerar innan du lämnar en plats.

1.2 SIA Connect webbgränssnitt

SIAs konfigurationsgränssnitt nås via en webbläsare på enhetens IP-adress, vanligtvis på port 80 eller 443 beroende på installationen.

1.3 Yggio

Yggio är den IoT-broker som fungerar som mellanhand mellan SIA och nedströmssystem som NODA Energy View eller Energy Opticon. Åtkomst sker via Yggios webbgränssnitt eller REST-API.

---

2. Hårdvaruinstallation i kundens IT-miljö

SIA Connect kräver följande nätverksåtkomst:

Riktning	Protokoll	Destination	Port	Syfte
Utgående	MQTTS	mqtt.example1.yggio.net	8883	Publicera data till Yggio
Utgående	HTTPS	Yggio REST-API	443	Registrering, konfiguration
Utgående	VPN	VPN-server	(varierar)	Fjärråtkomst
Intern	Modbus TCP	DUC/PLC	502 (standard)	Läsa/skriva register
Intern	ADS	Beckhoff TwinCAT	48898	Läsa/skriva variabler
Intern	BACnet/IP	BACnet-enheter	47808	Läsa/skriva objekt

Obs: All kommunikation från SIA är utgående. SIA behöver inte vara nåbart från internet.

Initial driftsättning: Gatewayen levereras med en statisk fabriksstandard-IP för den första uppsättningen (även nåbar via en direkt USB-C-anslutning). Den måste ändras till en adress i kundens nätverk innan driftsättning – se leverantörens hårdvaruguide för standard-IP:n och USB-C-proceduren.

---

3. Allmän konfiguration – SIA till Yggio

3.1 MQTT-connector

SIA kommunicerar med Yggio via MQTTS (MQTT över TLS). Skapa en MQTT-connector i SIA med följande inställningar:

Parameter	Värde
Broker	ssl://<yggio_mqtt_broker>
Port	8883
Topic	siaconnect/<SIA_UUID>
Keep Alive	30 sekunder (rekommenderat)
QoS	0 eller 1 beroende på krav

Autentisering: Broker-anslutningen kräver ett MQTT-användarnamn och lösenord. Dessa är inte tillgängliga i SIA:s eller Yggios gränssnitt – begär dem från supportteamet när du sätter upp connectorn. Brokern accepterar inte en anslutning utan giltiga uppgifter, oavsett topic-namn.

Obs: Skapa SIA Connect-connectorn i Yggio innan du publicerar. Connectorn bär samma <SIA_UUID>, och det är när den skapas som kön och bindningen som siaconnect/<SIA_UUID> levererar till sätts upp. Publicerar du till topicen innan connectorn finns kommer meddelandena ingenstans, utan något i Yggio som visar det. Topicen är bunden till den connectorns UUID, så den är inte en av de topics som kan registreras som Reserved MQTT Topic.

Kommandostöd (valfritt): Att aktivera att Yggio publicerar kommandon/börvärden tillbaka till SIA (används av Subscribe-mappningar – se 5.4 och 6.5) kräver en separat uppsättning uppgifter: URL:en till SIA:s webbgränssnitt samt ett SIA API-användarnamn/lösenord. Inte heller tillgängligt i gränssnittet – begär via supportteamet när kommandostöd behövs.

3.2 SIA/Edge Gateway-UUID

Varje SIA-instans har en unik UUID som används som dess identifierare i Yggio-topicen – kallad SIA UUID i det här dokumentet, Edge Gateway UUID i Yggios egen connector-dokumentation. Samma värde, två namn. UUID:n hittas i SIA:s administrationsgränssnitt. Dokumentera alltid UUID:n i projektets installationsjournal.

3.3 Keep Alive

Keep Alive-värdet styr hur ofta SIA skickar en heartbeat till brokern för att hålla MQTT-anslutningen vid liv. 30 sekunder rekommenderas baserat på erfarenhet. Ett för högt värde (t.ex. 240 s) kan få brokern att betrakta klienten som frånkopplad, vilket i sin tur utlöser onödiga watchdog-händelser och databuffring.

3.4 Execute on Startup

Inställningen Execute on startup på en mappning gör att den körs omedelbart när SIA startar om, utan att vänta på nästa schemalagda utlösning.

Denna inställning är inte aktiverad som standard i våra nuvarande installationer. Aktivera den om det finns ett specifikt behov av att säkerställa att publicerade värden skickas omedelbart vid omstart – till exempel för styrsignaler som annars kan ligga kvar i fel läge fram till nästa läscykel.

---

4. Tag-konfiguration i SIA

Tags representerar de datapunkter SIA läser från (eller skriver till) ett fältsystem – till exempel temperaturer, flöden eller styrsignaler. De kan konfigureras via SIA:s gränssnitt eller importeras som en CSV-fil.

4.1 Namngivningskonventioner

Namngivning av tags bestäms av den som sätter upp tag-listan för den aktuella fastigheten – utgå från respektive tag-lista snarare än en fast konvention här.

⚠️ Att byta namn på ett objekt i SIA skapar en ny nod i Yggio. Fältet name används som nodens identifierare i Yggio. Om du byter namn på ett befintligt objekt börjar SIA publicera under det nya namnet och en helt ny nod dyker upp i Yggio – den gamla noden uppdateras eller tas inte bort automatiskt. Den gamla noden ligger kvar i Yggio under det tidigare namnet och måste städas bort manuellt.

Se till att namngivningen är korrekt innan du ansluter till Yggio, och undvik att byta namn på objekt i produktion.

4.2 Trigger Behaviour och Log Condition

Dessa två inställningar styr när SIA vidarebefordrar ett värde.

trigger_behaviour

Värde	Betydelse
1	All – skickar vid varje läscykel oavsett förändring
2	All changes – skickar endast när värdet har ändrats

Vilket bör du använda?

Det beror på hur ofta kunden eller energisystemet behöver datapunkterna:

• All changes (trigger_behaviour=2) är vanligt och lämpligt när du bara vill ha ett värde när något faktiskt har ändrats – till exempel en temperaturavläsning. Minskar onödig datatrafik.
• All (trigger_behaviour=1) används när det mottagande systemet förväntar sig regelbundna uppdateringar oavsett förändring – till exempel mot NODA Energy View, som behöver täta, periodiska värden för sin energianalys.

Utgå alltid från vad det mottagande systemet kräver. Diskutera med kunden eller systemleverantören (t.ex. NODA, Energy Opticon) vilken datafrekvens de behöver.

Minimum Trigger Interval

En inställning som tvingar en trigger att utlösas med ett fast intervall även om villkoret för trigger behaviour inte är uppfyllt – till exempel, om värdet inte har ändrats och All changes är aktivt, utlöses mappningen ändå när intervallet löper ut.

Med andra ord är det ett golv (lägsta sändningsfrekvens), inte ett tak. Det säkerställer att stabila eller långsamt föränderliga värden ändå skickas periodiskt istället för att tystna helt.

Användbart när:

• All changes används men det mottagande systemet behöver en regelbunden heartbeat även när värdena är stabila
• Du vill skydda mot frysta/inaktuella värden i det mottagande systemet

Detta är ingen hastighetsbegränsare. Det förhindrar inte att en mappning utlöses oftare än intervallet om villkoret för trigger behaviour är uppfyllt.

---

4.3 Post-processing

Post-processing är ett valfritt skript som körs på det lästa värdet innan det vidarebefordras. Det bör endast användas när en omvandling faktiskt behövs – till exempel om PLC:n levererar ett värde i fel enhet eller skala.

Exempel 1 – Flöde från m³/h till l/h:

value = value * 1000

Används när ett energisystem rapporterar volymflöde i m³/h men det mottagande systemet förväntar sig l/h.

Exempel 2 – Skalfaktor för INT16:

value = value / 10

Används när en PLC levererar t.ex. 237 för att representera 23,7 °C (skalfaktor 10 i källsystemet).

Post-processing behövs inte om värdet redan är korrekt skalat och i rätt enhet. Kontrollera alltid källsystemets dokumentation (DUC-manual, PLC-registerlista) för att avgöra om en omvandling krävs.

---

4.4 Modbus TCP

Modbus TCP är ett av de vanligaste protokollen i byggnadssystem. SIA läser och skriver register direkt från/till en PLC eller DUC över TCP/IP.

Inställningar per tag:

Parameter	Beskrivning
IP-adress	PLC:ns IP-adress på nätverket
Port	Vanligtvis 502, men kan variera (t.ex. 503 för vissa enheter)
Server ID / Unit ID	Vanligtvis 1, men beror på enheten
Registertyp	3:XXXXX (Holding register) eller 4:XXXXX (Input register) osv.
Datatyp	INT16, UINT16, FLOAT, BOOL osv.

Registerförskjutning (offset):
Modbus-registeradresser i SIA Connect kan skilja sig från de som anges i enhetens dokumentation. Det är vanligt att en offset på ±1 gäller, men detta är inte universellt – det varierar mellan tillverkare och ibland mellan enheter.

Exempel: Abelko UltraBase20 har en offset på -1, vilket innebär att register 01001 i dokumentationen anges som 01000 i SIA Connect.

Verifiera alltid mot faktiska lästa värden om du är osäker. En felaktig offset läser tyst av fel register istället för att ge ett fel.

Praktiskt exempel – Abelko UltraBase20:

• IP: xxx.xx.xx.xxx, Port: 502, Server ID: 1
• Datatyp: INT16, skalfaktor 10 → post-processing: value = value / 10
• Registeroffset: -1 (dokumentationen visar 01001 → ange 01000 i SIA)
• Notera: vissa register på denna enhet kan vara FLOAT – kontrollera manualen

---

4.5 Beckhoff / TwinCAT ADS

ADS (Automation Device Specification) är Beckhoffs egna kommunikationsprotokoll.

Inställningar:

Parameter	Värde/beskrivning
TCP-port	48898
AMS-port	851 (TwinCAT 3) eller 801 (TwinCAT 2)
AMS Net ID	Enhetens IP-adress + .1.1, t.ex. xxx.xx.xx.xxx.1.1

Förutsättning: SIA Connects egen AMS Net ID måste läggas till som en statisk rutt i TwinCAT på PLC:n. Utan detta avvisas anslutningen.

⚠️ Instance timestamp måste vara satt till "Local timestamp" (inte "Server timestamp") på alla Beckhoff TwinCAT-instanser. Att använda Server timestamp kan orsaka ett kritiskt fel över tid. Bekräftat av SIA Connect-supporten. Se den begränsade referensen för detaljer.

Vanligt fel: Target port not found – orsakas vanligtvis av:

• SIA inte tillagt i TwinCATs statiska rutter, eller
• TwinCAT-runtime körs inte på PLC:n

Viktigt – Subscription/push-läge:
Vid användning av ADS opererar SIA i subscription/notification-läge – TwinCAT skickar ändringsnotiser direkt till SIA, istället för att SIA pollar med intervall. Detta innebär att inställningen read_interval inte begränsar hur ofta SIA tar emot (och vidarebefordrar) uppdateringar från TwinCAT.

I praktiken kan detta resultera i mycket täta MQTT-publiceringar oavsett konfigurerat läsintervall. Använd inställningen Minimum trigger interval på mappningen (se avsnitt 4.2) för att begränsa publiceringsfrekvensen.

---

4.6 BACnet

BACnet/IP används i vissa installationer där byggnadens styrsystem exponerar data via BACnet snarare än Modbus eller ADS. Bekräftat fungerande mot en Siemens DUC.

Instansinställningar:

Parameter	Värde/beskrivning
Adress	BACnet Device Instance ID för målenheten
Läge	Gateway
Läsintervall	Minst 60 sekunder rekommenderas – 2 sekunder genererar överdriven trafik

BACnet IP-uppsättning:

Parameter	Värde/beskrivning
Port	47808 (BACnet-standard – använder UDP, inte TCP)
Nätverksgränssnitt	eth0 eller eth1 beroende på installation – prova det andra om det ena inte fungerar
Device Id	SIA Connects eget BACnet Device ID på nätverket. Måste vara unikt – bekräfta med DUC-teknikern vilka ID:n som redan används

Obs: BACnet använder UDP-port 47808. Brandväggsregler måste uttryckligen tillåta UDP – TCP-regler räcker inte.

Adressformat per tag:

(Device Instance ID)(Object Type.Object Instance)

Exempel: (2100231)(0.43) = Enhet 2100231, Analog Input, instans 43.

Bekräftade BACnet-objekttyper i bruk:

Typnummer	Objekttyp	Riktning
0	Analog Input	Endast läs
1	Analog Output	Skriv
2	Analog Value	Läs + skriv (t.ex. börvärden)
3	Binary Input	Endast läs
4	Binary Output	Skriv
5	Binary Value	Läs + skriv

Tillverkarspecifika/proprietära objekttyper (t.ex. Siemens-specifika typer) täcks inte här – de har inte bekräftats som nödvändiga i praktiken. Anta inte att ett proprietärt typnummer fungerar likadant hos alla tillverkare; verifiera mot den faktiska enheten innan du förlitar dig på en.

Datatyp och post-processing: Värden bekräftade som REAL för Siemens/BACnet-installationer – ingen post-processing eller skalning krävs.

Subnät och identifiering: BACnet förlitar sig på UDP-broadcast för identifiering av enheter, vilket inte passerar subnätsgränser. Om SIA Connect och BACnet-enheten befinner sig på olika subnät krävs antingen en BBMD (BACnet Broadcast Management Device) eller registrering som Foreign Device. Bekräfta med nätverks-/DUC-teknikern om enheterna befinner sig på samma subnät.

---

4.7 Läs-/skrivriktning

Fältet readwrite styr om SIA läser en punkt, skriver till den, eller båda. I SIA:s gränssnitt visas detta som en beskrivande rullgardinsmeny; vid CSV-import är det ett numeriskt värde.

Etikett i gränssnittet	CSV-värde readwrite	Betydelse
Read only	1	SIA läser punkten och publicerar den till Yggio
Read & Write	0	Dubbelriktad – används för börvärdes-/styrtags, som behöver både en Publish-mappning (aktuellt värde ut) och en Subscribe-mappning (inkommande kommando in)

---

5. Vidarebefordringskonfiguration till Yggio

5.1 Mappningsgrupper

I SIA länkar mappningar tags till en MQTT-connector. Flera tags kan ingå i samma mappningsgrupp och publiceras via ett enda MQTT-objekt.

Rekommendation: En mappningsgrupp som innehåller alla relevanta tags, publicerad via ett MQTT-objekt, fungerar bra i de flesta fall och förenklar konfigurationen.

5.2 JSON-mall för publicering (Publish)

Följande mall har bekräftats fungera för publicering till Yggio:

{
  "t": "adstwincat",
  "v": %VALUE%,
  "tag": "%ITEM_SENDER.NAME%",
  "type": "%ITEM_SENDER.TYPE%",
  "ts": "%VALUE.EPOCH_TIME_MS%",
  "unit": "%ITEM_SENDER.UNIT%",
  "d": "%ITEM_SENDER.DESCRIPTION%"
}

Obs: "t" väljer vilken parser Yggio använder på meddelandet, inte källprotokollet. Yggio accepterar två värden: "adstwincat" för mallen ovan och "bacnet" för BACnet-mallen. Ett källprotokoll utan egen mall, Modbus TCP inräknat, publiceras genom ett av dessa två. Sätt inte "t" till protokollnamnet: ett okänt värde avvisas och meddelandet går förlorat.

⚠️ %ITEM_SENDER.TYPE% löses endast upp för ADS – den returnerar en tom sträng för BACnet- och Modbus TCP-källor. Lösning: hårdkoda typvärdet direkt i mallen, t.ex. "type":"10", istället för att förlita dig på %ITEM_SENDER.TYPE% för icke-ADS-mappningar.

Alternativ för tidsstämpel:

• %VALUE.EPOCH_TIME_MS% – returnerar epoch-tid i millisekunder. Fungerar korrekt med livedata.
• %TIME% – returnerar serverns lokala tid (fungerar).
• %ITEM.VALUE.TIME% – returnerar epoch 0 om värdet är inaktuellt eller i demoläge. Undvik i produktion.

5.3 Känd bugg – % i unit-fältet

⚠️ Tillfällig notering – ta bort när buggen är åtgärdad

Sätt aldrig ett %-tecken i en tags unit-fält (t.ex. för relativ luftfuktighet) – det kraschar SIA:s mallparser.

Lösning: Sätt enheten till pct eller lämna fältet tomt.
Rapporterat till SIA Connect-supporten. Se den begränsade referensen för varför detta händer.

5.4 Styrsignaler och börvärden – Subscribe

Tags som SIA ska ta emot kommandon för (t.ex. en körsignal eller ett börvärde från Yggio) konfigureras som Subscribe-mappningar, med readwrite=0 (Read & Write – se 4.7) i CSV:n.

En styrsignals-tag behöver vanligtvis två mappningar:

1. Publish – skickar det aktuella värdet ut till Yggio (så att det mottagande systemet kan se det aktuella tillståndet)
2. Subscribe – lyssnar efter inkommande kommandon från Yggio och skriver dem till PLC:n

Exempel – börvärdesleverans per byggnad (Bastec GT51)

Fastighetsnamnen och tags nedan är hämtade från Example1-projektet och behålls som ett konkret arbetsexempel – den underliggande mappningsmekanismen gäller oavsett kund eller fastighet.

Skärmbilden nedan visar en uppsättning Subscribe-mappningar där börvärden (t.ex. justeringar av värmekurvan) tas emot från Yggio och skrivs till skrivtags i SIA, som i sin tur levererar dem till varje byggnads styrsystem.

Så fungerar det:

• Sender – ett Yggio-objekt inom en Subscribe-connector (t.ex. SubscribeExample1Yggio). Detta är datapunkten i Yggio som håller det inkommande värdet.
• Receiver – motsvarande skrivtag i SIA, vars variable_name mappas mot den faktiska PLC-variabeln.
• Value: Direct parsing – värdet skickas igenom oförändrat, utan någon mallomvandling.

Sender (Yggio-objekt)	Receiver (SIA-skrivtag / PLC-variabel)
10001, Example Street 23 5601	F10001_EXAMPLE_STREET_23_5601.GT51_curveConf.rAdj
10002 Example Hall rad	F10002_EXAMPLE_HALL_5602.GT51_curveConf.rAdj

Varje rad är en separat mappningspost. Sändare och mottagare är länkade en-till-en – ett Yggio-objekt skriver till en SIA-skrivtag per fastighet/byggnadssystem.

Varje skrivtag måste vara förkonfigurerad i SIA med readwrite=0 (Read & Write – se 4.7) och korrekt variable_name som matchar PLC-variabeln innan Subscribe-mappningen kan skapas.

Post-processing på Subscribe-objekt

Varje Subscribe-objekt kräver en post-processing-sträng så att SIA vet vilket fält som ska extraheras ur Yggios inkommande JSON-nyttolast. Utan den tar SIA emot hela JSON-objektet men kan inte tolka ut det faktiska värdet.

Formatet är:

%VALUE.iotnode.<description>%

Där <description> matchar tagens description-fält – det vill säga NODA:s fältnamn (t.ex. supplytemp_sec_offset).

Exempel:

%VALUE.iotnode.supplytemp_sec_offset%

Detta måste sättas på varje objekt i en Subscribe-instans.

MQTT-topicformat för Subscribe-objekt

Topicformatet för Subscribe-objekt skiljer sig från Publish. Det tillhandahålls av Yggio och följer detta mönster:

yggio/output/v2/<recipient_id>/iotnode/<node_id>

Den fullständiga topicen hittas på objektets konfigurationssida i SIA när Yggio-noden väl finns. Varje objekt har sin egen unika topic.

5.5 Store and Forward

Store and Forward är en SIA-inställning som buffrar data lokalt när MQTT-anslutningen är nere, och sedan tömmer bufferten när anslutningen återställs.

• Aktiverad: Ingen data går förlorad vid driftstopp, men återanslutningar kan bli instabila under vissa förhållanden (se den begränsade referensen).
• Inaktiverad: Data som missas under ett driftstopp går förlorad, men återanslutningarna är rena.

För sensordata som skickas till NODA eller liknande system är det generellt säkert att inaktivera Store and Forward – det aktuella värdet väger tyngre än att fylla igen historiska luckor.

Inaktivera inte Store and Forward på mappningar där datakontinuitet är kritisk och det mottagande systemet inte tål luckor.

6. Konfiguration mot NODA Energy View

6.1 Bakgrund

NODA Energy View tar emot data via Yggio. I Yggio representeras varje mätpunkt eller enhet som en nod (thing), och nodtypen avgör vilka fält, metadata och konfigurationssteg som krävs.

Namnen och värdena i exemplen nedan (t.ex. 10002, Example Street...) är bara ett exempel på hur det kan se ut – inte en obligatorisk namngivningskonvention. Ditt projekts namngivning kommer att skilja sig.

---

6.2 Tre nodtyper

Det finns tre nodtyper som används i NODA-integrationen:

Typ	Riktning	Beskrivning
Building	-	Föräldranod som representerar en byggnad/krets. Håller den thingUUID som alla andra noder refererar till
Kontroll-/läsnod	SIA → NODA	Mät- eller statusdata som skickas från SIA till NODA (temperaturer, flöden, statussignaler)
Rumsgivare	SIA → NODA	Inomhusgivare (temperatur) länkad till en byggnad via newChildren

Återskrivning (börvärden från NODA → SIA) hanteras via en kanal på byggnadsnoden – inte en separat nodtyp.

---

6.3 Byggnadsnod (Building)

En byggnadsnod är föräldern som alla andra noder för en given krets refererar till via thingUUID.

Fält att sätta manuellt:

Fält	Värde
nodaDeviceType	building
device	Kelp-Basic
contextMap.connectNODAEnergyView	<connectNODAEnergyView_id> (Example1-projektet)
dataif	Kretsidentifierare, t.ex. 10002_AS02

Se respektive tag-lista för namngivningen som ska användas här.

Efter att dessa fält har patchats genererar NODA automatiskt en thingUUID för byggnaden inom ~10 minuter. Denna UUID används sedan när kontrollnoder och rumsgivare länkas.

Exempelresultat:

{
  "name": "10002, Example Street 1 F-5601 del2",
  "nodaDeviceType": "building",
  "device": "Kelp-Basic",
  "dataif": "10002_AS02",
  "contextMap": { "connectNODAEnergyView": "<connectNODAEnergyView_id>" },
  "thingUUID": "<building_thingUUID>"
}

---

6.4 Kontroll-/läsnoder

Dessa noder bär mätdata från SIA till NODA (t.ex. utomhustemperatur, tilloppstemperatur, ventilläge). De skapas automatiskt i Yggio när SIA börjar publicera, förutsatt att tagen har ett icke-tomt description-fält.

Krav på SIA-tag:

• description måste matcha NODA:s interna fältnamn (t.ex. outdoortemp) – detta är vad som visas som fältnamn på noden i Yggio och NODA
• readwrite=1 (Read only – se 4.7)

När noden väl visas i Yggio, uppdatera den med byggnadens thingUUID och contextMap med PUT /api/iotnodes/<node_id>:

{
  "contextMap": { "connectNODAEnergyView": "<connectNODAEnergyView_id>" },
  "thingUUID": "<building_thingUUID>"
}

Exempel på noderesultat:

{
  "name": "F10002_EXAMPLE_VS1_GT41_UTE_PV",
  "contextMap": { "connectNODAEnergyView": "<connectNODAEnergyView_id>" },
  "thingUUID": "<building_thingUUID>"
}

---

6.5 Write-back (börvärden från NODA till SIA)

NODA skriver börvärden (t.ex. offset för tilloppstemperatur) tillbaka till byggnaden via kanal-mekanismen på byggnadsnoden i Yggio. Detta är ingen separat nod – värdet hamnar på själva byggnadsnoden och SIA läser det via en Subscribe-mappning.

⚠️ Skriv-/börvärdesnoder (t.ex. supplytemp_sec_offset) får aldrig ha contextMap eller thingUUID satt direkt på sig. Värdet levereras via byggnadsnodens kanal; att patcha skrivnoden själv bryter mekanismen.

Steg 1 – Konfigurera taggen i SIA

• readwrite: Read & Write (CSV-värde 0 – se 4.7)
• description: Måste matcha NODA:s fältnamn exakt (t.ex. supplytemp_sec_offset)

För en Modbus-skrivtag som supplytemp_sec_offset behövs ingen post-processing – värdet skickas igenom direkt.

Steg 2 – Sätt upp en kanal på byggnadsnoden i Yggio

Gå till Channels på byggnadsnoden i Yggio och lägg till en MQTT-kanal. Den resulterande topicen följer detta mönster:

yggio/output/v2/<recipient_id>/iotnode/<building_node_id>

Kanalen behöver en Basic Credential Set (ett ID plus användarnamn/lösenord) för autentisering. Se Yggios Generic MQTT Connector-dokumentation för hur du skapar en via Swagger-API:et.

Denna topic används sedan som MQTT-topic på motsvarande Subscribe-objekt i SIA.

Steg 3 – Konfigurera Subscribe-objektet i SIA

Kopiera konfigurationen från ett befintligt Subscribe-objekt. Det kritiska fältet är post-processing-strängen, som måste sättas på varje objekt:

%VALUE.iotnode.supplytemp_sec_offset%

Ersätt supplytemp_sec_offset med description-fältet för den specifika taggen.

Både en Publish-mappning (aktuellt värde → Yggio) och en Subscribe-mappning (inkommande kommando → PLC) behövs för varje börvärdes-tag. Se avsnitt 5.4.

---

6.6 Rumsgivare

Rumsgivare (inomhus temperaturgivare via Webport/Elvaco) kräver att alla fyra fält sätts manuellt innan NODA genererar en thingUUID.

Fält att sätta manuellt:

Fält	Värde
nodaDeviceType	sensor/indoor
device	Generic Indoor Sensor
contextMap.connectNODAEnergyView	<connectNODAEnergyView_id> (Example1-projektet)
dataif	Tag-namn (t.ex. F10003_EXAMPLE_SENSOR_GT35_PV1)

Efter patchning genererar NODA automatiskt en thingUUID inom ~10 minuter. Samla in alla genererade thingUUID-värden och lägg till dem på föräldrabyggnadens nod via newChildren[].

Exempel på noderesultat:

{
  "name": "F10003_EXAMPLE_SENSOR_GT35_PV1",
  "nodaDeviceType": "sensor/indoor",
  "device": "Generic Indoor Sensor",
  "dataif": "F10003_EXAMPLE_SENSOR_GT35_PV1",
  "contextMap": { "connectNODAEnergyView": "<connectNODAEnergyView_id>" },
  "thingUUID": "<room_sensor_thingUUID>"
}

---

6.7 Länka rumsgivare till en byggnad – newChildren

⚠️ Kritiskt: newChildren ersätter hela barnlistan – den lägger inte till. Bekräfta alltid den fullständiga aktuella listan av barn-thingUUID:er innan du skickar en uppdatering. Att utelämna även en enda bryter tyst börvärdesstyrningen för hela byggnaden, utan felmeddelande vid tillfället det sker. Se den begränsade procedurreferensen (kontakta supportteamet) för den säkra uppdateringssekvensen.

---

6.8 Referens för nyckelfält

Fält	Betydelse
thingUUID	Identifierar vilken byggnad en nod tillhör. Alltid utanför contextMap
contextMap.connectNODAEnergyView	Identifierar vilken Energy View i NODA. Konstant per projekt
dataif	Används av NODA för att identifiera noden internt
newChildren[]	Registrerar rumsgivarnas thingUUID på en byggnadsnod. Ersätter alla – inkludera alla på en gång

connectNODAEnergyView är konstant per NODA-projekt. Ett annat projekt (annan kund eller NODA-instans) har sitt eget ID.

---

6.9 Ställa in nodfält

Identitetsfält för byggnads-/kontrollnoder (contextMap, thingUUID) sätts via Yggios API – inte en självbetjänings-åtgärd i gränssnittet. Kontakta supportteamet för åtkomst till den begränsade procedurreferensen.

---

6.10 Dataluckor i NODA

NODA har sin egen interna pollningscykel och kan missa avläsningar oberoende av om SIA→Yggio-leveransen fungerar korrekt. Se avsnitt 8.4 för vad du ska göra om du upptäcker luckor.

---

7. Watchdog – metoder och fallgropar

Watchdogs är valfria och kundspecifika – inte alla integrationer behöver en, och kunder som vill ha en kan vilja ha den implementerad på olika sätt. Mönstret nedan är ett konkret exempel från ett projekt, inte en standarddel av SIA/Yggio/NODA-uppsättningen.

7.1 Varför Watchdog?

I integrationer där ett externt system skickar styrsignaler till en DUC behövs ett sätt att upptäcka om kommunikationskedjan har brutits. Utan en watchdog kan DUC:n fortsätta agera på en gammal styrsignal istället för att falla tillbaka till lokal styrning.

7.2 Keep Alive som en passiv watchdog

MQTT Keep Alive (rekommenderat: 30 s) fungerar som en indirekt watchdog för MQTT-anslutningen. Om brokern inte hör från SIA inom Keep Alive-perioden betraktas klienten som frånkopplad. Notera att detta bara påverkar anslutningslagret – det påverkar inte direkt applikationslogik som räknarmönstret nedan.

7.3 Exempel: räknarmönster (Example2-projektet)

Denna specifika implementation används i Example2-projektet och kommer sannolikt inte att återanvändas som den är någon annanstans:

Energy Opticon → Yggio → SIA → DUC (tar emot räknare)
                                 ↓
Energy Opticon ← Yggio ← SIA ← DUC (returnerar räknare)

1. Energy Opticon skickar en inkrementerad watchdog-räknare via Yggio och SIA till DUC:n
2. DUC:n tar emot räknaren och returnerar den via Modbus/SIA/Yggio tillbaka till Energy Opticon
3. Energy Opticon flaggar kommunikationen som bruten om räknaren inte har inkrementerats inom projektets konfigurerade timeout (detta projekt använder ~15 minuter – valt utifrån detta systems risktolerans, inte en plattformsstandard)
4. DUC:n faller tillbaka till lokal styrning om den inte tar emot en uppdaterad räknare inom samma tidsfönster

---

8. Felsökning

8.1 Modbus

Symptom	Möjlig orsak	Åtgärd
Alla värden noll eller konstanta	Fel register (offset)	Verifiera register mot dokumentationen, prova ±1
Anslutning nekad	Fel IP, port eller Server ID	Kontrollera nätverksåtkomst och inställningar
Värde med orimlig magnitud	Fel datatyp (t.ex. INT16 vs FLOAT)	Kontrollera manualen för registertyp
Värde konsekvent fel med en faktor	Skalfaktor ej hanterad	Lägg till post-processing

8.2 Beckhoff / ADS

Symptom	Möjlig orsak	Åtgärd
Target port not found	SIA inte med i TwinCATs statiska rutter	Lägg till SIA:s AMS Net ID på PLC:n
Target port not found	TwinCAT-runtime körs inte	Starta TwinCAT på PLC:n
Ansluten men inga värden	Fel AMS-port (801 vs 851)	Kontrollera TC-version (TC2=801, TC3=851)

8.3 MQTT / Yggio

Symptom	Möjlig orsak	Åtgärd
Data publiceras inte	Ingen connector i Yggio fångar upp topicen, eller ogiltiga MQTT-uppgifter (se 3.1)	Kontrollera att en connector finns för siaconnect/<UUID> och att dess UUID matchar topicen
Tag skapar ingen nod i Yggio	Fältet description är tomt	Säkerställ att taggen har ett icke-tomt description
Tag skapar ingen nod i Yggio	Tag-värdet är 0 vid första publiceringen	Noden kan visas när ett icke-nollvärde tas emot; kontrollera annars description
Meddelandeflod (spam)	trigger_behaviour=1 (All) med kort intervall	Byt till All changes eller öka intervallet
Meddelandeflod (Beckhoff/ADS)	ADS push-läge kringgår läsintervallet	Sätt ett kort read_interval på enskilda tags; överväg att byta till trigger behaviour All changes
Meddelandeflod	Watchdog-omstart var ~7:e minut	Se avsnitt 7, justera Keep Alive
Bufferdump vid återanslutning orsakar flod	Store and Forward aktiverat	Inaktivera Store and Forward på mappningen

8.4 NODA Energy View

Symptom	Möjlig orsak	Åtgärd
Luckor/saknade datapunkter i NODA	NODA har sin egen interna pollningscykel och kan missa cykler även när SIA→Yggio-leveransen fungerar	Prova att sänka läsintervallet i SIA (t.ex. ner till ~2 minuter) för de berörda tagsen

---

9. Begränsningar

Begränsning	Beskrivning	Lösning
% i unit-fältet	Kraschar mallparsern	Använd pct eller lämna tomt
Namnbyte på ett objekt skapar en ny Yggio-nod	Fältet name är nodens identifierare – namnbyte genererar en ny nod och lämnar den gamla föräldralös i Yggio	Se till att namngivningen är korrekt innan anslutning till Yggio; städa bort gamla noder manuellt om ett namnbyte inte kan undvikas
Mappningar exporteras inte	CSV-export inkluderar bara objekt, inte mappningslogik	Dokumentera mappningar manuellt
Registeroffset varierar	Offset ±1 (eller annat) beror på tillverkare	Verifiera mot faktisk data vid driftsättning
Max 500 tags per gateway	Hård gräns på själva SIA Connect Edge Gateway	Planera antal gateways mot totalt antal tags vid omfattningsplanering – en stor fastighet kan behöva mer än en gateway

---

10. Rekommendationer

• Läsintervall: Minst 10 minuter rekommenderas för att undvika onödig trafik och belastning. Om du ser dataluckor specifikt i NODA, se avsnitt 8.4.
• Trigger behaviour: Välj utifrån det mottagande systemets krav – det finns inget universellt korrekt svar
• Post-processing: Lägg bara till om en omvandling faktiskt behövs
• Dokumentera alltid: IP, port, Server ID, register/variabler, datatyp, skalfaktor, offset

---

Senast uppdaterad: 2026-07-21
Detta dokument uppdateras löpande i takt med att nya konfigurationer bekräftas.