EEZ flow enhancements

[fietser28]

Based on version 0.9.83

While working with EEZ Flow I make a list of things I missed. This might be because they are not present OR because I didn't grasp the concepts behind EEZ Flow not completely. Some of them are also not strictly necessary because you can create them by combining existing functionality, but will make it easier to focus on creating flows.

I tried to list items not already mentioned in existing issues

Data type: Struct/dict

• [x] Struct/Dict: Combine several variables into a single data element. Often you are reusing the same set of variables multiple times in your flow ( instrument + channel, avg+min+max, measurement+timestamp, ...). This type looks either like a struct from C or maybe a dictionary from python/perl. The later being more dynamic and possibly a better fit for eek-flow. Actions related to the struct/dict datatype:
• [x] 'multiplexer': configurable input names are combined into the struct/dict with the configured names, output is the struct/dict. This creates the struct/dict on the fly. Solution: With the current implementation you can easily read/write variables in arrays and structures in expressions. A separate action is not needed.
• [x] 'demultiplexer': the other way around, you extract multiple (manually configured in the action) outputs. Solution: With the current implementation you can easily read/write variables in arrays and structures in expressions. A separate action is not needed.
• [x] set/get variable: should be able to use something like 'instrument.channel' to set/extract a member of the struct/duct

Data type: Ordered list (with limit)

• [ ] An ordered/numbered list with an optional limit that can be defined. If the limit is reached the list overwrites old entries. This type is useful for collecting measurement sets of data. I think the limit/overflow option is useful to avoid runaway logging. Reaching the limit should through a catchable error. I'm not sure what the best way is to number the list: newest entry = 0 or the other way around. Maybe it is possible to reuse/integrate this with DLOG data structures.
• [ ] The ordered list should be capable of storing struct/dict structures: Log combination of data (similar to DLOG).

Data type: JSON

This is useful for MQTT/HTTP interfacing later on.

• [ ] Add an action that inputs a struct/dict or multiple named inputs and outputs this in a JSON string. (#263)
• [ ] The other way around: read a JSON string and output one or more named parameters or a struct/dict. (#263)

Actions

Here is a list of specific actions I think might be useful to add. Most of them can be realised already in some way.

• [ ] regex-splitter: Some SCPI instruments return multiple arguments in a single string. You need regex to split this out in individual items. This is currently possible within the eval, but I think it is better to have a dedicated action for this. This also allows for better error handling if a string was not matched or add options if it is matched multiple times (= output multiple events or not). The latter is not easily possible now. Done for dashboard, not other flows.
• [x] changed-filter-action: an action that only outputs the incoming data if the data is different. This action is for reducing unnecesary events. E.q. in a situation where an instrument is polled, this filter only outputs if a different result is received. Solution to this is using a watch action (or implement in the native code if the variable is a native variable).
• [x] not-connected-sink. sink to avoid errors (small cross, like in KiCad schematics) for True and Compare, these give errors if not connected.
• [ ] add a 'declare as variable' option to the input action. Saves an action, nothing more. E.q. instrument input.
• [ ] In the declare variable action: Add a 'persistent' option. This makes a variable inside an action also persistent across triggers. This was discussed on discord with @mvladic
• [x] delay action: the delay parameter cannot be converted to input. a merge request is already there for this.
• [ ] statistics action: an action that calculates one or more of average, min, max, stddev. This action should also have a 'reset' input.
• [ ] timer action: it outputs events based om some timer settings: frequency/period, counts. You probably can make this with counter, delay and eval already, but that will have much more/to much jitter.
• [ ] formula action: outputs a time sampled waveform based on the given formula (3*sine(t), where t is generated ). This is possbile with timer and eval, or even with delay and eval but not user friendly.
• [ ] all done/ ‘wait for all triggers’. How to make sure action triggers ‘end’ action if everything is finished in action (a.s. all outputs are ready)? Without creating a bunch of trigger lines that create a order of execution not needed.

Library

• [x] Allow actions and widget/pages to be collected in libraries and shared/reused. If I change an item from a library it will be copied to my flow (See #162).

UI related items

• [ ] in text add sprintf format capabilities (rounding, units)
• [ ] a measurement formatting output: M/k/m/u and selectable # digits. Can also be an action if not integrated into UI elements.
• [x] In gauge: make min/max also inputs (dynamic scaling)
• [x] in line chart: allow for x/y input. X is now time based only. Probably best to have a the dict/struct like usage described above (#178)
• [x] ‘select from’ (dropdown)list, input is an list/array
use case: query the channels of instrument and let user choose the channel…. (see #259)
• [x] numerical input (min/max), unit (equivalent to BB3 keyboard input), maybe with fancy knob/slider. This can now be realised with widgets.
• [x] Allow callactions to have a custom logo/choose from list. I see call actions as the reusable/self programmable blocks. Also nice in library (See #162).
• [x] #141 add comment/description in ‘statusbar’ if used.
 Especially for: SCPI and callaction, it allows you to add a small description what the scope/action does in the visual presentation. If description is there it will be shown in the bottom part of the action (truncated?), just like the title but on the bottom row of the block. Also nice in a library.
• [ ] List editor action (like in the BB3 instrument for lists, reuse it?) that allows to output values in a timed way (limited in speed, but still useful).
• [ ] Histogram, shows distribution based on incoming events. Resettable.
• [ ] Table / log, showing a list of structures... with auto scroll to show last x entries, columns should have selectable title. Combine with dict/struct and ordered list above?
• [x] Nice to have: Progress bar
• [x] Nice to have: 7 segment display ‘look’. Just to give the classic instrument feeling. Maybe a theme? Solution: This can be done with a 7 digit font.

Interfacing

• [x] Add MQTT in/out actions. Just as with instrument: 1 action to connect, actions for public and subscribe to a topic. Important to have the JSON actions here (#264).
• [x] HTTP / REST. To send/ retreive data to the outside world/modern applications. Here JSON is also key. #201
• [x] File output. CSV, XML and/or JSON (Done: CSV and JSON are implemented on dashboard projects)
• [ ] PDF generator: To generate calibration certificates?
• [ ] mDNS discovery of instrument. (or is this already possbile with current implementation?)

Feel free to ask more detail about the items or skip them al together.