Protokoll-Events
Protocol events enable the connection of VISIONWEB to external communication channels and systems. They respond to incoming messages, status changes, or data packets transmitted via supported protocols. In addition to simply triggering a flow, these events can carry additional information that is directly integrated into the processing. This allows workflows to not only be started but also dynamically supplied with relevant data. Protocol events are particularly suitable for integration scenarios in which VISIONWEB is to interact with other devices, controllers, or software solutions in the network.
Three main structural types can be distinguished:
This chapter describes only the basic event types of protocols, as well as their implementation and use in workflows. A detailed description of the individual protocols—including specific configurations and examples—can be found in the respective Connection articles, which are organized by structure type.
Byte structure

Example: Receiving a broker message
Generally, most protocol events – depending on the respective data protocol – are defined based on byte structures. Therefore, the event type in Visionweb is often "Received Bytes (Name)." This makes it clear that the trigger is always active when a data packet is received. The following protocols respond to this structure:
JSON-String-Struktur

Example: Receiving HTTP events with direct struct processing
In addition, the HTTP event has its own JSON event, which outputs the received JSON document directly as a string. This allows structured data to be used without additional conversion, for example, to read values or to pass them specifically to other workflow components.
Wildcard structure

Example: Receiving a changed data type via wildcard events
For data-type-dependent protocols such as OPC UA, Visionweb offers an additional wildcard structure. This allows any data type to be further processed in the workflow. However, the user must know exactly which OPC node they are accessing and what data type will result. This is the only way to ensure correct processing. This is also currently being used in NATS.IO.