<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 29, 2017 at 1:46 PM, Zaid Abdulla <span dir="ltr"><<a href="mailto:zaid@genieacs.com" target="_blank">zaid@genieacs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hehe. I'm surprised it even works fine with that many presets! <br>
<br></blockquote><div><br></div><div>Well, load is a bit high on the server :).</div><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Why not use a single provision that fetches custom user config from an external<br>database and configure the device accordingly?<br><br></blockquote><div><br></div><div>Thats a can of worms because we'd be storing the Wi-Fi passphrase for CPEs in our system. I barely got by-off to store the creds on the ACS itself (because the ACS is on a very protected network with lots of ACLs). Looks like its time to revisit that.</div><div><br></div><div>Is there anyway to force Genie to send the PV to the CPE regardless of whether Genie thinks the value needs to be sent? Use case is 20-30 times we've ended up with the stored device model for the WLAN not matching the actual values stored on CPE. So to get Genie to send the desired value (SSID, etc) to the CPE, I have to refresh the value, then send the correct value.</div><div><br></div><div>My goal with v1.1 is to <b>not</b> maintain my own branch, it introduces needless complexity, especially now that v1.1 offers scripting.</div><div><br></div><div>-dan</div></div></div></div>