We have exciting plans for 2024 and we have started strong with new features we are currently working on and plan to release during January.

There are four features in our “Must have” list that we are launching very soon:

‍

A data ingestion debug feature

‍

As of now, data ingestion is a bit of a black box. The end user defines a message type and its associated payload schema, and then tries to ingest data for that message type.

If the data message received in the topic for that message type doesn't conform to the payload schema definition, the data is discarded silently. And the end user can't see what happened, or why.

That is why we have implemented a new developer tool feature that helps our users monitor and debug all the communication between the device and the Biotz IoT platform.

‍

‍

The user now will be able to see in real time all the details of the communication and make sure the incoming data fits the schema.

Device events (as opposed to platform events)

‍

There are two different concepts/features involved.

The first one is what it's already available in Biotz IoT, what we call alarms. The key characteristic of this concept is that it is tied to values present in the messages received from the devices. So, to summarize, alarms are tied to values carried by data messages received at data topics.

The second concept/feature, the one that we will implement, is the one that we call device events, to distinguish them from what we currently simply call "events", which we will now call platform events. A device event is tied to the fact that a message has been received in a "special topic". It doesn't care about the values carried by the message. It only cares about the fact that a message has been received on that topic.

Why do we say a "special topic"? Because those topics will not be data topics, but a different kind of topic. Let’s call them event topics. They will be under their own "topic sub-tree". Much like we have the "biotz/1/0/<customer-id>/<device-id>/publish/data/…" topic sub-tree for data topics, and "biotz/1/0/<customer-id>/<device-id>/subscribe/action/…" topic sub-tree for action topics, we will have the "biotz/1/0/<customer-id>/<device-id>/publish/event/…" topic sub-tree for event topics.

This is a very useful feature for devices that already create alarms internally and simply want to show them in the IoT platform, without further processing.

Saving payload schemas as "drafts"

‍

Right now creating a new payload schema is an all-or-nothing operation. Either you fully create the schema and save it, or all the work you did so far is lost if you navigate away from the view. Same for the case when your session (ID token) expires while you are creating the payload. This can happen when you keep the view open not to lose all of your work, but suspend your machine to keep working on your schema a few hours later or the next day (during that time the token will expire).

Having the option to save a schema as a "draft" avoids this kind of problem.

‍

Uploading a payload schema definition

‍

In addition to letting the end users build a payload schema through the front end UI, we have added an option to upload a payload schema definition.

For this option, all the validations applied for schemas built from the FE UI are also implemented. That is, the uploaded schema needs to be a fully compliant schema.

‍

All of these features will be released to the beta version soon. 

Bring on the new year, stay tuned!