
Project Flogo – Open Source Framework for IoT Integration - kundiis
http://www.flogo.io/
======
mrtree
I have been doing "IoT" for 10 years and after checking the website and the
github repo I still have no clue about what flogo does.

Isn't it like some basic http api for "triggers"? Is this what people think
IoT is about?

More importantly, can these basic set ups make money for some?

~~~
staticvar
The gist I get is that it's a daemon for a gateway device (like a Raspberry
Pi) that you configure data flows via JSON files. The Flogo CLI seems to be a
JSON generator ([https://github.com/TIBCOSoftware/flogo-
cli/blob/master/READM...](https://github.com/TIBCOSoftware/flogo-
cli/blob/master/README.md)). They compare their functionality to Nodered
([http://nodered.org/](http://nodered.org/)) except it doesn't have a GUI
(they mention working on it) and instead of being written in Node.js, it's
written in Go.

I'm of the opinion that these frameworks for Gateway devices are reinventing
Unix pipe and cron, that integrations for devices and databases should be
written in any language (as CLI), and running logic on the gateway is 90% of
the time not what you want to do, you just want to pull data from a device and
push it to a database somewhere. Shameless plug, in my free time I work on
Open Pipe Kit, a project that is building CLI for devices and databases. We're
currently working on a series of DIY LORA Nodes for Agriculture. If anyone is
interested in lending a hand, please reach out.
[http://openpipekit.github.io](http://openpipekit.github.io)

~~~
roymurdock
Nice work with the open pipe project. Looks perfect for DIY sensor/telemetry
projects.

If you are looking to monetize connectivity services, you certainly will need
a bi-directional architecture to push values back to end nodes, and compute
resources available at the gateway for data filtering, preprocessing, and
security.

But these are tasks that AWS IoT, Azure IoT, and GCP IoT are currently
tackling with a lot of resources. So it would be hard to compete at that
level.

~~~
staticvar
Thanks. While our examples are usually "pull from some device and push to a
database", with farmOS we experimented with "pull from a database and push to
a device". In this way, pipes are used to transfer state of a device two ways.
This depends on a database UI giving users the option to modify the state of
something, something that IoT databases like Phant
([http://data.sparkfun.com](http://data.sparkfun.com)) and Adafruit IO
([http://io.adafruit.com](http://io.adafruit.com)) don't currently support.

------
craigcabrey
>Internal Use Only License Grant. TIBCO hereby grants you a limited,
non‐transferable, non‐exclusive license to use the software solely for your
internal business purposes.

"open source"

~~~
jlgaddis
open source != free software

~~~
no_protocol
Pedants would probably agree that this is a true statement, but it is also not
relevant. The project itself claims it is open source and the parent claims it
isn't. No one mentioned the free software movement.

Parent is pointing out that the license lacks some provisions commonly
required to be considered "open source" \-- a better term for what is
presented might be "disclosed source" or "visible source."

Defining open source can be a point of contention, but the license in question
is pretty far away from most accepted definitions. There's not even a right to
modify the code. Note that this license appears to be only on the base project
that seems to contain nothing beyond documentation and samples.

------
PinguTS
It should be an IoT integration framework, which has 3,3 MB. That sound huge
to me. If I have an embedded processor that has 1 MB of Flash, than that is
already huge. Still this has to fit my application besides that framework.

~~~
betimsl
Initially I thought the same, but looks like it's only a web application, not
the software you'd ship with the node.

~~~
joezydeco
I'm not so sure.

 _" Build IoT applications that run on edge devices..._"

The moment I see "runs on Raspberry Pi", I know they haven't done any thinking
about low cost or low power consumption edge nodes. Get back to me when it can
run on a CortexM0 with 128KiB of flash.

~~~
zok3102
Good point - yes, we have M0-3 class target platforms on our roadmap. IoT
Gateway devices was where the need was most pressing for our customers and we
just went there first.

Now, we will likely end up doing a whole lot less functionality on an M0
profile, compared to a typical Flogo flow app on an IoT gateway, but the idea
is to offload the right level & kind of edge compute onto lower power nodes.

One point worth mentioning is that pretty much any framework can run on a Pi,
but running dozens of these Edge apps - "12-factor" style[1], that is where
Flogo's advantage shines through.

[1] [https://12factor.net/processes](https://12factor.net/processes)

------
zok3102
12 hours off HN & your project gets posted! Phew :)

I'm the PM on Project Flogo and welcome your questions + feedback. As some
have noted on the interweb, it's a pretty big step for an enterprise sw vendor
like us, to open up a core piece of our technology, so your constructive
feedback gets a lot of attention around here and shapes it!

Couple of quick clarifications:

\- All the repos (CLI, Library, Contrib and Services) except the top-level
repo are BSD-licensed. The top-level repo is docs+samples, so we have put it
under a free-beer license. However, we are in principle open to putting it out
under BSD or a CC license as well.

\- At its core, Flogo is a process engine that executes flow definitions
consisting of activities. These flows are triggered by events happening in the
real world. Triggers could be HTTP, MQTT, CoAP, etc. & activities could be AWS
IoT, Log, HTTP, Send MQTT, etc. There is a fairly simple SDK to build your own
activity or trigger and bring those along.

\- We are actively working on a Web UI to model the flows instead of
handcrafting the json DSLs or writing code.

\- The runtime footprint comparison is for apps with equivalent functionality
(Think a flow like MQTT Trigger -> Log Message -> HTTP Request -> Send MQTT).
We just chose 2 common frameworks to showcase the difference in runtime
footprint. We love Node & Java - it's just that for Edge integration
microservices we chose Golang - and the runtime footprint was a key decision
factor among others.

------
mdani
Google Brillo and Weave are essentially providing the same functions for
Google's evosystem for IoT which connects to Google Cloud Platform. How does
Flogo compare with Brillo + Weave?

~~~
zok3102
We havent seen a whole lot of real world demand yet, but something that could
likely end as a trigger or activity in Flogo.

------
Dowwie
A Tibco project?! What the.

~~~
zok3102
lol. This goes up on my review deck with execs. But yes, a (new) TIBCO & a new
TIBCO project :)

(Disclaimer: TIBCO PM working on Project Flogo)

