Please add StateRoles level.extern and sensor.contact

[J-Paul0815]

Contact Details

iobroker@hafenmeister.com

What do you miss?

I request adding 2 state.roles.

The first "level (numbers, read-write)" It could be called "level.extern", or "level.externTemperature" as examples. Set external measured temperature. The background is heating thermostats that allow external temperature sensors to be used for control. This can be useful in large rooms, if the thermostat is covered by furniture or curtains, or if it is more comfortable to measure the temperature in the lounge area, to name just 3 reasons. Automations are easier to create for larger installations (> 100 devices) if the states are already assigned suitable roles when they are created. Linking the temperature sensor and the thermostat once the room has been assigned would make this much easier if they have a suitable role.

The 2nd "Sensor (booleans, read-only)" "sensor.contact" contact opened-false or closed-true This could be mailboxes, flaps or anything that is not a door or a window.

Link

https://github.com/ioBroker/ioBroker.docs/blob/master/docs/en/dev/stateroles.md

[mcm1957]

ad first: level.temperature already exists. Why do you want level.temperatur.extern etc. ? Whats the difference between en external sensor and an internal sensor. Besides. LEVEL is used to SET a temperatur. So level.temperatur most likely relates to i.e. a cooling or heating equipment. Measerug sensors normally should be read only, this value.temperature.

ad second: sensor.contact - I agree, theres no matching role currently

[Apollon77]

@J-Paul0815 First of all please see roles mainly from the following perspective: Semantic information for UserInterfaces for end users! "value" means ... the value is just displayed ... level means that ideally control elements are shown so that "the end user" can set the value

The background is heating thermostats that allow external temperature sensors to be used for control.

hm ... but for the device this is still "Just a measured temperature" ... how the device uses this is a different topic. SO this is nothing that a user sets (which is the main topic for role "level" - a UI shows control elements for the user! So such a temperature sensor value is still a "readonly measurement value" (from the view of the device) and yes, some "binding" or such sets the value but no user! From this perspective in my opinion a "measured temperature values" (also when measured from an external sensor) is just a measured temperature.

BTW: I could understand the idea to separate "indoor" and "outdoor" temperatures with different roles because here measurements could be shown differently ... but that's not what you mean :-)

"sensor.contact" I would agree. We have the specialized versions for window and door but maybe a generic contact is also an interesting idea ...

[J-Paul0815]

@mcm1957 @Apollon77 Thanks for answering. Yes, that's exactly what I meant. Sorry if I wasn't clear. Let me describe the situation: A thermostat tries to adjust the target temperature to the measured temperature. If the target temperature is higher than the measured temperature, heating is needed. However, if the thermostat is behind a curtain, for example, then the thermostat will measure incorrectly (too high). To avoid this, this thermostat has the option of receiving a value measured by an external temperature sensor. This value is therefore set, not read. I mean two different things. A value is read (value.temperature) and then set/written, hence (level.extern). This (level )value is then used for control and no longer the internally measured one.

So such a temperature sensor value is still a "readonly measurement value" (from the view of the device)

No, it is explicit writable, see manual: Set External temperature sensor value with accuracy 0.1: Example downlink: 0x3C 0102 – the server notifies (Thermostat) Vicki that the measured temperature by the external sensor is 25.8 degrees Celsius. 25.8*10 = 258 = 0x0102 (Downlink=send to the device) The idea behind this state is that the user can set something there. Obviously not manually, but it is something to set, not something to read.

[Apollon77]

Also read and write flags in data are just meaned as guidance for UIs!!

Write means "writeable by user" ...

In fact you are basically right with your argumentation but in this case it is still no different role because irrelevant from a user perspective. Such "external measured data"are normally brought into the device by setting up some "Linking/binding" of this device to this external sensor and so the device gets the value from the sensor and writes it itself into an internal state or uses it for logic (or in special cases the value is pushed but this means that the outside deliverer writes the value into the relevant state with "ack=true" and the device needs logic to react on it. So yes this topic is a special case on how to correctly wire this.

But in the end it is something that the device handles internally and not a user. No user should get any UI elements to "set" this external value and from the user perspective (if the device expose this external measurement) it is just a read only value (irrelevant how it came into the state).

So Roles and also read/write are mainly there to allow building user interfaces and give "guidance" for users (and pot developers) on how the states are designed - and you also need to see them from this perspective.

[J-Paul0815]

@Apollon77 @mcm1957 Obviously roles should only be used for visualization, they should not have any other use. Creating the role level.extern would have helped us to develop user-friendly logic, but if that is not desired, we will find other ways. It's a shame that we couldn't even talk about it, because I can see from your answer that I was not understood.

[Apollon77]

It's a shame that we couldn't even talk about it, because I can see from your answer that I was not understood.

I understood you, thats not the topic, but roles are the wrong thing for such "semantic information" in my eyes. So it's not a shame ... and in fact noone said that we can not talk about how to do it differently. The Dev meeting would be an ideal place for such topic to bring up and talk "in person" and also with others, so lets move it there.

[mcm1957]

@Apollon77 Please reopen as at least button.contact is useful in my oppinion.

@J-Paul0815 The benefit to diffentiate between level.temperature and level.temperature.external is not clear to me. Indipendent from level or value (which is coupled with wroteable / read-only od a state) I do not see why one should diffentiate between a built in or an external temperature sensor of a device.I would be glad if you try to explain once more, especially: What kind of device do you have in mind ? Do mean tempearture.indoor / temperature.outdoor or something like this? To diffenentiate between the physical location of a temperatursensor in relation to the base unit of the device seems to be an overkill - assume a ds1820 sensor mounted internal of a case is internal while the same sensor mounted outside in anotehr case is external? Well - not completly serios - one could decleare light.wall and light.ceiling as different roles ...

But maybe I did not understand the situation. Please try again to explain or share the meeting.

An @J-Paul0815 I suggest that you evauate your reaction too. Why did you close the issue? Why do you state that one cannot discuss additional roles when the discussion of a new role is going on here (going on at least until you unexpectedly aborted it)?

[J-Paul0815]

There were 3 reasons to close the issue.

1. For me, the rejection of adding level.extern was a done deal.
2. I had the feeling that there was no attempt to understand my concerns. There is no "linking/binding", no "writes it itself", no "expose this external measurement". OK, there is, but that's not what I mean.
3. I have already found a solution that is outside of the LoRaWAN adapter.

@mcm1957 The benefit to diffentiate between level.temperature and level.temperature.external is not clear to me level.temperature = set desired temperature (Ziel-Temperatur setzen) level.temperature.external (or level.extern) = set actual temperature (Ist-Temperatur setzen)

Indipendent from level or value (which is coupled with wroteable / read-only od a state) In my case there is no "coupled"

I do not see why one should diffentiate between a built in or an external temperature sensor of a device.I would be glad if you try to explain once more I agree, there is no difference. No matter where the measurement is taken, it should have the role "value.temperature" readonly It doesn't matter whether the sensor is indoors, outdoors, inside the housing or outside, what matters is that it is a sensor. It measures and outputs the value (value.temperature readonly) The situation is different when the temperature value is sent TO a device and received there. In the first case, these are sensors, in the second case, actuators. As far as I understand, these cannot have the same role.

What kind of device do you have in mind ?

On the left side are 2 different temperature sensors (LoRaWAN and Zigbee). On the right side is the LoRaWAN heating thermostat. None of the devices are connected to each other. The thermostat is able to use either its own internally installed temperature sensor or a value that was sent there (measured externally). There is no way for the sensors to send the values ​​directly to the thermostat.

From my side, however, there is no need for unnecessary discussion. Every decision in this regard is respected and acknowledged. On the other hand, you should also respect it if I describe to users a way of implementing logic via state roles that is not in the official documentation. I think every user is free to enter whatever they want there.

I understand that it is new and unusual that 1000+ devices can be controlled, but it is already a reality. It is practical if measuring, controlling and regulating is only possible by assigning the devices to a room.

[mcm1957]

@mcm1957 The benefit to diffentiate between level.temperature and level.temperature.external is not clear to me level.temperature = set desired temperature (Ziel-Temperatur setzen) level.temperature.external (or level.extern) = set actual temperature (Ist-Temperatur setzen)

Sorry, I still do not really see the functionality level.temperature = set desired temperatur = Zeiltemperatur setzen) seems to be clear and is used at any heating controller.

BUT level.temperature.external is not clear. The actual temperature (IST temperatur) is noramlly measured by the device / sensor and read by the user / vis etc. Of course the adapter can and will set it. Thats what value.temperature is for.

Indipendent from level or value (which is coupled with wroteable / read-only od a state) In my case there is no "coupled"

level is always read/write, value is always read only. Thats what I mean with coupled.

I do not see why one should diffentiate between a built in or an external temperature sensor of a device.I would be glad if you try to explain once more I agree, there is no difference. No matter where the measurement is taken, it should have the role "value.temperature" readonly It doesn't matter whether the sensor is indoors, outdoors, inside the housing or outside, what matters is that it is a sensor. It measures and outputs the value (value.temperature readonly) The situation is different when the temperature value is sent TO a device and received there. In the first case, these are sensors, in the second case, actuators. As far as I understand, these cannot have the same role.

I agree. An actuator should have level.temperatur. (Again I do not see a need for level.temperatur.external there)

What kind of device do you have in mind ?

On the left side are 2 different temperature sensors (LoRaWAN and Zigbee). On the right side is the LoRaWAN heating thermostat. None of the devices are connected to each other. The thermostat is able to use either its own internally installed temperature sensor or a value that was sent there (measured externally). There is no way for the sensors to send the values ​​directly to the thermostat.

From my side, however, there is no need for unnecessary discussion. Every decision in this regard is respected and acknowledged. On the other hand, you should also respect it if I describe to users a way of implementing logic via state roles that is not in the official documentation. I think every user is free to enter whatever they want there.

I understand that it is new and unusual that 1000+ devices can be controlled, but it is already a reality. It is practical if measuring, controlling and regulating is only possible by assigning the devices to a room.

OK, Both leftside temperatur sensors should be OK with role value.temperature. Do you agree? The Thermostat on the right would be ok to use level.temperature. You can write a desired temperature to the state. If the valve is configured to use ist internal value it will simply write it to the state. I assume that you would like level.temperature.external for this termostat*s state to distinguisg between a desired value (Sollwert) and a measured value (IST Wert). Is this what you want to do? Well - as buth values are temperature level.temperature would be fine to use for both. It's up to the vis to display only those values to the user the user should control. The current value (IST Wert) can be written be i.e. a script.

On the other hand, you should also respect it if I describe to users a way of implementing logic via state roles that is not in the official documentation.

I'm not sure what you want to say. But the role attribute at any state must not contain a value not listed in the official documentation / official schema. roles are not a free text area. Adapter releases containing invalid state roles will not be published and js-conroller will likely block invalid state roles in future. You may use name, rooms etc. for free text configuration.

[J-Paul0815]

@mcm1957 OK, I understand, (set) desired value and (set) a measured value both have the same role. The documentation says otherwise (level.temperature - set desired temperature). I already agreed that I would accept any decision, no reason to threaten to prevent a good solution in the future. Is it in your interest to close this now, or to leave it open?

[mcm1957]

let ist open at the moment.

a) we could eventually adjust the descriptive text. This situation (writing another temperature value then a desired target value) was not on the radar until now. I coudl assume that the same could occure if you have some hardware display showing a temperature.

