नोड संदर्भ

प्रयोग में रखे जा सकने वाले हर तरह के नोड, ऐड मेनू के समूहों में: क्रियाएँ, प्रतीक्षाएँ, एमुलेशन, फ़ॉल्ट, डेटा, जाँचें और फ़्लो। उन्हें जोड़ने और वायर करने का तरीका एडिटर में है; signallab nodes वही सूची JSON के रूप में छापता है, स्क्रिप्ट और सहायकों के लिए (कमांड लाइन)।

इस पेज को पढ़ना

हर नोड के फ़ील्ड की एक तालिका होती है:

फ़ील्ड प्रॉपर्टीज़ पैन का नाम है; फ़ाइल में प्रयोग के JSON की key है।
डिफ़ॉल्ट वह है जो एडिटर में नोड जोड़ते समय मिलता है। जहाँ फ़ाइल किसी key को छोड़ सकती है, तब उसका जो मान लिया जाता है, वह if absent के रूप में दिया है; बाकी keys फ़ाइल में ज़रूरी हैं।
टेम्पलेट: हाँ — फ़ील्ड {{templates}} लेता है: पैरामीटर, पहले सेट किए गए वेरिएबल, सीक्रेट और जनरेटर, जो चरण चलते समय हल होते हैं (डेटा और टेम्पलेट)। केवल पैरामीटर — यह पहले चरण से पहले खोला जाता है, जब केवल पैरामीटर ज्ञात होते हैं। नहीं — मान जैसा लिखा है वैसा ही लिया जाता है।

समय मिलीसेकंड में हैं। रन शुरू होने से पहले सीमाएँ जाँची जाती हैं; सीमा से बाहर का फ़ील्ड प्रयोग को चलने से रोकता है और नोड पर दिखाया जाता है।

फ़ाइल में एक नोड

प्रयोग फ़ाइल में नोड एक ऑब्जेक्ट है जिसमें id (प्रयोग में अद्वितीय), उसका type, कैनवास पर उसकी जगह (x, y, शून्य या अधिक), उसके फ़ील्ड, और वे सेटिंग्स होती हैं जो वह उपयोग करता है (retry, repeat, load, बंद होने पर छोड़ दी जाती हैं)। एक वायर एक नोड के आउटपुट (port, न हो तो next) से दूसरे नोड तक एक एज है:

json

{
  "nodes": [
    { "id": "start", "type": "start", "x": 40, "y": 80 },
    { "id": "ping", "type": "udp", "x": 270, "y": 80, "target": "127.0.0.1:9000", "text": "PING",
      "retry": { "attempts": 3, "delay_ms": 500, "backoff": "fixed" } },
    { "id": "end", "type": "end", "x": 500, "y": 80 }
  ],
  "edges": [
    { "from": "start", "to": "ping", "port": "next" },
    { "from": "ping", "to": "end", "port": "next" }
  ]
}

नीचे के उदाहरण एक-एक नोड दिखाते हैं, जैसा फ़ाइल उसे रखती है।

कई नोड की साझा सेटिंग्स

ये नोड की प्रॉपर्टीज़ के निचले हिस्से में चालू की जाती हैं। कौन-सा नोड कौन-सी लेता है, वह हर नोड के नीचे दिया है।

सेटिंग	कौन लेता है	यह क्या करता है
दोबारा प्रयास	जो नोड भेजते या सुनते हैं: HTTP रिक्वेस्ट, TCP संदेश, OSC संदेश, UDP डेटाग्राम, MQTT पब्लिश, WebSocket कनेक्ट, WebSocket भेजें, और हर प्रतीक्षा	चरण विफल होने पर फिर कोशिश करता है
दोहराव	जो नोड भेजते हैं: HTTP रिक्वेस्ट, TCP संदेश, OSC संदेश, UDP डेटाग्राम, MQTT पब्लिश, WebSocket भेजें	बार-बार भेजता है, कितनी बार या कितनी देर तक
लोड	HTTP रिक्वेस्ट	लोड प्रोफ़ाइल पर रिक्वेस्ट भेजता है, थ्रेशोल्ड से मापा और जाँचा जाता है
जवाब की प्रतीक्षा	OSC संदेश, UDP डेटाग्राम	उसी चरण में भेजता है और जवाब की प्रतीक्षा करता है

दोबारा प्रयास

विफल होने पर पुनः प्रयास करें: जब चरण विफल होता है — कोई कनेक्शन नहीं, टाइमआउट, या ऐसी प्रतीक्षा जिससे कुछ मेल नहीं खाता — तो वह रुकता है और फिर चलता है। हर असफल प्रयास टाइमलाइन में एक पंक्ति है; अंतिम प्रयास विफल होने पर चरण विफल होता है। जो टेम्पलेट हल नहीं हो सकता, उसे दोबारा नहीं आज़माया जाता। रोकें भी रुकावट समाप्त कर देता है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ
प्रयास	`retry.attempts`	कुल प्रयास, पहला मिलाकर	3; एडिटर में 2–10 (फ़ाइल 1 भी कह सकती है)
विराम, ms	`retry.delay_ms`	दूसरे प्रयास से पहले का विराम	500; 0–60 000
विराम	`retry.backoff`	एक जैसे (`fixed`): हर बार वही विराम; दोगुने होते (`exponential`): हर विफलता के बाद दुगुना लंबा	`fixed` (न हो तो भी)

कोई भी विराम 60 सेकंड से लंबा नहीं होता, चाहे वह कितना भी दुगुना हो। जिस प्रतीक्षा के टाइमआउट आउटपुट पर वायर हो, वह टाइमआउट पर विफल नहीं होती — वह उसी आउटपुट से निकल जाती है — इसलिए तब उसे दोबारा नहीं आज़माया जाता।

दोहराव

भेजना दोहराएँ: नोड बार-बार भेजता है — हार्टबीट, पोल, एक स्थिर धारा — ग्राफ़ में लूप के बिना। हर भेजाव अपने टेम्पलेट नए सिरे से पढ़ता है ({{counter}} उसका क्रमांक है, {{now}} उसका समय), और चालू होने पर दोबारा प्रयास हर भेजाव पर लागू होता है। जब हर भेजाव सफल होता है तब चरण सफल होता है; जो भेजाव पूरी तरह विफल होता है, चरण विफल कर देता है। टाइमलाइन सेकंड में अधिकतम एक बार प्रगति बताती है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ
दोहराव	`repeat.until`	तय संख्या में (`count`) या तय समय तक (`duration`)	`count` (न हो तो भी)
बार	`repeat.count`	कुल भेजाव, पहला मिलाकर	10 (न हो तो भी); 2–10 000
अवधि, ms	`repeat.duration_ms`	पहले भेजाव से कितनी देर भेजते रहना है	10 000 (न हो तो भी); 1–300 000
अंतराल, ms	`repeat.interval_ms`	दो भेजावों के बीच का विराम	1 000; 10–60 000; फ़ाइल में ज़रूरी
जिटर, ms	`repeat.jitter_ms`	हर विराम इतना तक लंबा, रन के सीड से निकाला	0 (न हो तो भी); 0–60 000

दोहराव एक रन के 300 सेकंड में फ़िट होने चाहिए, और किसी समय तक को 10 000 से कम भेजाव चाहिए (उसका समय अंतराल से भाग)।

लोड

लोड के तहत भेजें, केवल HTTP रिक्वेस्ट पर: रिक्वेस्ट एक प्रोफ़ाइल पर भेजी जाती है — एक स्थिर दर, एक रैंप, चरण, एक स्पाइक या रैंडम आगमन — एक साथ अधिकतम 512 चल रही (डिफ़ॉल्ट 32), और मापी जाती है: विलंब, त्रुटियाँ, हासिल दर। थ्रेशोल्ड तय करते हैं कि चरण सफल होता है या नहीं। लोड दोहराव और दोबारा प्रयास की जगह लेता है (विफल रिक्वेस्ट गिनी जाती है, दोबारा नहीं आज़माई जाती), और अपने बाद की जाँचों के लिए कोई रिस्पॉन्स नहीं छोड़ता। इसके फ़ील्ड और नतीजे लोड टेस्टिंग में हैं।

