[Ovmsdev] MQTT V3 server problems

[Craig Leres]

On 10/9/21 07:58, Mark Webb-Johnson wrote:
> For the stale data issue the normal way I have done this in the past is to have a ‘connected’ metric showing time of connection, and have that sent after MQTT connection. Client also has a LWT to clear that metric. Then use MQTT keep alive to ensure it is cleared for a jammed connection. I can check that in the next few days.

I'd be interested in seeing that.

What I have now is a python daemon that subscribes to various ovms 
topics and submits nagios passive service check updates.

I think I can solve my problem by enabling mosquitto debug logging 
("log_type debug") and then parsing my local syslog file backwards 
looking for a PUBLISH line, e.g:

     Oct  9 12:41:56 localhost mosquitto[35689]: 1633808516: Received 
PUBLISH from UNIT1 (d0, q0, r1, m0, 'ovms/UNIT1/UNIT1/metric/v/type', 
... (10 bytes))

The other solution I was thinking about was an new metric that included 
the unix timestamp of the last update. It would be optionally enabled 
since it would result in some network data usage. But honestly, I'll 
probably write the syslog parsing code and be done with this.

> For the tls issue, it looks like let’s encrypt ca issue. If you are using 3.1.017 that should be resolved. If custom build, make sure you have the correct tls library chosen in menuconfig (not wolf ssl as broken). The server needs to be configured to access a) the key, b) the cert, and c) the chain. Some implementation simply concatenation c to b in one file.
> 
> When the client connects, the server sends the cert and chain, so client can verify the server.

Hum... So wolfssl works for https into the module but not mqtt/tls out 
to a mosquitto server? Ah, I rebuild with mbedtls and mqtt works again.

I guess I'll have to be patient and wait for our integration of wolfssl 
to evolve a bit further. It's a shame, I had gotten used to using https 
to manage the modules...

Thanks for the help.

		Craig