While many customers do run OTDT on metal or virtual servers it is also possible and - depending on the things which must get done - recommended to run OTDT on embedded devices.

With this concept it is possible to read hundreds and hundreds of documents simply by putting the appropriate amount of instances of OTDT into a cluster.

While only a fraction of all running instances of OTDT is in direct support, these instances now do process more than 200 millions of Triggers a month. This is an amount which - we have to admit - makes us proud.

Using this new library makes the serial port available as Trigger and as Action for OTDT. This means that for example in embedded environments special bus devices could be used.

In the definition of MQTT it is written, that QOS 0 messages are of type "fire and forget", so there is no acknowledgment of the receiver. However, these messages are sent to the server, ... or queued.

With the latest version of Mongo DB we updated the underlying libraries in OTDT to support and respect all given new features if using Mongo DB as state store.

With standard display connected via HDMI or E-Ink respectively E-Paper displays wired on SPI or similar interfaces informations and statuses of OTDT could be displayed to people around.

Using the configuration it is possible to restrict every URL's path. But, on the one hand the status path is always available, on the other hand sometimes it is even demanded to not even show that there would be a service listening.

It turned out that in special circumstances Actions must check for several values to "decide" whether a variable is empty or not. This should be more easy and consistent.

We already discussed the possibilities of using Bluetooth for communications. An additional scope would be to simple sense the presence of predefined devices and then react with a special Action.

Specially if running in a high availability environment with Mongo DB as the state store this configuration settings could significantly reduce the network traffic.

One of the public transit operators in Germany has an appropriate organization execute a penetration test against OTDT and the installations within the vessels of that operator: Again, no complaint was found!

If there is a GPSD available "near" OTDT, the positioning data often must be used in the Actions; so the GPS data must be piped to OTDT.

While OTDT is (tested and verified) reliable in the manner of availability and scalability, it may get a bit complicated when it comes to simply shape some processes.

Being a setting only for special environments, we added subscription-type to the configuration of STOMP in OTDT.

With this new additional configuration setting the processing speed and load could be controlled depending on the appropriate amount of incoming messages (Triggers) and the runtime of the Actions.

With the current additions to the protocol STOMP - failover, reconnect and heart-beat - the stability of OTDT connecting to message queue servers is even more reliable.

While this on the one hand gives the opportunity to send data via Bluetooth to OTDT being a Trigger, it is possible to establish a OTDT to OTDT communication using Bluetooth on the other hand.

Using exec in an Action is flexible, because you could use nearly any command the OS understands. But it is always synchronous waiting for a response within the Actions.

While in an Action using the publish method of the MQTT library enables to set QoS and retain, it is better to have default settings where OTDT itself add these settings.

The best practice for MQTT says, that QoS 1 and 2 messages are being held for an consumer even when/if currently not available, but sometimes it is not possible to reliable ensure, that waiting messages could be processed or even tranfered in the needed time.

While OTDT is already collecting production data in automotive industry, it is now installed in public transit vessels

One thing we had in mind from the very beginning is to have the response of an Action step being given to the next step or being the response of the whole Action itself.

The protocols for incoming message queues have been updated and some fixes to the configuration settings have been made.

Using OTDT on a Raspberry Pi for example, offers the opportunity to use wire statuses or measurements the simple way, which now could be integrated into OTDT very easily.

Certainly digest authentication is prefered (and should be for security), but like the title says, sometimes external services or components only offer basic authentication.

Ever wanted to know how often which control paths in OTDT were triggered and which actions were run for them? You will love our new feature "Flows".

We updated Philips Hue and Apple HomeKit integrations where controlling actions in OTDT directly now feel even more like having things run in a Home Automation.

Certainly – “we” developers do love to do things in “vi” (an Editor). Modifying “config/default.properties” and “config/rules.json” directly for us is like seeing Blondes in the Matrix code for the other one.

In some situations it might be useful to receive notifications upon certain device or trigger states. For example if the battery of radio based sensors goes down. Or you want to get informed if some windows or doors in your building are and/or stay open.

To be honest, we are great fans of Alexa. Yes, even while we do tell all people to watch their privacy. What can I say?

While we originally were building OTDT as a local “Trigger an Action”-Appliance (like IFTTT – “If This Then That” – does in the “cloud”), we recognized that controlling actions in OTDT directly would be a great thing.

Today we launched this website to move forward with OTDT. Several months of development and testing passed by and we are now able to release OTDT into the world.