WiFi configuration not being set

We got our boards & were happy to start integrating them:
Relay Controller 8-Channel General Purpose SPDT + 8 Channel ADC ProXR Lite
with WiFi Communications Module with Bluetooth USB MQTT
We are using:

Design & process seems good & sensible but we can’t get the WiFi configuration to take effect.

We have tried this with:

  • 2 different boards
  • jumper in both ‘run’ and ‘pgm’ position. We don’t see clarification that ‘pgm’ applies only to relay board configuration, or also wifi configuration.

What we do:

  • Powers up flashing green. Seems wrong, it doesn’t have a network, seems should be flashing red or blue.
  • We press small button nearest USB connector briefly, it starts flashing blue which is what we want. Note - we haven’t found documentation on those buttons, we just tried it & it worked.
  • Note - we assume the outer small button is ‘restart’, from trying it. Correct?
  • Indeed, we see NCD_NextGen in WiFi list, we connect successfully and get the config screen. All good, & well done.
  • We enable wifi, choose our site network from the dropdown (other devices are successfully on that network), enter password, disable dhcp, change gateway, mask 255.255.255.0, static IP normally - using 192.168.2.130 for this initial device
    ** We also later tried entering the SSID into the “Hidden network” box.
  • For this testing, we then change only Soft AP to a unique SSID/password, or not even change that. Not changing other elements yet, until WiFi works
  • Click “Save Settings” at bottom. Tried clicking twice.
  • PC does disconnect from that NCD_NextGen network

Now:

  • Board is flashing green
  • It is not on our network - Ubiquiti dashboard doesn’t show it (does show other devices), and the IP address does not respond to ping or HTTP access
  • The .2.130 address does not appear in any ARP listing
  • We have tried the ‘restart’ button, and power cycling the board, still not on our network
  • And pressing the small inner button to put it back in configuration/flashing blue mode, then connecting to NCD_NextGen as above (yes that shows in WiFi list), shows no settings have been changed.

Sorry - what are we missing?

There are two buttons on the module C and R. C is the configuration button, R is the reset button(just power cycles the module).

For testing try just enabling WiFi, select the SSID for the wifi network from the drop down, and enter the password, leave DHCP enabled. Then click save settings. The module should reboot and attempt to connect to the WiFi network. If it does not please let me know. I’m just wondering if there is an issue with Static IP. If this still does not work let me know if the network password contains any special characters(not alpha numeric), if so let me know which special characters it contains. Also please confirm the WiFi access point you are attempting to connect it to is 2.4ghz, the module does not support 5ghz WiFi.

@TravisE_NCD_Technica Thank you. It’s the password. Details + additional issue:

  • Our password was 32 chars long including #&@*
  • Remove those special chars, reduce to 25 chars, it works
  • Fixed IP is ok
  • Note: we added a new wifi network for that test. Doesn’t search for (new) networks on button C, only when press R then C again
  • Remember, those buttons are not documented anywhere we found
  • Your sample direct control commands work: e.g. 192.168.1.10/relayON?relay=1
  • Note: for those commands, relay numbers start at 0. The ProXR binary API commands start at 1

New issue - sendCommand fails:
The sample command
192.168.1.130/sendCommand?data:[254,108,1]
(our test IP address )
and variations of relay,action, bank etc do not work.

  • action does not take place on board
  • Chrome responds ERR_EMPTY_RESPONSE
  • We even tried the entire API string of byes but still no success

We much prefer using the sendCommand HTTP approach, faster to implement in our system. If that fails, we’ll have to go back to sockets.

I don’t have a setup here at my desk to test with but everything about the request appears to be correct. I will get back with you.

@TravisE_NCD_Technica Thanks, tried with another board/module just to be sure, all above the same.
FYI - one module reports name as “esp32-arduino” to our Ubiquity controller, the 2nd one reports its MAC address. Different revs, I suppose.

One of the devices would have to be quite old to have an old firmware version. There have not been changes to the firmware in way over a year. Do you know how long you have had them?

Just a couple weeks. invoice 49859. Talk to Nikki Elliott about that shipment.

But the 2 we tested (of 4 in shipment) had same result.

UPDATE TUES 1/30 12:20 PST:
Powered up & tested the last 2 of 4 boards in that shipment.
#4 is same as #1 & #2,

  • they talk,
  • they ping
  • they respond correctly to /RelayON?relay=2
  • as described above, they do not respond to sendCommand

#3:
These notes taken as did each step:

  • config page comes up properly, make same changes as others, now .2.132
  • shows as connected to Ubiquity AP as that IP
  • pings ok
  • when send same URL with /RelayON?relay=2 to it, which continues to work on other 3 boards, chrome says “refused to connect”
  • pressed the C button, it showed up in WiFi list with our configured SoftAP name (not the default). Saved, & it acted correctly & reconnected to the Ubiquity AP with the deployment SSID
  • repeated above, ping ok but same non-response to /RelayON?relay=2
  • even restarted AP,
  • ‘reconnected’ that module - now it’s not re-associating with AP at all
  • press C again, shows up again as our SoftAP name, saved etc
  • now same - associated, pings, responds to /RelayON?relay=2
  • so, ok now -- but concerned if flakey

If this helps, here are MAC addresses of the modules:

  1. .130 1c:9d:c2:c3:54:14
  2. .131 1c:9d:c2:c3:59:64
  3. .132 1c:9d:c2:c1:f6:00
  4. .133 40:f5:20:9a:0f:94

@TravisE_NCD_Technica
sendCommand issue RESOLVED

Your example on the wifi module page shows this:
192.168.1.130/sendCommand?data:[254,108,1]
but also this:
192.168.1.10/relayON?relay=1

One of our guys suddenly decided to try:
192.168.1.130/sendCommand?data=[254,108,1]
and it worked!

Ah. I completely overlooked that. I’ll get the docs updated. Thank you for letting me know.