All merged.

Only issue I had was that I was getting empty vehicleid in the topic id. Like this:

I (22478) ovms-server-v3: Tx metric ovms//m/freeram=4238232
I (22478) ovms-server-v3: Tx metric ovms//m/hardware=OVMS WIFI BLE BT cores=2 rev=ESP32/1
I (22478) ovms-server-v3: Tx metric ovms//m/monotonic=22
I (22478) ovms-server-v3: Tx metric ovms//m/net/mdm/iccid=

I think the problem is that topic_prefix is set in the ConfigChanged, but m_vehicleid is set at Connect() stage.

For simplicity, I moved m_topic_prefix initialisation to the Connect() function, like the others. But that means you need to stop/start the server if the topic prefix is changed in config. That is the same as username, password, etc, so should be acceptable.

Seems nice and stable to me now. Thanks for the mongoose fix (moving stuff around by pre-pending headers was a horrible kludge by mongoose anyway).

Regards, Mark.

On 4 Jul 2018, at 8:30 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

Yes, I'm trying to get this to a workable state.

Your changes look good. I will try to merge within the next few hours.

Regarding trusted ca cents, I don't think we need (or have space for) them all. Just the ones we use (and a way to add custom ones if necessary).

Regards, Mark

On 4 Jul 2018, at 8:03 PM, Jakob Löw <ovms@m4gnus.de> wrote:

Hey,

I've seen some changes pushed to the repo regarding the v3 server. I
did some development on that too and found it to be very unstable,
often crashing after start (when transmitting all metrics) or when the
NetUp was called before any interface was up. Both issues were
connected to race conditions. I opened two pull requests to fix them
[0], [1].
The first one also introduces a new configuration option to set a
custom prefix for the MQTT topic. OVMS metric names seem to use a sort
of namespacing using dots, like m.freeram or v.e.on. Replacing dots in
metric names by slashes in MQTT topics, makes the OVMS follow MQTT
namespacing rules (m/freeram and v/e/on).

One thing currently missing with the Server V3 is encryption. Mongoose
supports SSL so enabling it would be easy, but the problem is the
certificate management. We could allow users to load certs onto the
module, however this is something unexperienced users wouldnt do.
Another option is to ship the OVMS with a list of common root certs,
like many browsers do. The certs shipped with firefox are ~500KB and
can be easily obtained e.g. from the debian repos [2]. This could then
also be used by the server v2 to replace the outdated RC4 encryption.

- Jakob

[0] https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pu
ll/137
[1] https://github.com/openvehicles/mongoose/pull/1
[2] https://packages.debian.org/stretch/ca-certificates
_______________________________________________
OvmsDev mailing list
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