PR52-33A (ind. temp/hum sensor) won't connect to new gateway

I had one NCD MQTT Micro Gateway communicating with a PR52-33A temperature/humidity sensor. They were working fine, and sending data up to Ubidots.

I now have another MQTT Micro Gateway and have turned off the old one. The new gateway led is green and shows up in Ubidots. The problem is:

  1. I am not seeing any new telemetry updates from the sensor in Ubidots
  2. The connectivity between the gateway and sensor seems finicky.

I have checked all power. I have placed some distance between the sensor and the gateway, and tried removing the antenna from the sensor. I have reset the sensor to factory defaults (reset button, then hold config for 20 seconds).

When I put the gateway in config mode, and look at the devices tab, it always appears blank. Once I hit reset on the sensor or turn it off and back on, it then appears in the gateway’s devices list.

It seems that, when the gateway goes into run mode and is green, it is not establishing communication with the sensor. I have tried resetting and powering the sensor off and back on while the gateway is in run mode / green.

I do not really know of a way to verify connectivity between the gateway and sensor while the gateway is in run mode. The only visibility I have is via Ubidots… and I am seeing no telemetry updates from the sensor.

Shouldn’t a sensor that is powered on automatically connect to a new gateway that is powered on and green?

Hi,

Is the new MQTT Gateway updating it’s telemetry information on Ubidots?

Have you tried powering up the old gateway just to verify the sensor is still functioning properly?

If the sensor shows up on the Gateway’s Devices tab then it should show up on Ubidots as well.

