[Changelog] http protocol (for telematics hub)

baja

This topic is to publish all the changes to http protocol of flespi telematics hub.

baja

It is now possible to apply custom naming scheme to messages, accepted by http channel.

It can be used for:

message parameter renaming
excluding unnecessary parameters
validating message before storing
picking direct parameters from complex json

baja

http channel now has configuration option "skip_invalid" (disabled by default).
If enabled, http channel will silently skip messages:

without the ident field
that fail to apply the custom naming scheme

namo

Http protocol update is planned for the Thursday 2020-12-10, 12:00 UTC - protocol will be switched to a new parsing engine. This is an internal process, no changes in protocol work are expected.

namo

namo
Update postponed till tomorrow, 11-Dec-2020, 13:00 UTC

namo

namo
Http protocol update is planned once again, for tomorrow 2021-01-06, 12:00 UTC - protocol will be switched to a new parsing engine. This is an internal process, no changes in protocol work are expected.

namo

namo
Update is installed

namo

There was an issue with parsing of date time ISO 8601 strings (like "2019-02-25T02:26:38Z") into timestamp in HTTP 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.

kial

The protocol's internal implementation was changed to the new engine. No significant changes in behavior or parsing are expected.

shal

Tomorrow HTTP stream may slightly change its behavior.

During multiple data delivery to your endpoint within a single connection (Connection: keep-alive should be activated on your server) when stream will encounter Accept-Encoding header as a response from your server with either deflate or gzip value it will enable automatic compression of its contents starting from the next data portion in the same connection.

To enable such behavior and minimize traffic ensure that your server responding with next HTTP headers:
Connection: keep-alive
Accept-Encoding: gzip

This is optional of course and up to you.

For the very first request within a new connection only uncompressed data (as it is now) will be send. In case of your server will reply any http error code the stream will reset connection and retry data delivery in a new connection, always uncompressed.

Please check your http stream and your endpoint server logs for any details. We will activate this mode in next 24 hours.