MQTT Gateway with PR52-33N

kkrems · June 6, 2019, 3:55am

I’m trying to configure my MQTT Gateway to communicate with a PR52-33N. In the MQTT Gateway console I’m receiving the following error.

[{“problem”:“Failed to fetch device settings”,“message”:{“message”:“Failed to parse JSON”,“err”:{“line”:247,“column”:50,“sourceURL”:“http://captive.apple.com/main.js"},“data”:{“type”:"IOT Gateway”,“model”:7,“buzzer”:0,“ssid”:[{“ssid”:“clam”,“rssi”:-52,“encryption_type”:true,“bssid”:“14:91:82:A5:0D:D1”,“channel”:6,“selected”:true},{“ssid”:“clam”,“rssi”:-56,“encryption_type”:true,“bssid”:“58:EF:68:3A:2A:ED”,“channel”:11,“selected”:true},{“ssid”:“clam”,“rssi”:-69,“encryption_type”:true,“bssid”:“14:91:82:A4:FF:79”,“channel”:3,“selected”:true},{“ssid”:“clam”,“rssi”:-74,“encryption_type”:true,“bssid”:“14:91:82:A5:0C:45”,“channel”:9,“selected”:true}],“ssid_password”:“SET”,“interval”:5000,“azure_enabled”:1,“http_enabled”:false,“serial_print_enabled”:false,“apPass”:“SET”,“apSSID”:“WiFi_Micro_Gateway”,“dhcp_enabled”:0,“static_ip”:[192,168,1,11],“default_gateway”:[192,168,1,1],“subnet_mask”:[255,255,255,255],“dns_primary”:[8,8,8,8],“dns_secondary”:[8,8,4,4],“update_available”:false,“update”:false,“update_path”:"",“firmware_version”:“1.0.0”,“mac”:"",“local_ip”:"",“cloud”:{“host”:"",“host_ip”:[x,x,x,x],“host_port”:1883,“tls”:false,“client_id”:“w”,“user_name”:“wwww”,“password”:“SET”,“user_topic_format”:“blank”,“user_gateway_topic_format”:“blank”,“custom_ids”:{},“message_format”:“blank”,“gateway_message_format”:“blank”},“nodeConfig”:false}}}]

Can you provide guidance? Order [#343915] and [#341760]

Thanks,
Kurt

Travis · June 6, 2019, 2:37pm

When do you get this error? I mean what interface page on the MQTT gateway’s web interface do you get this? On the devices page or just on the main settings page?

We just recently added compatibility for sensor type 40(V2 vibration sensor). I suppose it would be possible that we did not fully support it on the web interface but that should not prevent it from reporting through the MQTT Gateway to the MQTT server. Please let me know when you get this error.

Travis · June 6, 2019, 2:58pm

I think the best coarse of action is to perform a factory reset on the gateway, then try to set it up again. It’s strange that the above data shows your Host IP as x.x.x.x and the username is www.

To do a factory reset open the gateway lid and power it up. If it is not in setup mode then hold the CFG button down and wait for the LED to flash blue, then release the CFG button. Once it is in setup mode(LED flashing Blue) press and hold the CFG button until the LED begins flashing random colors, then release the CFG button. It should now be back to factory default settings and should be in setup mode. Try configuring it again now and let us know what you find.

kkrems · June 6, 2019, 8:26pm

Hi Travis,

Thanks for the fast response. Attached PDF with full test of what I performed. I’m still not seeing the PR52-33N listed in the gateway under the devices tab?

Let me know and thanks again,
KurtMQTT_GATEWAY.pdf (935.9 KB)

Travis · June 6, 2019, 9:48pm

Hi Kurt,

Yes, that may be normal for it to not show up on the devices page of the gateway since it is new and is not yet properly supported by the gateway. You should however still see the sensor information propagated to the MQTT broker.

Configuration of enterprise sensors through the Micro Gateways is still in Beta and is not extremely reliable yet. We still recommend configuring the sensors through the LabView utilities which you can get more information about on the Sensor’s product page. This will however require that you have a USB modem connected to your computer. Do you have a modem currently or is the MQTT Gateway the only device you have other than the sensor?

kkrems · June 6, 2019, 10:07pm

Hi Travis,

Unfortunately, I do not see the PR52-33N sensor information being propogated to MQTT broker. I do not have a USB modem and the MQTT Gateway is currently the only device other than the sensor.

Any thoughts on how to proceed with the Vibration and Temperature sensor? Any recommendations on a USB modem? Would the USB modem allow me to configure the sensor to the MQTT Gateway?

Thanks,
Kurt

Travis · June 7, 2019, 2:15pm

Hi Kurt,

Default settings in the sensor and gateway should allow them to communicate. The only way you can really break that is to change settings in the wireless modules which could only be done on the gateway manually on the advanced page so they should be communicating.

Have you powered up the sensor? You do have to open it and switch it on. On power up if your gateway is listening it should get a transmission from the sensor and should propagate that to the MQTT broker. You can also press the reset button on the sensor at any time to force a transmission(keep in mind it takes a few seconds).

I just looked at your orders again though and I see you have a Mega Modem. That can be used to configure the wireless sensor using the LabView utilities. You’ll want to set it up and then connect it to your computer over USB. If it does not mount as a virtual com/serial device you’ll want to install this driver:
https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers
Open the Configuration Utility available on the Sensor’s product page and you should be able to wirelessly configure it as explained in the sensor’s docs over USB connection to that Mega Modem.

kkrems · June 7, 2019, 2:57pm

Hi Travis,

I only see a ‘C’ and ‘R’ buttons on the PR52-33N sensor. Where is the power switch(Attached image)? I also hit the reset button on the sensor with no luck.

I returned the mega modem for the MQTT gateway as it was more fitting for our typical use cases.

Thanks, Travis.

Travis · June 7, 2019, 3:37pm

Hi Kurt,

Your sensor has a jumper rather than a switch. See here:

f983ef63b25ef8cca4c2c9d8fc6cebb1bf4135eb_2_375x500

Your sensor is currently off. We ship them in the off position so it does not kill the batteries during transit. Move that jumper to turn the sensor on. This probably explains why you were not getting any data

kkrems · June 7, 2019, 3:57pm

Travis,

Thank you! That did ‘obviously’ correct the issue. I can now see a sensor payload being propagated. However, It looks like another potential issue. See attached payload.

Any thoughts?

Thanks,
Kurt

Travis · June 7, 2019, 4:22pm

Hi,

Yes, I’ve seen that before. I would assume it is caused by what you entered for the sensor data format in the Gateway Setup Web interface. Different editors use a different character for double quotes and that is what is causing the problem. Did you copy and paste your sensor format from somewhere? If so that is likely the problem. Manually type in the sensor topic format and the sensor payload format in the MQTT Gateway UI and hopefully that will resolve the problem.

Travis · June 7, 2019, 4:25pm

Here’s a post that shows there are 3 different double quote characters in UTF8. As you can see by your screen shot above you have the ones that are sort of curled. You want the strait ones:

I have no idea who thought this was a good idea(3 different characters for double quotes).

kkrems · June 7, 2019, 5:25pm

Travis,

Thanks again! Attached result.

I am curious about a few pieces of the result.

Can the sensor payload deliver a timestamp
Can I change the interval for MQTT publication to a shorter/longer duration?
What is the range between the sensor and gateway?
Can I tune the vibration sensor?

Thanks again, Travis! The customer support has been outstanding! I’ll be doing a writeup and publishing internally as well as social media.

Regards,
Kurt

dkhayes117 · June 7, 2019, 5:40pm

As far as I know…
I don’t think the sensor can deliver a timestamp seeing as there is probably not room in the protocol to fit that data in. I haven’t used AWS, but I figure there should be a way to use a system timestamp when data is received on the cloud side? The sensor has a configurable delay that determines how often the sensor wakes up and send data. This is done in LabView with a zigmo router currently. The range depends on the environment. Just take your sensor and move it around and monitor the rssi value which is signal strength. I was able to get 60-70 yards of range through at least 4 walls and still had 22% signal strength. I don’t know if the vibration sensor can be manually adjusted, but seems like it has a built-in learning function to establish a baseline.

Bhaskar · June 7, 2019, 6:15pm

regarding the sensor tune up – sensor has in built self calibration. after installing the sensor press reset button and it will calibrate it for that machine.

Thanks

Travis · June 7, 2019, 6:30pm

Currently the gateway/sensor do not have timestamp capability, but as @dkhayes117 mentioned this should be easy to obtain on the cloud side(AWS). These sensors do not buffer data so as soon as the cloud receives the transmission it can be assumed that the current server time will be very close to the time this sensor data was sent by the sensor.

Again as @dkhayes117 pointed out that is up to the sensor configuration. It can be configured to send readings as often as you need, although I believe with these vibration sensors it takes them a few seconds to assemble a reading, this would be a good question for @Bhaskar who is the EE that designed this sensor.

We say range is roughly 2 miles with clear line of sight(antennas would need to be mounted up high) or roughly 1000ft for indoor/urban applications. I think @dkhayes117’s findings are pretty typical.

I’ll leave vibration sensor tuning questions to @Bhaskar

Keep us updated on your progress Kurt!

kkrems · June 7, 2019, 10:55pm

Great information guys,

Thanks again for the rapid responses!