Difficulties getting a virgin board up and working #212
Comments
|
On Thu, 16 Mar 2017, Simon wrote:
Is anyone else finding it tricky to get a brand new board up and running? I've got a batch of Wemos D1 minis and the sequence goes as this:-
1. Pull the latest code
2. Use Arduino IDE to compile & upload code
3. System reboot, serial monitor showing the board is trying to connect to the 2 unknown wifi networks
4. 1min in WiFi AP mode - quick grab phone and try to switch wifi network to connect in time
5. AP not showing in phone - out of time, WDT reset
6. Loop back to 3 ad nausium....
Is there a better way of getting connected? I have tried sending commands over the serial link, but get no response.
set the wifi networks you want it to connect to in user_config.h (or
user_config_override.h)
that way you aren't having to try various trickery to get it to connect to your
network.
David Lang
|
|
Yes, I understand I can do that, David, but it's about having standard code and operational modes that are useful. I wonder if it would be better to start with no wifi, logging or mqtt servers in the code by default and for the devices to go to AP mode & accept serial interface commands when first started - not just for a minute. |
|
Surely for most people the easiest way would be to go into local AP mode when the button is held down? that's the way most similar commerical devices ship out of the box (and in fact the way the sonoff does with stock firmware). I think this mode would make the most sense if you were to for example want to resell pre-flashed devices (i.e. to people who don't know how to solder and flash) Having said that the "default" AP and mqtt/syslog domains could be removed I think from user-config (and default to off) as they will never be right for anyone else (other than @arendst :)). MQTT is actually quite annoying when not configured correctly but on as it tries to connect every 10 seconds and the portal device lags/hangs significantly while it trys to look up mDNS and then also when trying to connect. |
|
On Thu, 16 Mar 2017, Simon wrote:
Yes, I understand I can do that, David, but it's about having standard code
and operational modes that are useful. I wonder if it would be better to start
with no wifi, logging or mqtt servers in the code by default and for the
devices to go to AP mode & accept serial interface commands when first started
- not just for a minute.
for most modules, it does accept serial interface commands, with no time limit.
But some modules use the serial port and so that's not a safe thing to rely on.
I don't understand your reluctance to set the parameters before flashing. If you
don't want to modify the user_config.h you can set them in
user_config_override.h and only set the ones that you care about.
You have the option with both methods of setting the wifi to come up in AP mode,
but that is insecure and not something that it should sit in for long (you don't
want someone parked nearby to reconfigure these devices for you, right?)
You are complaining that the process is too complicated, but you are not willing
to use the methods provided to set your own defaults.
|
|
On Thu, 16 Mar 2017, khcnz wrote:
Having said that the "default" AP and mqtt/syslog domains could be removed I think from user-config (and default to off) as they will never be right for anyone else (other than @arendst :)).
you are ignoring the instructions that tell people to edit that file and set
them to what's appropriate for their network.
Sonoff-Tasmota is not designed for a vendor mass-producing modules and
installing this on all of them. If it were to be used for that, the defaults
would need to be changed.
It's designed for people setting up their own devices, in which case setting the
defaults in a file (either user_default.h or user_default_override.h) is very
reasonable.
|
It's a small side note at the bottom of one page, and one of the other pages implies the wifi mode from the button multi-press is the right way. Easy to miss if you are a first timer. My point was more so that those defaults could never be right - so IMO they just add a bit of confusion when first starting out (whats MQTT? whats this wifi network? whats domus? why does the UI keep hanging?) :)
Agreed, bad choice of words, and anyone distributing them in such a manner would be able to cope with updating the config as such
I think this is where we differ (and remember I am new to the project :)) with members providing statically hosted compiled versions and most options being in the webui all someone now would need is a soldering iron and run a command line - no coding ability needed. What if itead even let you enter a URL in their app to configure a custom flash path for example - then even a soldering iron wouldn't be needed |
|
@Smads (Simon) you were starting off on the right track only your step 4 won't work for the default compile as it won't provide Wifi AP mode as you expected but it will start in WPS mode as defined on line 29 in the user_config.h file (WIFI_CONFIG_TOOL). This value is the result of earlier requests where people thought that WPS would be a more logical approach to initial installation... It's just a matter of deciding which of three ways to choose from. For one WPS is the holy grail, for others Wifi AP and for me initially it was Wifi Smartconfig (using an app on your phone). All three options can be selected by button presses on the sonoff as I hoped to explain in the wiki - button section but I agree it tend to be trial and error. As David suggested you should be able to enter your Wifi parameters via serial too as SSID1 and PASSWORD1 commands during the 10 seconds or so before sonoff will retry the other AP.... I honesty thought I had provided more than enough possibilities to get the thing going but as there are so many unique people I can't satisfy them all. |
|
@khcnz Ah two souls one mind |
|
On Fri, 17 Mar 2017, khcnz wrote:
> It's designed for people setting up their own devices, in which case setting the
> defaults in a file (either user_default.h or user_default_override.h) is very
> reasonable.
I think this is where we differ (and remember I am new to the project :)) with members providing statically hosted compiled versions and most options being in the webui all someone now would need is a soldering iron and a bit of python - no coding ability needed.
While memebers are providing precompiled images, I think anyone using them is
being, shall we say, "overly trusting". You have no idea who these people are,
and no idea if the images provided actually use the released source.
What if itead even let you enter a URL in their app to configure a custom flash path for example - then even a soldering iron wouldn't be needed
it's a bit more complicated than that, even arendst's first generation of
firmware can't be upgraded to sonoff-tasmota because it needs to be installed at
a different address in flash.
|
|
Maybe just extend the default time in AP mode after failing the 2 stored SSIDs from 1 to 3 minutes to give phones a chance to catch the AP? Theo - I agree you have done a huge amount, and I'm very grateful. I felt guilty suggesting removing your own profile details from the defaults. But then again, I would not expect to see Microsoft's in-house wifi credentials when I first start Windows ;) |
|
Just checked but it seems the timeout for SmartConfig (using the phone App) is 60 seconds. Wifi Config (using the AccessPoint) timeout is 120 seconds. Perhaps I have to add some kind of age multiplier to it ;;;---))). |
|
@arendst what is the status of this? is it a wontfix or are you going to increase the timeouts? |
|
@arendst ping about the timeouts question. |
|
Change WifiConfig timeout from 60 seconds to 180 seconds in next release |
|
That's great - thanks Theo |
5.0.3 20170504 * Add command SensorRetain on|off to enable retaining of mqtt message tele/sonoff/SENSOR (#74) * Change WifiConfig timeout from 60 seconds to 180 seconds (#212) * Change Sonoff Touch command Ledstate functionality by turning led on if power is off (#214) * Add 4 seconds delay after power on before enabling button to workaround Wemos D1 mini RTS circuit (#380)
5.0.3 20170504 * Add command SensorRetain on|off to enable retaining of mqtt message tele/sonoff/SENSOR (arendst#74) * Change WifiConfig timeout from 60 seconds to 180 seconds (arendst#212) * Change Sonoff Touch command Ledstate functionality by turning led on if power is off (arendst#214) * Add 4 seconds delay after power on before enabling button to workaround Wemos D1 mini RTS circuit (arendst#380)
|
Hi, |
|
Sorry, Tasmota is not meant for what you want. Tasmota is meant for home automation to be used with mqtt broker. Please, see readme |
|
It is not correct , you can send also http command to tasmota without an mqtt broker!! http://sonoff/cm?cmnd=Power%20TOGGLE http://sonoff/cm?&user=put_username_here&password=put_password_here&cmnd=Power%20On |
|
Hi, sorry. Tasmota is not a Stand Alone device. Sorry. Please see readme for actual scope of Tasmota: Home Automation |
|
The rules system and sensor integrations make Tasmota ideal for standalone operation. I have a dozen devices out there that only connect to my phone's hotspot for configuration and otherwise do their job autonomously using rules. Device groups would even allow them to communicate with each other if they just had an access point. I understand that this is not the main use case for Tasmota, but would the core team be willing to review a pull request for a |
|
@AndreKR Don't hijack an old Issue with an off-topic message |
Is anyone else finding it tricky to get a brand new board up and running? I've got a batch of Wemos D1 minis and the sequence goes as this:-
Is there a better way of getting connected? I have tried sending commands over the serial link, but get no response.
Could the default code be SSID-less and put boards in AP mode until set (without a timeout)?
The text was updated successfully, but these errors were encountered: