License/terms of use for Veutify

Dashboard 2.0
1

Hi,

I am interested in using Dashboard 2.0 as part of an IOT product for wineries.

Are there any issues in using Veutify components using templates in such an application?

Thanks

2

Hi @solanus - thanks for your question. Vuetify components have the MIT License which is a very generous and flexible license permitting free of charge use in commercial settings.

3

Thanks, thats what I hoped!

Seperately, I know you get this question ad nauseam but when do you think you’ll have tags enabled for template nodes? I used the circular progress component to make a gauge but need the tag to increase the font size appropriately for the numeric value in the middle.

4

addendum to the above post ^^ I meant script tags not just tags

5

Hoping to start work on that this week. We’re just pushed a major update to third-party integrations which affected that a lot, so needed to tread carefully. It’s not going to be a trivial piece of work, so difficult for me to say when it will be delivered.

6

Thanks Joe!
Let me join @solanus with eager anticipation for the ability to add a JavaScript section in the template node, so that I can move from Dashboard 1.0 to 2.0.
The JS just needs to:

  • Provide handler functions to UI events (e.g. button click, drop-list select etc.)
  • Enable to send & receive msg objects (for current user only, as well as for all users)
7

This was added in the latest release of Dashboard 2.0 this week. Let me know how you get on!

8

We’re in business now!!!
Thank you Joe!

I started playing with it, and it looks great. I have a few questions:

  1. When using this.send(), I see that the provided data (primitive or object) is always set into the payload property of the output message. Yet if I send an object which has a payload property, only that property is being extracted & sent. What is the logic here? Also, what value goes into topic?

  2. How can I stop an incoming msg to be automatically forwarded to the output port? (for cases where I want to receive a msg via $socket.on(), process it and then discard it). In Dashboard 1.0 there was a checkbox for this in the node configuration.

  3. What is the scope of the socket id? (is it per page or per a connected browser with multiple pages?)

  4. Dashboard 1.0 templates support multi-user by checking the socket id (accepting only messages with same, or without, socket id). I can easily check this myself on incoming messages but would propose adding this option (of discarding messages with a different socket id) as a node-configuration checkbox.

9

Awesome work Joe!

I too have been messing around with it and have a couple questions:

  1. I share omrid’s question about this.send() always outputting as the payload property. This wasn’t the case before, will it remain this way?

  2. Whenever I try to refresh the dashboard it throws a white screen and errors : “Cannot GET /dashboard”. Any way to change this?

Thanks

10

Yeah, this is actually a problem I spotted on Friday just after I released 0.10.0. It’s been an issue since the start due to how I built this.send(), but can be sorted. I’ve raised an issue here: Bug: Impossible to define full `msg` from `ui-template · Issue #427 · FlowFuse/node-red-dashboard · GitHub

I have listed this in our migration document - not got round to adding that feature yet, but it’s on the list as Issue 354

It’s defined as a single Socket connection. This would be unique per Browser tab, but would actually reset on page refresh too, as that disconnects the socket. I’m working with Julian, developer of UI Builder, where we plan on agreeing on a set of “standards” for being able to map, more consistently, which user/client is connected at any given time - see our notes here

Given it’s fairly easy in the ui-template to do this check atm, I’m not likely to be in a rush to add this myself to the core repo (although all contributions are welcome). However, I don’t want to lose the idea in this forum, could you create an issue on our GitHub repo please?

11

That certainly shouldn’t be happening - can you open an issue please, and I will likely request a few more details on there.

12

Thanks Joe, for the clarifications.

It’s great to hear that you & Julian are concluding the standards, which would allow consistent multi-user behavior.
I asked the above question since currently, when moving between pages (while staying on the same browser tab), if I use the dashboard’s side-menu the socket id does not change, but if I specify the new page URL (in the browser’s address bar), it goes there with a new socket id. Is this by design?

13

Something similar also happens to me, but only when the browser console is open (due to the browser’s debugger pausing on a few recoverable load errors). Clicking ‘resume’ will eventually load the page and continue to operate correctly.
If the console is not open, refresh works with no issue.

14

This is a limitation of how WebSocket connections work, and until we come up with our own clientid standard that we store in localstorage for example, it’ll continue to be the way.

WebSocket client disconnects when a full page is refreshed/navigated way. We use VueJS, which is a “single-page application”, so when you’re navigating between pages using the left-side navigation, in fact VueJS doesn’t refresh/reload the page, it re-builds the content in front of you and just updates the URL in the browser, allowing it to maintain state.

1 Like
15

Control of automatic msg forwarding (in ui-template) has just been added in v0.11.6 and is working well. Thanks Joe!!

Now hoping for resolution of the other issue mentioned in Issue 354 - retaining the output msg in send() as-provided.

16

Thanks @omrid - just to check - you mean this one? Bug: Impossible to define full `msg` from `ui-template ¡ Issue #427 ¡ FlowFuse/node-red-dashboard ¡ GitHub

17

Yes, exactly. I understand there is some limitation to send a full msg object - maybe the framework can stringify/parse it?

The current behavior is like this:

  • Sending an object which has a payload property will output this payload (+ an empty topic property), while discarding all other properties (including the original topic property)

  • Sending an object without a payload property - will output this object within a payload property of the output msg

So currently my workaround is to use the second method, i.e. ensure we don’t specify a payload property, and extract the msg object from the output payload.

18

Am working on that feature today - should be out this week if all goes smoothly.

1 Like