• Edited

Method /platform/subaccounts/all/logs was added. Using it you can get your subaccount's logs in a single REST call. The most convinient way is to fill filter parameter to select what kind of logs do you need.
Use this request to fetch all deleted devices from all subaccounts:
https://flespi.io/platform/subaccounts/all/logs?data={"filter":"event_code=3,origin_type=11"}

    8 days later
    • Edited

    Devices and calculators received new property for controlling maximum storage threshold they can use.

    This parameter is a convenient way for controlling your flespi storage size. Now instead of guessing how much storage you will use in devices in a day/month/year you may just specify automatic messages rotation size and flespi will control it for you. Whenever any newly added message will overflow specified size older messages will be automatically discarded.

    Same applies to analytics and intervals size used by assigned devices.

    Read https://flespi.com/kb/how-to-manage-device-storage for more information about messages rotation.

    2 months later

    For streams to Azure IoT we have added special parameter replace_dots which is off by default. Once enabled in stream configuration all messages received by stream on Azure side will contain replaced dots to underscores in parameter names, e.g. "position.latitude" to "position_latitude" and so on. This is to enable special rules engine on Azure side which is impossible to use when original flespi parameter naming scheme is used (with dots).

    8 days later
    • Edited

    For security issues we decided to remove ident parameter from device telemetry. This way device telemetry can be securely exposed to external users via REST and MQTT. Together with recently installed changes to flespi ACL tokens it even possible to expose just the device telemetry excluding device settings or its configuration.

    The update which removes ident parameter from device telemetry will be installed tomorrow in the morning.

    shal We have removed ident from telemetry.

      • Edited

      We have implemented special plugins framework that extends functionality of flespi telematics hub for special cases.

      The very first case we have implemented is the possibility to forward telematics data from devices into Bulgarian tool roads system, effective from March 1st 2020 via tollbg.eu service. In order to use it you need to:

      • register at tollbg.eu service, receive authentication credentials that you will use for stream (if asked during registration for stream status webhook you may use this url: https://flespi.io/gw/hooks/toll_health);
      • register there plate number of vehicles you want to stream;
      • create flespi stream with type=tollbg:
      • activate tollbg plugin for the flespi device and fill per each device two required fields - pan number and license plate number, like on screenshot below:
      • subscribe stream to devices with activated tollbg plugin;

      As now we have this special framework that allows us to define custom fields and plugins for various types of flespi entities we plan to add more and more plugins in the future - connect to various toll roads services, government regulations system for specific countries and create connectors to various aggregators and hubs that our users can use upon their desires. Please contact us in flespi chat if you have requirements for some specific projects.

      2 months later

      The channel has a static IP address, but a static address is vulnerable to a DDoS attack.
      The goal is to minimize the impact of a theoretical DDoS attack on an gateway IP.
      Thus, we took the very first step to replace the static IP address of the channel with a personal DNS record.
      The panel now displays the channel URI as a DNS record.
      We recommend that you use a DNS record for all future connected devices and, if possible, reconfigure existing ones.

      adsa

      As a part of our anti-DDoS preventive measures we are softly switching from IP-based channel specification to DNS-based. Each channel is assigned its unique DNS record in form {channel-id}.flespi.gw. Currently it is resolved as a CNAME type record to gw.flespi.io for EU region and ru-gw.flespi.io for RU region which by itself are A-type records to the underlying IP address which was recently a part of channel’s URI.

      It means that except the visualization part currently there are no actual changes occurred in the endpoint where to connect your telematics devices. However we strongly recommend you to update the server address of your devices from IP-based format to the new DNS format as proposed by the channel uri property.

      In case of any kind of DDoS attack we will immediately manipulate with these DNS records to reroute devices to different multiple IP addresses and save and secure the traffic from your devices. If you use the DNS address of your channel you will be safe. If you use an old fashioned IP address - the traffic from your devices may be blocked for some period of time.

      Moreover later we will introduce more IP addresses for communication with devices and even may install and rotate channel listeners in different datacenters to improve reliability and performance. Please use the DNS name of your channel everywhere and together with flespi prepare for the future.

      For all new channels created from this point of time, with ID higher then 18000 for RU region and 22000 for EU region we expect that the devices connect to DNS name and we may further change IP address it points to without additional notice. Please be aware.

        18 days later

        We have added an "IP whitelist" optional property to the all channels configuration, where the channel is dealing with incoming connections (most of the protocols at this time).
        Now you may set a comma-separated list of IP addresses (or a wildcard-masks like 192.168..) to allow incoming connections only from such IP addresses.
        scr

        20 days later

        One of flespi access methods - pull based access to channel messages via REST API will update range values of some input parameters from 32-bit unsigned integer to 64-bit unsigned integer.

        Methods and parameters affected:

        In most processing systems these methods will continue to operate as is, cause in Javascript, Python and most of other languages there is no specific datatype for number limitation up to 64-bit.

        This message for you is just a notice to check your code and prepare for the upcoming update from flespi side.

          6 days later

          shal We upgraded curr_key/delete_key precision from 32-bit to 54-bit to preserve compatibility with javascript. The update has been installed, please check if your code is OK if you rely on the updated REST API methods.

            shal One additional update: we lowered returned key value from 54-bits to 53-bits and suggest you to restart your consumers for GET /gw/channels/messages API method users, if any.

              6 days later
              • Edited

              We released the second version of the plugin system to extend device functionality. All plugins for the initial release (the first version of plugins system) were converted into this new one and messages flow should be unaffected.

              From that moment we will add features to it on a constant basis. Plugins system is still considered experimental at the moment and thus we may introduce changes to its API without prior notice.

              In short, plugins allow you to define extra fields to messages published to devices. You define the schema of each plugin and its fields (name, parameter alias, actions with fields - store in the database, publish to MQTT, publish to device telemetry, etc) and after that, you may add devices to the plugin by filling their fields.

              Plugins can be used just to store and reference any extra information about the device and use it with REST API selectors. E.g. to extend each device with special customer number, plate number, or even to add a phone number or SIM ICCID.

              Some plugins, which are part of a complex pipeline process, like tollbg are available as a template making it simple to create and use them in one click.

              REST API is available here. You may read about associated plugins GUI changes here.

              We plan later to publish a few articles in our blog covering the most popular use cases for the plugins.

              We also plan later introduce plugins to other types of flespi entities, e.g. channels.

              Be aware that the number of plugins you may create is limited by your flespi plan. Free flespi users can create just one plugin. And Commercial flespi users have two plugins included in the base package and each extra plugin will cost $20.

                12 days later

                We implemented special REST API method to move device between various flespi accounts: PUT /gw/devices/{devices-selector}/cid

                This is quite a complex method and may be used by our commercial users that can organize their flespi account into subaccounts hierarchy on a per-project basis and to distribute devices between subaccounts persisting their settings, storage, calculation and streaming configurations.

                We do not plan to add button to call this method from GUI at the moment - it will remain available only via REST API.

                2 months later
                • Edited

                Please take a look at flespi database changelog message as it may affect the operation of the flespi telematics hub for you. We ensure our users to test their integrations and keep an eye on it during the transition period.

                  We've added the last_active field to the devices in the REST and MQTT. This field contains a timestamp where the platform received the last data piece from device over TCP/UDP/etc.
                  This field can be used to determine "alive" devices working over UDP or other connectionless transports.

                  • Edited

                  Dear flespi users!

                  We're announcing an upcoming change in the output of the REST API method GET /gw/devices/<selector>?fields=settings

                  For now, the output of this request contains an array with device settings as a JSON object, and every object contains such fields:

                  • address
                  • current
                  • mode
                  • pending
                  • schema
                  • tab
                  • tags
                  • updated

                  Next week, on August 28 the following fields will be removed from this list:

                  • address
                  • mode
                  • schema
                  • tab
                  • tags

                  All these fields can be obtained using another REST API request: GET /gw/protocols/all/device-types/<device-type-id-from-device>?fields=settings

                  8 days later

                  Dear flespi users!

                  We've installed the update mentioned above: kial

                    24 days later
                    • Edited

                    We are going to rename "gw/protocols" to "gw/channel-protocols". This will allow us to implement other protocol entities such as "gw/stream-protocols" etc. REST API methods based on "gw/protocols" are deprecated and will be removed on November 23rd.

                    List of affected methods:

                    Get protocols matching filtering parameters. Deprecated method:
                    GET /gw/protocols/{protocol-selector}
                    New method:
                    GET /gw/channel-protocols/{protocol-selector}

                    Get commands supported by protocol. Deprecated method:
                    GET /gw/protocols/{protocol-selector}/commands/{protocol-cmds-selector}
                    New method:
                    GET /gw/channel-protocols/{protocol-selector}/commands/{protocol-cmds-selector}

                    Get device types supported by protocol. Deprecated method:
                    GET /gw/protocols/{protocol-selector}/device-types/{devtypes-selector}
                    New method:
                    GET /gw/channel-protocols/{protocol-selector}/device-types/{devtypes-selector}

                    25 days later
                    • Edited

                    We are introducing a new REST entity called stream-protocols. The purpose and use of this entity is exactly the same as the previously mentioned channel-protocols:
                    curl -X GET --header 'Authorization: FlespiToken XXXX' https://flespi.io/gw/stream-protocols/all

                    To create a new stream, you must get the available protocols, and then pass the identifier of the desired one to the stream configuration:
                    curl -X POST --header 'Authorization: FlespiToken XXXX' -d '[{"configuration":{},"protocol_id":1}]' 'https://flespi.io/gw/streams'

                    By the way, the legacy format is still available until December 16:
                    curl -X POST --header 'Authorization: FlespiToken XXXX' -d '[{"configuration":{"protocol" : "http"}}]' 'https://flespi.io/gw/streams'