Arbeiten mit Funktionen in der ETS

[larsrosen]

Hi,

read ko directly without group address.

[S. De Bruyne]

Hi,

read ko directly without group address.

Thanks, but we were discussing about the "Funktionen" for quick creating GAs and functionality, not about ETS functionality in general.
By the way, reading GOs without GA is possible in Secure devices; I'd have to check the integration state.

[larsrosen]

Ups, sorry,


For quick creation of GA it would be useful to create a Master template like Powerpoint.
These can then be inserted into the building structure.

Possibly there should be a query here, in which GA group the GA should be created.

example heating:
I need 15 GA that are always identical.
Then I create a master heater with the labels.

When inserting it into the building, I enter the central address and that's it.

[henfri]

Hello,

it may be losely related only:
I see two usecases in which functions come to play:
1) transition of an existing project to function
2) a new project

I think most users will have some structure in their GAs then, it would be nice if ETS could learn. E.g. my first function "Light" would have
1/2/0 Kitchen Switch
1/2/1 Kitchen Switch Status
1/2/2 Kitchen Dim
1/2/3 Kitchen Dim Relative
1/2/4 Kitchen Dim Status

When I now say
1/2/5 Living Room Switch

I gues that everyone here can continue. So, it would be great if - when dragging the 1/2/5 onto a Light function, the GAs up to 1/2/9 would be associated automatically as a suggestion.

For a new project, I suggest to guide the user to completely get rid of GAs and manually thinking of a GA scheme and use functions only. I think, that this lower level (GAs) is not needed for 95% of the associations. So, if I have used the GAs for Switch of "Kitchen" there will never be a usecase where I need to associate the Dim functions of Living Room to the same Device.

What I mean is: Usually the GAs already work in Functions. Groups that "stick together". And it is only labor that I have to associate 5 GAs instead of one function in 95% of the cases.
I think that working in and thinking in functions could really be a step-change. But also I think that such a Step-Change is difficult, as the user-base has a way of working they are used to. So, you have to build the bridge. And this could be done by giving the user the possiblility to teach their GA structure to ETS-Functions.

Does that help, or is it too general/abstract?

Regards,
Hendrik

[SvenB]

Hendrik, last week I discovered the functions in the ETS 5 (was disappointing) and expected something similar to your ideas:
All main use cases have a default structure. Like a dimmer: switch, status, relative dimm, absolute dimm, dimm status.

When I connect all GA to the actor KOs they get automatically grouped into a function. Then it must be possible to connect the function to every other device (Fe. a switch) just by connecting the function instead of GA. Especially for RGBW devices there are many different Datatypes to represent the colours. When connecting a default function to a device all parameters should get adopt to this automatically to handle the function. All GAs are connected in the back - but still with the ability to customize things if needed. This reduces the connections and parameters a lot by giving more overview and context why things has been wired together.

From my perspective this is applicable for new projects but also for existing ones. At new projects the GA structure could/should be generated.

But this way of thinking in function may influence the device communication / GA connections. Let me try to make an example: now we connect a switch with the FIR detector and this is controlling the actor. But only for switching or sequence signals. Dim information are directly connected between switch and actor. When thinking to functions we may also route dimm and status information through the presence detector - with some drawbacks.

To think in functions could also be a method to map and document the main usecases in a house. Not all use cases are transparent for new electricians / experts - Like a switch at the front door is controlling the garage. With the room information I could imagine more documentation that could be used by the customer. And in the end he may customize things on functions (and not device) level in an UI / App that is easy to use by everyone.

Not easy in a heterogeneous decentralized system…

[eibster]

The question is.. is functions a topic where the KNX Association is willing to push forward.
the current state is … ok its there , someone could make a cross in their todo list.
but its very hard to find someone that a) actually uses it and b) likes it.

And there is no question that in the core its a good idea
but when unfinished its more like a break assist that don't works. ( i switch it of and behave like i don't have it)

[meti]

its very hard to find someone that a) actually uses

I thought the intention was to gain semantics to be used in KNX IoT.

[Klaus Gütter]

is functions a topic where the KNX Association is willing to push forward.

Otherwise Steven de Bruyne would not have asked here,

Everyone is unhappy with the current state of the functions and having seeing no progress here for many years, KNXA is asking for input from "real life" use cases.

[S. De Bruyne]

Thanks, Klaus. Sorry for not reacting in-between. Some feedback.


