SIA Connect

---

Table of Contents

1. Tools and Access
2. Hardware Installation in Customer IT Environment
3. General Configuration – SIA to Yggio
4. Tag Configuration in SIA
5. Forwarding Configuration to Yggio
6. Setup Towards NODA Energy View
7. Watchdog – Methods and Pitfalls
8. Troubleshooting
9. Limitations
10. Recommendations

---

1. Tools and Access

1.1 VPN

SIA Connect is installed inside the customer's building network and is normally not reachable directly from the internet. Remote access is provided via a VPN, which establishes an encrypted peer-to-peer tunnel to the device. Any VPN solution can be used.

Prerequisites:

• VPN client installed on the SIA device during commissioning
• Device added to the correct VPN network (organisation/customer)
• Access to the VPN management interface to register new devices

Without working VPN access, remote troubleshooting is practically impossible. Always verify that the VPN is functioning before leaving a site.

1.2 SIA Connect Web UI

SIA's configuration interface is accessed via a browser at the device's IP address, typically on port 80 or 443 depending on the installation.

1.3 Yggio

Yggio is the IoT broker that acts as the intermediary between SIA and downstream systems such as NODA Energy View or Energy Opticon. Access is via the Yggio web UI or REST API.

---

2. Hardware Installation in Customer IT Environment

SIA Connect requires the following network access:

Direction	Protocol	Destination	Port	Purpose
Outbound	MQTTS	mqtt.example1.yggio.net	8883	Publish data to Yggio
Outbound	HTTPS	Yggio REST API	443	Registration, configuration
Outbound	VPN	VPN server	(varies)	Remote access
Internal	Modbus TCP	DUC/PLC	502 (default)	Read/write registers
Internal	ADS	Beckhoff TwinCAT	48898	Read/write variables
Internal	BACnet/IP	BACnet devices	47808	Read/write objects

Note: All communication from SIA is outbound. SIA does not need to be reachable from the internet.

Initial commissioning: The gateway ships with a factory-default static IP for initial setup (also reachable via a direct USB-C connection). This must be changed to an address on the customer's network before deployment - see the vendor's hardware setup guide for the default IP and USB-C procedure.

---

3. General Configuration – SIA to Yggio

3.1 MQTT Connector

SIA communicates with Yggio via MQTTS (MQTT over TLS). Create an MQTT connector in SIA with the following settings:

Parameter	Value
Broker	ssl://<yggio_mqtt_broker>
Port	8883
Topic	siaconnect/<SIA_UUID>
Keep Alive	30 seconds (recommended)
QoS	0 or 1 depending on requirements

Authentication: The broker connection requires an MQTT username and password. These are not available in the SIA or Yggio UI - request them from the technical support team when setting up the connector. The broker will not accept a connection without a valid credential, regardless of topic name.

Note: Create the SIA Connect connector in Yggio before publishing. The connector carries the same <SIA_UUID>, and creating it is what sets up the queue and binding that siaconnect/<SIA_UUID> delivers into. Publish to the topic before the connector exists and the messages arrive nowhere, with nothing in Yggio to show for it. The topic is bound to that connector UUID, so it is not one of the topics that can be registered as a Reserved MQTT Topic.

Command support (optional): Enabling Yggio to publish commands/setpoints back to SIA (used by Subscribe mappings - see 5.4 and 6.5) requires a separate credential: the SIA Web Interface URL plus a SIA API username/password. Also not available in the UI - request via the technical support team when command support is needed.

3.2 SIA/Edge Gateway UUID

Every SIA instance has a unique UUID used as its identifier in the Yggio topic - called the SIA UUID in this doc, the Edge Gateway UUID in Yggio's own connector documentation. Same value, two names. The UUID is found in the SIA administration interface. Always document the UUID in the project's installation records.

3.3 Keep Alive

The Keep Alive value controls how often SIA sends a heartbeat to the broker to maintain the MQTT connection. 30 seconds is recommended based on experience. A value that is too high (e.g. 240 s) can cause the broker to consider the client disconnected, which in turn triggers unnecessary watchdog events and data buffering.

3.4 Execute on Startup

The Execute on startup setting on a mapping causes it to run immediately when SIA restarts, without waiting for the next scheduled trigger.

This setting is not enabled by default in our current installations. Enable it if there is a specific need to ensure published values are sent immediately on restart - for example, for control signals that might otherwise remain in the wrong state until the next read cycle.

---

4. Tag Configuration in SIA

