Well, it has been an interesting few weeks as the first production batch of OVMS v3 came online. I don’t know about for others helping out with support tickets, but I’ve sure learned a lot - especially about what can go wrong for inexperienced users trying to setup a complex product. 14 support tickets were opened, along with another perhaps 6 calls for help via other means, and here are the most common problems encountered: Switched from Access Point mode to Client mode, and lost access. Can’t get into module via USB (drivers seem ok, but terminal emulators, and baud rates, are beyond most people’s understanding). Too hard for most to do a factory reset. Can’t see modem ICCID when powered off. Modem powered off by default, unless the little tick box is clicked. Server v2 off by default, unless the little tick box is clicked. Upper vs lower case on command execution. Unable to do firmware update in Access Point mode. Password confusion (wifi client vs module vs server vehicle vs server account vs access point vs OVMSinit vs etc etc). wifi vs modem switches and DNS settings. Modem SIM registration issues (can’t see, or don’t know how to see, status of simcom). Don’t understand how to check status. While some of these issues have been addressed, I am reluctant to release a new batch of modules to the world, especially this time with less technically capable users coming online. It is probably not ‘fun’ work, but I think we can make this much simpler for new users. We can lead them through the setup in the following stages: Require, as a pre-requisite, users to initially setup the module within range of a home wifi / cellular hotspot connection. Factory default, use Access Point mode, SSID OVMS password “OVMSinit”, and no module password. Have them connect to the module over wifi Access Point, and http://192.168.4.1/ <http://192.168.4.1/>. The web interface then shows them a list of WiFi access points in range, and asks them to choose one and enter the password for that access point (clearly labelled as SSID, and "<SSID> Password”). The module then reconfigures as Client + Access Point mode, and tries to connect to the client wifi, as well as keeping the access point connection open. If not ok, tell them and go back to #3 for them to try again. When ok, proceed to ask them to update the firmware. This will do a simple OTA download over HTTP, then reboot. When back up, in one screen ask them to enter all the details for their network, and configure appropriately: Use Wifi? WiFi Mode (AccessPoint+SpecificClient, or ScanningClient) OVMS Access Point SSID New OVMS Access Point password (as OVMSinit is insecure beyond initial setup) DNS (default: google, or custom) Module password (as default empty is insecure beyond initial setup) Use OVMS Server v2? Vehicle type Vehicle ID Vehicle Server password Vehicle server (openvehicles, dexter, or custom) Use modem? Modem APN, username and password (default: hologram) Test each of the above, and show them the results. Set auto appropriately, and disable quickstart then reboot. The point is to lead them through each of the steps, test each setting and show them the result. Technically, my only concern is the switch from AP to AP+client mode and whether the existing wifi connection will die or survive the channel switch. We also have to do a wifi scan, in Access Point mode, but I think we can do that by just temporarily turning off access point or doing it before the access point is brought up. Both these will depend on how ESP32 handles it. I’m happy to do a lot (if not all) of the above, but will definitely need help with the web side. But, first let’s agree on the proper list of questions to ask and flow to follow. Regards, Mark.
On 04/23/18 01:44, Mark Webb-Johnson wrote:
# Factory default, use Access Point mode, SSID OVMS password “OVMSinit”, and no module password. Have them connect to the module over wifi Access Point, and http://192.168.4.1/.
I thought making the setup wifi passphrase be the the serial number printed on the module was an excellent factory default. I've seen dsl modems that do this. When I see unique default passwords in products it gives a little confidence they were designed with security in mind. What would be really slick is if the smartphone apps could have a "setup new module" mode. I've never used it but I think ruckus wireless has this. The app looks for ssid's with the right name then prompts the user to enter the serial number, scan again to pick a wifi network, enter the details, etc. Craig
Craig, the serial number has a major issue: it's lost once you do a factory reset. So we need to tell people "use this password for your first setup, UNLESS you've done a factory reset, in which case you need to use that password". That's already too much to keep in mind for most of our current users. There is no serial number in the ESP32, and the modem is optional, so we can't use that or the hologram SIM. We thought about burning a serial number into an efuse, but that adds complexity and chance of failure to the QC procedure. The smartphone app extension is a nice idea, but I'd rather consider that an option. The setup should be possible without. Regards, Michael Am 23.04.2018 um 18:06 schrieb Craig Leres:
On 04/23/18 01:44, Mark Webb-Johnson wrote:
# Factory default, use Access Point mode, SSID OVMS password “OVMSinit”, and no module password. Have them connect to the module over wifi Access Point, and http://192.168.4.1/.
I thought making the setup wifi passphrase be the the serial number printed on the module was an excellent factory default. I've seen dsl modems that do this. When I see unique default passwords in products it gives a little confidence they were designed with security in mind.
What would be really slick is if the smartphone apps could have a "setup new module" mode. I've never used it but I think ruckus wireless has this. The app looks for ssid's with the right name then prompts the user to enter the serial number, scan again to pick a wifi network, enter the details, etc.
Craig
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Mark, I also had quite some user feedback to process over here. I could get some of them to send versions, backtraces and logs, very helpful. Current remaining main issues: * Mongoose crash after STA disconnect in AP+Client mode (issue #45) * OTA (http download) via modem * SD logging affects overall performance badly, leading to failures of time critical functions * Server v2 crash on modem connection loss (got two user logs on this today, will check this now) * Memory loss can still happen (I've some new clues on this, will check later) Also, I'm not sure the websocket queue lock issue is solved yet. It didn't occur for me in a while, but I've seen it in user logs, need to check their circumstances. I second the need for a fool proof setup procedure. We can track the setup state in a config instance, so it doesn't matter if the wifi mode switch needs a reconnect -- or the module crashes, or the user unplugs it in the process. Fools can't handle complex pages with multiple issues, so the setup wizard should perform the parts and tests in series if possible. Probably mainly a UI issue, I think about maybe an accordion for this. Do we need to include the DNS in the wizard? I think we can use a default and let the user change that later. Or is there no public DNS that is accessable from everywhere? Also, as the vehicle type is fundamental, it should not be under the "use server v2" option. Regards, Michael Am 23.04.2018 um 10:44 schrieb Mark Webb-Johnson:
Well, it has been an interesting few weeks as the first production batch of OVMS v3 came online. I don’t know about for others helping out with support tickets, but I’ve sure learned a lot - especially about what can go wrong for inexperienced users trying to setup a complex product. 14 support tickets were opened, along with another perhaps 6 calls for help via other means, and here are the most common problems encountered:
* Switched from Access Point mode to Client mode, and lost access. * Can’t get into module via USB (drivers seem ok, but terminal emulators, and baud rates, are beyond most people’s understanding). * Too hard for most to do a factory reset. * Can’t see modem ICCID when powered off. * Modem powered off by default, unless the little tick box is clicked. * Server v2 off by default, unless the little tick box is clicked. * Upper vs lower case on command execution. * Unable to do firmware update in Access Point mode. * Password confusion (wifi client vs module vs server vehicle vs server account vs access point vs OVMSinit vs etc etc). * wifi vs modem switches and DNS settings. * Modem SIM registration issues (can’t see, or don’t know how to see, status of simcom). * Don’t understand how to check status.
While some of these issues have been addressed, I am reluctant to release a new batch of modules to the world, especially this time with less technically capable users coming online.
It is probably not ‘fun’ work, but I think we can make this much simpler for new users. We can lead them through the setup in the following stages:
1. Require, as a pre-requisite, users to initially setup the module within range of a home wifi / cellular hotspot connection.
2. Factory default, use Access Point mode, SSID OVMS password “OVMSinit”, and no module password. Have them connect to the module over wifi Access Point, and http://192.168.4.1/.
3. The web interface then shows them a list of WiFi access points in range, and asks them to choose one and enter the password for that access point (clearly labelled as SSID, and "<SSID> Password”).
4. The module then reconfigures as Client + Access Point mode, and tries to connect to the client wifi, as well as keeping the access point connection open. If not ok, tell them and go back to #3 for them to try again.
5. When ok, proceed to ask them to update the firmware. This will do a simple OTA download over HTTP, then reboot.
6. When back up, in one screen ask them to enter all the details for their network, and configure appropriately: * Use Wifi? o WiFi Mode (AccessPoint+SpecificClient, or ScanningClient) o OVMS Access Point SSID o New OVMS Access Point password (as OVMSinit is insecure beyond initial setup) * DNS (default: google, or custom) * Module password (as default empty is insecure beyond initial setup) * Use OVMS Server v2? o Vehicle type o Vehicle ID o Vehicle Server password o Vehicle server (openvehicles, dexter, or custom) * Use modem? o Modem APN, username and password (default: hologram)
7. Test each of the above, and show them the results. Set auto appropriately, and disable quickstart then reboot.
The point is to lead them through each of the steps, test each setting and show them the result.
Technically, my only concern is the switch from AP to AP+client mode and whether the existing wifi connection will die or survive the channel switch. We also have to do a wifi scan, in Access Point mode, but I think we can do that by just temporarily turning off access point or doing it before the access point is brought up. Both these will depend on how ESP32 handles it.
I’m happy to do a lot (if not all) of the above, but will definitely need help with the web side.
But, first let’s agree on the proper list of questions to ask and flow to follow.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Probably best to raise those as github issues. To answer some:
OTA (http download) via modem I have my doubts of this. Our async link speed is 115200baud - even in ideal conditions, that is 3 to 6 minutes to download the firmware and 2 to 4MB of data bandwidth.
SD logging affects overall performance badly, leading to failures of time critical functions I wish I could find whoever was in charge of SD support and those bootstrapping pins, at Espressif, and slap them. I’ve wasted so much time on this and their flaky code.
We can track the setup state in a config instance, so it doesn't matter if the wifi mode switch needs a reconnect -- or the module crashes, or the user unplugs it in the process.
Yep. Exactly what I thought. Also makes it easier to test things and track state through reboots.
Fools can't handle complex pages with multiple issues, so the setup wizard should perform the parts and tests in series if possible. Probably mainly a UI issue, I think about maybe an accordion for this.
Yep.
Do we need to include the DNS in the wizard? I think we can use a default and let the user change that later. Or is there no public DNS that is accessable from everywhere?
For me, 8.8.8.8 and 8.8.4.4 work fine and universally. There are also other alternatives (such as the new cloudflare one at 1.1.1.1). Under the premise of “don't ask any question you don’t want to know the answer to”, I agree - best to just default to ours for quickstart and don’t even offer it. They can always go to Config / Network later and change it if they don’t like it. Given that google is blocked in China, perhaps 8.8.8.8 and 1.1.1.1 as default?
Also, as the vehicle type is fundamental, it should not be under the "use server v2" option.
Agreed. Also VehicleID I think (as it affects mdns). I’m working on the WiFi at the moment, as that seems critical to this. We need to know what happens when we do scans, or connect STA clients, while AP is running. It seems we are doing it wrong and it would be better to have client and ap set separately, rather than an overall mode. The documentation says if you set a AP+Client mode you can do both, including scans, but I don’t believe it - all I get are crashes. Anyway, I’m testing what is possible. Regards, Mark.
On 24 Apr 2018, at 12:17 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I also had quite some user feedback to process over here. I could get some of them to send versions, backtraces and logs, very helpful.
Current remaining main issues: Mongoose crash after STA disconnect in AP+Client mode (issue #45) OTA (http download) via modem SD logging affects overall performance badly, leading to failures of time critical functions Server v2 crash on modem connection loss (got two user logs on this today, will check this now) Memory loss can still happen (I've some new clues on this, will check later) Also, I'm not sure the websocket queue lock issue is solved yet. It didn't occur for me in a while, but I've seen it in user logs, need to check their circumstances.
I second the need for a fool proof setup procedure.
We can track the setup state in a config instance, so it doesn't matter if the wifi mode switch needs a reconnect -- or the module crashes, or the user unplugs it in the process.
Fools can't handle complex pages with multiple issues, so the setup wizard should perform the parts and tests in series if possible. Probably mainly a UI issue, I think about maybe an accordion for this.
Do we need to include the DNS in the wizard? I think we can use a default and let the user change that later. Or is there no public DNS that is accessable from everywhere?
Also, as the vehicle type is fundamental, it should not be under the "use server v2" option.
Regards, Michael
Am 23.04.2018 um 10:44 schrieb Mark Webb-Johnson:
Well, it has been an interesting few weeks as the first production batch of OVMS v3 came online. I don’t know about for others helping out with support tickets, but I’ve sure learned a lot - especially about what can go wrong for inexperienced users trying to setup a complex product. 14 support tickets were opened, along with another perhaps 6 calls for help via other means, and here are the most common problems encountered:
Switched from Access Point mode to Client mode, and lost access. Can’t get into module via USB (drivers seem ok, but terminal emulators, and baud rates, are beyond most people’s understanding). Too hard for most to do a factory reset. Can’t see modem ICCID when powered off. Modem powered off by default, unless the little tick box is clicked. Server v2 off by default, unless the little tick box is clicked. Upper vs lower case on command execution. Unable to do firmware update in Access Point mode. Password confusion (wifi client vs module vs server vehicle vs server account vs access point vs OVMSinit vs etc etc). wifi vs modem switches and DNS settings. Modem SIM registration issues (can’t see, or don’t know how to see, status of simcom). Don’t understand how to check status.
While some of these issues have been addressed, I am reluctant to release a new batch of modules to the world, especially this time with less technically capable users coming online.
It is probably not ‘fun’ work, but I think we can make this much simpler for new users. We can lead them through the setup in the following stages:
Require, as a pre-requisite, users to initially setup the module within range of a home wifi / cellular hotspot connection.
Factory default, use Access Point mode, SSID OVMS password “OVMSinit”, and no module password. Have them connect to the module over wifi Access Point, and http://192.168.4.1/ <http://192.168.4.1/>.
The web interface then shows them a list of WiFi access points in range, and asks them to choose one and enter the password for that access point (clearly labelled as SSID, and "<SSID> Password”).
The module then reconfigures as Client + Access Point mode, and tries to connect to the client wifi, as well as keeping the access point connection open. If not ok, tell them and go back to #3 for them to try again.
When ok, proceed to ask them to update the firmware. This will do a simple OTA download over HTTP, then reboot.
When back up, in one screen ask them to enter all the details for their network, and configure appropriately: Use Wifi? WiFi Mode (AccessPoint+SpecificClient, or ScanningClient) OVMS Access Point SSID New OVMS Access Point password (as OVMSinit is insecure beyond initial setup) DNS (default: google, or custom) Module password (as default empty is insecure beyond initial setup) Use OVMS Server v2? Vehicle type Vehicle ID Vehicle Server password Vehicle server (openvehicles, dexter, or custom) Use modem? Modem APN, username and password (default: hologram)
Test each of the above, and show them the results. Set auto appropriately, and disable quickstart then reboot.
The point is to lead them through each of the steps, test each setting and show them the result.
Technically, my only concern is the switch from AP to AP+client mode and whether the existing wifi connection will die or survive the channel switch. We also have to do a wifi scan, in Access Point mode, but I think we can do that by just temporarily turning off access point or doing it before the access point is brought up. Both these will depend on how ESP32 handles it.
I’m happy to do a lot (if not all) of the above, but will definitely need help with the web side.
But, first let’s agree on the proper list of questions to ask and flow to follow.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Hi Mark, We also need to handle home networks that are hidden. I think both this and the channel switch / scan problem can be handled by simply asking the user to enter both the SSID and Passphrase manually. It's not a huge concern if it doesn't connect on restart, since the AP side still works in AP+Client mode. A connection failure can be highlighted for re-entry (probably good regardless of whether you've completed the setup procedure or not). Greg Mark Webb-Johnson wrote:
Technically, my only concern is the switch from AP to AP+client mode and whether the existing wifi connection will die or survive the channel switch. We also have to do a wifi scan, in Access Point mode, but I think we can do that by just temporarily turning off access point or doing it before the access point is brought up.
I would at least like to give the user the opportunity to choose from a list. Trying hard to reduce the chance of error, and typing in SSIDs is error-prone. We can also give the option of ‘custom’ to enter their own manually. Chances are, if the user has hidden their SSID then they know enough to be fairly technically savvy (but not enough to know that it is a waste of time and offers practically no extra protection over a visible SSID). Actually, probably a pretty good indicator of technical competence of the user ;-) Regards, Mark.
On 24 Apr 2018, at 5:56 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
We also need to handle home networks that are hidden. I think both this and the channel switch / scan problem can be handled by simply asking the user to enter both the SSID and Passphrase manually. It's not a huge concern if it doesn't connect on restart, since the AP side still works in AP+Client mode. A connection failure can be highlighted for re-entry (probably good regardless of whether you've completed the setup procedure or not).
Greg
Mark Webb-Johnson wrote:
Technically, my only concern is the switch from AP to AP+client mode and whether the existing wifi connection will die or survive the channel switch. We also have to do a wifi scan, in Access Point mode, but I think we can do that by just temporarily turning off access point or doing it before the access point is brought up.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I really liked the way athom.com did it with their 'Homey' home automation device. Their setup.homey.com page tells you step by step what to do, and pre-loads the firmware update, so once you have connected to homey's wifi hotspot, it can upgrade the firmware through the browser and configure the device. https://www.youtube.com/watch?v=ctAGzdC4rvc -Michael Op 23-4-2018 om 10:44 schreef Mark Webb-Johnson:
Well, it has been an interesting few weeks as the first production batch of OVMS v3 came online. I don’t know about for others helping out with support tickets, but I’ve sure learned a lot - especially about what can go wrong for inexperienced users trying to setup a complex product. 14 support tickets were opened, along with another perhaps 6 calls for help via other means, and here are the most common problems encountered:
* Switched from Access Point mode to Client mode, and lost access. * Can’t get into module via USB (drivers seem ok, but terminal emulators, and baud rates, are beyond most people’s understanding). * Too hard for most to do a factory reset. * Can’t see modem ICCID when powered off. * Modem powered off by default, unless the little tick box is clicked. * Server v2 off by default, unless the little tick box is clicked. * Upper vs lower case on command execution. * Unable to do firmware update in Access Point mode. * Password confusion (wifi client vs module vs server vehicle vs server account vs access point vs OVMSinit vs etc etc). * wifi vs modem switches and DNS settings. * Modem SIM registration issues (can’t see, or don’t know how to see, status of simcom). * Don’t understand how to check status.
While some of these issues have been addressed, I am reluctant to release a new batch of modules to the world, especially this time with less technically capable users coming online.
It is probably not ‘fun’ work, but I think we can make this much simpler for new users. We can lead them through the setup in the following stages:
1. Require, as a pre-requisite, users to initially setup the module within range of a home wifi / cellular hotspot connection.
2. Factory default, use Access Point mode, SSID OVMS password “OVMSinit”, and no module password. Have them connect to the module over wifi Access Point, and http://192.168.4.1/.
3. The web interface then shows them a list of WiFi access points in range, and asks them to choose one and enter the password for that access point (clearly labelled as SSID, and "<SSID> Password”).
4. The module then reconfigures as Client + Access Point mode, and tries to connect to the client wifi, as well as keeping the access point connection open. If not ok, tell them and go back to #3 for them to try again.
5. When ok, proceed to ask them to update the firmware. This will do a simple OTA download over HTTP, then reboot.
6. When back up, in one screen ask them to enter all the details for their network, and configure appropriately: * Use Wifi? o WiFi Mode (AccessPoint+SpecificClient, or ScanningClient) o OVMS Access Point SSID o New OVMS Access Point password (as OVMSinit is insecure beyond initial setup) * DNS (default: google, or custom) * Module password (as default empty is insecure beyond initial setup) * Use OVMS Server v2? o Vehicle type o Vehicle ID o Vehicle Server password o Vehicle server (openvehicles, dexter, or custom) * Use modem? o Modem APN, username and password (default: hologram)
7. Test each of the above, and show them the results. Set auto appropriately, and disable quickstart then reboot.
The point is to lead them through each of the steps, test each setting and show them the result.
Technically, my only concern is the switch from AP to AP+client mode and whether the existing wifi connection will die or survive the channel switch. We also have to do a wifi scan, in Access Point mode, but I think we can do that by just temporarily turning off access point or doing it before the access point is brought up. Both these will depend on how ESP32 handles it.
I’m happy to do a lot (if not all) of the above, but will definitely need help with the web side.
But, first let’s agree on the proper list of questions to ask and flow to follow.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (5)
-
Craig Leres -
Greg D. -
Mark Webb-Johnson -
Michael Balzer -
Michael Stegen