जवाब की प्रतीक्षा

जवाब की प्रतीक्षा करें, किसी OSC संदेश या UDP डेटाग्राम पर: संदेश उसी पोर्ट से भेजा जाता है जिस पर जवाब की प्रतीक्षा होती है, इसलिए जो डिवाइस भेजने वाले को जवाब देता है, वह सुनाई देता है, और चरण तभी सफल होता है जब समय पर मेल खाता जवाब आता है। जवाब न आने पर चरण विफल होता है — दोबारा प्रयास फिर भेजता है। जवाब एक वेरिएबल में सहेजा जाता है, जैसे प्रतीक्षा का होता है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
जवाब का पोर्ट (IP:port)	`reply.bind`	भेजने और सुनने का `IP:port`; पोर्ट 0 कोई भी ख़ाली पोर्ट ले लेता है	`0.0.0.0:0`	नहीं
जवाब का पता पैटर्न (OSC)	`reply.address`	जवाब का पता पैटर्न, जैसे OSC की प्रतीक्षा में	`/*`	हाँ
आर्ग्युमेंट नियम (OSC)	`reply.args`	आर्ग्युमेंट नियम, जैसे OSC की प्रतीक्षा में	कोई नहीं; अधिकतम 16	मान: हाँ
जवाब का पेलोड (UDP)	`reply.mode`	`any`, `contains`, `regex` या `hex` — देखें पेलोड मिलान	`any` (न हो तो भी)	नहीं
पैटर्न (UDP)	`reply.pattern`	जवाब में क्या होना या मेल खाना चाहिए	ख़ाली; `any` के अलावा ज़रूरी	हाँ
टाइमआउट, ms	`reply.timeout_ms`	कितनी देर प्रतीक्षा करनी है	2 000 (न हो तो भी); 1–120 000	नहीं
जवाब का वैरिएबल	`reply.variable`	जवाब जिस वेरिएबल में सहेजा जाता है	`reply` (न हो तो भी)	नहीं

जवाब का पोर्ट पहले चरण से पहले खोला जाता है, जैसे प्रतीक्षा का।

क्रियाएँ

जो नोड भेजते हैं। किसी क्रिया के बाद की प्रतीक्षा उस क्रिया के शुरू होने के क्षण से संदेश गिनती है।

HTTP रिक्वेस्ट

एक HTTP रिक्वेस्ट भेजता है और रिस्पॉन्स अपने बाद की जाँचों, ब्रांचों और मान निकालें नोड के लिए रखता है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
मेथड	`request.method`	GET, HEAD, POST, PUT, PATCH, DELETE या OPTIONS (फ़ाइल कोई भी मेथड कह सकती है)	`GET`	नहीं
URL	`request.url`	एक `http://` या `https://` URL	`http://127.0.0.1:8080/`	हाँ
टाइमआउट (ms)	`request.timeout_ms`	पूरे आदान-प्रदान के लिए	4 000 (न हो तो 10 000); 1–120 000	नहीं
रिक्वेस्ट हेडर	`request.headers`	`[[name, value], …]`; ख़ाली नाम वाली पंक्ति छोड़ दी जाती है	कोई नहीं	हाँ, नाम और मान
बॉडी	`request.body`	टेक्स्ट, या न हो तो `null`	`null`	हाँ
प्रमाणीकरण	`request.auth`	कोई नहीं, Basic, Bearer टोकन या Digest, उपयोगकर्ता नाम और पासवर्ड के साथ, या टोकन	कोई नहीं	हाँ

कोई भी जवाब चरण पास करा देता है, 404 और 500 भी: स्टेटस HTTP स्टेटस से जाँचें या स्टेटस पर शाखा से उस पर ब्रांच करें। जिस रिक्वेस्ट का कोई जवाब नहीं आता — अस्वीकार, टाइमआउट, ऐसा नाम जो हल नहीं होता, ऐसा सर्टिफ़िकेट जिस पर भरोसा नहीं — वह चरण विफल कर देती है।
रीडायरेक्ट का पीछा किया जाता है, अधिकतम दस। https:// सर्टिफ़िकेट सत्यापित होते हैं।
रिस्पॉन्स बॉडी जाँचों के लिए 256 KiB तक रखी जाती है; उससे बड़ी बॉडी वहीं काट दी जाती है (जब जो खोजा जा रहा हो वह कटाव के पार हो सकता है, तो जाँचें यह बताती हैं)।
Digest सर्वर की 401 चुनौती का जवाब देता है और रिक्वेस्ट फिर भेजता है। क्रेडेंशियल केवल रिक्वेस्ट में जाते हैं: चरण, रिपोर्ट और इंस्पेक्टर कभी Authorization हेडर नहीं दिखाते। पासवर्ड {{secret.NAME}} के रूप में लिखें।
जब तक प्रयोग कुकीज़ रखता है (डिफ़ॉल्ट रूप से चालू, पैरामीटर के नीचे), सर्वर जो सेट करते हैं वह रन की बाद की रिक्वेस्टों के साथ उन्हें वापस भेजा जाता है।

आउटपुट: आउटपुट। सेटिंग्स: दोबारा प्रयास, दोहराव, लोड।

json

{ "id": "cue", "type": "http", "x": 270, "y": 80,
  "request": { "method": "POST", "url": "{{api}}/cue", "headers": [["Content-Type", "application/json"]],
               "body": "{\"cue\": 1}", "timeout_ms": 5000,
               "auth": { "scheme": "bearer", "token": "{{secret.API_TOKEN}}" } } }

यह भी देखें HTTP।

TCP संदेश

TCP पर किसी होस्ट से कनेक्ट होता है, पेलोड लिखता है, जवाब के पहले बाइट के लिए अधिकतम 250 ms प्रतीक्षा करता है (अधिकतम 1 024 बाइट, एक बार पढ़ता है) और कनेक्शन बंद कर देता है। जवाब का आकार बताया जाता है, जाँचा नहीं जाता।

इंस्पेक्टर में चरण experiment स्रोत वाले दो tcp फ़्रेम हैं: लिखा गया पेलोड और, जब आया हो, पढ़ा गया जवाब। काम में लिए गए सीक्रेट दोनों में मास्क रहते हैं, जैसे किसी भी फ़्रेम में।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
होस्ट	`host`	होस्ट नाम या IP पता	`127.0.0.1`	हाँ
पोर्ट	`port`		9000; 1–65 535	नहीं
टाइमआउट (ms)	`timeout_ms`	कनेक्ट होने, लिखने और जवाब के लिए मिलाकर	4 000 (न हो तो भी); 1–120 000	नहीं
पेलोड	`payload`	कनेक्ट होने पर लिखा गया टेक्स्ट, UTF-8 के रूप में	`hello`	हाँ

कनेक्शन अस्वीकार होने, नाम हल न होने या समय बीत जाने पर चरण विफल होता है। आउटपुट: आउटपुट। सेटिंग्स: दोबारा प्रयास, दोहराव। अभी भेजें एक बार कनेक्ट होकर पेलोड लिखता है, और नोड का नतीजा बताता है कि कितने बाइट भेजे गए और वापस आए।

json

{ "id": "go", "type": "tcp", "x": 270, "y": 80, "host": "127.0.0.1", "port": 5000, "payload": "GO\r\n", "timeout_ms": 2000 }

OSC संदेश

UDP पर एक OSC 1.0 संदेश भेजता है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
लक्ष्य host:port	`target`	`IP:port` या `host:port`; होस्ट नाम चरण के भेजते समय हल होता है, IPv4 पता तब लिया जाता है जब उसके पास हो	`127.0.0.1:9000`	हाँ
OSC पता	`address`	`/` से शुरू होता है	`/test`	हाँ
आर्ग्युमेंट	`args`	`[{ "type", "value" }, …]` — `int`, `float`, `str`, `long`, `double`, `bool`, `blob` (बाइट), `nil` (कोई मान नहीं)	कोई नहीं	टेक्स्ट (`str`) मान: हाँ
जवाब की प्रतीक्षा करें	`reply`	वैकल्पिक: भेजें और जवाब की प्रतीक्षा करें — देखें जवाब की प्रतीक्षा	बंद