Tags represent the data points SIA reads from (or writes to) a field system - for example temperatures, flow rates, or control signals. They can be configured via SIA's interface or imported as a CSV file.

4.1 Naming Conventions

Tag naming is decided by whoever sets up the tag list for that property - refer to the respective tag list rather than a fixed convention here.

⚠️ Renaming an item in SIA creates a new node in Yggio. The name field is used as the node identifier in Yggio. If you rename an existing item, SIA will start publishing under the new name and a brand new node will appear in Yggio - the old node is not updated or removed automatically. The old node will remain in Yggio under the previous name and must be cleaned up manually.

Get the naming right before connecting to Yggio, and avoid renaming items in production.

4.2 Trigger Behaviour and Log Condition

These two settings control when SIA forwards a value.

trigger_behaviour

Value	Meaning
1	All – sends on every read cycle regardless of change
2	All changes – sends only when the value has changed

Which should you use?

It depends on how frequently the customer or energy system needs data points:

• All changes (trigger_behaviour=2) is common and appropriate when you only want a value when something has actually changed - for example a temperature reading. Reduces unnecessary data traffic.
• All (trigger_behaviour=1) is used when the receiving system expects regular updates regardless of change - for example towards NODA Energy View, which needs frequent, periodic values for its energy analysis.

Always base this on what the receiving system requires. Discuss with the customer or system supplier (e.g. NODA, Energy Opticon) what data cadence they need.

Minimum Trigger Interval

A setting that forces a trigger to fire at a set interval even if the trigger behaviour condition has not been met - for example, if the value has not changed and All changes is active, the mapping will still fire once the interval expires.

In other words, it is a floor (minimum send frequency), not a ceiling. It ensures that stable or slowly-changing values are still sent periodically rather than going silent.

Useful when:

• Using All changes but the receiving system needs a regular heartbeat even when values are stable
• You want to guard against frozen/stale values appearing in the receiving system

This is not a rate limiter. It does not prevent a mapping from firing more frequently than the interval if the trigger behaviour condition is met.

---

4.3 Post-Processing

Post-processing is an optional script that runs on the read value before it is forwarded. It should only be used when a conversion is actually needed - for example if the PLC delivers a value in the wrong unit or scale.

Example 1 – Flow rate from m³/h to l/h:

value = value * 1000

Used when an energy system reports volume flow in m³/h but the receiving system expects l/h.

Example 2 – Scale factor for INT16:

value = value / 10

Used when a PLC delivers e.g. 237 to represent 23.7 °C (scale factor of 10 in the source system).

Post-processing is not needed if the value is already correctly scaled and in the right unit. Always check the source system's documentation (DUC manual, PLC register list) to determine whether a conversion is required.

---

4.4 Modbus TCP

Modbus TCP is one of the most common protocols in building systems. SIA reads and writes registers directly from/to a PLC or DUC over TCP/IP.

Settings per tag:

Parameter	Description
IP address	The PLC's IP address on the network
Port	Typically 502, but can vary (e.g. 503 for some devices)
Server ID / Unit ID	Typically 1, but depends on the device
Register type	3:XXXXX (Holding register) or 4:XXXXX (Input register) etc.
Data type	INT16, UINT16, FLOAT, BOOL etc.

Register offset:
Modbus register addresses in SIA Connect may differ from those listed in the device's documentation. It is common for an offset of ±1 to apply, but this is not universal - it varies between manufacturers and sometimes between devices.

Example: The Abelko UltraBase20 has an offset of -1, meaning register 01001 in the documentation is entered as 01000 in SIA Connect.

Always verify against actual read values if you are unsure. An incorrect offset will silently read the wrong register rather than producing an error.

Practical example – Abelko UltraBase20:

• IP: xxx.xx.xx.xxx, Port: 502, Server ID: 1
• Data type: INT16, scale factor 10 → post-processing: value = value / 10
• Register offset: -1 (documentation shows 01001 → enter 01000 in SIA)
• Note: some registers on this device may be FLOAT - check the manual

---

4.5 Beckhoff / TwinCAT ADS

ADS (Automation Device Specification) is Beckhoff's proprietary communication protocol.

Settings:

Parameter	Value / Description
TCP port	48898
AMS port	851 (TwinCAT 3) or 801 (TwinCAT 2)
AMS Net ID	Device IP address + .1.1, e.g. xxx.xx.xx.xxx.1.1

Prerequisite: SIA Connect's own AMS Net ID must be added as a static route in TwinCAT on the PLC. Without this, the connection will be refused.

