• shal

  • Post #1
  • Edited

This topic has special name - we couldn't name it just MQTT protocol as MQTT is more generic name. What we mean here - in this topic we will publish all the changes to mqtt protocol of flespi telematics hub.

MQTT protocol can be used to inject data coming as MQTT messages into flespi channel. It is then possible preprocess it (define what and where to store) and then register historical messages in devices of type "MQTT" if such devices with specified ident exists.

This is convenient way of generating own set of data for flespi devices that further can be used with analytics for real time data analyzes and visualization with MQTT Tiles.

Some usage sample of MQTT protocol for flespi telematics hub are:

    We modified the scheme of channel configuration and now it is possible to receive into the channel not only valid parseable JSON payloads, but also any kind of data that will be stored as a value of some parameter, which name can be specified either as a fixed string or can be retrieved from the topic. E.g. if device send message with topic="room/6/lights" and payload="11" it is possible to convert it into flespi channel message like:
    {"ident":"room_6", "timestamp":1567242121, "lights":11}

    The timestamp of channel message, if not specified will be retrieved (if available) from "timestamp" user property of MQTT message. If used with flespi MQTT broker, it sets this user property automatically as the indication of the message reception time.

    Now it is also possible to specify as ident not only just one topic segment, but multiple segments. E.g. message to topic 'city/la/room/6' may generate ident 'la_room_6'.

    All existent channel configurations are automatically upgraded to new scheme.

    2 years later

    MQTT protocol of flespi telematics hub is to be updated on the Thursday 2021-04-22, about 12:00 UTC - protocol will be switched to a new parsing engine. This is an internal process, no significant changes expected in the operation of mqtt channels.

    namo
    Update postponed.

        4 days later

        MQTT protocol of flespi telematics hub is to be updated on the Wednesday 2021-04-28, about 07:00 UTC - protocol will be switched to a new parsing engine. This is an internal process, no significant changes expected in the operation of mqtt channels.

          7 months later

          MQTT protocol of flespi telematics hub implementation changed: now MQTT messages with empty payload will be skipped for "Channel message composition: MQTT payload as parameter value" configuration.
          Previous logic generated an empty message (with standard parameters only) for MQTT messages with empty payload.

          3 months later

          • namo

          • Post #10
          • Edited

          An update of MQTT protocol of flespi telematics hub is planned for Monday 07-Feb-2022: MQTT channels configuration schema is going to be changed.

          The new schema will allow configuring the MQTT channel's connection to the flespi broker with just one click - just choose an appropriate flespi token.
          Alternatively, the new schema will allow connecting to any arbitrary MQTT broker having specified full connection details.

          After the upgrade, current configurations of the MQTT channel will be marked as deprecated. We will migrate all MQTT channel's configurations from the deprecated schema to the new one, so no actions will be needed from flespi users.

          No significant interruptions in MQTT channels operation are expected during the update and migration.
          We just ask you to monitor your MQTT channels and let us know in case of any unexpected issues.

          4 days later

          namo The update is installed. Configurations of MQTT channels are migrated to the new configuration schema.

            11 days later

            • kial

            • Post #12

            Mqtt protocol updated to the new runtime. No behavior changes are expected.

              • kial

              • Post #13
              • Edited

              Improved ability to register arbitrary MQTT message payload as a channel message parameter.
              Previously when you set "Channel message composition" to "MQTT payload as parameter value", there were no options on how to parse it, only JSON syntax was used. Thus, to store string values it was required to enclose them into double quotes.

              Now there is an option "MQTT payload data type for parameter" with 3 variants: "JSON value" (the default, denotes previous behavior), "Plaintext string" to store an utf8-valid string payload value, and "Binary/HEX data" to store arbitrary payload in HEX encoding.

              scr

              a month later

              • namo

              • Post #14
              • Edited

              There was an issue with parsing of date time ISO 8601 strings (like "2019-02-25T02:26:38Z") into timestamp in MQTT channels. The issue began in the afternoon of March 29 and was fixed at noon of March 30.
              The issue was caused by incorrect timezone calculation with Daylight saving time applied and appeared as incorrectly registered messages timestamps - the timestamps were registered with values 2 hours earlier that what they should be.
              The issue affected the data of devices that send time as ISO 8601 string.
              We in flespi deeply apologize for the malfunction that may have caused data invalidity.

              2 months later

              • namo

              • Post #15
              • Edited

              MQTT protocol of flespi telematics hub is updated.
              Now the channels that use persistent session (Clean Session flag in the channel's configuration is set to false) will unsubscribe from the previously configured topics if the subscription topics of the channel has changed.
              The update fixes the unexpected behavior that might have been observed for the channels with persistent session: when the subscription topics change but the channel continues receiving messages from the topics it was previously subscribed to.

              2 months later

              • namo

              • Post #16
              • Edited

              MQTT protocol of flespi telematics hub is updated.
              Now subscriptions to flespi MQTT broker will be always performed with flag retain_handling=1, so that retained messages from flespi MQTT broker won't be delivered to the channel after server restart, if clean_session=false.
              The update is applicable only to the channels configured as flespi MQTT broker (see more)

              16 days later

              MQTT protocol of flespi telematics hub is updated.
              Configuration of MQTT channel has changed: subscribe array has moved into broker object, and for MQTT Version 5.0 retain_handling option is added for each subscription.
              Configuration of all existing MQTT channels was migrated to the new schema. No changes in the operation of MQTT channels are expected.

              a year later

              MQTT protocol of flespi telematics hub internal implementation has been switched to a new engine. No significant changes in behavior are expected.

              We implemented access to raw traffic generated by MQTT client from flespi in channels with MQTT protocol type:

              The whole traffic of MQTT connection is accumulated under "unidentified" ident:

              10 months later

              We changed default expire_interval configuration option for MQTT channels with non-clean session from 30(or 86400 in some cases) seconds to strict 10 days.

              It means that you can stop your channel and the broker will buffer pending messages for up to 10 days.

              To achieve this buffering you need to specify QoS=1 for your subscriptions and clean=false session flag in MQTT channel configuration.

              Please be aware that when connection is restored your channel may be temporary blocked if it exceeds any limitation such as allowed amount of messages or traffic per minute. In that case you can navigate to MQTT=>Sessions and delete corresponding MQTT session associated with the channel.

              7 months later

              • adsa

              • Post #21

              Previously, MQTT channels ignored additional SSL configuration parameters, such as CA certificates and private keys, due to a bug. We have now fixed the bug, and the functionality has been restored.

                Write a Reply...