Here’s the progress message on the serial monitor:
Device: Blynk Refrigerator Tempera-N63M
Firmware: 0.1.5 (build Sep 19 2024 09:53:21)
Platform: ESP8266 @ 80MHz
Boot ver: 31
SDK: 2.2.2-dev(38a443e)
ESP Core: 3.1.2
Flash: 4096K
Free mem: 26392
[765] INIT => WAIT_CONFIG
[1475] AP URL: blynk.setup
The serial output waits for my Blynk app on my phone to continue. When I go to the app, I select “+ Add new device”, “Find devices nearby”, and proceed to connect to the device. The serial output then continues:
[15826] WAIT_CONFIG => CONFIGURING
[15826] Sending board info…
[18739] Scanning networks…
[20925] Found networks: 13
[37709] Applying configuration…
[37709] WiFi SSID: (myWiFi SSID was correct here) Pass: (my WiFi pass was correct here)
[37710] Blynk cloud: 0tYg1Ew4PiiFCt9yzCjPZuuUMQAe3y0R @ blynk.cloud:443
[37713] CONFIGURING => SWITCH_TO_STA
On my phone, it goes through the WiFi Configuring Device (as shown above), then reconnecting back to cloud (green checkmark), and then hangs on “Waiting for device online”. It always stalls there, and the device never comes on line. I think I’m missing something silly - can anyone point me to the obvious?
Are you using GPIO pins that conflict with those used in Settings.h ?
Pete.
Hello Pete: It’s possible. I discovered that the Feather Huzzah has a more limited set of I/O pins than other 8266 boards. I’m using a fair number of pins in my application, so I’ll recheck to see if I’ve duplicated anything. Thanks for your thoughtful response.
I think I’ve gotten around that particular issue - it seems that on the Adafruit Feather Huzzah, some GPIO pins are duplicated(!!) on both sides of the board, although the screen print labeling doesn’t reflect that. Which means that I have 3 fewer I/O pins to work with…
I have no idea why Adafruit would think that was a good idea. They’ve already labelled 6 pins as “NC”, so it’s already limited as to the I/O you can attach.
A couple of supplemental questions:
- After provisioning and everything working OK, I see in the Serial Monitor that the line ending “Hold the button for 10 seconds to reset configuration…” repeats many times before my data reads (on a timer) come through. I tried commenting out line 24 in ResetButton.h, but that didn’t work. I couldn’t find a reference to this anywhere else in the various components of the sketch. Any idea how to block this?
- I don’t anticipate that I will need OTA very much, if at all, on this device. Is there a simpler way to effect WiFi re-provisioning without the Edgent overhead?
Thanks in advance!
With regards to the “Hold the button…” repeating message on the Serial Monitor, a re-upload of the sketch with that line commented out fixed it.
No. If you wanted OTA but not provisioning then that’s easy to do with a non-Edgent sketch, but not the other way around.
I’m not familiar with the Huzzah hardware range, preferring to use regular(and far cheaper) ESP8266 based dev words like the Wemos D1 Mini or NodeMCU.
The problem with the ESP8266 is tear there are only really five GPIOs that you can use, and if you run an Edgent sketch then you’re using two of these for your LED and config reset switch (both of which you really need to reconfigure your device effectively).
TBH, now that ESP32 boards cost so little, it sounds like you’d be better with an ESP32 dev board unless there’s a reason you’re wedded to the Huzzar ecosystem.
Pete.
I feared that I had to take the whole package. Thanks for the info.
WRT the Feather Huzzah, I went with it for a couple of reasons - most importantly, I already had two on hand! I needed two, because I am building two devices to monitor and record fridge & freezer temperatures at a soup kitchen run by a relative. I wanted to have a combination SD card writer and RTC, and Adafruit makes a nice little matching shield that sits on top and does what I want.
I completely agree with your hardware preference - I’ve got a drawer-full of the WeMos D1’s and I really like them! I probably won’t buy any more Huzzah’s again, just because (as you say) they are more expensive and don’t confer any more flexibility than the D1’s.
Do you have any reason to think that the WiFi access to Blynk by the device would be blocked by “ordinary” routers or firewalls? I want to avoid any glitches in deployment by making this as bulletproof as possible - the destination for these devices is on the other side of Canada from me, about 4,200 km by road! Not an easy field service trip for me!
Not by ordinary routers, but if there’s a separate firewall appliance involved then it’s not an “ordinary” setup and the firewall may need to be reconfigured by the IT guys to allow Blynk traffic through.
If it is that remote then you really do need to get the credentials reset button and LED working correctly so someone on site can reconfigure it, although they would obviously need admin access on Blynk to do that if you don’t have a Pro account.
Pete.
I think this is a very simple WiFi setup in a church in Ontario. I very much doubt that they have a firewall appliance or any dedicated IT guys!
I don’t think I realized that they would require Admin access. That’s OK in this instance, since the person in question is my brother-in-law and he’s reasonably tech-savvy.
I’m retired (and don’t have any plans to turn this into a business), so I can’t justify the cost of having a Pro account. Is there no other way to give an ordinary user the ability to reprovision the device? Obviously, I can’t do it myself without knowing the SSID and password ahead of time, and that leaves open the chance that they might make changes to their WiFi at some time in the future.
You really need to look at users, device ownership, permissions etc if you’re using the free or maker subscriptions.
You can do this easily by creating another user and logging-in as that user, then trying to provision/use the device.
I don’t think you can invite an admin user to your device with free or maker subscriptions, so the solution is probably to transfer the device to the user and see what happens.
But, I keep coming back to the changes you’ve made to the reset button code.
Without this reset working properly your remote user wont be able to reprovision the device manually, and you won’t be able to do it remotely as you’ll have lost access if the WiFi settings have changed.
Pete.
Good advice, Pete - thanks. I’ll create a regular user and see if they can perform re-provisioning. I haven’t made any changes to the reset button code; I’m using a single-color LED so I only need two pins, and I was able to successfully hijack GPIO1 & 3. They are originally purposed as the serial TX & RX pins so I lose the serial monitor capability, but I was able to reprovision from my account on the mobile app using the button.
What exactly is involved in “transferring the device”? Does that require them to create their own Blynk free or maker subscription?
It’s done in the web console. Invite a user then when they’ve accepted you select the device and transfer it to them.
No, doing that will make it impossible to transfer the device.
Pete.
That seems straightforward enough, thanks!
A couple of final queries, and then I’ll stop pestering you:
- Once I have transferred ownership of a particular device or devices to a User, will they automatically receive access to the Mobile Dashboard or Web Dashboard that I created or will they have to build either or both for themselves?
- Once I have transferred ownership, will the User be able to reprovision the device(s) using the pushbutton that’s already a part of the device & proven to be working?
Thanks again for taking the time to answer and help - I really appreciate it! I have found that the documentation provided by Blynk, although voluminous, is sometimes lacking in full explanation of the odd things I need to know. It’s good to have someone as knowledgeable as yourself to turn to.
Yes.
Should be able to, try it.
Pete.
OK, I will give it a go. I’m going to try transferring ownership to my spouse here at home - that way, if she doesn’t have the permissions required I’ll have time to figure something else out. Perhaps I’ll have to hard-code the WiFi into the devices - I’d rather not do that, but if it comes down to the crunch that’s what I’ll do!
I’ll let you know how my next tests go - thanks again!
1 Like
Oh, before I make a bunch of extra work for myself, if I transfer ownership of a device to my spouse for testing, can it then be transferred to the correct owner at the final destination? If it’s a one-shot, I’ll simply create a third device, very simple, for testing only!
Transfer ownership back to you then delete the user.
Pete.
Thanks! Will give it a go later today and let you know. Hope you have a great weekend!
1 Like
Hi Pete:
Well, as I feared, the test was unsuccessful. I could transfer ownership of the device to an ordinary User, but that user does not have the option to “Reconfigure device” in the Android App. I guess the workaround is to hard-code the WiFi credentials in the ConfigStore.h portion of the code. I think I only need to declare the actual values in the ‘char’ definitions on lines 17 & 18 - is that correct? There are other references to ‘wifiSSID’ and ‘wifiPass’ in that code, but they aren’t replacements, I don’t think.
Do you have any suggestions to ensure that this works, or any other workarounds?
I really can’t justify Pro - this project is a charity one-off for me, and I have no interest in creating a business. Retirement suits me just fine!