आउटपुट: आउटपुट; जवाब अपेक्षित होने पर उसका पीछा तभी किया जाता है जब जवाब आया हो। सेटिंग्स: दोबारा प्रयास, दोहराव, एक जवाब। ⚡ प्रॉपर्टीज़ में बाधा से होकर भेजें इसके आगे एक नेटवर्क बाधा रखता है।

json

{ "id": "fader", "type": "osc", "x": 270, "y": 80, "target": "{{device}}", "address": "/fader/1",
  "args": [{ "type": "float", "value": 0.75 }] }

यह भी देखें OSC।

UDP डेटाग्राम

एक टेक्स्ट पेलोड एक या अधिक टारगेट को एक UDP डेटाग्राम के रूप में भेजता है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
लक्ष्य host:port	`target`	`IP:port` या `host:port`; अल्पविराम, सेमीकोलन या नई पंक्तियों से अलग किए कई टारगेट को डेटाग्राम मिलता है। होस्ट नाम चरण के भेजते समय हल होता है, IPv4 पता तब लिया जाता है जब उसके पास हो	`127.0.0.1:9000`	हाँ
पेलोड	`text`	पेलोड, UTF-8 के रूप में	`hello`; अधिकतम 65 507 बाइट	हाँ
जवाब की प्रतीक्षा करें	`reply`	वैकल्पिक: भेजें और जवाब की प्रतीक्षा करें — देखें जवाब की प्रतीक्षा	बंद

अगर कोई भी टारगेट न पहुँच सके तो चरण विफल होता है। आउटपुट: आउटपुट। सेटिंग्स: दोबारा प्रयास, दोहराव, एक जवाब।

json

{ "id": "ping", "type": "udp", "x": 270, "y": 80, "target": "{{device}}", "text": "PING {{run.id}}",
  "reply": { "bind": "0.0.0.0:0", "mode": "contains", "pattern": "PONG", "timeout_ms": 1000, "variable": "pong" } }

MQTT पब्लिश

एक MQTT ब्रोकर से कनेक्ट होता है, एक संदेश पब्लिश करता है और डिस्कनेक्ट हो जाता है। कनेक्शन सादे TCP पर MQTT 3.1.1 है, क्लीन सेशन के साथ और बिना उपयोगकर्ता नाम या पासवर्ड। कनेक्ट होना, पब्लिश करना और ब्रोकर की पुष्टि — सब 15 सेकंड के भीतर होने चाहिए।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
ब्रोकर होस्ट	`host`	ब्रोकर का होस्ट नाम या पता	`127.0.0.1`	हाँ
पोर्ट	`port`		1883; 1–65 535	नहीं
टॉपिक	`topic`	कोई वाइल्डकार्ड नहीं (`+`, `#`)	`lab/test`	हाँ
पेलोड	`payload`	संदेश, टेक्स्ट के रूप में	`hello`	हाँ
QoS	`qos`	0, 1 या 2	0	नहीं
संदेश retain करें	`retain`	`true`: ब्रोकर इसे टॉपिक के मान के रूप में रखता है	`false`	नहीं

फ़ाइल में सभी छह key ज़रूरी हैं। जब ब्रोकर तक न पहुँचा जा सके या वह कनेक्शन या संदेश अस्वीकार कर दे, तो चरण विफल होता है। आउटपुट: आउटपुट। सेटिंग्स: दोबारा प्रयास, दोहराव।

json

{ "id": "light", "type": "mqtt", "x": 270, "y": 80, "host": "{{broker}}", "port": 1883,
  "topic": "lab/light/1/set", "payload": "on", "qos": 1, "retain": false }

यह भी देखें MQTT।

WebSocket कनेक्ट

बाकी रन के लिए, या किसी WebSocket बंद करें तक एक WebSocket खोलता है। उसके बाद जो आता है, वह उस पर के WebSocket की प्रतीक्षा चरणों के लिए रखा जाता है। URL और हेडर चरण के चलते समय हल होते हैं, इसलिए पहले निकाला गया टोकन उनमें हो सकता है। फिर चलाने पर — किसी लूप में — यह पहले अपना पिछला कनेक्शन बंद करता है और नया खोलता है। रन किसी भी तरह समाप्त होने पर उसके कनेक्शन एक क्लोज़ फ़्रेम के साथ बंद कर दिए जाते हैं।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
URL	`url`	एक `ws://` या `wss://` URL	`ws://127.0.0.1:9001/`	हाँ
रिक्वेस्ट हेडर	`headers`	अपग्रेड रिक्वेस्ट के साथ भेजे गए `[[name, value], …]`	कोई नहीं	हाँ, नाम और मान
सबप्रोटोकॉल	`protocols`	वरीयता के क्रम में देने के लिए सबप्रोटोकॉल; सर्वर एक चुनता है	कोई नहीं	नहीं
टाइमआउट (ms)	`timeout_ms`	कनेक्ट होने और अपग्रेड के लिए	5 000 (न हो तो 10 000); 1–120 000	नहीं

wss:// उन्हीं सर्टिफ़िकेट पर भरोसा करता है जिन पर https://। कनेक्शन या अपग्रेड विफल होने पर चरण विफल होता है; कारण में सर्वर का स्टेटस होता है। आउटपुट: आउटपुट। सेटिंग्स: दोबारा प्रयास (दोहराव नहीं)।

json

{ "id": "socket", "type": "ws_connect", "x": 270, "y": 80, "url": "ws://127.0.0.1:9001/chat",
  "headers": [["Authorization", "Bearer {{token}}"]], "protocols": ["chat.v1"], "timeout_ms": 5000 }

यह भी देखें WebSocket।

WebSocket भेजें

जिस कनेक्शन को WebSocket कनेक्ट ने खोला, उस पर एक संदेश भेजता है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
कनेक्शन	`connection`	इस प्रयोग के एक WebSocket कनेक्ट नोड की id	पहला	नहीं
फ़ॉर्मेट	`binary`	टेक्स्ट (`false`), या बाइनरी (hex) (`true`): पेलोड hex में लिखे बाइट हैं, `de ad be ef`	`false` (न हो तो भी)	नहीं
पेलोड	`text`	संदेश	`hello`; अधिकतम 16 MiB	हाँ

कनेक्ट उसके पाथ पर भेजाव से पहले आना चाहिए; जिस भेजाव का कनेक्शन खुला न हो, वह विफल होता है। जवाब संदेश लिखे जाने के क्षण से गिने जाते हैं। आउटपुट: आउटपुट। सेटिंग्स: दोबारा प्रयास, दोहराव।

json

{ "id": "hello", "type": "ws_send", "x": 500, "y": 80, "connection": "socket",
  "text": "{\"type\":\"ping\",\"id\":\"{{uuid}}\"}", "binary": false }

WebSocket बंद

क्लोज़ हैंडशेक के साथ कनेक्शन बंद करता है। टाइमलाइन बताती है कि इसे किसने बंद किया: यह चरण, पहले सर्वर (उसके कोड के साथ), या कोई कनेक्शन जो टूट गया था।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
कनेक्शन	`connection`	एक WebSocket कनेक्ट नोड की id	पहला	नहीं
क्लोज़ कोड	`code`	1000 (सामान्य), या किसी एप्लिकेशन के अपने के लिए 3000–4999	1000 (न हो तो भी)	नहीं
कारण	`reason`	कोड के साथ भेजा गया	ख़ाली; टेम्पलेट के बाद अधिकतम 123 बाइट	हाँ

आउटपुट: आउटपुट। कोई सेटिंग नहीं।

json

{ "id": "bye", "type": "ws_close", "x": 960, "y": 80, "connection": "socket", "code": 1000, "reason": "done" }

लॉग मार्कर

टाइमलाइन और रिपोर्ट में एक पंक्ति लिखता है — एक चेकपॉइंट, या वे मान जिन तक रन पहुँचा।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
संदेश	`message`	टेक्स्ट	`Check point`; अधिकतम 10 000 अक्षर	हाँ

