[Dave]

I managed to figure this out.

I was doing all my work from the command line and not using your Web UI 🙁 Once I added the rule and clicked “Save and Restart”. Everything is now working.

Thanks for your help

[Dave]

Thanks Jeff,

After looking at the difference between the two, I was able to find the missing rule and add it to the filter table to get things working but I still haven’t found out how to persist that rule through a reboot. Once I reboot, the rule is gone. Is there some magic place or command that will make this permanent?

Dave.

[Dave]

I made some progress. I looked at the output from iptables-save command on both Conduits and saw some differences between the one I could access and the one I was having trouble accessing. I saved the output from the “good” iptables-save command to a file, copied that file to the “bad” Conduit, did iptables-restore < <good-file> and I was able to access the MQTT server. Only problem is that on reboot, everything stops working and I have to reissue the iptables-restore command.

I’m not familiar with iptables. Can it be disabled? Can I disable it or at least save the new configuration through a reboot?

[Dave]

You say that there is no firewall enabled by default but can you enable a firewall in mLinux? This device was being used by another group in our organization and I can’t find out who all had their fingers on it. Is there a way I can tell if a firewall was enabled on the device (assuming you can enable one).

Thanks

[Dave]

When you say “the firewall”, which firewall? The device is in our internal network and does not pass through any firewall.

[Dave]

That’s great! Thanks again for your help.

[Dave]

Thanks for the reply.

So what happens if I try to send a message that is too big for the current data rate? Will it be broken up by the network server and each fragment delivered to the mDot? We have an using the mDot to receive messages. What will the app see? Each fragment or the final, re-assembled message?

Dave.

[Dave]

Things have moved along quite well. I’ve got my app receiving msgs from an mdot, running in demo mode, via the mqtt broker but I’m just a little confused about the messages I’m seeing.

When I send a message from the mdot, I get two messages showing up on the broker: one on the ‘lora/<devid>/packet_recv’ topic and another on the ‘lora/<devid>/up’ topic. It looks like the data I’m interested in is the message coming from the ‘../up’ topic. Decoding the ‘data’ element of the json, seems to give me the data values shown on my mdot’s display. Is this correct? If so, what is the purpose of message that shows up on the ‘../packet_recv’ topic?

Also, the mdot I have is publishing a pressure value, which, according to your web site is the pressure scaled as ‘0.25 kPa (Signed MSB)’. However, when I look at the data value I’m getting from the message, i.e.:

“data”: “DgAAEAgFbxgFAAALAZA=”

it translates to byte array ‘0e 00 00 10 08 05 6f 18 05 00 00 0b 01 90’. I’m assuming the pressure reading are the bytes: ’08 05 6f 18′ (0x08 = pressure type, 0x056f18 = value). When I convert this to an integer value, I get 356120. Multiplying this by 0.25, I get 89030. However, this looks like Pa, not kPA, since the value shown on my mdot’s display is 89.03 kPa. Is this correct? Or am I completely off base?

Thanks,
Dave.

[Dave]

Awesome! Thanks for the quick reply!!

[Dave]

That helped. Thanks!

Is there a way to connect to the Conduit’s MQTT server using an external tool? I’ve been trying to use some of my own tools and also Paho Client but I keep getting “Connection refused”.

Dave.

[Author]

Posts