⚠️ Instance timestamp must be set to "Local timestamp" (not "Server timestamp") on all Beckhoff TwinCAT instances. Using Server timestamp can cause a critical failure over time. Confirmed by SIA Connect support. See the restricted reference for details.

Common error: Target port not found - usually caused by:

• SIA not added to TwinCAT's static routes, or
• TwinCAT runtime not running on the PLC

Important – Subscription/push mode:
When using ADS, SIA operates in subscription/notification mode - TwinCAT pushes change notifications to SIA directly, rather than SIA polling at intervals. This means the read_interval setting does not rate-limit how often SIA receives (and forwards) updates from TwinCAT.

In practice this can result in very frequent MQTT publishes regardless of the configured read interval. Use the Minimum trigger interval setting on the mapping (see section 4.2) to limit publish frequency.

---

4.6 BACnet

BACnet/IP is used in some installations where the building control system exposes data via BACnet rather than Modbus or ADS. Confirmed working against a Siemens DUC.

Instance settings:

Parameter	Value / Description
Address	BACnet Device Instance ID of the target device
Mode	Gateway
Read interval	Minimum 60 seconds recommended - 2 seconds generates excessive traffic

BACnet IP setup:

Parameter	Value / Description
Port	47808 (BACnet standard - uses UDP, not TCP)
Network Interface	eth0 or eth1 depending on installation - if one doesn't work, try the other
Device Id	SIA Connect's own BACnet Device ID on the network. Must be unique - confirm with the DUC technician which IDs are already in use

Note: BACnet uses UDP port 47808. Firewall rules must explicitly allow UDP - TCP rules are not sufficient.

Address format per tag:

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

Example: (2100231)(0.43) = Device 2100231, Analog Input, instance 43.

BACnet object types confirmed in use:

Type number	Object type	Direction
0	Analog Input	Read only
1	Analog Output	Write
2	Analog Value	Read + Write (e.g. setpoints)
3	Binary Input	Read only
4	Binary Output	Write
5	Binary Value	Read + Write

Vendor-specific/proprietary object types (e.g. Siemens-specific types) are not covered here - they haven't been confirmed as needed in practice. Don't assume a proprietary type number works the same way across vendors; verify against the actual device before relying on one.

Data type and post-processing: Values confirmed as REAL for Siemens/BACnet installations - no post-processing or scaling required.

Subnets and discovery: BACnet relies on UDP broadcasts for device discovery, which does not cross subnet boundaries. If SIA Connect and the BACnet device are on different subnets, either a BBMD (BACnet Broadcast Management Device) or Foreign Device registration is required. Confirm with the network/DUC technician whether devices are on the same subnet.

---

4.7 Read/Write Direction

The readwrite field controls whether SIA reads a point, writes to it, or both. In the SIA UI this appears as a descriptive dropdown; in CSV import it's a numeric value.

UI label	CSV readwrite value	Meaning
Read only	1	SIA reads the point and publishes it to Yggio
Read & Write	0	Bidirectional - used for setpoint/control tags, which need both a Publish mapping (current value out) and a Subscribe mapping (incoming command in)

---

5. Forwarding Configuration to Yggio

5.1 Mapping Groups

In SIA, mappings link tags to an MQTT connector. Multiple tags can be part of the same mapping group and published via a single MQTT item.

Recommendation: One mapping group containing all relevant tags, published via one MQTT item, works well in most cases and simplifies the configuration.

5.2 JSON Template for Publishing (Publish)

The following template has been confirmed working for publishing to 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%"
}

Note: "t" selects which parser Yggio applies to the message, not the source protocol. Yggio accepts two values: "adstwincat" for the template above, and "bacnet" for the BACnet template. A source protocol without a template of its own, Modbus TCP included, is published through one of these two. Do not set "t" to the protocol name: an unrecognised value is rejected and the message is lost.

⚠️ %ITEM_SENDER.TYPE% only resolves for ADS - it returns an empty string for BACnet and Modbus TCP sources. Workaround: hardcode the type value directly in the template, e.g. "type":"10", instead of relying on %ITEM_SENDER.TYPE% for non-ADS mappings.

Timestamp options:

• %VALUE.EPOCH_TIME_MS% - returns epoch time in milliseconds. Works correctly with live data.
• %TIME% - returns the server's local time (works).
• %ITEM.VALUE.TIME% - returns epoch 0 if the value is stale or in demo mode. Avoid in production.

5.3 Known Bug – % in the Unit Field

⚠️ Temporary note - remove when the bug is fixed

