Sahte hedef

Her zaman evet diyen bir hedef neredeyse hiçbir şeyi kanıtlamaz. Yeniden deneme, artan bekleme ve ölü mektup kuyruğu ancak alıcı taraf bilerek başarısız olabiliyorsa gözlemlenebilir.

Sahte hedef, tam olarak bunu yapan bir yerine geçen uygulamadır. localhost:3004 üzerinde çalışır; konsolu /ui adresindedir.

Başlatın ve Merkez'i buna yöneltin

cd sink-test
npm install
cp .env.example .env
npm run start:dev

Sonra HEDEF entegrasyonunuzun uç nokta adresini şu yapın:

http://localhost:3004/sink

Entegrasyonda Test et'e basın — yeşile dönmelidir. (Sahte hedef, o düğmenin kullandığı erişilebilirlik yoklamasını HEAD /sink üzerinde yanıtlar.)

Şimdi sahte kaynakla bir şey gönderin ve düşüşünü izleyin.

Gerçekte ne geldiğini görün

localhost:3004/ui canlı bir akıştır — iletimler sorgulanarak değil, geldikçe itilir.

Üst çubuk aynı zamanda kontrol panelidir: davranış modu, yedek downlink ve etkin kurallar sayfadan çıkmadan değiştirilebilir. Sayaçlar — iletim, downlink, başarısız, tekrar, bozuk imza — bir testin beklediğinizi yapıp yapmadığını en hızlı okuma biçimidir. Burada hedef fail modundayken iki satır 503 yanıtlamış, iki satır da DUP işaretlenmiştir.

Tüm alışverişi görmek için bir satıra tıklayın: başlıklar, istek gövdesi, yanıt gövdesi ve imza kararı, boolean yerine kelimelerle yazılmış hâlde.

Üstteki şerit, bunun ack: true olan bir DATA_BIDIR olmasındandır — yanıtı yük taşıyan tek iletim türü. Altında geri dönen downlink ve onu bir kuralın mı seçtiği yoksa yedeğin mi kullanıldığı; sonra istek bilgileri — sizin tarafınızın tekrar ayıklaması gereken idempotencyKey dâhil.

İki ayrıntı bunu bir terminalden daha kullanışlı kılar:

• Satırlar messageType ile etiketlenir — Merkez'in bir mesaj için kullandığı tek ad; Sigfox için bu callback'tir (DATA_UPLINK, DATA_BIDIR, …) — uplink — indirger; yani ona göre yapılmış bir liste hangi callback'in geldiğini söyleyemez, ki downlink söz konusu olduğunda bilmeniz gereken tam olarak budur. Satırda DATA_BIDIR (0/3) yazar.
• awaits reply, yanıtı yük taşıyan bir iletimi işaretler — ack: true olan bir DATA_BIDIR; cihazın penceresini açık tuttuğu durum.

downlinks ya da problems ile süzün; problems, temiz bir kabul olmayan her şey demektir: 2xx olmayan bir yanıt, bir tekrar veya bozuk bir imza.

Günlük HTTP üzerinden de vardır:

curl -s localhost:3004/log
curl -X DELETE localhost:3004/log

Bozuk davranmaya zorlayın

Tek bir uç nokta davranışı çalışma anında değiştirir:

curl -s localhost:3004/control                      # şu an ne yapıyor?
curl -X POST localhost:3004/control \
  -H 'content-type: application/json' \
  -d '{"mode":"fail","failStatus":503}'

Dört mod ve her birinde Merkez'den beklenen davranış:

Mod değiştirmek flaky sayacını sıfırlar; ikinci bir flaky denemesi tükenmiş başlamaz. Mod değişikliği, belirtmediğiniz ayarları asla silmez.

Uygulamalı örnek: bir ölü mektubun oluşmasını izleyin

# 1. Hedefi her şeyi reddetmeye zorla
curl -X POST localhost:3004/control -H 'content-type: application/json' \
     -d '{"mode":"fail","failStatus":503}'

