Writing values

Tags are not only read. Values also go in through the same tag — and, where it is set up that way, out to the machine. There is exactly one route for it. Capture, a machine over the interface, a script and the AI all use it; nobody has their own.

Which tags accept a value

Kind	Writing
Memory tag	accepts the value and holds it
Connector tag	accepts the value; with direction out it goes to the machine
Script tag	hands the value to the script, if one is set up for it
Record tag, whole type	appends a record
Record tag, one field	is refused
Query tag	is refused

The two refusals are deliberate, not a gap: a derived tag does not own its value. A written value there would be a second truth that the next read refutes. So it is refused out loud rather than silently dropped — somebody writing into the void has to be told.

Writing by hand

The tag page offers Write value. The button next to it says what will happen:

• Record — the value is kept here. Recorded here. Nothing was sent to a machine.
• Send to the machine — the value goes out.

Before sending, TrakState asks and names the connection and the topic: Write {{value}} to “{{path}}”? This goes out over the connection “{{connection}}” to the topic “{{topic}}” and the machine acts on it. Recording something here is undoable bookkeeping; commanding a machine is not.

Direction

A connector tag has a Direction. It sits on the tag, not in the head of whoever writes:

Setting	Meaning
Reads from the machine	inbound
Writes to the machine	outbound
Both	both

The hint below states the consequence: A write to an outbound tag goes to the machine and fails if it does not arrive. An inbound tag only records.

No sending without an acknowledgement

A value that goes out has to answer whether it arrived.

• Arrived — the interface says Sent - the machine acknowledged it.
• Did not arrive — the write fails, and nothing is stored either. Otherwise the tag would show a setpoint the plant never received.
• No connector running — the write fails saying exactly that, rather than looking as though something happened.

An inbound tag stores and claims nothing. Every answer to a write says which of the two cases it was.

Writing into a record

A record tag at whole-record-type level takes a value object on write and creates a record from it. That is the route a capture mask takes. The record lands whole or not at all.

Four operations are possible: append (the default), update, deactivate and reactivate. There is no delete: captured records reference master-data rows, so deactivate is how something stops being used. An operation that only makes sense on a record tag is refused on any other tag rather than ignored.

For a record that was in transit for a long time — a device without a connection — the rule is: write what still fits; what no longer fits is dropped and named. Nineteen fields that still hold are worth more than no record at all. The live path stays strict, because somebody is standing at the mask.

Permissions and the audit trail

Writing values hangs on the data permission that every normal role holds. Creating and changing tags stays with the tenant administrator.

A written value produces no audit entry. It carries its own provenance — timestamp, quality, the writing party — and a connector delivering ten values a second would drown the configuration trail the audit exists to protect. Creating, changing and deleting a tag is recorded.

What is kept per tag is one current value. If you need a trend over long periods, build it with a query tag over your operational data.