आउटपुट: आउटपुट। कोई सेटिंग नहीं।

json

{ "id": "ready", "type": "log", "x": 500, "y": 80, "message": "device {{device}} ready" }

प्रतीक्षाएँ

निगरानी समूह: वे नोड जो किसी चीज़ के आने की प्रतीक्षा करते हैं। इनके ये साझा नियम हैं:

वे रन के शुरू से सुनते हैं। प्रतीक्षा का पोर्ट या ब्रोकर सब्सक्रिप्शन पहले चरण से पहले खोला जाता है, इसलिए जो डिवाइस अगले चरण के शुरू होने से तेज़ जवाब देता है, वह छूटता नहीं। एक ही पते पर दो प्रतीक्षाएँ एक ही सॉकेट साझा करती हैं।
वे अपनी ब्रांच पर नवीनतम क्रिया से गिनती करते हैं। जो संदेश ब्रांच की अंतिम रिक्वेस्ट से पहले आया, वह उसका जवाब नहीं है; किसी भी क्रिया से पहले, रन के शुरू होने के बाद का सब कुछ गिना जाता है।
पहला मेल खाता संदेश लिया जाता है। जो संदेश एक प्रतीक्षा ने ले लिया, वह दूसरी को दिखता नहीं।
मेल खाया या टाइमआउट। मेल खाने पर संदेश प्रतीक्षा के वेरिएबल में सहेजा जाता है और फ़्लो मेल खाया का पीछा करता है। समय बीत जाने पर वह टाइमआउट का पीछा करता है, अगर उस आउटपुट पर वायर हो; वरना चरण विफल होता है, और बताता है कि कितने और संदेश आए।
हर सॉकेट नवीनतम 1 024 संदेश (और 64 MiB) रखता है; पुराने छोड़ दिए जाते हैं, और टाइमआउट बताता है कि कितने छूटे।
अभी सुनें उसी एक चरण के साथ, अब से सुनता है।

आउटपुट: मेल खाया (ज़रूरी), टाइमआउट (वैकल्पिक)। सेटिंग्स: दोबारा प्रयास।

पेलोड मिलान

UDP की प्रतीक्षा, MQTT की प्रतीक्षा, WebSocket की प्रतीक्षा और एक UDP जवाब चुनते हैं कि पेलोड कैसा होना चाहिए:

विकल्प	फ़ाइल में	तब मेल खाता है जब पेलोड
कोई भी डेटाग्राम	`any`	कुछ भी हो
टेक्स्ट शामिल है	`contains`	UTF-8 टेक्स्ट के रूप में पढ़ा गया, पैटर्न रखता है (केस-संवेदी)
regex से मेल खाता है	`regex`	UTF-8 टेक्स्ट के रूप में पढ़ा गया, रेगुलर एक्सप्रेशन से मेल खाता है
बाइट शामिल हैं (hex)	`hex`	बाइट रखता है, hex जोड़ों में लिखे: `de ad be ef`, `deadbeef`, `0xde,0xad`, `DE:AD`

मेल खाया संदेश एक ऑब्जेक्ट के रूप में सहेजा जाता है। बाद के चरण उसके फ़ील्ड {{reply.text}} के रूप में पढ़ते हैं (वेरिएबल के नाम के साथ reply की जगह):

फ़ील्ड	क्या
`text`	पेलोड टेक्स्ट के रूप में
`hex`, `bytes`	पेलोड hex में (उसके पहले 1 024 बाइट), और बाइट में उसका आकार
`match`	जो मेल खाया: टेक्स्ट, रेगुलर एक्सप्रेशन का पहला ग्रुप (या पूरा मिलान), या बाइट
`from`	भेजने वाले का `IP:port`
`ms`	ब्रांच की नवीनतम क्रिया (या रन के शुरू) से संदेश तक के मिलीसेकंड
`topic`	MQTT की प्रतीक्षा: जिस टॉपिक पर इसे पब्लिश किया गया
`json`, `kind`	WebSocket की प्रतीक्षा: संदेश JSON के रूप में पार्स किया गया (`null` जब न हो), और `text` या `binary`

OSC की प्रतीक्षा

ऐसे OSC संदेश की प्रतीक्षा करता है जिसका पता किसी पैटर्न से मेल खाता हो और जिसके आर्ग्युमेंट हर नियम पूरा करते हों। बंडल में, जो पहला संदेश मेल खाता है, वही लिया जाता है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
सुनने का पता (IP:port)	`bind`	सुनने का `IP:port`; हर नेटवर्क कार्ड के लिए `0.0.0.0`	`127.0.0.1:9001`	नहीं
पता पैटर्न	`address`	`*` कोई भी अक्षर, `?` एक, `[0-9]` एक समूह (`[!0-9]` उससे बाहर), `{ping,pong}` दोनों में से कोई; वाइल्डकार्ड एक ही `/` सेगमेंट के भीतर रहते हैं	`/pong`; अधिकतम 512 अक्षर	हाँ
आर्ग्युमेंट नियम	`args`	`[{ "index", "op", "value" }, …]`: आर्ग्युमेंट `index` की तुलना `value` से `op` द्वारा (तुलनाएँ); सभी पूरे होने चाहिए	कोई नहीं; अधिकतम 16, index 0–63	मान: हाँ
टाइमआउट, ms	`timeout_ms`		2 000 (न हो तो भी); 1–120 000	नहीं
जवाब का वैरिएबल	`variable`	संदेश कहाँ सहेजा जाता है	`reply` (न हो तो भी)	नहीं

आर्ग्युमेंट की तुलना टेक्स्ट के रूप में होती है: संख्याएँ जैसी लिखी हैं, स्ट्रिंग बिना उद्धरण, true/false, blob hex में। जिस आर्ग्युमेंट पर नियम है और संदेश में वह नहीं है, वह पूरा नहीं होता। सहेजे गए संदेश में address, args ({{reply.args[0]}}), from और ms होते हैं।

json

{ "id": "status", "type": "wait_osc", "x": 500, "y": 80, "bind": "0.0.0.0:9001", "address": "/status",
  "args": [{ "index": 0, "op": "eq", "value": "ready" }], "timeout_ms": 5000, "variable": "reply" }

UDP की प्रतीक्षा

ऐसे UDP डेटाग्राम की प्रतीक्षा करता है जिसका पेलोड मेल खाता हो।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
सुनने का पता (IP:port)	`bind`	सुनने का `IP:port`	`127.0.0.1:9001`	नहीं
पेलोड	`mode`	देखें पेलोड मिलान	`contains` (न हो तो `any`)	नहीं
पैटर्न	`pattern`	पेलोड में क्या होना या मेल खाना चाहिए	`pong`; `any` के अलावा ज़रूरी	हाँ
टाइमआउट, ms	`timeout_ms`		2 000 (न हो तो भी); 1–120 000	नहीं
जवाब का वैरिएबल	`variable`		`reply` (न हो तो भी)	नहीं

json

{ "id": "ready", "type": "wait_udp", "x": 500, "y": 80, "bind": "0.0.0.0:9002", "mode": "contains",
  "pattern": "READY", "timeout_ms": 5000, "variable": "reply" }

MQTT की प्रतीक्षा

ब्रोकर पर किसी टॉपिक को पब्लिश किए गए ऐसे संदेश की प्रतीक्षा करता है जिसका पेलोड मेल खाता हो। रन अपने पहले चरण से पहले कनेक्ट होकर सब्सक्राइब करता है। सब्सक्राइब करते समय ब्रोकर जो retained संदेश दोहराता है, वे छोड़ दिए जाते हैं: केवल वही गिना जाता है जो रन शुरू होने के बाद पब्लिश हुआ।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
ब्रोकर होस्ट	`host`	ब्रोकर	`127.0.0.1`	केवल पैरामीटर
पोर्ट	`port`		1883; 1–65 535	नहीं
टॉपिक फ़िल्टर	`topic`	एक फ़िल्टर: `+` कोई भी एक लेवल, `#` उसके नीचे सब कुछ (केवल अंत में)	`lab/#`	केवल पैरामीटर
पेलोड	`mode`	देखें पेलोड मिलान	`any` (न हो तो भी)	नहीं
पैटर्न	`pattern`		ख़ाली; `any` के अलावा ज़रूरी	हाँ
टाइमआउट, ms	`timeout_ms`		2 000 (न हो तो भी); 1–120 000	नहीं
जवाब का वैरिएबल	`variable`		`reply` (न हो तो भी)	नहीं