# 2. Bir mesaj gönder
curl -X POST localhost:3003/emit/bidir

# 3. Analitik'i izleyin: denemeler tekrarlandıkça Başarısız artar.
#    Sekizden sonra iletim Ölü mektuplar'a düşer.

# 4. "Kesintiyi" düzelt
curl -X POST localhost:3004/control -H 'content-type: application/json' -d '{"mode":"ok"}'

# 5. Merkez'de Ölü mektuplar'ı açıp Yeniden gönder'e basın — artık başarılı olur.

Bu döngü, beş komutta iletim sözleşmesinin tamamıdır: en az bir kez, artan bekleme, ölü mektup, yeniden gönderim.

Uygulamalı örnek: yeniden denemenin veri kaybı olmadığını kanıtlayın

curl -X POST localhost:3004/control -H 'content-type: application/json' \
     -d '{"mode":"flaky","flakyFailures":2}'
curl -X POST localhost:3003/emit/bidir

İlk iki deneme başarısız olur, üçüncüsü başarır. Mesaj ölü mektuba düşmez, iletilir — ve iletim kaydı birden fazla deneme gösterir. Gerçekte bir sorun yokken kısa bir hedef kesintisinin görünüşü budur.

Bir downlink'i yanıtlamak

İletilen bir mesaj downlink istediğinde, cihaza yanıt veren şey o aynı isteğe verilen cevaptır. Bu yüzden sahte hedef, ek bir bağlantı gerekmeden bir downlink köprüsünün uzak ucu gibi davranabilir.

Bir yedek yanıt tanımlayın:

curl -X POST localhost:3004/control -H 'content-type: application/json' \
     -d '{"downlinkHex":"deadbeef00000001"}'

Hex tam olarak 16 karakter olmalıdır — Sigfox downlink'leri 8 bayttır — yoksa Merkez onu atar.

Kararı mesaja bırakın

Gerçek bir uygulama sabit bir yanıt vermez; sayacın ne bildirdiğine bakar. Kurallar bunu modeller: bu koşulların tümü sağlanıyorsa şu hex ile yanıtla. İlk eşleşme kazanır.

curl -X POST localhost:3004/control -H 'content-type: application/json' -d '{
  "downlinkRules": [
    { "name": "low battery", "downlinkHex": "deadbeef00000001", "when": [
      { "path": "messageType", "op": "eq", "value": "DATA_BIDIR" },
      { "path": "ack", "op": "eq", "value": true },
      { "path": "payload.alarms.LowBattery", "op": "eq", "value": true }
    ]}
  ]
}'

Operatörler eq, neq, gt, lt, contains, exists ve missing. Değerler tip bakımından gevşek karşılaştırılır; yani true boolean'ı true metniyle eşleşir.

Bunların tümünü konsoldan da düzenleyebilirsiniz — downlink rules → edit — davranış modu ve yedek hex de üst çubuktan değiştirilebilir.

Her konsol nerede durur

Sahte hedef size uygulamanın ne aldığını söyler. Sunduğu bir downlink'in cihaza gerçekten ulaşıp ulaşmadığını söyleyemez — bunu gösteren, gidiş-dönüşü cihazın tarafından gösteren sahte kaynağın konsoludur.

İkisini birlikte kullanın: bir uç ne gönderildiğini, diğeri ne geri geldiğini kanıtlar.

Bulutta

Aynı düzenek Dokploy üzerinde sink.iot.una.center adresinde çalışır: üretimdeki Merkez'in teslimat işçileri, bir müşterinin uç noktasına yapacakları gibi https://sink.iot.una.center/sink adresine POST eder; konsol /ui adresindedir. Günlüğü bellekte tutulur — yeniden dağıtım onu boşaltır. Her şeye ok yanıtı veren, herkese açık bir uç noktadır: kimse test etmiyorken uygulamayı durdurun.

Sırada