Best way to create derived data


#1

Hi,

My sensor produces electrical current info. In some graphs I want to plot Power instead of current. One of your competitors has something called DERIVED values. I provided a source metric, a formula and on every update the DERIVED metric is also populated.

I got it to work on Losant, but it’s very, very messy. What is the best way to do this?

Bas


#2

The best way to do this is with a workflow. The workflow can trigger on Device State. You can then use a Math node, or any other nodes to calculate the derived value. The workflow then can use a Device State node to record the calculated value back on the device. To the rest of the system, it will look like the original value and the derived value were recorded at the same time.


#3

Hi Brandon,

That is how I have it now, but the workflow updating the state, triggers the worflow again. So I need to have a condition in there to check if it’s a sensor update or not. It’s not very elegant at all.

See AppID 599ce37f9da22b000714315c

Is there a clearner way to no retrigger the same WF?

The Ubidots implementation for this is much cleaner. I would think that having a “calculated” field type on the device would make it much nicer

Bas


#4

You’re right, you do also need the conditional.

Calculated attributes is absolutely on the horizon. It’s something we’ve been talking about for quite a while. It would definitely clean up the implementation. It’s probably a good time to rethink prioritizing that feature again. Thanks!


#5

And to make sure I’m not missing something obvious, there is no way to do math in the time series graph itself, correct?

Bas


#6

That’s correct, you cannot currently perform any math in the time series graph itself. Other users have asked for that as well - it would make an excellent feature addition.


#7

TX! Do you guys share a public roadmap. Google didn’t turn one up. And is there a mechanism for your userbase to vote on features being considered?


#8

We don’t publish a public roadmap. We move pretty fast and want to keep feature additions as agile as possible. I’d hate to misinform people.

We’ve thought a lot about bringing on a more formal way to ask and vote of features. Currently the forums here have been a very good source of input for us. Might be worth some additional brainstorming on something like a voting system.


#9

Awesome. I will keep a close eye on the BLOG posts then. You guys have build a great platform!