json

{ "id": "state", "type": "wait_mqtt", "x": 500, "y": 80, "host": "{{broker}}", "port": 1883,
  "topic": "lab/+/state", "mode": "contains", "pattern": "on", "timeout_ms": 5000, "variable": "reply" }

HTTP रिक्वेस्ट की प्रतीक्षा

उस पते पर रन के एमुलेटर को आने वाली HTTP रिक्वेस्ट — वेबहुक, कॉलबैक — की प्रतीक्षा करता है, या, जब रन का वहाँ कोई HTTP एमुलेटर न हो, तो रन के अपने ऐसे लिसनर की जो हर रिक्वेस्ट को 204 से जवाब देता है। रिक्वेस्ट को मेथड, पाथ और हर शर्त से मेल खाना चाहिए।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
सुनने का पता (IP:port)	`bind`	`IP:port`	`127.0.0.1:18080` — जहाँ नया एमुलेटर सुनता है	नहीं
मेथड	`method`	एक मेथड, या कोई भी (`ANY`); GET HEAD भी लेता है	`ANY` (न हो तो भी)	नहीं
पाथ	`path`	`/hooks/:name` एक सेगमेंट को नाम देता है (`{{request.params.name}}`); अंत का `/*` बाकी सब लेता है	`/*` (न हो तो भी); अधिकतम 512 अक्षर	हाँ
शर्तें	`when`	किसी `header`, `query` पैरामीटर, `body` या `json` पाथ पर `[{ "on", "name", "op", "value" }, …]`; हर एक पूरा होना चाहिए	कोई नहीं; अधिकतम 16	हाँ, नाम और मान
टाइमआउट, ms	`timeout_ms`		5 000 (न हो तो 2 000); 1–120 000	नहीं
जवाब का वैरिएबल	`variable`		`request` (न हो तो भी)	नहीं

सहेजी गई रिक्वेस्ट में method, path, query, headers, body, json, params, from और ms होते हैं: {{request.json.event}}, {{request.headers.x-key}}।

json

{ "id": "hook", "type": "wait_http", "x": 500, "y": 80, "bind": "127.0.0.1:18081", "method": "POST",
  "path": "/hooks/:name", "when": [{ "on": "json", "name": "$.event", "op": "eq", "value": "deploy" }],
  "timeout_ms": 5000, "variable": "request" }

WebSocket की प्रतीक्षा

जिस कनेक्शन को WebSocket कनेक्ट ने खोला, उस पर आने वाले ऐसे संदेश की प्रतीक्षा करता है जिसका पेलोड मेल खाता हो। ब्रांच पर नवीनतम क्रिया के बाद के संदेश गिने जाते हैं — कनेक्ट ख़ुद, कोई भेजाव, या कोई और रिक्वेस्ट।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
कनेक्शन	`connection`	एक WebSocket कनेक्ट नोड की id	पहला	नहीं
पेलोड	`mode`	देखें पेलोड मिलान	`any` (न हो तो भी)	नहीं
पैटर्न	`pattern`		ख़ाली; `any` के अलावा ज़रूरी	हाँ
टाइमआउट, ms	`timeout_ms`		2 000 (न हो तो भी); 1–120 000	नहीं
जवाब का वैरिएबल	`variable`		`reply` (न हो तो भी)	नहीं

एक JSON संदेश फ़ील्ड दर फ़ील्ड पढ़ा जा सकता है: {{reply.json.type}}। कनेक्ट उसके पाथ पर प्रतीक्षा से पहले आना चाहिए।

json

{ "id": "pong", "type": "wait_ws", "x": 730, "y": 80, "connection": "socket", "mode": "contains",
  "pattern": "pong", "timeout_ms": 3000, "variable": "reply" }

एमुलेशन

एमुलेटर

पूरे रन के लिए एक डिपेंडेंसी निभाता है — HTTP API, OSC, UDP या TCP डिवाइस, MQTT ब्रोकर। यह पहले चरण से पहले खुलता है और रन समाप्त होने तक जवाब देता है; फ़्लो में चरण तुरंत सफल होता है। इसे जो मिला, वह रन की रिपोर्ट में नियम दर नियम गिना जाता है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट
संपादित करें…	`emulator`	एमुलेटर: `name`, `bind` (`IP:port`), `protocol` (`http`, `osc`, `udp`, `tcp`, `mqtt`), उसके रूट या नियम, और वैकल्पिक `outage`	`127.0.0.1:18080` पर API नाम का HTTP API जो `/health` का जवाब देता है

प्रॉपर्टीज़ एक पंक्ति में बताती हैं कि यह क्या निभाता है। संपादित करें… इसके नियम खोलता है, वही एडिटर जो एमुलेटर स्क्रीन का है; लाइब्रेरी में एमुलेटर लाइब्रेरी में एक कॉपी रखता है, और लाइब्रेरी से इसकी जगह उससे एक कॉपी ले आता है। नियम — रूट, रिस्पॉन्स, फ़ॉल्ट, आउटेज — वहीं बताए गए हैं।

एक HTTP एमुलेटर वही है जिसे उसके पते पर HTTP रिक्वेस्ट की प्रतीक्षा पढ़ती है; एक OSC या UDP एमुलेटर अपना पोर्ट वहाँ रन की प्रतीक्षाओं के साथ साझा करता है।
एक ही ट्रांसपोर्ट के दो एमुलेटर एक रन में एक पोर्ट साझा नहीं कर सकते।
एमुलेटर बंद/चालू इसे बंद करता है और वापस लाता है।

आउटपुट: आउटपुट। कोई सेटिंग नहीं।

json

{ "id": "api", "type": "emulator", "x": 270, "y": 80,
  "emulator": { "name": "Orders API", "bind": "127.0.0.1:18080", "protocol": "http",
    "routes": [{ "method": "GET", "path": "/orders/:id", "order": "sequence",
                 "responses": [{ "status": 503 }, { "status": 200, "body": "{\"id\":\"{{request.params.id}}\"}" }] }] } }

फ़ॉल्ट

वे नोड जो इशारे पर चीज़ें तोड़ते हैं। विलंब नोड की एक ब्रांच और ट्रैफ़िक के बगल में ये, मिलकर एक शेड्यूल जैसे पढ़े जाते हैं; शेड्यूल पर फ़ॉल्ट बताता है कि कैसे।

इम्पेयरमेंट

पूरे रन के लिए एक इम्पेयरमेंट रिले: जाँचे जा रहे सिस्टम असली टारगेट की जगह सुनने का पता को भेजता (या उससे कनेक्ट होता) है; रिले आगे भेजें तक अग्रेषित करता है, और जवाब उसी रास्ते वापस आते हैं, प्रोफ़ाइल से इम्पेयर किए हुए। यह पहले चरण से पहले खुलता है और रन किसी भी तरह समाप्त होने पर बंद हो जाता है, ताकि कुछ भी इम्पेयर न रहे; फ़्लो में चरण तुरंत सफल होता है। हर निर्णय रन के सीड से निकलता है: वही सीड और वही ट्रैफ़िक, वही अंजाम।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
सुनने का पता	`listen`	जाँचा जा रहा सिस्टम जिस `IP:port` पर भेजता है	`127.0.0.1:9010`	केवल पैरामीटर
आगे भेजें	`target`	असली गंतव्य का `IP:port`, या `host:port` — होस्ट नाम रन शुरू होते समय हल होता है, और जो नाम न मिल सके वह इस नोड पर रन रोक देता है	`127.0.0.1:9000`	केवल पैरामीटर
प्रोटोकॉल	`protocol`	UDP (`udp`): हर डेटाग्राम का अपना अंजाम होता है; TCP (`tcp`): हर कनेक्शन टारगेट तक अपने एक कनेक्शन से जोड़ा जाता है, और दोनों धाराएँ इम्पेयर होती हैं	UDP (न हो तो `udp`)	नहीं
प्रीसेट और उसके नीचे के मान	`profile`	रिले ट्रैफ़िक के साथ क्या करता है — देखें प्रोफ़ाइल	LAN (न हो तो कोई इम्पेयरमेंट नहीं)	नहीं