b) sensor.contact should be added anyway.

[J-Paul0815]

@mcm1957 Through your demonstration of force and threat of adapter suspension and a "special programming operation in the Javascript adapter" you succeeded well in preventing thermostat solutions based on state roles. Here's an actually rhetorical question for a friend: Should someone have the nerve to circumvent your "solution prevention" by:

using "level.temperature" for "set desired temperature" using "level.default" for "set measured value"

Both are listed in the official documentation / official schema. roles. I assume that the use of these official state roles must correspond to your personal feeling of name correspondence? What punishments would this person have to expect?

[Apollon77]

So, ok wechseln wir mal auf deutsch :-)

Wie bereits oben erklärt haben die Rolen eines STates aktuell ausschliesslich von der Idee her eine Bedeutung für "Bedienoberflächen". Formal genauso die "read" und "write" flags. Und Rollen sollten bitte auch nur aus diesem Blickwinkel betrachtet und verstanden werden. Rollen haben nicht das Ziel Logiken abzubilden, dafür sind üblicherweise die Namen o.ä. da.

Das bedeutet:

• Ein Temperatursensor hat immer eine "value.temperature" Rolle mit "write=false" weil es ein "Vom Nutzer in einer UI nicht änderbarer Wert" ist
• Ein Thermostat welche einen Wert misst hat diesen evbenso als "value.temperature mit "write=false" weil es ein Messwert ist.
• Ein Thermostat hat dann meistens einen "Setpoint" state der die Zieltemperatur angibt und das ist schreibbar und damit "level.temperature" mit "write=false"

