Dev corner

Calling all engineers, tinkerers, hackers and geeks.

Who uses TMPO data and the query daemon?

Hello community,
working with the TMPO charting I started the corresponding query daemon on my FLM (still v244) some while ago; and it runs and runs and runs; no dump, no break... Anybody else gained experience so far? If nobody experiences any issues (if so, please report as github issue) we might convince Bart to integrate it into the tmpo-daemon with firmware v25x already...
Thanks for your feedback
Markus

P.S.: If somebody can tell me, why the heck the input fields do not provide full text height, please give me a hint also! (css oddity between the two bootstrap stylesheets, of course)

P.P.S.: To get an understanding what this is all about, read my corresponding blog article.

a possible widget for the flukso displaying charts in javascript

As another alternative to query local tmpo data from the flukso by heavy use of javascript I wrote a d3 widget for zabbix. The api is json zabbix, but could be modified to talk to the flukso as well.
As my flukso talks to my zabbix-server via my flukso-proxy I managed to set up a demo page of how a chart served from the flukso could look like.
http://mein-webportal.de/zabbix-d3js-widgets/samples.html

throw your flukso readings into zabbix

More than a year ago I tried to put the flukso readings into my own database. Surely that's something that has to be carefully thought of, which I didn't. What I needed was a server where I can put in all my measurements I take (without rewriting it). Since we use zabbix at work to monitor all our hosts and containers I came up with the idea to use it for my own measurements as well.
And it's simple: zabbix does all the work for you. I decided to leave the readings as posted by the flukso and let zabbix do the transformation. With zabbix you set up how long your data is kept until it's transformed to trend data, triggers can be set up to alarm you, and so on. Ok zabbix seems to be overkill for this job, but I'm already using it for many of my measurements. So I gave it a try.
I checked in a first working php version of a proxy redirecting the flukso's data to my zabbix server and flukso.net at the same time.
https://github.com/hgruber/flukso-proxy
have a look at: http://www.zabbix.com/

Querying local tmpo data [solved]

To get a little further with the tmpo data, I decided to not directly move into the tmpo-daemon, but in a first proof-of-concept provide an extra daemon to handle query requests for FLM local tmpo data.
The result may be "admired" in https://github.com/gebhardm/flmlocal#querying-tmpo-data with the respective lua-code.
The idea is to handshake query requests and corresponding chart visualization directly on the fluksometer utilizing the existing local visualization capabilities, without any necessity to a web connection.
It works in the way that a query request is sent via MQTT to the FLM query deamon, relating tmpo files are retrieved and passed back as a related MQTT message.
This works fine, but is rather slow as sent back messages may have a high latency. So, looking forward to a discussion on how to increase the charting efficiency without an external database or "funny Python scripting".