रिले का सुनने का पता रन का कोई और सॉकेट नहीं हो सकता, और रिले एक-दूसरे को गोल घेरे में अग्रेषित नहीं कर सकते। नाम से दिया टारगेट हल होते ही उसका पीछा किया जाता है, इसलिए किसी नाम से बना घेरा रन के शुरू होते ही उसे रोक देता है। रिपोर्ट रिले के हर चरण को अलग गिनती है।

आउटपुट: आउटपुट। कोई सेटिंग नहीं।

json

{ "id": "relay", "type": "impairment", "x": 270, "y": 80, "listen": "127.0.0.1:9010", "target": "{{device}}",
  "profile": { "name": "lan", "latency_ms": 1, "jitter_ms": 1 } }

प्रोफ़ाइल

एक प्रीसेट चिप — LAN, व्यस्त Wi-Fi, 4G, सैटेलाइट, रुक-रुक कर, ऑफ़लाइन — हर मान भर देती है; उसके बाद उनमें से कोई भी बदलें। रिले केवल अपने प्रोटोकॉल के मान पढ़ता है; फ़ाइल में हर key छोड़ी जा सकती है (शून्य, बंद)।

फ़ील्ड	फ़ाइल में	क्या	सीमाएँ	प्रोटोकॉल
—	`name`	टाइमलाइन और रिपोर्ट के लिए एक लेबल: किसी प्रीसेट की key (`lan`, `wifi`, `4g`, `satellite`, `intermittent`, `offline`) या आपकी अपनी	अधिकतम 60 अक्षर	दोनों
ऑफ़लाइन — कुछ नहीं जाता	`offline`	कुछ भी पार नहीं जाता	`true` / `false`	दोनों
लेटेंसी	`latency_ms`	हर पैकेट, या धारा के हर chunk में जोड़ा गया विलंब	0–60 000 (स्लाइडर 1 000 तक जाता है)	दोनों
जिटर	`jitter_ms`	इतना तक रैंडम अतिरिक्त विलंब; एक TCP धारा क्रम में रहती है	0–60 000 (स्लाइडर 500 तक जाता है)	दोनों
बैंडविड्थ, kbit/s	`rate_kbps`	बैंडविड्थ सीमा, न हो तो 0। UDP: एक सेकंड से ज़्यादा की कतार होने पर डेटाग्राम थ्रॉटल होकर छोड़ दिए जाते हैं; TCP: भेजने वाला धीमा किया जाता है, कुछ नहीं छोड़ा जाता	0, या 8–10 000 000	दोनों
पैकेट लॉस	`loss`	डेटाग्राम छूट जाने की संभावना	0–1 (स्लाइडर % दिखाता है)	UDP
बर्स्ट लॉस, बर्स्ट की लंबाई, डेटाग्राम	`burst_start`, `burst_length`	नुकसान के झोंके शुरू होने की संभावना, और वह औसतन कितने डेटाग्राम चलता है	0–1; झोंके चालू होने पर 1–1 000	UDP
डुप्लिकेशन	`duplicate`	डेटाग्राम दो बार भेजे जाने की संभावना	0–1	UDP
दूषण	`corrupt`	डेटाग्राम का एक बिट पलट जाने की संभावना	0–1	UDP
क्रम बदलना	`reorder`	डेटाग्राम रोक लिए जाने की संभावना, ताकि बाद वाले उसे पीछे छोड़ दें	0–1	UDP
कनेक्शन रीसेट	`reset`	धारा के किसी chunk की जगह उसका कनेक्शन रीसेट होने की संभावना — दोनों तरफ़ रीसेट मिलता है	0–1	TCP
अर्ध-खुला	`stall`	किसी chunk के बाद उसका कनेक्शन आधा-खुला छूटने की संभावना: अब किसी भी तरफ़ कुछ और नहीं जाता, और किसी को बताया नहीं जाता	0–1	TCP

रिले, प्रीसेट और वे क्या मॉडल करते हैं, इस पर और जानकारी बाधा पेज पर।

इम्पेयरमेंट बदलें

रन के किसी नेटवर्क बाधा नोड को इस चरण से दूसरी प्रोफ़ाइल पर बदल देता है, बिना उसका पोर्ट छोड़े। अब तक का चरण बंद कर दिया जाता है और रिपोर्ट में गिना जाता है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट	टेम्पलेट
नेटवर्क बाधा	`relay`	इस प्रयोग के एक नेटवर्क बाधा नोड की id	पहला	नहीं
प्रीसेट और उसके नीचे के मान	`profile`	अब से यह किसके साथ इम्पेयर करता है — देखें प्रोफ़ाइल; रिले अपने ही प्रोटोकॉल के मान पढ़ता है	ऑफ़लाइन (न हो तो कोई इम्पेयरमेंट नहीं)	नहीं

अगर रिले चल नहीं रहा तो चरण विफल होता है — मान लीजिए, वह रिले करने में विफल रहा। आउटपुट: आउटपुट। कोई सेटिंग नहीं।

json

{ "id": "cut", "type": "impairment_change", "x": 730, "y": 200, "relay": "relay",
  "profile": { "name": "offline", "offline": true } }

एमुलेटर बंद/चालू

रन के किसी एमुलेटर को बंद कर देता है, या वापस चालू कर देता है। बंद रहते समय एक HTTP एमुलेटर वैसा जवाब देता है जैसा बंद रहते समय कहता है; एक TCP डिवाइस और MQTT ब्रोकर अपने कनेक्शन तोड़ देते हैं और नए अस्वीकार करते हैं; OSC और UDP डिवाइस कोई जवाब नहीं देते। फिर चालू होने पर एमुलेटर अपना आउटेज शेड्यूल चलाता है, अगर उसके पास हो।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट
एमुलेटर	`emulator`	इस प्रयोग के एक एमुलेटर नोड की id	पहला
स्थिति	`down`	बंद (`true`) या चालू (`false`)	बंद (न हो तो `false`)
बंद रहते समय	`fault`	केवल HTTP: 503 Unavailable (`unavailable`), कनेक्शन बंद करें (`reset`: कनेक्शन बिना जवाब के बंद कर दिया जाता है) या कोई जवाब नहीं (`timeout`: रिक्वेस्ट तब तक रोकी जाती है जब तक क्लाइंट हार न माने, अधिकतम 120 s)	`unavailable` (न हो तो भी)

आउटपुट: आउटपुट। कोई सेटिंग नहीं। कुछ भी टेम्पलेट नहीं है।

json

{ "id": "down", "type": "emulator_state", "x": 500, "y": 200, "emulator": "api", "down": true, "fault": "unavailable" }

डेटा

मान निकालें

अपने पाथ पर नवीनतम HTTP रिस्पॉन्स का एक हिस्सा वेरिएबल के रूप में सहेजता है, बाद के फ़ील्ड ({{token}}), जाँचों और ब्रांचों के लिए। हर पाथ पर इससे पहले एक HTTP रिक्वेस्ट आनी चाहिए। अभी भेजें के रिस्पॉन्स में किसी मान पर क्लिक करने से आपके लिए एक जुड़ जाता है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
वैरिएबल	`variable`	नाम: अक्षर, अंक और `_`, अंक से शुरू नहीं, आरक्षित शब्द नहीं, किसी पैरामीटर का नाम नहीं	`token`	नहीं
कहाँ से लें	`from`	JSON फ़ील्ड (`json`), हेडर (`header`), स्टेटस कोड (`status`), पूरी बॉडी (`body`) या रेगुलर एक्सप्रेशन (`regex`)	`json`	नहीं
JSON पाथ, हेडर का नाम या पैटर्न (ग्रुप 1, यदि हो)	`expr`	एक JSON पाथ (`$.data.token`, `$.items[0]`, `$["first name"]`), एक हेडर नाम (किसी भी केस में), या एक रेगुलर एक्सप्रेसन — उसका पहला ग्रुप, या पूरा मिलान	`$.token`; स्टेटस और बॉडी के लिए उपयोग नहीं होता	नहीं

