The first returns the Protobuf integer, the second the generated enum
type. The big difference is that the first .to_string() would convert
the Protobuf integer to the same but then as String type, where the
latter returns something like '1.0.3' which is provided by the
fmt::Display trait implementation by ChirpStack.
Please note that for LoRaWAN 1.1.x, mac-commands in the f_opts field are
encrypted. Within the context of the device we can decrypt these, but
within the context of a gateway we can only show these as raw bytes.
This changes the clean_session default to false, as only in case of a
persistent session, qos > 0 would be effective. If the client_id is not
set, then ChirpStack will generate a random client_id, which stays the
same during the lifetime of the chirpstack process.
This also implements a subscribe loop, as the client re-connect feature
does not re-subscribe. Even in case of a persistent session there is no
guarantee that the subscription is recovered, as it might have been a
MQTT broker restart. In case the broker stores the sessions in-memory,
the client would re-connect, but without subscriptions.
The (re)subscribe logic is placed outside the on-connected callback, as
the callback function must not block, thus can not wait for the
subscribe result. No the (re)subscribe happens async from the
on-connected.
With the update to diesel 2.0.0-rc0, it is now possible to cross-compile
without emulation. Note that during each (cross)compile, we have to
install libpq-dev for the target platform, as only one version can be
installed at a time (e.g. libpq-dev:amd64 conflicts with libpq-dev:armhf).
Diesel 1.4.x makes it impossible to properly cross-compile when using
PostgreSQL and thus having a dependency on libpq. On compile and I
believe when using the diesel_migrations crate, there is a dependency on
both the host and target libpq. Unfortunately, only one can be installed
at a time, because of conflicts. See also:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995768
Until now the cross-compile solution is based on docker buildx, which
uses qemu to emulate the different targets. This works, but is very,
very slow.
Diesel 2.0.0-rc.0 no longer depends on both the host and target libpq on
compile and makes it possible to implement proper cross-compiling (using
the rust --target flag in combination with the cross-compile
toolchains).
