New Visualization – Is HTML widget JavaScript / KNX interaction officially supported?

[Ahmed.K]

Hello,
I would like to clarify the supported behavior of the HTML widget in the new LogicMachine visualization.
Questions

1. Does the HTML widget in the new visualization support inline / embedded JavaScript execution, or is it limited to HTML/CSS rendering only?
   
2. Is Custom JavaScript in the new visualization supposed to interact with DOM elements created inside an HTML widget?
   
3. If we build a custom HTML-based interface in the new visualization, is there any officially supported way to trigger KNX writes (switch / dimming / RGB values) from that interface?
   
4. If not, is the recommended approach to use native LM widgets only for all control logic in the new visualization?
   

I would like to confirm what is officially supported before finalizing the architecture of a custom supervision page.
Thank you.

[admin]

You can't put inline JS into HTML widget, you have to use Custom JS for that. Check the links below.

Basic HTML widget interaction: https://forum.logicmachine.net/showthrea...3#pid42313
Visu JavaScript reference: https://kb.logicmachine.net/misc/visu/

[Ahmed.K]

You can't put inline JS into HTML widget, you have to use Custom JS for that. Check the links below.

Basic HTML widget interaction: https://forum.logicmachine.net/showthrea...3#pid42313
Visu JavaScript reference: https://kb.logicmachine.net/misc/visu/

Hello,
Thank you for the clarification regarding the HTML widget and inline JavaScript.
I would like to confirm the next step for the new visualization:
Question
If the HTML widget is used only for the markup and the interaction logic is implemented in Custom JavaScript, what is the official / supported way to trigger KNX writes from that Custom JavaScript?
For example, from a custom RGB interface we need to write:

• boolean ON/OFF values
  
• dimming / percentage values
  
• RGB 3-byte values
  

Could you please clarify which of the following is the recommended method in the new visualization?

1. A supported JavaScript API / function to write values directly to KNX objects from Custom JavaScript
   
2. Using native LM widgets only for the control logic, while Custom JS is used only for the UI behavior
   
3. Calling a Lua / HTTP bridge from Custom JavaScript
   
4. Another officially supported mechanism
   

If there is a supported JavaScript API, could you please indicate the relevant documentation or function names for:

• boolean write
  
• numeric / dimming write
  
• RGB 3-byte write
  

I would like to confirm the correct architecture for building a fully custom control page in the new visualization.
Thank you.

[Daniel]

Did you evaluate the existing widgets which can already do the same? It could be much simpler way. Don't forget that on custom widget you can combine several widgets into one.

[Ahmed.K]

Yes, we are evaluating the native widgets approach in the new Visu, and we agree it may be the better path if the required RGB workflow can be covered without custom JavaScript.

Our target is to build one RGB supervision page with:
- one global ON / OFF command for all RGB zones
- one global color selector applied to all zones
- individual zone control from the plan (zone ON / OFF + color selection per zone)
- all of this inside one custom visual block / page layout

Before we rebuild everything with native widgets only, could you please confirm the recommended way to achieve this in the current Visu?

More precisely:
1. Can a custom widget in the new Visu combine several native widgets (switch / color / slider / buttons / links) into one operational RGB control block?
2. For an RGB zone, what is the recommended native widget combination to control:
  - 1-bit ON/OFF object
  - RGB color object (3-byte / DPT 232.600)
3. Is it possible to have one “global color” control writing the same RGB value to multiple group addresses directly from Visu, without using custom JS?
4. For the plan view, is the recommended method to place multiple widgets over the background image (one widget per zone), rather than using an HTML widget?
5. If some logic is needed (for example “apply global color to all zones”), should this be handled by LM resident/event scripts, while Visu remains only the front-end?

If you have a simple example / best practice for an RGB page in the new Visu, that would help us align with the official supported method.

Thank you.

[Daniel]

1. Yes
2. Light, but there are other widgets for RGB, play with them ans select the one fits you best.
3. There are two ways, A correct one is to create global group for your all RGB in ETS and use it for global control, or create new object and event script which will write to your other RGB groups(this will create extra traffic) No JS needed here
4. Not sure what you mean, you can do what you want there.
5. See point 3.
Visu is very flexible tool and it is up to you how you will design your visualization.

[Ahmed.K]

Thank you for the clarification.
Yes, we understand that the RGB control logic itself can be handled with native widgets, a global ETS object, or LM scripting when needed.

Our remaining question is mainly about the recommended architecture for the visualization layer in the new Visu.

Our goal is to build a single RGB supervision page with a custom user interface, including:

• a background floor plan,
  
• several RGB zones directly accessible from the plan,
  
• one global RGB control area,
  
• individual zone interaction (ON/OFF + color),
  
• and a more intuitive / modern page layout than a standard list of widgets.
  

So what we want to confirm is the following:

For this type of advanced RGB supervision page in the new Visu, is the recommended / supported approach to:

1. use the floor plan image as the visual base,
   
2. place multiple native Visu widgets on top of it as the interactive layer (switches, RGB/color widgets, buttons, links, indicators, etc.),
   
3. group them visually into one custom page layout,
   
4. and keep ETS / LM scripts only for the backend logic if some global behavior is required?
   

In other words, we would like to confirm that HTML widget + custom JavaScript is not the intended method for building the interactive control layer of such a page, and that the correct supported approach is to rely on native widgets for all interactions, while custom styling remains only a visual/layout topic.

If this understanding is correct, we will proceed with that architecture.

Thank you.

[Daniel]

There is no recommendation, all is up to you. For sure the best way is to use ready widgets and not a custom HTML+ JavaScripts.