जब लेने के लिए कुछ न हो तो चरण विफल होता है: बॉडी JSON नहीं है, पाथ या हेडर मौजूद नहीं है, एक्सप्रेशन मेल नहीं खाता, या — किसी JSON फ़ील्ड या पूरी बॉडी के लिए — बॉडी रखे गए 256 KiB से लंबी थी। स्टेटस संख्या के रूप में सहेजा जाता है; बाकी टेक्स्ट के रूप में, या जो JSON मान मिला उसके रूप में। आउटपुट: आउटपुट। कोई सेटिंग नहीं।

json

{ "id": "token", "type": "extract", "x": 500, "y": 80, "variable": "token", "from": "json", "expr": "$.data.token" }

वेरिएबल पर और जानकारी डेटा और टेम्पलेट में।

जाँचें

एक जाँच या तो सफल होती है, या रन विफल कर देती है। चारों रिस्पॉन्स जाँचें अपने पाथ पर नवीनतम HTTP रिस्पॉन्स पढ़ती हैं, इसलिए हर पाथ पर उनसे पहले एक HTTP रिक्वेस्ट — लोड वाली नहीं — आनी चाहिए।

HTTP स्टेटस

जब नवीनतम रिस्पॉन्स का स्टेटस ठीक दिया गया हो तब सफल होती है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
अपेक्षित स्टेटस	`status`		200; 100–599	नहीं

आउटपुट: आउटपुट। कोई सेटिंग नहीं।

json

{ "id": "ok", "type": "assert_status", "x": 500, "y": 80, "status": 200 }

रिस्पॉन्स टेक्स्ट

जब नवीनतम रिस्पॉन्स की बॉडी में वह टेक्स्ट ठीक-ठीक (केस मिलाकर) हो तब सफल होती है। बॉडी के केवल पहले 256 KiB रखे जाते हैं: जो टेक्स्ट ऐसी बॉडी में न मिले जो काटी गई थी, वह उसी वजह से विफल होती है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
शामिल टेक्स्ट	`contains`		`ok`; ज़रूरी	हाँ

आउटपुट: आउटपुट। कोई सेटिंग नहीं।

json

{ "id": "ready", "type": "assert_body", "x": 500, "y": 80, "contains": "ready" }

रिस्पॉन्स हेडर

जब नवीनतम रिस्पॉन्स में वह हेडर हो और उसका मान वह टेक्स्ट रखता हो तब सफल होती है। हेडर का नाम किसी भी केस में मिलाया जाता है; मान ठीक-ठीक।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
हेडर का नाम	`name`		`content-type`; ज़रूरी	हाँ
शामिल टेक्स्ट	`contains`	उसके मान में क्या होना चाहिए; ख़ाली: हेडर का होना ही काफ़ी है	`application/json`	हाँ

आउटपुट: आउटपुट। कोई सेटिंग नहीं।

json

{ "id": "json", "type": "assert_header", "x": 500, "y": 80, "name": "Content-Type", "contains": "json" }

रिस्पॉन्स समय

जब नवीनतम रिस्पॉन्स में अधिकतम इतना समय लगा हो, रिक्वेस्ट भेजने से लेकर उसकी बॉडी के अंत तक, तब सफल होती है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
अधिकतम समय, ms	`max_ms`		1 000; 1–120 000	नहीं

आउटपुट: आउटपुट। कोई सेटिंग नहीं।

json

{ "id": "fast", "type": "assert_latency", "x": 500, "y": 80, "max_ms": 250 }

मान जाँचें

एक मान — आम तौर पर एक वेरिएबल, टेम्पलेट के रूप में लिखा — की तुलना अपेक्षित मान से करती है, और जब तुलना पूरी होती है तब सफल होती है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट	टेम्पलेट
मान	`value`	किसकी तुलना होती है: `{{token}}`, `{{reply.args[0]}}`	`{{token}}`	हाँ
शर्त	`op`	देखें तुलनाएँ	खाली नहीं है	नहीं
अपेक्षित	`expected`	खाली है और खाली नहीं है इसका उपयोग नहीं करते	ख़ाली (न हो तो भी)	हाँ

आउटपुट: आउटपुट। कोई सेटिंग नहीं।

json

{ "id": "state", "type": "assert_value", "x": 730, "y": 80, "value": "{{state}}", "op": "eq", "expected": "ready" }

तुलनाएँ

मान जाँचें, मान पर शाखा, किसी लूप की निकास शर्त, OSC आर्ग्युमेंट नियम और HTTP शर्तें एक ही तरह तुलना करते हैं:

विकल्प	फ़ाइल में	तब पूरा होता है जब मान
के बराबर है	`eq`	अपेक्षित के बराबर है — संख्याओं के रूप में जब दोनों संख्याएँ हों (`200` = `200.0`), वरना ठीक-ठीक टेक्स्ट के रूप में
के बराबर नहीं है	`ne`	उसके बराबर नहीं है, उसी नियम से
से कम है, से अधिक नहीं है, से अधिक है, से कम नहीं है	`lt`, `le`, `gt`, `ge`	कम, अधिकतम, अधिक, कम से कम है — दोनों संख्याएँ होनी चाहिए: वरना कोई जाँच, ब्रांच या लूप चरण विफल कर देता है, और कोई आर्ग्युमेंट नियम या HTTP शर्त पूरी नहीं होती
को शामिल करता है	`contains`	अपेक्षित टेक्स्ट रखता है
regex से मेल खाता है	`matches`	अपेक्षित रेगुलर एक्सप्रेशन से मेल खाता है
खाली है, खाली नहीं है	`empty`, `not_empty`	ख़ाली है (स्पेस ख़ाली गिने जाते हैं) / ख़ाली नहीं है

फ़्लो

वे नोड जो तय करते हैं कि रन कहाँ जाता है। ब्रांच, जॉइन और लूप पर और जानकारी फ़्लो में।

प्रारंभ

जहाँ रन शुरू होता है; हर प्रयोग में ठीक एक होता है। इसका कोई इनपुट और कोई फ़ील्ड नहीं होता। टाइमलाइन की पहली पंक्ति रन का सीड बताती है।

आउटपुट: आउटपुट, ज़रूरी। इससे कई वायर एक साथ समानांतर ब्रांचें शुरू करते हैं।

json

{ "id": "start", "type": "start", "x": 40, "y": 80 }

अंत

जहाँ रन पूरा होता है; हर प्रयोग में ठीक एक होता है, और उसका कोई आउटपुट नहीं होता। इस तक कई ब्रांचें पहुँच सकती हैं: अंतिम ब्रांच के पूरा होने के बाद रन एक बार सफल होता है, और तभी जब कोई विफल न हुई हो। जो रन कभी अंत तक न पहुँचे, वह विफल होता है।

json

{ "id": "end", "type": "end", "x": 960, "y": 80 }

विलंब

अगले चरण से पहले एक तय समय प्रतीक्षा करता है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
विलंब (ms)	`ms`		300; 0–60 000	नहीं

आउटपुट: आउटपुट। कोई सेटिंग नहीं। लंबी प्रतीक्षाओं के लिए, कई एक पंक्ति में या किसी लूप में रखें।

json

{ "id": "pause", "type": "delay", "x": 500, "y": 80, "ms": 500 }

स्टेटस ब्रांच

जब नवीनतम HTTP रिस्पॉन्स का यह स्टेटस हो तब हाँ चुनता है, वरना नहीं। हर पाथ पर इससे पहले एक HTTP रिक्वेस्ट आनी चाहिए।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
अपेक्षित स्टेटस	`status`		200; 100–599	नहीं