Der "Sonderfall" kommt jetzt genau in deinem Fall: Wie Du sagst müssen die Werte ja irgendwie "da hin" kommen, weil in Deine Fall es keine direkt verbindung gibt. WIr sind uns denke ich einig das nicht der User diesen Wert setzt, also ist eine "level.*"-Rolle oder write=true formal falsch. Bei Homematic zb würde man direkt im gerät die beiden geräte verknüpfen und das Thermostat würde sich den abgesetzten Te,peraturwert dann abholen oder es "gepusht" bekommen und ihn nur "darstellen" (nicht schreibbar für den user). Jetzt ist die Frage wie denn dann der Wert von A nach B kommt ... Entweder ein Adapter der die Verbindung kennt oder ein Skript wird diese Werte übertragen. Das ist denke ich die Realität oder? Und jetzt kommen wir dazu: Keiner verbietet das in so einem Fall ein so ein "value.temperature mit write=false" beschrieben wird - das wichtige ist das die Schreibaktion mt "ack=true" stattfinden muss weil es kein "kommando" sondern der Reale Wert ist. Es ist korrekt das wir aktuell kein Kontept dafr haben solche Fälle abzubilden, dazu müsste man das rollenkonzept erweitern oder andere Dinge finden.

On the other hand, you should also respect it if I describe to users a way of implementing logic via state roles that is not in the official documentation. I think every user is free to enter whatever they want there.

Naja, da sind wir wieder beim Thema "Wildwuchs" und Probleme die plötzlich selbstgebaut werden wil eigene Rollen erfunden werden und keiner weiss wie eine UI darauf reagiert. Im einfachsten Fallwird es ignoriert. Im problemfall crasht die UI. Am Ende gilt für mich: Wenn Du so einen Fall hast dann sind Rollen und read/write die falschen Mittel zu transportieren das dieser Wert mit einem externen Messwert beschreibbar ist.

[J-Paul0815]

Ja danke, gern auf deutsch, besser als hin und her tippen, wäre allerdings sprechen (vielleicht morgen, beim (oder kurz vor) dem DEV Meeting). WIr sind uns denke ich einig das nicht der User diesen Wert setzt, also ist eine "level.*"-Rolle oder write=true formal falsch. Doch es ein Wert der vom User gesetzt wird, in der Praxis wohl nicht manuell, aber doch: Der User bestimmt welcher Wert dort gesetzt wird. Es können ja unterschiedliche Sensoren geben, wo dieser Wert herkommt, oder ein "empfundener" Wert, oder ein Wert mit einem Offset/Versatz. Entweder ein Adapter der die Verbindung kennt oder ein Skript wird diese Werte übertragen. Das ist denke ich die Realität oder? Es gibt da keinen Unterschied beim setzen dieses Wertes (Ist-Temperatur) zum setzen der Ziel-Temperatur. Wir sind uns einig, dass es da von der Rolle her aber einen Unterschied gibt, es ist nicht das gleiche (Wunsch und Realität). Deswegen passt da die Rolle Level perfekt. Wie der nun heißt ist ja nebensächlich (level.extern, level.externtemperature....) Und Rollen sollten bitte auch nur aus diesem Blickwinkel betrachtet und verstanden werden. Rollen haben nicht das Ziel Logiken abzubilden, dafür sind üblicherweise die Namen o.ä. da. Der Vergleich hinkt sicherlich, aber wenn du die einen PKW (PersonKraftWagen) kaufst, dann sollte es kein Problem sein, damit auch einen Hund, oder etwas anderes zu transportieren. Auch wenn Rollen hauptsächlich für die Visualisierung gedacht ist, kann es doch nicht "verboten" sein, über den ID-Selektor (globale) Logiken mit den Rollen zu erstellen. Bevor ich Beispiele anführe, gestatte bitte kurz den Hintergrund zu beschreiben. Mit dem LoRaWAN Adapter und einigen Voreinstellungen ist bisher folgendes Implementiert: Neue Geräte werden im LNS z.B. über eine CSV Datei hinzugefügt, (auch ein paar 100 Stück) die states bilden sich in Iobroker automatisch, sobald diese beginnen Daten zu senden und diese landen ohne weiteres Zutun in der DB (InfluxDB, SQL, History...) auch werden die States zur Steuerung angelegt. Die Geräte sind also sofort (Zero-Touch) einsatzfähig. Des weiteren ist implementiert, dass die States je nach Namen beim Anlegen state.roles bekommen (z.B OPEN=sensor.door Open=sensor.window open=sensor.contact)
Über den decoder haben wir Einfluss über die Schreibweise des Namens. Hier 2 Beispiele zur Nutzung:

