<html><head></head><body><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div></div>
<div>Hi all, </div><div><br></div><div>I have managed to install 2 V.3 boxes on two Think City A306 and the basic functionality works great - I am able to see the SOC, position, battery temperature. </div><div>I will be measuring power consumption and look at logging and adding more parameters in near future.</div><div><br></div><div>I had a few wows that came from me not reading documentation and one that I could not find in the documentation. </div><div>The undocumented one was that I was able to set password to "test" - it was just for testing on the bench, and I was no longer able to find the access point... when I connected via usb cable and terminal I could see that the process for the AC was complaining that the module password was too short and aborted startup. </div><div>I haven't tested this in the latest update, but wanted to put it out there in case any of you run in to it. </div><div><br></div><div>Nikolay</div><div><br></div><div><br></div>
</div></div><div id="yahoo_quoted_2228148538" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Thursday, July 12, 2018, 11:40:49 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">Just seems wasteful to have a dozen metrics for this. Expensive in ram, bandwidth, and mqtt. Every vehicle module would have to set the unused ones to ‘no’ (due to the way mqtt retained topics work). If we add a new capability, all the vehicle modules would have to be changed to set it to ’no'.<br clear="none"><br clear="none">Your suggestion is cleaner, but more expensive.<br clear="none"><br clear="none">Regards, Mark.<br clear="none"><br clear="none">> On 12 Jul 2018, at 5:34 PM, Robin O'Leary <<a shape="rect" ymailto="mailto:ovmsdev@caederus.org" href="mailto:ovmsdev@caederus.org">ovmsdev@caederus.org</a>> wrote:<br clear="none">> <br clear="none">> On Thu, Jul 12, 2018 at 08:56:25AM +0800, Mark Webb-Johnson wrote:<br clear="none">>> I think the capabilities are useful, but need to be done in a better, more future-proof, way. Relying on protocol v2 commands is limited.<br clear="none">> ... <br clear="none">>> My suggestion is:<br clear="none">>> <br clear="none">>> Create a standard metric ‘v.capabilities’.<br clear="none">>> Have the vehicle modules set that metric with their capabilities, as a comma-separated list of the commands supported:<br clear="none">> <br clear="none">> Mapping things to strings seems rather roundabout.<br clear="none">> Would it not be better to have individual boolean capabilities?<br clear="none">> <br clear="none">> v.capability.chargemode = yes/no<br clear="none">> ...<br clear="none">> v.capability.climate = yes/no<br clear="none">> _______________________________________________<br clear="none">> OvmsDev mailing list<br clear="none">> <a shape="rect" ymailto="mailto:OvmsDev@lists.openvehicles.com" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a><br clear="none">> <a shape="rect" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><div class="yqt2239895682" id="yqtfd01932"><br clear="none"><br clear="none">_______________________________________________<br clear="none">OvmsDev mailing list<br clear="none"><a shape="rect" ymailto="mailto:OvmsDev@lists.openvehicles.com" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a><br clear="none"><a shape="rect" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br clear="none"></div></div></div>
</div>
</div></div></body></html>