Hi @TravisE_NCD_Technica ,
The new gateway is not updating its telemetry on Ubidots. It does it once when powered on and getting to green but after that, no more updates. (See MicroGateway variables and updates not sending to Ubidots - #2 by ybakos)

I do not have the old gateway as I have deployed it. But, that old gateway has been powered on, has a sensor connected to it, and seems to be ok so far. (I am willing to bet that I will not see further Gateway telemetry updates though.)

When you say “If the sensor shows up on the Gateway’s Devices tab then it should show up on Ubidots as well.,” I agree, but here is what I see happening:

  1. Sensor is on and at a proper distance. I put the gateway into config mode. I view the devices tab and the list is empty.
  2. I turn off the sensor and turn it back on (or hit Reset). The sensor then suddenly appears in the gateway devices list.

Shouldn’t the sensor appear in the devices tab of the gateway immediately? Because it does not, I am suspicious that they are not talking/connecting once I put the gateway in run mode and it is green.

The Gateway only reports it’s telemetry upon boot so it’s normal that it does not send any more data.

Are you using a PR52-33A temperature/humidity sensor with the new gateway or is it a different sensor? Perhaps if it is a new sensor it is not yet supported in the MQTT Gateway firmware.

Thank you for the answer regarding gateway telemetry. Makes sense. (Although, it would be cool if it sent something every now and then, like power status, or device count). :slight_smile:

The PR52-33A is the sensor. The gateway is a PR55-21_AZURE that has been flashed to the MQTT Gateway firmware. The old gateway, that I was last successful with the sensor, was a PR55-21_MQTT.

Remove the board out of the Gateway box and you will find a USB connector. Plug that into your computer, then use a serial terminal application to monitor the output from the device. It should print some information to the terminal that would help us troubleshoot the issue.

Ok. Here is the output of my serial monitor. This output is immediately after I hit the red reset button, and I am using the cheap Arduino serial monitor to capture and display the serial output.

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1100
load:0x40078000,len:9232
load:0x40080400,len:6412
entry 0x400806a8
A8:03:2A:57:E0:9C
Not updating
settings.update is false
update path is blank
Seconds since last loop: 4.83
Pass is null
Gateway updated with Topic: /v1.6/devices/A8:03:2A:57:E0:9C Message: {"mac":"A8:03:2A:57:E0:9C","ip":"192.168.1.48","xbee_address":"00:13:A2:00:41:BA:BF:07","network_id":"7FFF","preamble":"0","tx_power":"4","xbee_ready":"1"}

And here is the serial output once I put the gateway into configure mode (holding down the red reset button until the led blinks blue).

Note that, this time, when I view the Devices tab in the gateway web config, I do indeed see the temp/humidity sensor! This is the first time it has appeared automatically without me needing to restart the sensor. But, no telemetry update sent to Ubidots.

ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1100
load:0x40078000,len:9232
load:0x40080400,len:6412
entry 0x400806a8
A8:03:2A:57:E0:9C
Seconds since last loop: 11.51
{"type":"IOT Gateway","model":7,"buzzer":0,"ssid":[{"ssid":"Harriman","rssi":-54,"encryption_type":true,"bssid":"E4:90:7E:F9:D1:C4","channel":1,"selected":true},{"ssid":"Spacfx","rssi":-79,"encryption_type":true,"bssid":"30:57:8E:14:BE:46","channel":1},{"ssid":"Fanaika","rssi":-82,"encryption_type":true,"bssid":"30:57:8E:93:C4:26","channel":1},{"ssid":"Go Beavs!","rssi":-84,"encryption_type":true,"bssid":"F0:9F:C2:D4:F2:0A","channel":6},{"ssid":"GoBeavs2","rssi":-84,"encryption_type":true,"bssid":"FA:9F:C2:D4:F2:0A","channel":6},{"ssid":"M Go Blue","rssi":-93,"encryption_type":true,"bssid":"14:91:82:96:19:08","channel":3}],"ssid_password":"__SET__","interval":5000,"azure_enabled":1,"http_enabled":false,"serial_print_enabled":false,"apPass":"__SET__","apSSID":"WiFi_Micro_Gateway","dhcp_enabled":1,"static_ip":[192,168,1,2],"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.1","wifi_enterprise_username":"","wifi_enterprise_identity":"","mac":"","local_ip":"","cloud":{"host":"industrial.api.ubidots.com","host_ip":[0,0,0,0],"host_port":1883,"tls":0,"client_id":"yong_home","user_name":"XXXX-private","user_topic_format":"/v1.6/devices/::Sensor_ID::","user_gateway_topic_format":"/v1.6/devices/::Gateway_ID::","custom_ids":{},"message_format":"::Sensor_Data::","gateway_message_format":"::Gateway_Data::","node_receive_topic":"endnodereceive","node_transmit_topic":"endnodetransmit"},"nodeConfig":false}
Configured Devices: {}
# ...
Configured Devices: {}
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1100
load:0x40078000,len:9232
load:0x40080400,len:6412
entry 0x400806a8
A8:03:2A:57:E0:9C
Not updating
settings.update is false
update path is blank
Seconds since last loop: 5.03
Pass is null

I put a # ... where it repeatedly displays Configured Devices: {} about fifty or so times. This is surprising, because the list here is empty, but I do see the sensor listed in the gateway’s web-based config Devices list. (!)

The last bit at the end is displayed after the config mode times out and the device resets into run mode.

Waited a few minutes and I see a new message in the serial monitor:

Publish success Topic: /v1.6/devices/00:13:A2:00:41:D6:3B:07 Message: 

Notice how the message is blank.

That’s very odd. I have not seen this before(empty message). I will dig a bit here and see if I can come up with a solution. I will more than likely have you re-flash your gateway in a bit.

Ok. In the mean time I will try another gateway. While I don’t have the old one that connected to the sensor I have two others boxes (mega modems) that I have just flashed to be mqtt gateways.

I also have some additional sensors I will connect to the “troubled” gateway and log the serial output.

Let me know what you find using a different gateway. This will determine if there is a bug in the code or if it is an issue only with that particular gateway. So far I am not seeing any issues in the firmware code.

I have just powered on a PR52-33J Wireless Activity Detection sensor and this troubled gateway is also displaying a blank Message payload.

Here’s another clue: the Message: data isn’t empty, it is, based on the console output, a long empty string. (Scroll to the right here:)

Gateway updated with Topic: /v1.6/devices/A8:03:2A:57:E0:9C Message: {"mac":"A8:03:2A:57:E0:9C","ip":"192.168.1.48","xbee_address":"00:13:A2:00:41:BA:BF:07","network_id":"7FFF","preamble":"0","tx_power":"4","xbee_ready":"1"}
Publish success Topic: /v1.6/devices/00:13:A2:00:41:C3:C6:49 Message:                                                                                                                                            Publish success Topic: /v1.6/devices/00:13:A2:00:41:C3:C6:49 Message:

I am suspicious of the gateway. I will try another gateway I have flashed and see what we get. I will also reflash and share the console output of the flashing process.

There must be something amiss with the firmware being used to flash these gateways. Here are the results of a Mega Modem that has been reflashed as an MQTT gateway.

Same behavior as the first troubled gateway - sensors do not appear in the Devices tab list in the setup UI. When I have that tab selected, the serial output is Devices: {} over and over again.

Here is the output during/after configuration for Ubidots.

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1100
load:0x40078000,len:9232
load:0x40080400,len:6412
entry 0x400806a8
AC:67:B2:DB:06:1C
Not updating
settings.update is false
update path is blank
Seconds since last loop: 4.92
Pass is null
Gateway updated with Topic: /v1.6/devices/AC:67:B2:DB:06:1C Message: {"mac":"AC:67:B2:DB:06:1C","ip":"192.168.1.84","xbee_address":"00:13:A2:00:41:C3:C5:BE","network_id":"7FFF","preamble":"0","tx_power":"4","xbee_ready":"1"}
load:0x40078000,len:9232
load:0x40080400,len:6412
entry 0x400806a8
AC:67:B2:DB:06:1C
Seconds since last loop: 7.25
{"type":"IOT Gateway","model":7,"buzzer":0,"ssid":[{"ssid":"Harriman","rssi":-48,"encryption_type":true,"bssid":"E4:90:7E:F9:D1:C4","channel":1,"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":1,"static_ip":[192,168,1,2],"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.1","wifi_enterprise_username":"","wifi_enterprise_identity":"","mac":"","local_ip":"","cloud":{"host":"api.industrial.ubidots.com","host_ip":[0,0,0,0],"host_port":1883,"tls":0,"client_id":"omep_c3c5be","user_name":"HIDINGFORPOST","user_topic_format":"/v1.6/devices/::Sensor_ID::","user_gateway_topic_format":"/v1.6/devices/::Gateway_ID::","custom_ids":{},"message_format":"::Sensor_Data::","gateway_message_format":"::Gateway_Data::","node_receive_topic":"endnodereceive","node_transmit_topic":"endnodetransmit"},"nodeConfig":false}
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1100
load:0x40078000,len:9232
load:0x40080400,len:6412
entry 0x400806a8
AC:67:B2:DB:06:1C
Not updating
settings.update is false
update path is blank
Seconds since last loop: 4.92
Pass is null
Gateway updated with Topic: /v1.6/devices/AC:67:B2:DB:06:1C Message: {"mac":"AC:67:B2:DB:06:1C","ip":"192.168.1.84","xbee_address":"00:13:A2:00:41:C3:C5:BE","network_id":"7FFF","preamble":"0","tx_power":"4","xbee_ready":"1"}
Publish success Topic: /v1.6/devices/00:13:A2:00:41:C3:C6:49 Message:
Publish success Topic: /v1.6/devices/00:13:A2:00:41:C3:C6:49 Message:
Publish success Topic: /v1.6/devices/00:13:A2:00:41:D6:3B:07 Message:

So we are at least seeing messages from the two sensors, even though they are blank.

Now, I am going to reflash again using these instructions: How to update Micro Gateway Firmware - ncd.io and I will record the console output.

Here is the result of reflashing the MegaModem to the MQTT gateway firmware.

(ncd_flashing) ~/projects/ncd_flashing[master] python ncd_flasher.py
Scanning for Serial Ports
Please wait for the scan to complete
Serial Port Options:
[1]: /dev/cu.Bluetooth-Incoming-Port
[2]: /dev/cu.SLAB_USBtoUART

Please enter the number of the desired Serial Port above: 2
Firmware Choices:
[1]: WiFi AWS Gateway
[2]: WiFi Azure Gateway
[3]: WiFi MQTT Gateway
[4]: WiFi Google IoT Gateway
[5]: Mega Modem
[6]: Cellular MQTT Gateway
[7]: Losant Gateway
[8]: 4 Relay MirPro
[9]: AWS WiFi Sensor
[10]: MQTT WiFi Sensor
[11]: Mirror PR53-4
[12]: Azure WiFi Sensor
[13]: Contact Closure Email Generator
[14]: ESP XBee

Please enter the number of the desired firmware: 3
https://ncd-esp32.s3.amazonaws.com/WiFi_MQTT/firmware.bin
('./firmware.bin', <http.client.HTTPMessage object at 0x10c0af580>)
https://ncd-esp32.s3.amazonaws.com/WiFi_MQTT/spiffs.bin
('./spiffs.bin', <http.client.HTTPMessage object at 0x10c0af5b0>)
https://ncd-esp32.s3.amazonaws.com/WiFi_MQTT/bootloader.bin
('./bootloader.bin', <http.client.HTTPMessage object at 0x10c0afe80>)
https://ncd-esp32.s3.amazonaws.com/WiFi_MQTT/partitions.bin
('./partitions.bin', <http.client.HTTPMessage object at 0x10c0af670>)
/dev/cu.SLAB_USBtoUART

fingers crossed:
esptool.py v2.8-dev
Serial port /dev/cu.SLAB_USBtoUART
Connecting....
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: ac:67:b2:db:06:1c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 16848 bytes to 10928...
Wrote 16848 bytes (10928 compressed) at 0x00001000 in 0.1 seconds (effective 910.7 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 131...
Wrote 3072 bytes (131 compressed) at 0x00008000 in 0.0 seconds (effective 3336.9 kbit/s)...
Hash of data verified.
Compressed 1507328 bytes to 38086...
Wrote 1507328 bytes (38086 compressed) at 0x00290000 in 1.8 seconds (effective 6710.0 kbit/s)...
Hash of data verified.
Compressed 1338704 bytes to 782362...
Wrote 1338704 bytes (782362 compressed) at 0x00010000 in 14.0 seconds (effective 763.3 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Then, here is the behavior after reconfiguring to talk to Ubidots, and the result of a sensor message - still blank.

Gateway updated with Topic: /v1.6/devices/AC:67:B2:DB:06:1C Message: {"mac":"AC:67:B2:DB:06:1C","ip":"192.168.1.84","xbee_address":"00:13:A2:00:41:C3:C5:BE","network_id":"7FFF","preamble":"0","tx_power":"4","xbee_ready":"1"}
Publish success Topic: /v1.6/devices/00:13:A2:00:41:C3:C6:49 Message:

I am now going to change the configuration of the message format to be some “fake” string to see if it shows up as the message payload.

When I change “Sensor Message Format” to THIS_IS_SENSOR_MESSAGE_FORMAT like this:

I see the following:

Gateway updated with Topic: /v1.6/devices/AC:67:B2:DB:06:1C Message: {"mac":"AC:67:B2:DB:06:1C","ip":"192.168.1.84","xbee_address":"00:13:A2:00:41:C3:C5:BE","network_id":"7FFF","preamble":"0","tx_power":"4","xbee_ready":"1"}
Publish success Topic: /v1.6/devices/00:13:A2:00:41:D6:3B:07 Message: THIS_IS_SENSOR_MESSAGE_FORMAT
Publish success Topic: /v1.6/devices/00:13:A2:00:41:C3:C6:49 Message: THIS_IS_SENSOR_MESSAGE_FORMAT

It was set to ::Sensor_Data:: per the instructions here (Connecting Ubidots to NCD Wireless IoT Sensors using MQTT) which has always previously worked for other gateways.

I am going to try some string interpolated syntax next.

I am suspicious of my particular firmware version and the expectations of how the configuration string is being parsed by the particular implementation of the gateway firmware.

I have now changed the Sensor Message Format” to the factory default {"::Sensor_ID::"::::Sensor_Data::}

And here is the serial monitor output.

Gateway updated with Topic: /v1.6/devices/AC:67:B2:DB:06:1C Message: {"mac":"AC:67:B2:DB:06:1C","ip":"192.168.1.84","xbee_address":"00:13:A2:00:41:C3:C5:BE","network_id":"7FFF","preamble":"0","tx_power":"4","xbee_ready":"1"}
Publish success Topic: /v1.6/devices/00:13:A2:00:41:C3:C6:49 Message: {"00:13:A2:00:41:C3:C6:49"::}
Publish success Topic: /v1.6/devices/00:13:A2:00:41:D6:3B:07 Message: {"00:13:A2:00:41:D6:3B:07"::}

Check it out. The firmware is not properly replacing ::Sensor_Data:: with the appropriate sensor telemetry JSON payload.

@TravisE_NCD_Technica This leads me to believe that the downloadable / flashable firmware has a bug or is out of date. (?)

The repo’s latest commit is 7f1a64335b2f7e98a5e8804378d429d590f5714b on Dec 16.

I notice that the flasher script is downloading/modifying the firmware.bin file that is committed in the repo. After running the flasher, the status of the repo is:

modified:   firmware.bin
modified:   partitions.bin
modified:   spiffs.bin

I believe I found the issue. It looks like a JSON library update broke parsing. I corrected it. Try flashing your gateway again and let me know if you have any trouble.

Thanks @TravisE_NCD_Technica

Issue is resolved. After re-flashing, serial monitor reports:

Publishing with packet from sensor: {"mac":[0,19,162,0,65,195,198,73],"data":[127,0,2,3,255,122,0,24,0,255,163,253,34,0,31,0,0]}
Sending to mqttPublish: {"data":{"transmission_count":122,"battery_level":3.29406,"type":24,"node_id":0,"rssi":100,"acc_x":-93,"acc_y":-734,"acc_z":31,"temp_change":0},"deviceID":"00:13:A2:00:41:C3:C6:49"}
message object before new topic: {"data":{"transmission_count":122,"battery_level":3.29406,"type":24,"node_id":0,"rssi":100,"acc_x":-93,"acc_y":-734,"acc_z":31,"temp_change":0},"deviceID":"00:13:A2:00:41:C3:C6:49"}
New Custom Topic: /v1.6/devices/00:13:A2:00:41:C3:C6:49
message object after new topic: {"transmission_count":122,"battery_level":3.29406,"type":24,"node_id":0,"rssi":100,"acc_x":-93,"acc_y":-734,"acc_z":31,"temp_change":0}
messageToSend: {"transmission_count":122,"battery_level":3.29406,"type":24,"node_id":0,"rssi":100,"acc_x":-93,"acc_y":-734,"acc_z":31,"temp_change":0}
Publish success Topic: /v1.6/devices/00:13:A2:00:41:C3:C6:49 Message: {"transmission_count":122,"battery_level":3.29406,"type":24,"node_id":0,"rssi":100,"acc_x":-93,"acc_y":-734,"acc_z":31,"temp_change":0}
                                             Publishing with packet from sensor: {"mac":[0,19,162,0,65,214,59,7],"data":[127,0,10,3,255,247,0,1,0,3,94,20,29]}
Sending to mqttPublish: {"data":{"transmission_count":247,"battery_level":3.29406,"type":1,"node_id":0,"rssi":100,"humidity":8.62,"temperature":51.49},"deviceID":"00:13:A2:00:41:D6:3B:07"}
message object before new topic: {"data":{"transmission_count":247,"battery_level":3.29406,"type":1,"node_id":0,"rssi":100,"humidity":8.62,"temperature":51.49},"deviceID":"00:13:A2:00:41:D6:3B:07"}
New Custom Topic: /v1.6/devices/00:13:A2:00:41:D6:3B:07
message object after new topic: {"transmission_count":247,"battery_level":3.29406,"type":1,"node_id":0,"rssi":100,"humidity":8.62,"temperature":51.49}
messageToSend: {"transmission_count":247,"battery_level":3.29406,"type":1,"node_id":0,"rssi":100,"humidity":8.62,"temperature":51.49}
Publish success Topic: /v1.6/devices/00:13:A2:00:41:D6:3B:07 Message: {"transmission_count":247,"battery_level":3.29406,"type":1,"node_id":0,"rssi":100,"humidity":8.62,"temperature":51.49}

Awesome. Please let me know if I can help with anything else.