Never put a % character in a tag's unit field (e.g. for relative humidity) - it crashes SIA's template parser.

Workaround: Set the unit to pct or leave the field empty.
Reported to SIA Connect support. See the restricted reference for why this happens.

5.4 Control Signals and Setpoints – Subscribe

Tags that SIA should receive commands for (e.g. a run signal or setpoint from Yggio) are configured as Subscribe mappings, with readwrite=0 (Read & Write - see 4.7) in the CSV.

A control signal tag typically needs two mappings:

1. Publish - sends the current value out to Yggio (so the receiving system can see the current state)
2. Subscribe - listens for incoming commands from Yggio and writes them to the PLC

Example – Setpoint delivery per building (Bastec GT51)

The property names and tags below are from the Example1 project, kept as a concrete worked example - the underlying mapping mechanism applies regardless of customer or property.

The screenshot below shows a set of Subscribe mappings where setpoints (e.g. heating curve adjustments) are received from Yggio and written to write tags in SIA, which in turn delivers them to each building's control system.

How it works:

• Sender - a Yggio item within a Subscribe connector (e.g. SubscribeExample1Yggio). This is the data point in Yggio that holds the incoming value.
• Receiver - the corresponding write tag in SIA, whose variable_name maps to the actual PLC variable.
• Value: Direct parsing - the value is passed through as-is, without any template transformation.

Sender (Yggio item)	Receiver (SIA write tag / PLC variable)
10001, Example Street 23 5601	F10001_EXAMPLE_STREET_23_5601.GT51_curveConf.rAdj
10002 Example Hall rad	F10002_EXAMPLE_HALL_5602.GT51_curveConf.rAdj

Each row is a separate mapping entry. The sender and receiver are linked one-to-one - one Yggio item writes to one SIA write tag per property/building system.

Each write tag must be pre-configured in SIA with readwrite=0 (Read & Write - see 4.7) and the correct variable_name matching the PLC variable before the Subscribe mapping can be created.

Post-processing on Subscribe Items

Every Subscribe item requires a post-processing string so that SIA knows which field to extract from Yggio's incoming JSON payload. Without it, SIA receives the full JSON object but cannot parse out the actual value.

The format is:

%VALUE.iotnode.<description>%

Where <description> matches the description field of the tag - i.e. the NODA field name (e.g. supplytemp_sec_offset).

Example:

%VALUE.iotnode.supplytemp_sec_offset%

This must be set on every item in a Subscribe instance.

MQTT Topic Format for Subscribe Items

The topic format for Subscribe items differs from Publish. It is provided by Yggio and follows this pattern:

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

<recipient_id> is the identity the channel publishes to - a user ID, client app ID or basic credentials set ID (see MQTT), not a Yggio instance identifier.

The full topic is found on the item's configuration page in SIA once the Yggio node exists. Each item has its own unique topic.

5.5 Store and Forward

Store and Forward is a SIA setting that buffers data locally when the MQTT connection is down, then flushes the buffer when the connection is restored.

• Enabled: No data is lost during outages, but reconnects can become unstable under certain conditions (see restricted reference).
• Disabled: Data missed during an outage is lost, but reconnects are clean.

For sensor data sent to NODA or similar systems, it is generally safe to disable Store and Forward - the current value matters more than filling historical gaps.

Do not disable Store and Forward on mappings where data continuity is critical and the receiving system cannot tolerate gaps.

6. Setup Towards NODA Energy View

6.1 Background

NODA Energy View receives data via Yggio. In Yggio, each measurement point or device is represented as a node (thing), and the node type determines what fields, metadata, and setup steps are required.

The names and values in the examples below (e.g. 10002, Example Street...) are just an example of what it can look like - not a required naming convention. Your project's naming will differ.

---

6.2 Three Node Types

There are three node types used in the NODA integration:

Type	Direction	Description
Building	-	Parent node representing a building/circuit. Holds the thingUUID all other nodes reference
Control/read node	SIA → NODA	Measurement or status data sent from SIA to NODA (temperatures, flows, status signals)
Room sensor	SIA → NODA	Indoor sensor (temperature) linked to a building via newChildren

Write-back (setpoints from NODA → SIA) is handled via a channel on the building node - not a separate node type.

---

6.3 Building Node

A building node is the parent that all other nodes for a given circuit reference via thingUUID.

Fields to set manually:

Field	Value
nodaDeviceType	building
device	Kelp-Basic
contextMap.connectNODAEnergyView	<connectNODAEnergyView_id> (Example1 project)
dataif	Circuit identifier, e.g. 10002_AS02

