MQTT protokolü sensör okumalarını BLE üzerinden iletmek için uygun mu?

İletişim aracı olarak BLE'ye dayanan ve bu cihazların daha güçlü bir ağ geçidine (örneğin, Ahududu pi seviyesi cihazları) bağlı olduğu çok sayıda zayıf sensörün (örn., Arduino seviye cihazları) olduğunu varsayın.

MQTT'nin okumalarını iletmek için uygun bir protokol olup olmadığını bilmek istiyorum (kısa, sık sık mesajlar).

Bazı bloglar / dokümanlar, MQTT'yi "IoT uygulamaları" için uygun görür, çünkü HTTP ile karşılaştırıldığında hafif (er) ağırlıktır ve güç tasarrufu sağlar. Bununla birlikte, benim anlayışım için, BLE veya IoT için uygun diğer iletişim protokolleri için geçerli olmayan bir bağlantı açık tutulmasını gerektirir. BLE, enerji rezervi sağlamak için bağlantıyı uzun süre açık tutmaz. Görünüşe göre MQTT, WiFi gibi bir MAC katman protokolü kullanıldığında uygundur. Bu neredeyse ilk etapta MQTT kullanımının ardındaki mantığı kırıyor (yani, cihaz WiFi gibi bir protokolü tamamen işliyorsa, MQTT gibi bir protokole ihtiyaç duymayabilir). Bu mantıkta bir kusur görüyor musunuz?

Bu amaçla alternatif bir uygulama katmanı protokolü var mı? Bu tür iletilerin (ör. Ham ikili veriler, JSON, XML) bir ağ geçidiyle iletişim kurduklarında ve bir sunucu ile doğrudan iletişim kurduklarında en sık görülen yapı nedir?

mqtt power-consumption bluetooth-low-energy

— dr.doom
kaynak

Yerel BLE mekanizması herhangi bir nedenden dolayı uygun değil mi?

— Sean Houlihane

Sean'ın sorusu en iyi iki bölüme ayrılabilir - A) cihazdan hemen bağlantı için kullanılabilen yerel BLE protokol mekanizmaları ve B) verilerin nihai olarak nereye gitmesi gerekir? B kısmının cevabı BLE aralığının ötesindeyse, bir köprü (en azından radyo formatları arasında, ancak muhtemelen protokoller arasında) gereklidir.

— Chris Stratton

Ağ geçidi ham değerleri tüketiyor mu yoksa basitçe aktarıyor mu ve bu bağlamda, ağ geçidindeki MQTT'ye doğal olarak BLE köprüsü yapmak yerine uçtan uca tünel açmak mantıklı olabilir mi?

— Sean Houlihane

Yanıtlar:

MQTT, TCP / IP üzerinden çalıştırılmalıdır (gerçekten spesifikasyonda olup olmadığını veya bunu yapmak için yeterli varsayımların yapıldığını hatırlayamıyorum ) ancak kardeş protokolü MQTT-SN , veri aktarabilen neredeyse tüm protokoller üzerinde çalıştırılabilir , UDP ve seri uygulamaları gördüm.

BLE üzerinde çalışarak ne kazandığınızdan emin olmadığımı söyledikten sonra, BLE'nin yerleşik özellikleri, bildirim gibi şeylerle aynı faydayı (yalnızca 1'e 1 temelinde) sunar.

Sanırım hatırlanması gereken önemli şeylerden biri IoT'de "I" nin ne anlama geldiği, bir noktada internete erişim anlamına geliyor (bir ağ geçidi cihazı veya telefon olsa bile). Bu noktada MQTT çok yararlı olabilir, ancak mutlaka (kanama) kenarına kadar olan anlamına gelmez.

— hardillb
kaynak

Her şeyden önce, MQTT-SN'un varlığını bana bildirdiğiniz için teşekkürler. Literatürün büyük çoğunluğu biraz yanıltıcıdır, çünkü MQTT'nin çoğunlukla güç tasarrufu özelliklerinden dolayı kenar cihazlarını güçlendirdiğini ima eder. Bu durumda, düşük güç tüketimi gerçek bir argüman değildir, çünkü bu profile sahip cihazlarda önemli değildir. Cihazlar tam bir IP yığını uygulamalıdır ve MQTT açık bir bağlantı sağladığından, enerji tasarruflu MAC katman protokolleri bir seçenek değildir.

— dr.doom

MQTT, HTTP gibi bir şeyle karşılaştırıldığında güç tasarrufu sağlar, çünkü açık bir TCP bağlantısı, zaten bir TCP yığını çalıştırdıktan sonra açık tutmaya yetecek kadar güç tüketmez ve canlı tutma paketleri küçüktür. Ayrıca, bir HTTP üstbilgisi bir MQTT paket üstbilgisine kıyasla çok büyük olduğundan protokol ek yükü HTTP'den çok daha düşüktür. Hesaplama literatürünün çoğu hücresel bir cihaza dayanmaktadır, örneğin telefon

— hardillb

Ayrıca kenar taşındı, TCP / IP'nin durduğu yerdi, ble ve ZigBee (özellikle lpwan ile) ve daha düşük güç işlemcileri bile daha ince cihazlara taşındı

— hardillb 19:17

Bu açıkça bu değil sadece TCP / IP; tek gereklilik protokolün "düzenli, kayıpsız, çift yönlü bağlantılar" sağlaması gerektiğidir. Dokümanın özetinin ikinci paragrafı gibi. SN vardır, çünkü bu gereksinim küçük sistemler, özellikle radyo tabanlı sistemler için zahmetlidir. Belki de "bunu yapmak için yeterli varsayımlar yapılır" derken bunu kastediyorsunuz, ancak kesinlikle TCP / IP'ye bağımlı değil.

— Dave Newton

Muhtemelen, kelimenin tam anlamıyla BLE üzerinden MQTT göndermeye çalışmak yerine, BLE paradigmalarından MQTT'ye basit bir veri eşlemesi yapmak daha iyi olur.

BLE genellikle veri karakteristikleri biçiminde alışverişi yapar . Bunlar, yararlı bulabileceğiniz değer değişikliğini keşfetmek için çeşitli BLE'ye özgü mekanizmalara sahiptir. Ancak maksimum veri uzunluğu 20 bayttır .

Bir olası her seferinde 20 bayt hareket BLE üzerinden seri veri akışı. Bu bazen sanal bir seri bağlantı noktası uygulamak için yapılır ve bu sayede tam MQTT'yi tünelleyebilirsiniz.

Ancak muhtemelen farklı konuların verilerini taşımak için bir BLE özellikleri koleksiyonu kullanmak ve karakteristik kimliği bir MQTT konusuna eşleyen ve değeri MQTT yüküne eşleyen bir köprünüz olması daha iyi olur.

BLE'nin bağlı olmayan oturumlara karşı kendi devam eden bağlı oturumları vardır. Muhtemelen BLE'nin kullanımınız için hangi kullanımının en iyi olduğunu bulmalı ve daha sonra bunu MQTT'nin bir bağlantıyı koruma duygusu ile eşleştirmelisiniz.

Bunu iki yönde veya her iki yönde de yapabilmeniz gerekir: BLE-> MQTT ve MQTT-> BLE

— Chris Stratton
kaynak

Bir MQTT 2 BLE köprüsü istiyorsanız mayın github.com/hardillb/mqtt2ble

— hardillb 19:17 '

Bu bağlantı için teşekkürler, şu anda bir göz atıyorum.

— dr.doom