1. Nach Zuordnung des Raums vom Device mit der Rolle sensor.window und Device mit der Rolle level.temperature kann eine globale Logik die Zieltemperatur im entsprechenden Raum herabzusetzen, sobald ein Fenster geöffnet wird. Das könnten in dem Fall auch 500+ Räume sein. (Funktioniert soweit).

2. Nach Zuordnung des Raums vom Device mit der Rolle sensor.temperature und Device mit der Rolle level.extern kann eine globale Logik die Ist-Temperatur im entsprechenden Raum (genauer) setzen. Warum level.extern Probleme durch "Wildwuchs" verursachen soll, erschließt sich mir nicht, im Gegenteil: Eine exaktere Rollen Verteilung kommt auch der VIS zugute und kann dort im Zweifel auch ignoriert werden.

   Möglichkeit: Die Rolle level.extern wird in der Doku mit aufgenommen, eine Code Änderung wäre wohl nicht nötig Möglichkeit: Wir würden im LoRaWAN Adapter einen vorhanden Wert nehmen, z.B. "level.default" Möglichkeit: Man könnte ein Script zur Verfügung stellen, außerhalb vom Adapter, der die Rollen setzt. Möglichkeit: Man nutzt dafür keine Rollen, sondern Namen. Das wäre die schlechteste alle Möglichkeiten, dem User kaum zu vermitteln. Ergänzung: Während bei den anderen Lösungsanbietern und Branchengrößen im Zweifel der Facility Manager durch 1000 Räume geschickt wird, funktioniert die Iobroker Lösung weiter! Nur zur Klarstellung: Habe selbst nur 5 Heizkörper, eine globale Logik brauche ich persönlich nicht.

[mcm1957]

WIr sind uns denke ich einig das nicht der User diesen Wert setzt, also ist eine "level.*"-Rolle oder write=true formal falsch. Doch es ein Wert der vom User gesetzt wird, in der Praxis wohl nicht manuell, aber doch: Der User bestimmt welcher Wert dort gesetzt wird.

In jedem Fall MUSS das Adapter sicherstellen, dass nur zulässige Werte gesetzt werden. Ich werde keine Release freigeben bei der bekannter Maßen freie / unzulässige Werte in die Objekte geschrieben werden können.

Möglichkeit: Die Rolle level.extern wird in der Doku mit aufgenommen, eine Code Änderung wäre wohl nicht nötig

Warum nicht level.temperature? Oder nur level? Beide gibt es bereits und sind zulässig,

Möglichkeit: Wir würden im LoRaWAN Adapter einen vorhanden Wert nehmen, z.B. "level.default"

level.default wäre zulässig aber nach der bishrigen Diskussion inhaltlich falsch. Ein Adapter der bewußt falsche Roles setzt - no comment,

Möglichkeit: Man könnte ein Script zur Verfügung stellen, außerhalb vom Adapter, der die Rollen setzt.

Wie meinen? Ein Script das die States eines Adapter manipuliert. Die States eines Adapters dürfen nur von diesem geändert werden. Bitte nicht nach Möglichkeiten suchen die Struktur von ioBroker zu untergraben und mit wilden Querzugriffen da zu basteln.

Möglichkeit: Man nutzt dafür keine Rollen, sondern Namen. Das wäre die schlechteste alle Möglichkeiten, dem User kaum zu vermitteln.

Keine Ahnung was dem User nicht zu vermitteln wäre. Name und Description sind jedenfalls fereier Text den der Adapter und der User beliebig ändern kann. Und die State Id kann der Adapter auch bestimmen. Ev. könnt ihr eure Codierung ja auch dort unterbringen (zulässige Zeihen beachten!)

Des weiteren ist implementiert, dass die States je nach Namen beim Anlegen state.roles bekommen (z.B OPEN=sensor.door Open=sensor.window open=sensor.contact) Über den decoder haben wir Einfluss über die Schreibweise des Namens.