Refer to the respective tag list for the naming to use here.

After patching these fields, NODA will auto-generate a thingUUID for the building within ~10 minutes. This UUID is then used when linking control nodes and room sensors.

Example result:

{
  "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 Control / Read Nodes

These nodes carry measurement data from SIA to NODA (e.g. outdoor temperature, supply temperature, valve position). They are created automatically in Yggio when SIA starts publishing, provided the tag has a non-empty description field.

SIA tag requirements:

• description must match the NODA internal field name (e.g. outdoortemp) - this is what appears as the field name on the node in Yggio and NODA
• readwrite=1 (Read only - see 4.7)

Once the node appears in Yggio, update it with the building's thingUUID and contextMap using PUT /api/iotnodes/<node_id>:

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

Example node result:

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

---

6.5 Write-back (Setpoints from NODA to SIA)

NODA writes setpoint values (e.g. supply temperature offset) back to the building via the channel mechanism on the building node in Yggio. This is not a separate node - the value lands on the building node itself and SIA reads it via a Subscribe mapping.

⚠️ Write/setpoint nodes (e.g. supplytemp_sec_offset) must never have contextMap or thingUUID set on them directly. The value is delivered through the building node's channel; patching the write node itself will break the mechanism.

Step 1 – Configure the tag in SIA

• readwrite: Read & Write (CSV value 0 - see 4.7)
• description: Must match the NODA field name exactly (e.g. supplytemp_sec_offset)

For a Modbus write-tag such as supplytemp_sec_offset, no post-processing is needed - the value is passed straight through.

Step 2 – Set up a channel on the building node in Yggio

On the building node in Yggio, go to Channels and add an MQTT channel. The resulting topic will follow this pattern:

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

The channel needs a Basic Credential Set (an ID plus username/password) to authenticate. See the Yggio Generic MQTT Connector docs for how to create one via the Swagger API.

This topic is then used as the MQTT topic on the corresponding Subscribe item in SIA.

Step 3 – Configure the Subscribe item in SIA

Copy the setup from an existing Subscribe item. The critical field is the post-processing string, which must be set on every item:

%VALUE.iotnode.supplytemp_sec_offset%

Replace supplytemp_sec_offset with the description field of the specific tag.

Both a Publish mapping (current value → Yggio) and a Subscribe mapping (incoming command → PLC) are needed for each setpoint tag. See section 5.4.

---

6.6 Room Sensors

Room sensors (indoor temperature sensors via Webport/Elvaco) require all four fields to be set manually before NODA generates a thingUUID.

Fields to set manually:

Field	Value
nodaDeviceType	sensor/indoor
device	Generic Indoor Sensor
contextMap.connectNODAEnergyView	<connectNODAEnergyView_id> (Example1 project)
dataif	Tag name (e.g. F10003_EXAMPLE_SENSOR_GT35_PV1)

After patching, NODA auto-generates a thingUUID within ~10 minutes. Collect all generated thingUUID values and add them to the parent building node via newChildren[].

Example node result:

{
  "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 Linking Room Sensors to a Building – newChildren

⚠️ Critical: newChildren replaces the entire children list - it does not append. Always confirm the complete current list of child thingUUIDs before submitting an update. Omitting even one silently breaks setpoint control for the whole building, with no error at the time it happens. See the restricted procedure reference (contact the technical support team) for the safe update sequence.

---

6.8 Key Fields Reference

Field	Meaning
thingUUID	Identifies which building a node belongs to. Always outside contextMap
contextMap.connectNODAEnergyView	Identifies which Energy View in NODA. Constant per project
dataif	Used by NODA to identify the node internally
newChildren[]	Registers room sensor thingUUIDs on a building node. Replaces all - include all at once

connectNODAEnergyView is constant per NODA project. A different project (different customer or NODA instance) will have its own ID.

---

6.9 Setting Node Fields

Building/control-node identity fields (contextMap, thingUUID) are set via the Yggio API - not a self-service UI action. Contact the technical support team for access to the restricted procedure reference.

---

6.10 Data Gaps in NODA

NODA has its own internal polling cycle and can miss readings independently of whether SIA→Yggio delivery is working correctly. See section 8.4 for what to do if you notice gaps.

---

7. Watchdog – Methods and Pitfalls

Watchdogs are optional and customer-specific - not every integration needs one, and customers who want one may want it implemented differently. The pattern below is a concrete example from one project, not a standard part of the SIA/Yggio/NODA setup.

7.1 Why Watchdog?

In integrations where an external system sends control signals to a DUC, there needs to be a way to detect if the communication chain has broken. Without a watchdog, the DUC could continue acting on an old control signal instead of falling back to local control.

7.2 Keep Alive as a Passive Watchdog

MQTT Keep Alive (recommended: 30 s) acts as an indirect watchdog for the MQTT connection. If the broker does not hear from SIA within the Keep Alive period, the client is considered disconnected. Note that this only affects the connection layer - it does not directly affect application-level logic such as the counter pattern below.

7.3 Example: Counter Pattern (Example2 Project)

This specific implementation is used in the Example2 project and is unlikely to be reused as-is elsewhere:

Energy Opticon → Yggio → SIA → DUC (receives counter)
                                 ↓
Energy Opticon ← Yggio ← SIA ← DUC (returns counter)

1. Energy Opticon sends an incremented watchdog counter via Yggio and SIA to the DUC
2. The DUC receives the counter and returns it via Modbus/SIA/Yggio back to Energy Opticon
3. Energy Opticon flags the communication as broken if the counter has not incremented within the project's configured timeout (this project uses ~15 minutes - chosen for this system's risk tolerance, not a platform default)
4. The DUC falls back to local control if it does not receive an updated counter within that same window

---

8. Troubleshooting

8.1 Modbus

Symptom	Possible Cause	Action
All values zero or constant	Wrong register (offset)	Verify register against documentation, try ±1
Connection refused	Wrong IP, port, or Server ID	Check network access and settings
Value with unreasonable magnitude	Wrong data type (e.g. INT16 vs FLOAT)	Check manual for register type
Value consistently off by a factor	Scale factor not handled	Add post-processing

8.2 Beckhoff / ADS

Symptom	Possible Cause	Action
Target port not found	SIA not in TwinCAT's static routes	Add SIA's AMS Net ID on the PLC
Target port not found	TwinCAT runtime not running	Start TwinCAT on the PLC
Connected but no values	Wrong AMS port (801 vs 851)	Check TC version (TC2=801, TC3=851)

8.3 MQTT / Yggio

Symptom	Possible Cause	Action
Data not being published	No connector in Yggio is picking up the topic, or an invalid MQTT credential (see 3.1)	Check that a connector exists for siaconnect/<UUID> and that its UUID matches the topic
Tag does not create a node in Yggio	description field is empty	Ensure the tag has a non-empty description
Tag does not create a node in Yggio	Tag value is 0 on first publish	Node may appear once a non-zero value is received; or check description
Message flood (spam)	trigger_behaviour=1 (All) with short interval	Switch to All changes or increase interval
Message flood (Beckhoff/ADS)	ADS push mode bypasses read interval	Set a short read_interval on individual tags; consider switching to All changes trigger behaviour
Message flood	Watchdog restart every ~7 minutes	See section 7, adjust Keep Alive
Buffer dump on reconnect causing flood	Store and Forward enabled	Disable Store and Forward on the mapping

8.4 NODA Energy View

Symptom	Possible Cause	Action
Gaps / missing data points in NODA	NODA has its own internal polling cycle and can miss cycles even when SIA→Yggio delivery is fine	Try lowering the read interval in SIA (e.g. down to ~2 minutes) for the affected tags

---

9. Limitations

Limitation	Description	Workaround
% in unit field	Crashes the template parser	Use pct or leave empty
Renaming an item creates a new Yggio node	The name field is the node identifier - renaming generates a new node and leaves the old one orphaned in Yggio	Get naming right before connecting to Yggio; clean up old nodes manually if a rename is unavoidable
Mappings not exported	CSV export includes items only, not mapping logic	Document mappings manually
Register offset varies	Offset ±1 (or other) depends on manufacturer	Verify against actual data during commissioning
500 tags max per gateway	Hard limit on the SIA Connect Edge Gateway itself	Plan gateway count against total tag count during scoping - a large property may need more than one gateway

---

10. Recommendations

• Read interval: A minimum of 10 minutes is recommended to avoid unnecessary traffic and load. If you're seeing data gaps in NODA specifically, see section 8.4.
• Trigger behaviour: Choose based on the receiving system's requirements - there is no universally correct answer
• Post-processing: Only add if a conversion is actually needed
• Always document: IP, port, Server ID, registers/variables, data type, scale factor, offset

---

Last updated: 2026-07-21
This document is updated continuously as new configurations are confirmed.