<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class="">There probably isn't a<br class="">need for a custom SSID based on MAC or other serialization; that would<br class="">only be necessary if configuring multiple modules at the same time in<br class="">the same place.  Use case?</blockquote><div class=""><br class=""></div>Yep. My thoughts exactly.<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""> it might be<br class="">a good idea to have a required step of the configuration procedure be to<br class="">force a passkey change and re-connect on the part of the user.</blockquote><div class=""><br class=""></div>Yep. If we ask them to specify the AP name, and new password, then that resolves both problems.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">If things get messed up or forgotten, can't the module be reset to<br class="">factory with some button sequence?  I asked that regarding my /store<br class="">issue, but never heard back.</blockquote><div class=""><br class=""></div>We have two buttons:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">Hardwired RESET. That resets the chip.</li><li class="">IO0 BOOT. If held during BOOT, that goes into firmware download mode.</li></ol><div><br class=""></div><div>So, only #2 is usable, and that only after boot. I guess we could have a boot delay to allow time for it to be pressed after power up.</div><div><br class=""></div><div>But, that would require opening up the case to get to the button. Nasty. Plugging it into a PC is probably easier?</div><div><br class=""></div><div>Regards, Mark.</div><div><br class=""><blockquote type="cite" class=""><div class="">On 22 Feb 2018, at 12:37 PM, Greg D. <<a href="mailto:gregd2350@gmail.com" class="">gregd2350@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Mark,<br class=""><br class="">I like the idea of being able to configure the module by the internal<br class="">website via AP mode WiFi.  That's about as close to a universal<br class="">interface as exists on the planet right now.  There probably isn't a<br class="">need for a custom SSID based on MAC or other serialization; that would<br class="">only be necessary if configuring multiple modules at the same time in<br class="">the same place.  Use case?<br class=""><br class="">But if we have the wifi open (or fixed key) out of the box, it might be<br class="">a good idea to have a required step of the configuration procedure be to<br class="">force a passkey change and re-connect on the part of the user.  That<br class="">way, the car can't be controlled until it's configured, and once<br class="">configured it won't have the default AP passkey. <br class=""><br class="">If things get messed up or forgotten, can't the module be reset to<br class="">factory with some button sequence?  I asked that regarding my /store<br class="">issue, but never heard back.<br class=""><br class="">Greg<br class=""><br class=""><br class="">Mark Webb-Johnson wrote:<br class=""><blockquote type="cite" class="">Regarding the password, not all modules will have ICCID. The MAC<br class="">address is not externally visible. Maybe just have the access point<br class="">named OVMS.<last-bit-of-mac> and password OVMS? Then provide a<br class="">facility in the web UI to be able to change that password?<br class=""></blockquote><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></body></html>