आउटपुट: हाँ और नहीं, दोनों ज़रूरी। कोई सेटिंग नहीं।

json

{ "id": "branch", "type": "branch_status", "x": 500, "y": 80, "status": 200 }

मान पर ब्रांच

जब कोई तुलना पूरी होती है तब हाँ चुनता है, वरना नहीं। इसके फ़ील्ड और तुलनाएँ वही हैं जो मान जाँचें के हैं; जो तुलना की ही नहीं जा सकती (lt टेक्स्ट पर), वह चरण विफल कर देती है।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट	टेम्पलेट
मान	`value`	किसकी तुलना होती है	`{{token}}`	हाँ
शर्त	`op`		के बराबर है	नहीं
अपेक्षित	`expected`		ख़ाली (न हो तो भी)	हाँ

आउटपुट: हाँ और नहीं, दोनों ज़रूरी। कोई सेटिंग नहीं।

json

{ "id": "ok", "type": "branch_value", "x": 730, "y": 80, "value": "{{reply.args[0]}}", "op": "eq", "expected": "ok" }

समानांतर ब्रांच

शाखा 1 और शाखा 2 के बाद जो आता है, उसे एक ही समय पर चलाता है, हर ब्रांच के पास वेरिएबल की अपनी कॉपी होती है। और ब्रांचों के लिए हर आउटपुट पर और वायर हो सकते हैं। कोई फ़ील्ड नहीं।

आउटपुट: शाखा 1 और शाखा 2, दोनों ज़रूरी।

json

{ "id": "split", "type": "fork", "x": 270, "y": 80 }

ब्रांचें जोड़ें

तब तक प्रतीक्षा करता है जब तक इसमें आने वाले हर वायर तक न पहुँचा जाए, फिर एक बार आगे बढ़ता है, ब्रांचों के वेरिएबल मिलाकर — जहाँ दो ब्रांचें एक ही वेरिएबल सेट करती हैं, वहाँ फ़ाइल में जिसका वायर बाद में आता है वह जीतता है — और उनमें से जिस आख़िरी के पास थी उसका नवीनतम HTTP रिस्पॉन्स। कोई फ़ील्ड नहीं।

यहाँ केवल वे ब्रांचें मिलती हैं जो सब चलती हैं: किसी स्टेटस पर शाखा के पीछे का शाखाएँ जोड़ें, जिसके हाँ और नहीं दोनों कभी नहीं होते, कभी आगे नहीं बढ़ता; जब कोई और पाथ अंत तक न पहुँचे, तो रन इसी नोड पर विफल होता है, और बताता है कि वह अब भी कितनी ब्रांचों की प्रतीक्षा कर रहा था।

आउटपुट: आउटपुट, ज़रूरी।

इसमें आने वाले कई वायर वाला कोई भी और नोड हर आगमन पर एक बार चलता है।

json

{ "id": "joined", "type": "join", "x": 730, "y": 80 }

लूप

बॉडी पर के चरण — जो वापस इसी तक लाते हैं — बार-बार चलाता है: अधिकतम कई बार, और, जब कोई निकास शर्त हो, तब तक जब तक वह पूरी न हो जाए।

फ़ील्ड	फ़ाइल में	क्या	डिफ़ॉल्ट और सीमाएँ	टेम्पलेट
अधिकतम इटरेशन	`max`	अधिकतम पुनरावृत्तियाँ	5; 1–1 000	नहीं
पहले रुकें, जब	`until`	वैकल्पिक निकास शर्त `{ "value", "op", "expected" }`, जैसे मान जाँचें में	बंद	मान और अपेक्षित: हाँ

बॉडी हमेशा कम से कम एक बार चलती है। निकास शर्त हर पुनरावृत्ति के बाद पढ़ी जाती है, इसलिए बॉडी वह सेट कर सकती है जो वह जाँचती है।
जब शर्त पूरी होती है तब पूर्ण का पीछा किया जाता है — या, बिना शर्त के, अंतिम पुनरावृत्ति के बाद।
जब शर्त पूरी होने से पहले पुनरावृत्तियाँ ख़त्म हो जाती हैं तब सीमा का पीछा किया जाता है। उस पर वायर न हो तो वह चरण विफल कर देता है।
बॉडी के भीतर, {{counter}} पुनरावृत्ति का क्रमांक है।
बॉडी एक ब्रांच के रूप में चलती है: उसके भीतर हर आउटपुट पर एक वायर होता है; उसमें कोई शुरुआत, अंत, समानांतर शाखा, शाखाएँ जोड़ें या दूसरा लूप नहीं होता; उसमें प्रवेश केवल बॉडी से होता है; और उसका हर वायर बॉडी में आगे या लूप तक वापस ले जाता है।

आउटपुट: बॉडी और पूर्ण (ज़रूरी), सीमा (वैकल्पिक)। कोई सेटिंग नहीं।

json

{ "id": "poll", "type": "loop", "x": 270, "y": 80, "max": 10,
  "until": { "value": "{{status.args[0]}}", "op": "eq", "expected": "ready" } }

नोड संदर्भ ​

इस पेज को पढ़ना ​

फ़ाइल में एक नोड ​

कई नोड की साझा सेटिंग्स ​

दोबारा प्रयास ​

दोहराव ​

लोड ​

जवाब की प्रतीक्षा ​

क्रियाएँ ​

HTTP रिक्वेस्ट ​

TCP संदेश ​

OSC संदेश ​

UDP डेटाग्राम ​

MQTT पब्लिश ​

WebSocket कनेक्ट ​

WebSocket भेजें ​

WebSocket बंद ​

लॉग मार्कर ​

प्रतीक्षाएँ ​

पेलोड मिलान ​

OSC की प्रतीक्षा ​

UDP की प्रतीक्षा ​

MQTT की प्रतीक्षा ​

HTTP रिक्वेस्ट की प्रतीक्षा ​

WebSocket की प्रतीक्षा ​

एमुलेशन ​

एमुलेटर ​

फ़ॉल्ट ​

इम्पेयरमेंट ​

प्रोफ़ाइल ​

इम्पेयरमेंट बदलें ​

एमुलेटर बंद/चालू ​

डेटा ​

मान निकालें ​

जाँचें ​

HTTP स्टेटस ​

रिस्पॉन्स टेक्स्ट ​

रिस्पॉन्स हेडर ​

रिस्पॉन्स समय ​

मान जाँचें ​

तुलनाएँ ​

फ़्लो ​

प्रारंभ ​

अंत ​

विलंब ​

स्टेटस ब्रांच ​

मान पर ब्रांच ​

समानांतर ब्रांच ​

ब्रांचें जोड़ें ​

लूप ​

नोड संदर्भ

इस पेज को पढ़ना

फ़ाइल में एक नोड

कई नोड की साझा सेटिंग्स

दोबारा प्रयास

दोहराव

लोड

जवाब की प्रतीक्षा

क्रियाएँ

HTTP रिक्वेस्ट

TCP संदेश

OSC संदेश

UDP डेटाग्राम

MQTT पब्लिश

WebSocket कनेक्ट

WebSocket भेजें

WebSocket बंद

लॉग मार्कर

प्रतीक्षाएँ

पेलोड मिलान

OSC की प्रतीक्षा

UDP की प्रतीक्षा

MQTT की प्रतीक्षा

HTTP रिक्वेस्ट की प्रतीक्षा

WebSocket की प्रतीक्षा

एमुलेशन

एमुलेटर

फ़ॉल्ट

इम्पेयरमेंट

प्रोफ़ाइल

इम्पेयरमेंट बदलें

एमुलेटर बंद/चालू

डेटा

मान निकालें

जाँचें

HTTP स्टेटस

रिस्पॉन्स टेक्स्ट

रिस्पॉन्स हेडर

रिस्पॉन्स समय

मान जाँचें

तुलनाएँ

फ़्लो

प्रारंभ

अंत

विलंब

स्टेटस ब्रांच

मान पर ब्रांच

समानांतर ब्रांच

ब्रांचें जोड़ें

लूप