Danke für die INfo / Erheiterung. Die Lösung verdient m.E. das Prädikat "Krücke des Tages". Wenn man dem User klarmachen kann, dass DOOR ein Fenster und Door eine Türe ist dann kann man ihm wohl auch klarmachen dass er die Namen benutzen kann / soll. (Ist übriogends DooR dann eine zweiflügelige Türe und dOOr ein Garagentor ? :-)

[J-Paul0815]

_Warum nicht level.temperature? Level.temperatur steht in der Dokumentation als Ziel-Temperatur. Die Ist-Temperatur ist nicht die Soll-Temperatur und sollte deshalb mMn nicht die gleiche Rolle haben.

Oder nur level? Beide gibt es bereits und sind zulässig, Ja, wollte es gerade ändern, ich meinte level, nicht level.default Wie er heißt ist ja egal. Wenn das von Eurer Seite in Ordnung ist, dann nehmen wir für das setzten einer externen Temperatur die (KdT) State Role "Level". Wenn es dann Verwechselungen gibt, kann man ja "level.extern" später doch hinzufügen.

Danke für die INfo / Erheiterung. Die Lösung verdient m.E. das Prädikat "Krücke des Tages". Wenn man dem User klarmachen kann, dass DOOR ein Fenster und Door eine Türe ist dann kann man ihm wohl auch klarmachen dass er die Namen benutzen kann / soll. (Ist übriogends DooR dann eine zweiflügelige Türe und dOOr ein Garagentor ? :-) Vielleicht zeigst du mir einen einzigen Adapter, der die State Roles sensor.door und/oder sensor.window bisher sinnvoll nutzten konnte. Nur einen bitte, damit ich mit lachen kann. Bisher standen die in der Dokumentation nur zur Zierde, unnütz wie ein Kropf, weil keiner wissen kann, wo die hin geklebt werden. Sobald "zweiflügelige Türe" und "Garagentor" als Rollen in der Doku stehen, lässt sich da auf Deinen Wunsch hin bestimmt was machen ;-) Da das nun geklärt ist, mach ich zu hier.

[mcm1957]

Nur einen bitte, damit ich mit lachen kann. Der Absatz bezog sich darauf dass ihr durch die SCHREIBWEISE von Door unetrschiedliche zu öffenende Objekte definiert, Das ist originalle und m.E. eher ein Quick Hack denn ne saubere Lösung. Worum DOOR und Door statt window und door ? Das wißt wahrscheinlich nur ihr :-)

Geklärt ist hier eigentlich nichts - aber wenn du meinst ...

Da du dieses Issue nun geschlossen hast, hab ich mal den sonsor.contact PR erstellt damit diese eigentlich von allen als sinnvoll anerkannte Role nicht untergeht. (https://github.com/ioBroker/ioBroker.docs/pull/547)

[J-Paul0815]

@mcm1957 Geklärt ist hier eigentlich nichts - aber wenn du meinst ... So kann man doch kaum ungewollt an einander vorbei kommunizieren? Für mich klang das jetzt schon 2 x so, als wenn das Hinzufügen von "level.extern" aus welchen Gründen auch immer nicht vorgenommen wird. Der Vorschlag hierfür nun "level" zu nutzen, kam von Dir. Da kann man nur hoffen, dass derjenige, der die externe Temperatur nutzen möchte keine Zisterne, Öltank oder ähnliches hat, weil ich vermute, dass die Rolle dafür vorgesehen ist, aber von meiner Seite respektiere ich Eure Entscheidung.

[mcm1957]

Ja, ich sehe kein Problem einem State die role level zuzuweisen. Bezüglich level.extern geb ich dir recht, da ist zwar keine finale Entscheidung gefallen - das muss ich anderern überlassen -aber die Chancen dafür stehen eher schlecht.

Aber warum sollte ein anderer state mit der role level stören? Aus einer state role - egal welcher - kann definitiv NICHT auf ein spezielles Gerät geschlossen werden. Auch denn es eine role level.extern gäbe verbietet niemand, dass diese role nicht für ein Gerät am Schwimmbad oder sonst wo verwendet wird. Der User muss ja jedenfalls in seiner VIS auswählen was er ändern möchte. Detto kann / muss er in seinen Scripten auswählen was er verändern will.