Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Heatmap widget #577

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
Open

Conversation

bartbutenaers
Copy link
Contributor

@bartbutenaers bartbutenaers commented Feb 13, 2024

Description

As discussed with @joepavitt, this pull request is an attempt to migrate my node-red-contrib-ui-heatmap from D1 to D2, but now as a core UI node.

Demo:
demo

Demo flow included as a file, because it contains a base64 encoded image and was not accepted by Github in this readme:
demo_flow.json

My old ui node was based on the heatmap.js, but that is not maintained anymore for about 8 years. Therefore I have used the visual-heatmap library for this one. The author of that node has been very helpfull! P.S. His visualHeatmap.esm.min.js file is about 16KB large.

TODO's:

  • When the view is resized, it doesn't fit anymore into the div.
  • When the browser is refreshed, the heatmap is empty. I think I have stored the data correctly in the datastore, but it is not used.
  • My pull request (for dynamically setting gradients) has been merged, but we need to wait for a new version on npm. Otherwise this option won't work...
  • Allow labels to be drawn on top of the heatmap (like in the old ui node).
    Detail: I wanted to draw it on top of the visual-heatmap canvas, however it has a webgl context which does not support fonts. Therefore the author of the visual-heatmap node has provided me another solution (see demo). However it is based on his i2djs library, and that minified file is 237KB large. Not sure if that is acceptable. If we could have a canvas on top of the heatmap (which resizes the same way) that might be a better solution perhaps...

Question: when you injected an array of numeric values into my old ui node, these points were rendered from top to bottom and left to right (i.e. vertical columns). Now with this node they are rendered from left to right and top to bottom (i.e. horizontal lines). I could change it to make it more the same as in the old node, but I think it is more intuitive to do it this way?

P.S. I have not added unit tests, simply due to a severe lack of free time...

Related Issue(s)

See issue.

Checklist

  • [ X ] I have read the contribution guidelines
  • Suitable unit/system level tests have been added and they pass
  • [ X ] Documentation has been updated
    • Upgrade instructions
    • [ X ] Configuration details
    • Concepts
  • Changes flowforge.yml?
    • Issue/PR raised on FlowFuse/helm to update ConfigMap Template
    • Issue/PR raised on FlowFuse/CloudProject to update values for Staging/Production

Labels

  • Backport needed? -> add the backport label
  • Includes a DB migration? -> add the area:migration label

@Paul-Reed
Copy link
Contributor

@joepavitt - Please consider what is the rationale in making this a core node, instead of a contrib node?
I just wonder where the list of core nodes will end, and contrib nodes will begin.
Currently, there are no DB2 contrib nodes in the node-RED library, and therefore no examples that developers can use as templates to develop their own.
No offense Bart, you know I'm a fan of your nodes and work, but I can't personally see a use for this node myself at this time, so why should it be included in my palette?
It sort of makes the node-RED 'Manage Palette' feature redundant...

@joepavitt
Copy link
Collaborator

joepavitt commented Feb 14, 2024

Please consider what is the rationale in making this a core node, instead of a contrib node?

Reasonable question - my initial motivations for the decision was that it's a general type of visualisation, and is consistent with how it interacts and behaves with our other core nodes (Charts and Gauge) in that regard.

We also discussed ui-svg being ported, but we agreed, for example, that would remain third-party as it's API for defining content would be very bespoke to just ui-svg, and isn't consistent with other core nodes.

Similarly, I've been asked many times to include UI LED (#550) as a core node, but I want that to remain third-party as it's particular to Home Automation and/or Manufacturing, and doesn't represent a generalized tool/widget that could have multiple use cases.

I do understand the concern though, this wouldn't be a "popular" node like ui-template or ui-button, and so does that by itself therefore warrant it's exclusion - it's a very fair point and something that is making me think twice.

Currently, there are no DB2 contrib nodes in the node-RED library, and therefore no examples that developers can use as templates to develop their own.

We do have the Example project for this, and there is an in-progress and very nearly ready third party widget for Webcam integration

Co-authored-by: Zeger-Jan van de Weg <ZJvandeWeg@users.noreply.github.com>
@joepavitt
Copy link
Collaborator

@bartbutenaers and I have spoken about @Paul-Reed's feedback, and agreed that this will serve better as a third-party widget.

As such, @bartbutenaers will open a new repo under his ownership, and we'll assist with any migration/changes required in order to make it compatible, as there are some minor differences between core and third-party widgets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants