FYI The order for production batch #2 has just been placed: 50x US kits (module + US 3G modem + Hologram sim) 150x EU kits (module + EU 3G modem + Hologram sim) 20x modules only (board + case, but no modem) 5x EU 3G modems (incl. Hologram sim) 5x US 3G modems (incl. Hologram sim) No change to specification and board layout from the first production batch, except to re-iterate the points that came in from feedback. We are arranging a foam box to ship the modules in, with our logo on it, to avoid the issues with sticky glue on those padded bags. Availability at Fasttech perhaps in about 3 weeks time. Our deadline for firmware is about 10 days. This is a lot of $$$ upfront payment, and the project is pretty tapped financially (I’ve had to pay for most of this myself). Once the money from sales starts to come in, we’ll be better off. I have quotes from certification labs for CE and FCC certs, and it seems possible. They say we may have some small changes to make (ESD primarily), but overall our design seems fine and they are confident we can achieve the certification. The process is expensive, but is just a one off upfront payment. Current plan is to start with that process once we have this production batch built and at Fasttech. We did consider doing this before this production batch #2, but that would have just delayed things several months. So long as this certification process doesn’t drag on, we should be able to keep OVMS v3 in stock and available from now. Regards, Mark.
Mark, thanks for the update and your monetary support. Regarding the CE/FCC certification, maybe we can raise some funds from the users interested in this, i.e. nearly all EU users. How much is it? Regarding the firmware deadline, 10 days may be a bit short for the wifi rework and new setup wizard to get done and mature enough for rollout. The web UI now checks for all common mistakes users made in their initial setup (I hope I got all of them…). I'll see if I can add a "quick setup" page of the main configuration options. We should replace the serial number process by the factory defaults (wifi AP "OVMS / OVMSinit", no shell password). Regards, Michael Am 02.05.2018 um 08:24 schrieb Mark Webb-Johnson:
FYI
The order for production batch #2 has just been placed:
* 50x US kits (module + US 3G modem + Hologram sim) * 150x EU kits (module + EU 3G modem + Hologram sim) * 20x modules only (board + case, but no modem) * 5x EU 3G modems (incl. Hologram sim) * 5x US 3G modems (incl. Hologram sim)
No change to specification and board layout from the first production batch, except to re-iterate the points that came in from feedback. We are arranging a foam box to ship the modules in, with our logo on it, to avoid the issues with sticky glue on those padded bags.
Availability at Fasttech perhaps in about 3 weeks time. Our deadline for firmware is about 10 days.
This is a lot of $$$ upfront payment, and the project is pretty tapped financially (I’ve had to pay for most of this myself). Once the money from sales starts to come in, we’ll be better off.
I have quotes from certification labs for CE and FCC certs, and it seems possible. They say we may have some small changes to make (ESD primarily), but overall our design seems fine and they are confident we can achieve the certification. The process is expensive, but is just a one off upfront payment. Current plan is to start with that process once we have this production batch built and at Fasttech. We did consider doing this before this production batch #2, but that would have just delayed things several months.
So long as this certification process doesn’t drag on, we should be able to keep OVMS v3 in stock and available from now.
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
Michael,
Regarding the CE/FCC certification, maybe we can raise some funds from the users interested in this, i.e. nearly all EU users. How much is it?
Certification lab is suggesting to do CE-RED and FCC-ID. The direct certificate test and consultancy charge is about US$2,000 for CE-RED, and US$4,000 for FCC-ID. Modifications to our circuit and test modules will probably cost not much at all (few hundred US$). Not sure about the actual certification filing fees (but I am told not excessive, and maybe able to negotiate with test lab). Also not sure about the other parts of CE, like WEEE (and still waiting for confirmation on that). Those prices are for a China lab doing it, and seem about the going rate. The testing process itself is 1 to 2 weeks (plus whatever time we need to make revisions in order to pass). Doing it in china speeds up those revision times to a matter of days. Financially, once the money for the first batch comes in fully, we can afford it out of project funds.
Regarding the firmware deadline, 10 days may be a bit short for the wifi rework and new setup wizard to get done and mature enough for rollout. The web UI now checks for all common mistakes users made in their initial setup (I hope I got all of them…). I'll see if I can add a "quick setup" page of the main configuration options.
I think so too. For me, it depends on how well the wifi re-work I am doing goes. I should know that this week. I am trying to get it so that the module can be configured as AP + STA mode, and then either AP or STA brought up and down as necessary (including taking down the STA, doing a scan, then bringing it back up). But the ESP32 IDF library is not co-operating.
We should replace the serial number process by the factory defaults (wifi AP "OVMS / OVMSinit", no shell password).
Yes. I will update the production notes and deal with factory for that. Should be fine, and much simpler for the user. But, need to get the prompt for password configuration during initial setup very clear to the user, to avoid this becoming a major vulnerability. Regards, Mark.
On 2 May 2018, at 5:00 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
thanks for the update and your monetary support.
Regarding the CE/FCC certification, maybe we can raise some funds from the users interested in this, i.e. nearly all EU users. How much is it?
Regarding the firmware deadline, 10 days may be a bit short for the wifi rework and new setup wizard to get done and mature enough for rollout. The web UI now checks for all common mistakes users made in their initial setup (I hope I got all of them…). I'll see if I can add a "quick setup" page of the main configuration options.
We should replace the serial number process by the factory defaults (wifi AP "OVMS / OVMSinit", no shell password).
Regards, Michael
Am 02.05.2018 um 08:24 schrieb Mark Webb-Johnson:
FYI
The order for production batch #2 has just been placed:
50x US kits (module + US 3G modem + Hologram sim) 150x EU kits (module + EU 3G modem + Hologram sim) 20x modules only (board + case, but no modem) 5x EU 3G modems (incl. Hologram sim) 5x US 3G modems (incl. Hologram sim)
No change to specification and board layout from the first production batch, except to re-iterate the points that came in from feedback. We are arranging a foam box to ship the modules in, with our logo on it, to avoid the issues with sticky glue on those padded bags.
Availability at Fasttech perhaps in about 3 weeks time. Our deadline for firmware is about 10 days.
This is a lot of $$$ upfront payment, and the project is pretty tapped financially (I’ve had to pay for most of this myself). Once the money from sales starts to come in, we’ll be better off.
I have quotes from certification labs for CE and FCC certs, and it seems possible. They say we may have some small changes to make (ESD primarily), but overall our design seems fine and they are confident we can achieve the certification. The process is expensive, but is just a one off upfront payment. Current plan is to start with that process once we have this production batch built and at Fasttech. We did consider doing this before this production batch #2, but that would have just delayed things several months.
So long as this certification process doesn’t drag on, we should be able to keep OVMS v3 in stock and available from now.
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
I have just pushed the first version of a setup wizard. It currently consists of five steps: 1. Secure module access (configure wifi AP and module password) 2. Connect module to internet (switch to Wifi APCLIENT mode) 3. Update to latest firmware version 4. Configure vehicle type and server 5. Configure modem (if equipped) I tried hard to avoid any dead ends and simplify the process as much as possible, but need your help to test if I really handled all potential screw-ups. I developed and tested the whole process on my 3.0 hardware module, so if you've got an unused 3.0 module you can use that for the test without destroying your car configuration. The wizard state is kept in config module / init, with states "1" … "5" = steps above + sub steps suffixed, and "done" being the final state. There is currently no "back" option, but you can simply set the config variable. You can start at any point, regardless of the configuration already existing. The wizard will also not change configuration options it doesn't need to touch, so you can run it also on an already configured module. But it's really meant to be a first init wizard, and thus won't be a standard menu option. It only shows if module/init is not "done". If you try the new version on an existing module, you won't see the wizard until you do: * config set module init "" …that's because the previous "password/changed" variable is migrated to "module/init=done". The wizard is offered on the home screen if init is empty. It automatically loads after login and from the home screen when started, but it does not block the UI. You can use all UI pages normally, to return to the wizard, simply click the home icon. Logging is currently maybe a bit excessive, especially as it's on the info level. That is to be able to get some debug info also from modules in default configuration. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
@All: please note there was an error in both sdkconfig default files, LWIP SO_REUSE was not enabled. That is necessary for the wifi reconfiguration to work. If you patch your existing sdkconfig, you also need to add the second line: CONFIG_LWIP_SO_REUSE=y CONFIG_LWIP_SO_REUSE_RXTOALL=y Regards, Michael Am 05.05.2018 um 20:57 schrieb Michael Balzer:
I have just pushed the first version of a setup wizard.
It currently consists of five steps:
1. Secure module access (configure wifi AP and module password) 2. Connect module to internet (switch to Wifi APCLIENT mode) 3. Update to latest firmware version 4. Configure vehicle type and server 5. Configure modem (if equipped)
I tried hard to avoid any dead ends and simplify the process as much as possible, but need your help to test if I really handled all potential screw-ups.
I developed and tested the whole process on my 3.0 hardware module, so if you've got an unused 3.0 module you can use that for the test without destroying your car configuration.
The wizard state is kept in config module / init, with states "1" … "5" = steps above + sub steps suffixed, and "done" being the final state. There is currently no "back" option, but you can simply set the config variable.
You can start at any point, regardless of the configuration already existing. The wizard will also not change configuration options it doesn't need to touch, so you can run it also on an already configured module. But it's really meant to be a first init wizard, and thus won't be a standard menu option.
It only shows if module/init is not "done". If you try the new version on an existing module, you won't see the wizard until you do:
* config set module init ""
…that's because the previous "password/changed" variable is migrated to "module/init=done".
The wizard is offered on the home screen if init is empty. It automatically loads after login and from the home screen when started, but it does not block the UI. You can use all UI pages normally, to return to the wizard, simply click the home icon.
Logging is currently maybe a bit excessive, especially as it's on the info level. That is to be able to get some debug info also from modules in default configuration.
Regards, Michael
-- 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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael, Really good. I had a quick run-through, and it seems to work. I have some factory modules here that I can try this with. A couple of minor suggestions: Step 3 (Update Firmware): I suggest the labels: Asia-Pacific (openvehicles.com) Europe (dexters-web.de) Step 4 (Vehicle and Server): I suggest the labels: No server connection Asia-Pacific (api.openvehicles.com) Europe (dexters-web.com) The only thing that worries me is the Wifi. I spent this week looking through the code I wrote months ago, and given what I know now, it is really not optimal. In particular, the way it works (with one primary mode) does not now seem correct (given what we know about the wifi stack now). I have now re-worked the wifi driver to work as follows: The wifi stack is powered up in ESP32 WIFI_MODE_APSTA. That allows us to have a STA, an AP, both, or neither. The STA settings are set completely independently of AP settings. So, a STA mode is set (off, scan-only, promiscuous (scanning-client), SSID, or SSID+BSSID). The AP settings are set completely independently of STA settings. So, an AP mode is set (off, or SSID). We now track the different modes and statuses, independently. This gives us a number of advantages: We can do a SCAN even when an STA or AP connection is up. This causes about 2 to 3 seconds of loss of connectivity, but doesn’t seem to kick anyone off. We can turn on/off a STA connection, without affecting the AP at all. We can turn on/off the AP, without affecting the STA connection at all. The STA code is much more symmetric, and scanning handled better. We can (in theory) have a scanning STA promiscuous client, combined with an active AP. I’m not 100% sure of the practicality of this (as I think the scan will affect the AP while it is ongoing), but it should be possible to some extent. The new code (and modes) is working for me, along with some new commands (wifi client, wifi accesspoint). I am now trying to convert the old commands to retain backwards compatibility (but I would like to deprecate those, long-term). The ‘auto’ system also needs conversion (but again, I’m trying to make it backwards compatible). I should be able to get to a level where I can commit (and push) today, for you to have a look at. Regards, Mark.
On 6 May 2018, at 2:57 AM, Michael Balzer <dexter@expeedo.de> wrote:
I have just pushed the first version of a setup wizard.
It currently consists of five steps: Secure module access (configure wifi AP and module password) Connect module to internet (switch to Wifi APCLIENT mode) Update to latest firmware version Configure vehicle type and server Configure modem (if equipped) I tried hard to avoid any dead ends and simplify the process as much as possible, but need your help to test if I really handled all potential screw-ups.
I developed and tested the whole process on my 3.0 hardware module, so if you've got an unused 3.0 module you can use that for the test without destroying your car configuration.
The wizard state is kept in config module / init, with states "1" … "5" = steps above + sub steps suffixed, and "done" being the final state. There is currently no "back" option, but you can simply set the config variable.
You can start at any point, regardless of the configuration already existing. The wizard will also not change configuration options it doesn't need to touch, so you can run it also on an already configured module. But it's really meant to be a first init wizard, and thus won't be a standard menu option.
It only shows if module/init is not "done". If you try the new version on an existing module, you won't see the wizard until you do: config set module init "" …that's because the previous "password/changed" variable is migrated to "module/init=done".
The wizard is offered on the home screen if init is empty. It automatically loads after login and from the home screen when started, but it does not block the UI. You can use all UI pages normally, to return to the wizard, simply click the home icon.
Logging is currently maybe a bit excessive, especially as it's on the info level. That is to be able to get some debug info also from modules in default configuration.
Regards, Michael
-- 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
Yes. That is a hardware limitation. I think if a client connection is made on a different channel, the AP is switched to match. Regards, Mark.
On 6 May 2018, at 11:55 AM, Greg D. <gregd2350@gmail.com> wrote:
Are AP and STA still constrained to use the same channel?
Greg
Mark Webb-Johnson wrote:
Michael,
Really good. I had a quick run-through, and it seems to work. I have some factory modules here that I can try this with.
A couple of minor suggestions:
Step 3 (Update Firmware): I suggest the labels: Asia-Pacific (openvehicles.com <http://openvehicles.com/>) Europe (dexters-web.de <http://dexters-web.de/>)
Step 4 (Vehicle and Server): I suggest the labels: No server connection Asia-Pacific (api.openvehicles.com <http://api.openvehicles.com/>) Europe (dexters-web.com <http://dexters-web.com/>)
The only thing that worries me is the Wifi. I spent this week looking through the code I wrote months ago, and given what I know now, it is really not optimal. In particular, the way it works (with one primary mode) does not now seem correct (given what we know about the wifi stack now). I have now re-worked the wifi driver to work as follows:
The wifi stack is powered up in ESP32 WIFI_MODE_APSTA. That allows us to have a STA, an AP, both, or neither. The STA settings are set completely independently of AP settings. So, a STA mode is set (off, scan-only, promiscuous (scanning-client), SSID, or SSID+BSSID). The AP settings are set completely independently of STA settings. So, an AP mode is set (off, or SSID). We now track the different modes and statuses, independently.
This gives us a number of advantages:
We can do a SCAN even when an STA or AP connection is up. This causes about 2 to 3 seconds of loss of connectivity, but doesn’t seem to kick anyone off. We can turn on/off a STA connection, without affecting the AP at all. We can turn on/off the AP, without affecting the STA connection at all. The STA code is much more symmetric, and scanning handled better. We can (in theory) have a scanning STA promiscuous client, combined with an active AP. I’m not 100% sure of the practicality of this (as I think the scan will affect the AP while it is ongoing), but it should be possible to some extent.
The new code (and modes) is working for me, along with some new commands (wifi client, wifi accesspoint). I am now trying to convert the old commands to retain backwards compatibility (but I would like to deprecate those, long-term). The ‘auto’ system also needs conversion (but again, I’m trying to make it backwards compatible).
I should be able to get to a level where I can commit (and push) today, for you to have a look at.
Regards, Mark.
On 6 May 2018, at 2:57 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I have just pushed the first version of a setup wizard.
It currently consists of five steps: Secure module access (configure wifi AP and module password) Connect module to internet (switch to Wifi APCLIENT mode) Update to latest firmware version Configure vehicle type and server Configure modem (if equipped) I tried hard to avoid any dead ends and simplify the process as much as possible, but need your help to test if I really handled all potential screw-ups.
I developed and tested the whole process on my 3.0 hardware module, so if you've got an unused 3.0 module you can use that for the test without destroying your car configuration.
The wizard state is kept in config module / init, with states "1" … "5" = steps above + sub steps suffixed, and "done" being the final state. There is currently no "back" option, but you can simply set the config variable.
You can start at any point, regardless of the configuration already existing. The wizard will also not change configuration options it doesn't need to touch, so you can run it also on an already configured module. But it's really meant to be a first init wizard, and thus won't be a standard menu option.
It only shows if module/init is not "done". If you try the new version on an existing module, you won't see the wizard until you do: config set module init "" …that's because the previous "password/changed" variable is migrated to "module/init=done".
The wizard is offered on the home screen if init is empty. It automatically loads after login and from the home screen when started, but it does not block the UI. You can use all UI pages normally, to return to the wizard, simply click the home icon.
Logging is currently maybe a bit excessive, especially as it's on the info level. That is to be able to get some debug info also from modules in default configuration.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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>
_______________________________________________ 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>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Mark, radio labels are changed. Your wifi rework will make the process much more streamlined, I think we can then completely avoid the long reconnect phase on step 2, and of course offer a selection of wifi networks from a scan. Btw, I've seen a WPS API, do you think we can use that? Don't invest too much time in backwards compatibility, the web UI can be changed easily to support separate control of AP/STA modes. Regards, Michael Am 06.05.2018 um 05:45 schrieb Mark Webb-Johnson:
Michael,
Really good. I had a quick run-through, and it seems to work. I have some factory modules here that I can try this with.
A couple of minor suggestions:
* Step 3 (Update Firmware): I suggest the labels: o Asia-Pacific (openvehicles.com <http://openvehicles.com>) o Europe (dexters-web.de <http://dexters-web.de>)
* Step 4 (Vehicle and Server): I suggest the labels: o No server connection o Asia-Pacific (api.openvehicles.com <http://api.openvehicles.com>) o Europe (dexters-web.com <http://dexters-web.com>)
The only thing that worries me is the Wifi. I spent this week looking through the code I wrote months ago, and given what I know now, it is really not optimal. In particular, the way it works (with one primary mode) does not now seem correct (given what we know about the wifi stack now). I have now re-worked the wifi driver to work as follows:
* The wifi stack is powered up in ESP32 WIFI_MODE_APSTA. That allows us to have a STA, an AP, both, or neither. * The STA settings are set completely independently of AP settings. So, a STA mode is set (off, scan-only, promiscuous (scanning-client), SSID, or SSID+BSSID). * The AP settings are set completely independently of STA settings. So, an AP mode is set (off, or SSID). * We now track the different modes and statuses, independently.
This gives us a number of advantages:
1. We can do a SCAN even when an STA or AP connection is up. This causes about 2 to 3 seconds of loss of connectivity, but doesn’t seem to kick anyone off. 2. We can turn on/off a STA connection, without affecting the AP at all. 3. We can turn on/off the AP, without affecting the STA connection at all. 4. The STA code is much more symmetric, and scanning handled better. 5. We can (in theory) have a scanning STA promiscuous client, combined with an active AP. I’m not 100% sure of the practicality of this (as I think the scan will affect the AP while it is ongoing), but it should be possible to some extent.
The new code (and modes) is working for me, along with some new commands (wifi client, wifi accesspoint). I am now trying to convert the old commands to retain backwards compatibility (but I would like to deprecate those, long-term). The ‘auto’ system also needs conversion (but again, I’m trying to make it backwards compatible).
I should be able to get to a level where I can commit (and push) today, for you to have a look at.
Regards, Mark.
On 6 May 2018, at 2:57 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I have just pushed the first version of a setup wizard.
It currently consists of five steps:
1. Secure module access (configure wifi AP and module password) 2. Connect module to internet (switch to Wifi APCLIENT mode) 3. Update to latest firmware version 4. Configure vehicle type and server 5. Configure modem (if equipped)
I tried hard to avoid any dead ends and simplify the process as much as possible, but need your help to test if I really handled all potential screw-ups.
I developed and tested the whole process on my 3.0 hardware module, so if you've got an unused 3.0 module you can use that for the test without destroying your car configuration.
The wizard state is kept in config module / init, with states "1" … "5" = steps above + sub steps suffixed, and "done" being the final state. There is currently no "back" option, but you can simply set the config variable.
You can start at any point, regardless of the configuration already existing. The wizard will also not change configuration options it doesn't need to touch, so you can run it also on an already configured module. But it's really meant to be a first init wizard, and thus won't be a standard menu option.
It only shows if module/init is not "done". If you try the new version on an existing module, you won't see the wizard until you do:
* config set module init ""
…that's because the previous "password/changed" variable is migrated to "module/init=done".
The wizard is offered on the home screen if init is empty. It automatically loads after login and from the home screen when started, but it does not block the UI. You can use all UI pages normally, to return to the wizard, simply click the home icon.
Logging is currently maybe a bit excessive, especially as it's on the info level. That is to be able to get some debug info also from modules in default configuration.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ 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
WPS isn't a good idea from a security perspective. It is (should be) one of the first things disabled when one sets up a new WiFi router at home, no? We did have (at least) one support ticket logged about not being able to get connected to the AP, but don't recall the root cause. Will moving away from the serial number-based passphrase solve that? Greg Michael Balzer wrote:
Btw, I've seen a WPS API, do you think we can use that?
From what I can see, WPS support is fairly trivial if we want it. https://github.com/espressif/esp-idf/tree/master/examples/wifi/wps Literally just two calls, and handle the appropriate events. But I suggest we get the new wifi driver working correctly first. Regards, Mark.
On 8 May 2018, at 7:36 AM, Greg D. <gregd2350@gmail.com> wrote:
WPS isn't a good idea from a security perspective. It is (should be) one of the first things disabled when one sets up a new WiFi router at home, no? We did have (at least) one support ticket logged about not being able to get connected to the AP, but don't recall the root cause. Will moving away from the serial number-based passphrase solve that?
Greg
Michael Balzer wrote:
Btw, I've seen a WPS API, do you think we can use that?
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I think I need at least another 24 to 48 hours for this. Just getting too many edge cases and esp wifi library weird stuff going on. It seems that sometimes we can change the mode easily, but other times not. Regards, Mark.
On 6 May 2018, at 11:45 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Michael,
Really good. I had a quick run-through, and it seems to work. I have some factory modules here that I can try this with.
A couple of minor suggestions:
Step 3 (Update Firmware): I suggest the labels: Asia-Pacific (openvehicles.com <http://openvehicles.com/>) Europe (dexters-web.de <http://dexters-web.de/>)
Step 4 (Vehicle and Server): I suggest the labels: No server connection Asia-Pacific (api.openvehicles.com <http://api.openvehicles.com/>) Europe (dexters-web.com <http://dexters-web.com/>)
The only thing that worries me is the Wifi. I spent this week looking through the code I wrote months ago, and given what I know now, it is really not optimal. In particular, the way it works (with one primary mode) does not now seem correct (given what we know about the wifi stack now). I have now re-worked the wifi driver to work as follows:
The wifi stack is powered up in ESP32 WIFI_MODE_APSTA. That allows us to have a STA, an AP, both, or neither. The STA settings are set completely independently of AP settings. So, a STA mode is set (off, scan-only, promiscuous (scanning-client), SSID, or SSID+BSSID). The AP settings are set completely independently of STA settings. So, an AP mode is set (off, or SSID). We now track the different modes and statuses, independently.
This gives us a number of advantages:
We can do a SCAN even when an STA or AP connection is up. This causes about 2 to 3 seconds of loss of connectivity, but doesn’t seem to kick anyone off. We can turn on/off a STA connection, without affecting the AP at all. We can turn on/off the AP, without affecting the STA connection at all. The STA code is much more symmetric, and scanning handled better. We can (in theory) have a scanning STA promiscuous client, combined with an active AP. I’m not 100% sure of the practicality of this (as I think the scan will affect the AP while it is ongoing), but it should be possible to some extent.
The new code (and modes) is working for me, along with some new commands (wifi client, wifi accesspoint). I am now trying to convert the old commands to retain backwards compatibility (but I would like to deprecate those, long-term). The ‘auto’ system also needs conversion (but again, I’m trying to make it backwards compatible).
I should be able to get to a level where I can commit (and push) today, for you to have a look at.
Regards, Mark.
On 6 May 2018, at 2:57 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I have just pushed the first version of a setup wizard.
It currently consists of five steps: Secure module access (configure wifi AP and module password) Connect module to internet (switch to Wifi APCLIENT mode) Update to latest firmware version Configure vehicle type and server Configure modem (if equipped) I tried hard to avoid any dead ends and simplify the process as much as possible, but need your help to test if I really handled all potential screw-ups.
I developed and tested the whole process on my 3.0 hardware module, so if you've got an unused 3.0 module you can use that for the test without destroying your car configuration.
The wizard state is kept in config module / init, with states "1" … "5" = steps above + sub steps suffixed, and "done" being the final state. There is currently no "back" option, but you can simply set the config variable.
You can start at any point, regardless of the configuration already existing. The wizard will also not change configuration options it doesn't need to touch, so you can run it also on an already configured module. But it's really meant to be a first init wizard, and thus won't be a standard menu option.
It only shows if module/init is not "done". If you try the new version on an existing module, you won't see the wizard until you do: config set module init "" …that's because the previous "password/changed" variable is migrated to "module/init=done".
The wizard is offered on the home screen if init is empty. It automatically loads after login and from the home screen when started, but it does not block the UI. You can use all UI pages normally, to return to the wizard, simply click the home icon.
Logging is currently maybe a bit excessive, especially as it's on the info level. That is to be able to get some debug info also from modules in default configuration.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
One of "my" testers managed to find a major bug in the wizard, allowing to enter an empty wifi client password, which would lead to a reboot loop. Luckily the user can use a USB terminal. Fix is pushed, along with some optimizations and other minor fixes. Mark, the wizard currently works with the old wifi implementation. If the wifi rework turns up new esp-idf bugs, given the deadline I think we should not include it in the production firmware yet. Regards, Michael Am 06.05.2018 um 16:48 schrieb Mark Webb-Johnson:
I think I need at least another 24 to 48 hours for this. Just getting too many edge cases and esp wifi library weird stuff going on. It seems that sometimes we can change the mode easily, but other times not.
Regards, Mark.
On 6 May 2018, at 11:45 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Michael,
Really good. I had a quick run-through, and it seems to work. I have some factory modules here that I can try this with.
A couple of minor suggestions:
* Step 3 (Update Firmware): I suggest the labels: o Asia-Pacific (openvehicles.com <http://openvehicles.com/>) o Europe (dexters-web.de <http://dexters-web.de/>)
* Step 4 (Vehicle and Server): I suggest the labels: o No server connection o Asia-Pacific (api.openvehicles.com <http://api.openvehicles.com/>) o Europe (dexters-web.com <http://dexters-web.com/>)
The only thing that worries me is the Wifi. I spent this week looking through the code I wrote months ago, and given what I know now, it is really not optimal. In particular, the way it works (with one primary mode) does not now seem correct (given what we know about the wifi stack now). I have now re-worked the wifi driver to work as follows:
* The wifi stack is powered up in ESP32 WIFI_MODE_APSTA. That allows us to have a STA, an AP, both, or neither. * The STA settings are set completely independently of AP settings. So, a STA mode is set (off, scan-only, promiscuous (scanning-client), SSID, or SSID+BSSID). * The AP settings are set completely independently of STA settings. So, an AP mode is set (off, or SSID). * We now track the different modes and statuses, independently.
This gives us a number of advantages:
1. We can do a SCAN even when an STA or AP connection is up. This causes about 2 to 3 seconds of loss of connectivity, but doesn’t seem to kick anyone off. 2. We can turn on/off a STA connection, without affecting the AP at all. 3. We can turn on/off the AP, without affecting the STA connection at all. 4. The STA code is much more symmetric, and scanning handled better. 5. We can (in theory) have a scanning STA promiscuous client, combined with an active AP. I’m not 100% sure of the practicality of this (as I think the scan will affect the AP while it is ongoing), but it should be possible to some extent.
The new code (and modes) is working for me, along with some new commands (wifi client, wifi accesspoint). I am now trying to convert the old commands to retain backwards compatibility (but I would like to deprecate those, long-term). The ‘auto’ system also needs conversion (but again, I’m trying to make it backwards compatible).
I should be able to get to a level where I can commit (and push) today, for you to have a look at.
Regards, Mark.
On 6 May 2018, at 2:57 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I have just pushed the first version of a setup wizard.
It currently consists of five steps:
1. Secure module access (configure wifi AP and module password) 2. Connect module to internet (switch to Wifi APCLIENT mode) 3. Update to latest firmware version 4. Configure vehicle type and server 5. Configure modem (if equipped)
I tried hard to avoid any dead ends and simplify the process as much as possible, but need your help to test if I really handled all potential screw-ups.
I developed and tested the whole process on my 3.0 hardware module, so if you've got an unused 3.0 module you can use that for the test without destroying your car configuration.
The wizard state is kept in config module / init, with states "1" … "5" = steps above + sub steps suffixed, and "done" being the final state. There is currently no "back" option, but you can simply set the config variable.
You can start at any point, regardless of the configuration already existing. The wizard will also not change configuration options it doesn't need to touch, so you can run it also on an already configured module. But it's really meant to be a first init wizard, and thus won't be a standard menu option.
It only shows if module/init is not "done". If you try the new version on an existing module, you won't see the wizard until you do:
* config set module init ""
…that's because the previous "password/changed" variable is migrated to "module/init=done".
The wizard is offered on the home screen if init is empty. It automatically loads after login and from the home screen when started, but it does not block the UI. You can use all UI pages normally, to return to the wizard, simply click the home icon.
Logging is currently maybe a bit excessive, especially as it's on the info level. That is to be able to get some debug info also from modules in default configuration.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ 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
If the wifi rework turns up new esp-idf bugs, given the deadline I think we should not include it in the production firmware yet.
It did. The Espressif documentation shows the flow as (a) init, (b) config, (c) start the wifi. They don’t talk about changing the config after start, at all. For Station side, I find I can (a) disconnect, (b) re-config, and (c) connect just fine. It works 100% of the time for me. I can also do scans while in connected state (as well as in blank empty client config disconnected state). I think this works so well because we have that connect/disconnect method. If an Access Point is needed, there is no point in using plain AP mode - APSTA seemingly has no drawbacks but has plenty of advantages (such as being able to do scans, and start/stop station connections, even while the access point it up). But for the Access Point side, there is no connect/disconnect method. The access point is started automatically when the wifi is started, and stopped when the wifi is stopped. Stopping the wifi disconnects the client side (which is undesirable). I find that with an access point running, I can simply re-config it and the wifi stack correctly stops and starts the access point - but it does it in a really messy way (seemingly indicating that this is a side-effect not a deliberate support). Worse, if I bring up wifi in APSTA mode, with a blank access point config, it starts a access point with a blank SSID. Dynamically changing between STA and APSTA mode seemed promising, but it is now randomly crashing for me. Bottom line is that I need more time to get this right. To work out how best to work-around the idiosyncrasies of the Espressif wifi stack. Deadline is approaching, so I’ll stash my changes for the moment, and come back to them later when we have more time. We’ll go with the current wifi driver for the 3.1.006 firmware release to factory. Regards, Mark.
On 6 May 2018, at 11:11 PM, Michael Balzer <dexter@expeedo.de> wrote:
One of "my" testers managed to find a major bug in the wizard, allowing to enter an empty wifi client password, which would lead to a reboot loop. Luckily the user can use a USB terminal.
Fix is pushed, along with some optimizations and other minor fixes.
Mark, the wizard currently works with the old wifi implementation.
If the wifi rework turns up new esp-idf bugs, given the deadline I think we should not include it in the production firmware yet.
Regards, Michael
Am 06.05.2018 um 16:48 schrieb Mark Webb-Johnson:
I think I need at least another 24 to 48 hours for this. Just getting too many edge cases and esp wifi library weird stuff going on. It seems that sometimes we can change the mode easily, but other times not.
Regards, Mark.
On 6 May 2018, at 11:45 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Michael,
Really good. I had a quick run-through, and it seems to work. I have some factory modules here that I can try this with.
A couple of minor suggestions:
Step 3 (Update Firmware): I suggest the labels: Asia-Pacific (openvehicles.com <http://openvehicles.com/>) Europe (dexters-web.de <http://dexters-web.de/>)
Step 4 (Vehicle and Server): I suggest the labels: No server connection Asia-Pacific (api.openvehicles.com <http://api.openvehicles.com/>) Europe (dexters-web.com <http://dexters-web.com/>)
The only thing that worries me is the Wifi. I spent this week looking through the code I wrote months ago, and given what I know now, it is really not optimal. In particular, the way it works (with one primary mode) does not now seem correct (given what we know about the wifi stack now). I have now re-worked the wifi driver to work as follows:
The wifi stack is powered up in ESP32 WIFI_MODE_APSTA. That allows us to have a STA, an AP, both, or neither. The STA settings are set completely independently of AP settings. So, a STA mode is set (off, scan-only, promiscuous (scanning-client), SSID, or SSID+BSSID). The AP settings are set completely independently of STA settings. So, an AP mode is set (off, or SSID). We now track the different modes and statuses, independently.
This gives us a number of advantages:
We can do a SCAN even when an STA or AP connection is up. This causes about 2 to 3 seconds of loss of connectivity, but doesn’t seem to kick anyone off. We can turn on/off a STA connection, without affecting the AP at all. We can turn on/off the AP, without affecting the STA connection at all. The STA code is much more symmetric, and scanning handled better. We can (in theory) have a scanning STA promiscuous client, combined with an active AP. I’m not 100% sure of the practicality of this (as I think the scan will affect the AP while it is ongoing), but it should be possible to some extent.
The new code (and modes) is working for me, along with some new commands (wifi client, wifi accesspoint). I am now trying to convert the old commands to retain backwards compatibility (but I would like to deprecate those, long-term). The ‘auto’ system also needs conversion (but again, I’m trying to make it backwards compatible).
I should be able to get to a level where I can commit (and push) today, for you to have a look at.
Regards, Mark.
On 6 May 2018, at 2:57 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I have just pushed the first version of a setup wizard.
It currently consists of five steps: Secure module access (configure wifi AP and module password) Connect module to internet (switch to Wifi APCLIENT mode) Update to latest firmware version Configure vehicle type and server Configure modem (if equipped) I tried hard to avoid any dead ends and simplify the process as much as possible, but need your help to test if I really handled all potential screw-ups.
I developed and tested the whole process on my 3.0 hardware module, so if you've got an unused 3.0 module you can use that for the test without destroying your car configuration.
The wizard state is kept in config module / init, with states "1" … "5" = steps above + sub steps suffixed, and "done" being the final state. There is currently no "back" option, but you can simply set the config variable.
You can start at any point, regardless of the configuration already existing. The wizard will also not change configuration options it doesn't need to touch, so you can run it also on an already configured module. But it's really meant to be a first init wizard, and thus won't be a standard menu option.
It only shows if module/init is not "done". If you try the new version on an existing module, you won't see the wizard until you do: config set module init "" …that's because the previous "password/changed" variable is migrated to "module/init=done".
The wizard is offered on the home screen if init is empty. It automatically loads after login and from the home screen when started, but it does not block the UI. You can use all UI pages normally, to return to the wizard, simply click the home icon.
Logging is currently maybe a bit excessive, especially as it's on the info level. That is to be able to get some debug info also from modules in default configuration.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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>
_______________________________________________ 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>
_______________________________________________ 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
FYI: I'm getting more reports of modules being stopped / sent back by german customs offices now. None crushed up to now AFAIK. Problem is, with the current module looking like a commercial product, customs officers no longer accept the hobbyist / development board declaration, they now require a CE label when checking the package contents. Regards, Michael Am 02.05.2018 um 13:40 schrieb Mark Webb-Johnson:
Michael,
Regarding the CE/FCC certification, maybe we can raise some funds from the users interested in this, i.e. nearly all EU users. How much is it?
Certification lab is suggesting to do CE-RED and FCC-ID. The direct certificate test and consultancy charge is about US$2,000 for CE-RED, and US$4,000 for FCC-ID. Modifications to our circuit and test modules will probably cost not much at all (few hundred US$). Not sure about the actual certification filing fees (but I am told not excessive, and maybe able to negotiate with test lab). Also not sure about the other parts of CE, like WEEE (and still waiting for confirmation on that).
Those prices are for a China lab doing it, and seem about the going rate. The testing process itself is 1 to 2 weeks (plus whatever time we need to make revisions in order to pass). Doing it in china speeds up those revision times to a matter of days.
Financially, once the money for the first batch comes in fully, we can afford it out of project funds.
Regarding the firmware deadline, 10 days may be a bit short for the wifi rework and new setup wizard to get done and mature enough for rollout. The web UI now checks for all common mistakes users made in their initial setup (I hope I got all of them…). I'll see if I can add a "quick setup" page of the main configuration options.
I think so too. For me, it depends on how well the wifi re-work I am doing goes. I should know that this week. I am trying to get it so that the module can be configured as AP + STA mode, and then either AP or STA brought up and down as necessary (including taking down the STA, doing a scan, then bringing it back up). But the ESP32 IDF library is not co-operating.
We should replace the serial number process by the factory defaults (wifi AP "OVMS / OVMSinit", no shell password).
Yes. I will update the production notes and deal with factory for that. Should be fine, and much simpler for the user. But, need to get the prompt for password configuration during initial setup very clear to the user, to avoid this becoming a major vulnerability.
Regards, Mark.
On 2 May 2018, at 5:00 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
thanks for the update and your monetary support.
Regarding the CE/FCC certification, maybe we can raise some funds from the users interested in this, i.e. nearly all EU users. How much is it?
Regarding the firmware deadline, 10 days may be a bit short for the wifi rework and new setup wizard to get done and mature enough for rollout. The web UI now checks for all common mistakes users made in their initial setup (I hope I got all of them…). I'll see if I can add a "quick setup" page of the main configuration options.
We should replace the serial number process by the factory defaults (wifi AP "OVMS / OVMSinit", no shell password).
Regards, Michael
Am 02.05.2018 um 08:24 schrieb Mark Webb-Johnson:
FYI
The order for production batch #2 has just been placed:
* 50x US kits (module + US 3G modem + Hologram sim) * 150x EU kits (module + EU 3G modem + Hologram sim) * 20x modules only (board + case, but no modem) * 5x EU 3G modems (incl. Hologram sim) * 5x US 3G modems (incl. Hologram sim)
No change to specification and board layout from the first production batch, except to re-iterate the points that came in from feedback. We are arranging a foam box to ship the modules in, with our logo on it, to avoid the issues with sticky glue on those padded bags.
Availability at Fasttech perhaps in about 3 weeks time. Our deadline for firmware is about 10 days.
This is a lot of $$$ upfront payment, and the project is pretty tapped financially (I’ve had to pay for most of this myself). Once the money from sales starts to come in, we’ll be better off.
I have quotes from certification labs for CE and FCC certs, and it seems possible. They say we may have some small changes to make (ESD primarily), but overall our design seems fine and they are confident we can achieve the certification. The process is expensive, but is just a one off upfront payment. Current plan is to start with that process once we have this production batch built and at Fasttech. We did consider doing this before this production batch #2, but that would have just delayed things several months.
So long as this certification process doesn’t drag on, we should be able to keep OVMS v3 in stock and available from now.
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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ 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
The problem we’ve had is that we have too many combinations, some are incompatible with each other (for example a SIM5360E EU modem in a FCC case), and this complicates things. But, it seems we can use the contains/includes feature of FCC to simplify. CE is easier. The approach we’ve narrowed this down to seems to be to certify: [A] OVMS v3 main board only (in case) - FCC + CE [B] SIM5360A standalone modem module - FCC [C] SIM5360E standalone modem module - CE We can label [B] and [C] on the circuit board itself. Label [A] will be on the case. As the core radio modules we use (WROVER-32, SIM5360A, SIM5360E) have the appropriate radio certifications already, we have minimised testing to just unintentional emissions and EMC stuff. We are currently waiting for the lab to confirm that is acceptable, and finalise costing. Hopefully certification can start soon (days). Once we’ve certified, we can also look for an EU distributor. I think that would make it much easier for you guys in Europe (as customs is proving a real hassle and delay for this). Any suggestions / offers would be great. Regards, Mark.
On 30 Aug 2018, at 1:06 AM, Michael Balzer <dexter@expeedo.de> wrote:
FYI: I'm getting more reports of modules being stopped / sent back by german customs offices now. None crushed up to now AFAIK.
Problem is, with the current module looking like a commercial product, customs officers no longer accept the hobbyist / development board declaration, they now require a CE label when checking the package contents.
Regards, Michael
Am 02.05.2018 um 13:40 schrieb Mark Webb-Johnson:
Michael,
Regarding the CE/FCC certification, maybe we can raise some funds from the users interested in this, i.e. nearly all EU users. How much is it?
Certification lab is suggesting to do CE-RED and FCC-ID. The direct certificate test and consultancy charge is about US$2,000 for CE-RED, and US$4,000 for FCC-ID. Modifications to our circuit and test modules will probably cost not much at all (few hundred US$). Not sure about the actual certification filing fees (but I am told not excessive, and maybe able to negotiate with test lab). Also not sure about the other parts of CE, like WEEE (and still waiting for confirmation on that).
Those prices are for a China lab doing it, and seem about the going rate. The testing process itself is 1 to 2 weeks (plus whatever time we need to make revisions in order to pass). Doing it in china speeds up those revision times to a matter of days.
Financially, once the money for the first batch comes in fully, we can afford it out of project funds.
Regarding the firmware deadline, 10 days may be a bit short for the wifi rework and new setup wizard to get done and mature enough for rollout. The web UI now checks for all common mistakes users made in their initial setup (I hope I got all of them…). I'll see if I can add a "quick setup" page of the main configuration options.
I think so too. For me, it depends on how well the wifi re-work I am doing goes. I should know that this week. I am trying to get it so that the module can be configured as AP + STA mode, and then either AP or STA brought up and down as necessary (including taking down the STA, doing a scan, then bringing it back up). But the ESP32 IDF library is not co-operating.
We should replace the serial number process by the factory defaults (wifi AP "OVMS / OVMSinit", no shell password).
Yes. I will update the production notes and deal with factory for that. Should be fine, and much simpler for the user. But, need to get the prompt for password configuration during initial setup very clear to the user, to avoid this becoming a major vulnerability.
Regards, Mark.
On 2 May 2018, at 5:00 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
thanks for the update and your monetary support.
Regarding the CE/FCC certification, maybe we can raise some funds from the users interested in this, i.e. nearly all EU users. How much is it?
Regarding the firmware deadline, 10 days may be a bit short for the wifi rework and new setup wizard to get done and mature enough for rollout. The web UI now checks for all common mistakes users made in their initial setup (I hope I got all of them…). I'll see if I can add a "quick setup" page of the main configuration options.
We should replace the serial number process by the factory defaults (wifi AP "OVMS / OVMSinit", no shell password).
Regards, Michael
Am 02.05.2018 um 08:24 schrieb Mark Webb-Johnson:
FYI
The order for production batch #2 has just been placed:
50x US kits (module + US 3G modem + Hologram sim) 150x EU kits (module + EU 3G modem + Hologram sim) 20x modules only (board + case, but no modem) 5x EU 3G modems (incl. Hologram sim) 5x US 3G modems (incl. Hologram sim)
No change to specification and board layout from the first production batch, except to re-iterate the points that came in from feedback. We are arranging a foam box to ship the modules in, with our logo on it, to avoid the issues with sticky glue on those padded bags.
Availability at Fasttech perhaps in about 3 weeks time. Our deadline for firmware is about 10 days.
This is a lot of $$$ upfront payment, and the project is pretty tapped financially (I’ve had to pay for most of this myself). Once the money from sales starts to come in, we’ll be better off.
I have quotes from certification labs for CE and FCC certs, and it seems possible. They say we may have some small changes to make (ESD primarily), but overall our design seems fine and they are confident we can achieve the certification. The process is expensive, but is just a one off upfront payment. Current plan is to start with that process once we have this production batch built and at Fasttech. We did consider doing this before this production batch #2, but that would have just delayed things several months.
So long as this certification process doesn’t drag on, we should be able to keep OVMS v3 in stock and available from now.
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 <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ 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
participants (3)
-
Greg D. -
Mark Webb-Johnson -
Michael Balzer