Other eChart Types possible? If yes how?

[Elrusso (Stefan)]

How is it possible to integrate other echart types? I would like to integrate tree-type diagrams to create a dynamic overview of the devices I use.

I tried the following based on the information in the documentation.
Unfortunately the preview remains empty, what am I doing wrong or is there even a way to copy the config from echart?

tags: []
props:
  parameters:
  parameterGroups: []
timestamp: Mar 25, 2024, 7:46:13 PM
component: f7-card
config:
  style:
    with: auto
    padding: 0px
    margin: 0px
slots:
  default:
   - component: oh-chart
     option:
      tooltip:
        trigger: 'item'
        triggerOn: 'mousemove'
     slots:
        series:
          - component: oh-data-series
            config:
              type: tree
              id: 0,
              name: 'tree1'
              top: '10%'
              left: '8%'
              bottom: '22%'
              right: '20%'
              symbolSize: 7,
              edgeShape: 'polyline'
              edgeForkPosition: '63%'
              initialTreeDepth: 3
              lineStyle:
                width: 2
              label: 
                backgroundColor: '#fff'
                position: 'left'
                verticalAlign: 'middle'
                align: 'right'                
              leaves: 
                label: 
                  position: 'right'
                  verticalAlign: 'middle'
                  align: 'left'
              emphasis: 
                focus: 'descendant'
              expandAndCollapse: true
              animationDuration: 550
              animationDurationUpdate: 750
              data: 
                - name: "Vacuum cleaner"
                  children:
                  - name: "Vacuum cleaner 1st Floor"
                    value: 721
                  - name: "Vacuum cleaner 2nd Floor"
                    value: 721
              axisLine:
                lineStyle:
                  width: 10    

It shall be look like

[splatch (Łukasz Dywicki)]

I am afraid it might not be possible, or can lead to unstable results. Overall - some of charts require specific shape of data, and preparation of this data is done in UI functions which process output of persistence services.

[stefan.hoehn (Stefan Höhn)]

I know that @patrik_gfeller has done amazing stuff here! Patrik, can you help?

[florian-h05 (Florian H.)]

Only line, heatmap, scatter and bar are officially „supported“ by Main UI.

The other charts supported by Echarts are not expected to work since they are not imported, see openhab-webui/bundles/org.openhab.ui/web/src/components/widgets/system/oh-chart-component.vue at 974e28e9babf865d92297980db7e4ff144ffa566 · openhab/openhab-webui · GitHub. Please note that I’ve upgraded echarts last week, which changed the way their tree shaking API works, but I did not change what is imported.

To make tree charts work I guess the according component needs to be imported and enabled, and also added to openhab-webui/bundles/org.openhab.ui/web/src/assets/definitions/widgets/chart/index.js at 974e28e9babf865d92297980db7e4ff144ffa566 · openhab/openhab-webui · GitHub, where pie chart is missing.

My only concern is the bundle size increase, but we will be able to check this once a PR is created.

[patrik_gfeller]

thanks to @stefan.hoehn for the flowers .

I’m not an expert in that topic, but I was able to use e.g. the pie chart for eChart directly - but you have to process the data most likely in a rule to have a format than can be used. I did not use other chart types yet - but it seems to work to a degree in 4.1.1. The only problem I’ve encountered is that I could not define callback functions in the UI to perform more advanced formatting …

Have a look at Create a pie chart with oh-chart to show top 5 processes (system information) - that’s the chart I’ve done so far.

Let me know if it helped - and if it worked maybe also document what was the things that need to be considered.

@florian-h05

Please note that I’ve upgraded echarts last week, which changed the way their tree shaking API works, but I did not change what is imported.

I do not know if this will prevent e.g. pie chart to work in the future - we’ll see - maybe there’ll be a way to keep the bundle size reasonable and keep the functionality (e.g. lazy loading of modules in case they are used …).

If it works maybe you have time to check if it still works with the snapshot including the updates. At the moment I’m very busy & do not have time - but if you do not know how to do this I’ll add it to my todo list let me know.

Btw.: For such experiments with other openHAB version a docker container can be very useful to isolate the test system from your productive environment.

with kind regards,
Patrik

[florian-h05 (Florian H.)]

@patrik_gfeller

I do not know if this will prevent e.g. pie chart to work in the future - we’ll see -

I have kept everything that was supported previously, pie chart is hence still included into the UI bundle and should still work — tree was never included and therefore won‘t work.

@patrik_gfeller

