Sending CONNACK to nrfPublisher, but no responses (MQTT)

RE: Sending CONNACK to nrfPublisher, but no responses (MQTT)

Ros — Thu, 11 Mar 2021 10:14:43 GMT

Is there any update?

RE: Sending CONNACK to nrfPublisher, but no responses (MQTT)

Charlie — Tue, 26 Jan 2021 10:36:40 GMT

Hi Ras,

I saw exactly the same issue. Get another similar ticket from MQTT publisher doesn't connect to broker, one of my colleague will follow this issue and hope to solve the problem soon. Thanks for your patient waiting.

Best regards

Charlie

RE: Sending CONNACK to nrfPublisher, but no responses (MQTT)

Ros — Thu, 21 Jan 2021 23:28:23 GMT

It seems that linux/raspberry pi cannot send packets to bt0 interface although ping6 works perfectly. As far I know all ports in raspberry pi is open by default. I updated raspberry pi OS to the latest.

RE: Sending CONNACK to nrfPublisher, but no responses (MQTT)

Ros — Mon, 18 Jan 2021 10:16:51 GMT

My application is remote monitoring of a single node. With 6lowpan, I just needed one BLE device with a rasberry pi, possibly a Pi W board. The thread border router needs one BLE chip with raspberry pi. If I can merge the border router with application layer then the Thread is a solution but in the current scenario sensing node is a battery powered device.

When I looked the Thread solution some time ago, the border router is not supported with raspberry Pi boards other than Pi 3. Maybe it will work with other versions as well.

I found 6lowpan + MQTT application in the latest Thread + ZigBee SDK.

I am not very comfortable to use nRFConnect SDK, and slowly migrating.

RE: Sending CONNACK to nrfPublisher, but no responses (MQTT)

Charlie — Mon, 18 Jan 2021 08:43:20 GMT

Hi Ras,

I will try to recreate your problem, but for your development, I have some questions or suggestions.

Is your project focus on the application layer or lower layers? Could you explain why you have to use our legacy IoT solution in this example? As you may realize our nRF52 SDK/NCS have switched to a more robust open-source project OpenThread solution lead by Google. There will no further development on this legacy solution, which means you may have trouble getting further support in the future. On another hand, as a transport and network layers solution, Thread is a better choice than you develop your own, maybe it is better to study and modify it if you have other needs.

Best regards,

Charlie