Putting complicated trigger logic in a 10x10 pixel widget

Custom Widgets
1

Sometimes I find the App trigger mechanism a bit much. For simple triggers, it works great. I have one case, though, where I’m building a state machine. There are 4 states, and one state variable (a number). Each time you get a trigger it figures out what to do with the outer layer of “IF current state ==2 THEN …” and then makes some decisions on what state to advanced to next based on other variables.

What I end up with is something that’s kind of long. It doesn’t all fit on one screen, it’s a little hard to read, and very tedious to initially enter.

As a workaround, I tried it another way: I made a custom widget that has a little tiny HTML that basically just indicates that this logic exists on the Step. I then feed the inputs into the state machine, but let the javascript keep track of the current state. All the state transitions are internal. The javascript can fire off events. There are a number of events, and I also write back variables directly when necessary.

It works great, but in a lot of ways it really goes against the philosophy of no-code / low-code development. What’s important to realize though is that the no-code approach is a little frustrating for more sophisticated users who realize that they can replace a complicated muilti-part trigger with a few, readable lines of code.

This drives home something else I have already asked about, though: it would be nice to be able to insert custom javascript at the Step level, just like you would insert a widget but skip the CSS and HTML. If you do that, then there are no limits. Want some other kind of Aggregation that’s not currently supported? No problem, just write one. Want to compute kurtosis? easy. Give me an easy way to access tables (and the rest of the API) by passing in an ‘api’ object. Then, give me the ability to pull in pandas and numpy and things really start to get wild.

I appreciate that Tulip might not want some of this. I get the concerns, in particular, about impacts on performance and stability. My counterargument, though, is that you can always hose yourself somehow, if I do something that fork-bombs the player that’s kind of my problem. I think the other half of the concern is when that happens someone will call Tulip support demanding answers. I get the concern and sensitivity to things like that.

Regardless … this is all just food for thought, I’m curious what everyone else is doing out there.

–C

2

Hey @wz2b,

I basically whole-heartedly agree that the current trigger UI can be clunky when executing a lot of logic in one trigger. Coming from a traditional software background where hot keys and code reusability is a first order priority, Tulip was frustrating. Thankfully there is a lot going on to make this better:

  • This pain was identified several years ago, and in the last 6 months we have been collecting this feedback, building a team, and strategizing to both improve trigger capabilities while making them less tedious for advanced users. I can’t yet give much detail on what that will look like, but the your feedback is invaluable to focusing our work. This team is actively releasing functionality incrementally as it is completed every couple weeks. I would expect to see more major UI changes in the back half of 2022.
  • Custom widgets act as a decent stopgap immediately to work around these limitations. That feature is about a month old, and we are already seeing massive adoption. We will be using the usecases people solve with custom widgets to improve the trigger UI. The first widget I made was an on change widget that runs a trigger when a prop changes. This wasn’t something I had ever considered needing in the product but this widget has proven so useful that it is now documented as needed native functionality.

There has absolutely been discussion around enabling natively programming languages in the Tulip editor, and it might be something we enable in the future (like cases where you are using a custom widget to basically run step triggers), but enabling something like javascript is just a lazy approach to solve the root cause (that is that the trigger UI leaves something to be desired).

Your feedback as a power-user is always appreciated! Keep it coming!
Pete

3

@wz2b Just to share, before custom widgets existed I began working on a python server hosted on heroku that is basically just a separate API that I hit with Tulip connectors to do more complicated operations on tables. Probably more than half the stuff I have in there I’ll be able to eventually replace with a custom widget, but I have no javascript experience at this point.

As far as your pondering on the philosophy of no/low-code I figure it can only be a good thing to allow advanced users to do whatever they’d like, and keep no-code options for people who are making simpler apps (or just slightly modifying apps from the library)

In regards to some of your other suggestion (pandas, numpy, aggregations) there is always just the option of creating a standalone application that utilizes tulip data. I’ve already created an application for batch downloading photos from Tulip based on the operations they’re associated with, and we might just create a standalone application for engineering-level review of data to take advantage of libraries like pandas and have more display options.

4

Thanks for sharing your experience with this, it’s great to know.

I do a fair amount of work with building automation systems, and in that world, the same bifurcation exists - there are controls experts that don’t know much about software development, and there are lots of software developers who don’t know anything about controls. It’s hard to make both of them happy. I think it’s kind of the same thing here.

I am doing some external automation like you describe. I have been doing it mostly in node-red but here at the sustainability institute we use Jupyter Lab and Python extensively for our scientific and research work. I’m not sure that these tools are useful to a lot of Tulip users (maybe?) but if you really were developing machine learning algorithms based on data that’s in Tulip (e.g. machine data) then Jupyter would probably be the best candidate development platform. IMO, YMMV. :slight_smile:

5

  1. Jupyter and Python both come up all the time in discussion with Tulip people (users and staff).

  2. Having also come from industrial controls, I have seen the same awkward and abrupt transitions between no-code (for example HMIs) and code (for example ladder logic). It’s things that in consumer software are abstracted, refined, and iterated on until it’s impossible for an end user to accidentally see the sausage getting made.

1 Like
6

Yup. Agreed. I use a mostly drag-and-drop SCADA/HMI suite called Citect at work (it’s now called something else, I forget the name). I have been using it for a decade; when I started with it, you were stuck with their fairly small set of widgets and terrible graphs. Over the years they have slowly evolved mechanisms where - if you’re more of a developer - you can add custom widgets and business logic, initially with their own terrible basic-like language, and eventually in anything that can generate a .dll. So I think they eventually got on the same path Tulip is heading toward, which is great.

With Citect, I was pretty frustrated early on. It felt very claustrophobic. I definitely don’t feel that way in Tulip. I don’t really feel constrained, it’s more that I see the possibilities and want to leap toward them, if that makes sense :smiley:

7

@wz2b -

You hit the nail on the head. There will always be cases where it doesn’t make sense for Tulip to develop a point solution for. The hope is Custom widgets fill that void.

Having said that - A lot of what custom widgets are being used for it to fill gaps in the product, which is also ok, but something we will use to better understand where finite engineering resources will be allocated. We want 90% of apps to not require custom widgets.

Pete