A. ETS Funktions are not thought for "quick creation of GA", but actually, they could be used for this.
B. The current ETS Functions are only a basic start. So, I understand that it is disappointing :-) If this works well, more Functions (tens, hundreds...) can be added. That's why I asked for examples of possible ETS Functions.
C. In the same way, repeating GA structures (henfri) can be seen. What you write is indeed what Functions are thought for.
D. Functions obviously will bring a lot more semantics in the project than DPTs.

Thanks.

[nina b]

ETS functions lack the flexibility to be truly useful in their current state. There's no control over where the GAs are created, what GAs a function truly needs, and no influence over the naming of the GAs.

A sensible GA structure is important. For all the work that functions may spare me, laboriously fixing my GA structure afterward makes that irrelevant. When I copy a function the ETS asks me where to create the GAs, why not when adding a new one? The ability to add a function that uses already existing GAs but the added metadata of roles would be nice as well.

Support for GA structures that split the GAs of a given function over multiple middle groups would be nice as well.

Another important part is the naming system of the GAs. The GAs created by functions do have location and function information in their description, but to access that information when looking at a device I need to hover over each linked GA. I prefer putting that information into the name of the GA.

Exposing the roles object would be a big help. I could create functions and add already existing GAs I've created using my own GA structure and naming system without losing out on the metadata. User-defined templates for functions as well as the GAs would also be helpful.

[jhaeberle]

Does anybody have any requests/suggstions for a. ("Standard ETS Functions") ?

• schaltbare Steckdosen
• Wetterstation

Die vorhandenen Funktionen sollten anpassbar sein, so dass man das auf seine Aktoren/Situation anpassen kann. Nicht jedes Rollo ist ein Jalousie, Dimmer funktionieren auch nicht alle gleich.

[Beleuchtfix]

Die Diskussion habe ich vor 4 Jahren gestartet, vor 1,5 Jahren wurde von S. De Bruyne angedroht“, das man hunderte von Funktionen machen könnte, wenn man nur wüsste, was gebraucht wird. So richtige Fortschritte sehe ich noch nicht.
Gruß Florian

[henfri]

Hallo Klaus,

Zitat aus 2020:

Benutzerdefinierte Funktionen haben nun leider keine Rollen und die ETS-Oberfläche bietet auch keine Möglichkeit an, die zu definieren. Deswegen kann sich die ETS auch nicht die einmal getroffenen Zuordnungen merken.

Persönlicher Kommentar: Sollte jemand sagen wollen, dass das Konzept irgendwie nach "auf halbem Weg stehengeblieben" aussieht, kann ich nicht direkt widersprechen. Das Thema ist bei der KNX aber noch auf der Tagesordnung und ich hoffe, dass das im Zuge der IoT-Initiative wieder Fahrt aufnimmt.

Ist das Thema immernoch dabei Fahrt auf zu nehmen? :-)

Wie du die ETS-Vordefinierten Funktionen beschreibst klingen die nach dem, was KNX braucht um in diesem Jahrtausend anzukommen. In GAs zu denken ist in meinen Augen 90er.
Die benutzerdefinierten Funktionen scheitern aber daran, dass sie nicht lernen. Dadurch sind sie quasi wertlos (oder?).
Ich verstehe, dass es schwer ist, eine Kompatibilität zu alten Geräten zu erzeugen. Aber ganz ehrlich: Warum wird hier die Community nicht eingebunden? In Nullkommanix würde es Vorlagen geben, die die (1) alle erdenklichen Benutzerdefinierten Funktionen und (2) Zuordnungen zwischen diesen und allen erdenklichen Geräten erzeugt haben.
Danach müsste man nur noch Funktionen und nicht mehr GAs in der ETS verwenden.

Noch praktische Fragen:
Funktionen kann ich nur auf Kanäle ziehen, oder? Sprich: Unterstützt ein Gerät keine Kanäle (z.B. Zennio Quad), so kann man keine Funktionen verwenden sondern -Fallback- muss GAs nutzen? (Auch hier würde die Community schnell "wrapper" erzeugen.

Und noch ein Problem, welches ich beim Probieren hatte:
image.png
Warum sind hier die GAs leer auf der linken Seite? In der Funktion sind sie ja definiert.
(ETS 6.2. Traue mich weiter nicht auf die 6.3)

Gruß,
Hendrik

[BadSmiley]

Knx A und Fahrt aufnehmen.. Die wissen max wie sie noch mehr Geld machen können... 80€ für einen Passwort Manager...