maybe there’ll be a way to keep the bundle size reasonable and keep the functionality (e.g. lazy loading of m

The oh-chart-component is already lazy loaded, but we should try to keep the size of this component small by not including the whole echarts library. Adding tree charts however should be fine (I guess so), we just should not include the whole echarts library.

[patrik_gfeller]

@florian-h05

I have kept everything that was supported previously, pie chart is hence still included into the UI bundle and should still work — tree was never included and therefore won‘t work.

@Elrusso - then you do not need to spend the time to experiment obviously. The only thing I can think of is what would happen if you use a script element to load the missing eChart parts inside the widget - but I’m do not know if that is possible and never tried something like this. But as html element can be used it depends - I do not know how the UI processed the yml exactly and if there are mechanisms that will prevent the load of a script like this. That would be try and error to see what happens …

If it does not work we could consider a feature request for the UI that allows to include custom resources like scripts and css - but I’m not a web specialist; this might be more complex than I think and most likely be something only for very advanced users - as it can also be a security risk to load side load code like this.

as the graph element you need will probably be included soon you might just wait - or spend some time and experiment if the script approach is feasible (or a completely stupid idea, but would be very interesting to know what can be done in that regards to have a basis for a potential feature request/discussion).

[Elrusso (Stefan)]

Thanks for all the answers and tips. I am pleased that it may be included in one of the next milestones.
I’ve also thought about possibly integrating it as HTML, but I don’t have much experience in creating it. The script approach is a point where I also get clever. But since my time is definitely limited for another 1-2 months, probably not with a timely result.

In addition to the example of a structured representation of the devices and their communication medium, it is also possible to display the energy flow in the house on the individual phases and fuses and, if necessary, to make a decision on which phase a wallbox should be connected to if cable cross-sections are limited or other large consumers are already connected to one phase. Most of the information is already integrated into Openhab, I just haven’t been able to create a clear representation here yet. Tree eChart seems to be a promising and simple approach here.

I have already recreated the PI chart (for the top electrical consumers) and that is how I discovered all the possibilities of the eCharts

[JustinG]

@patrik_gfeller

The only thing I can think of is what would happen if you use a script element to load the missing eChart parts inside the widget - but I’m do not know if that is possible and never tried something like this.

It is possible to use the widget yaml to include scripts, both inline and loaded from source. This is not widely advertised and definitely not officially supported (and not likely to ever be, for obvious reasons), but it can be done. I’m not sure it’s going to solve this particular problem, however, as passing data between the widget context script and the mainUI backend is non-trivial.

[florian-h05 (Florian H.)]

@JustinG

It is possible to use the widget yaml to include scripts, both inline and loaded from source. This is not widely advertised and definitely not officially supported (and not likely to ever be, for obvious reasons), but it can be done.

Out of interest: Can you please provide an example?

[JustinG]

@florian-h05

Can you please provide an example?

Put test.js in your conf/html folder:

console.log("This widget runs scripts!")

Then this widget, as soon as it loads will remove the navbar and print to the console:

uid: demo_js
tags: []
props:
  parameters: []
  parameterGroups: []
timestamp: Mar 27, 2024, 4:08:59 PM
component: f7-card
config:
  title: JS example
slots:
  default:
    - component: script
      config:
        content: |
          document.getElementsByClassName("navbar")[2].style.display="none"
          document.getElementsByClassName("page-content")[3].style.paddingTop=0
    - component: script
      config:
        src: /static/test.js

[ysc (Yannick Schaus)]

@JustinG

This is not widely advertised and definitely not officially supported (and not likely to ever be, for obvious reasons)

[florian-h05 (Florian H.)]

@patrik_gfeller

The only thing I can think of is what would happen if you use a script element to load the missing eChart parts inside the widget - but I’m do not know if that is possible and never tried something like this.

Then you’d need to load them from a CDN and also activate them for openHAB‘s Echarts instance.
I would rather recommend that we import the TreeChart component for Echarts and see how bundle size changes. I guess it is not that much so I would be fine with it.

[florian-h05 (Florian H.)]

@patrik_gfeller

If it does not work we could consider a feature request for the UI that allows to include custom resources like scripts and css - but I’m not a web specialist; this might be more complex than I think and most likely be something only for very advanced users - as it can also be a security risk to load side load code like this.

As Justin has shown this already works …

@ysc
Wrt to this being a security risk: At least only the admin user is able to load custom scripts into the UI for all other users, I would consider this case the same as the scripting engines on the server, it’s like remote code execution/injection explicitly allowed to the admin user.
But I’m against documenting this approach, I don’t think it should ever be widely used.
Anyway I’m curious how powerful it is, I will have a look at it.