Beiträge von Ewald Lais

Problem: Cloudprogrammierung: Bei 2 verschiedenen Shelly Plus 2PM lassen sich die Ausgangszustände nicht abfragen. (aktuelle Firmware)

Dies betrifft beide Ausgänge der 2PM.

Mit anderen Shelly Produkten (Plug S, UNI, 1PM) funktioniert dies problemlos.

Zum Test habe ich eine einfache Szene angelegt.
Der Schaltzustand wird wiederholt abgefragt und bei korrekter Verknüpfung ein Plug S eingeschaltet.
(Ausschalten von Hand)

Test auf EIN:

Test auf AUS:

Geräteeigenschaften:

Egal welcher Ausgangszustand ausgewählt wird, der Plug S wird nicht eingeschaltet.

Die Komplexität ist ausgesprochen überschaubar.
Wie gesagt: mit anderen Shellys funktioniert es.

Bei Lust und Laune: der steinige Weg zur bisherigen Erkenntnis hat über einen weiten Umweg geführt. (am Ende wird´s interessant.)

Thema

Shelly Plus 2PM melden Ausgangsstatus nicht korrekt. Konkrete Ursachenforschung ->am Ende des Fred

Funktion: Anzeige von Stromüberschuß, wenn die PV einspeist.

Problem: die Szenen funktionieren nicht wie gedacht. Wahrscheinlich liegt es an den Triggern.

Eigentlich wäre es ja ganz einfach:
Eine Shelly Color Bulb hängt im Wohnzimmer und zeigt mir und meinen Mitbewohnern grob an, wieviel überschüssiger Strom gerade ins Netz eingespeist wird.
Und daß es jetzt eine gute Idee wäre z.B. die Waschmaschine oder den Geschirrspüler laufen zu lassen.

Nun ist es aber so, daß bereits 3 Verbraucher in…

Ewald Lais

1. November 2024 um 19:10

Aber nicht dran aufhalten: die Essenz lautet: was ist da los? Ist das bei euch auch so?

Und noch weitere Infos zum letzten Eintrag:
Das Aktivitätsprotokoll
Die Reihenfolge ist wie geplant: Laden, Grundladung, Laden 1, Laden 1 neu, Laden 2 neu, Laden 2, Anzeige verzögert -> Alarmmeldungen

So, und nun kommt der Hammer.
Ich habe die beiden Überwachungsszenen deaktiviert, weil die natürlich fortlaufend gemeldet haben.
Am Nachmittag, als die Sonne wieder raus kam, habe ich sie wieder aktiviert.

UND DANN KAM KEIN ALARM MEHR.
Der Ausgang wurde korrekt abgefragt.

Was ist denn das für ein Sch...?

Was sagt uns das?
An den Shelly 2PM kann´s fast nicht liegen.
Beide reagieren gleich. Funktioniert´s bei einem nicht, funktioniert´s auch beim anderen nicht.
Werden die Szenen in der Cloud zeitweise falsch abgearbeitet?
Gibt es in der Cloud verschiedene Instanzen, die die Szenen abarbeiten?
Und hat eine davon einen Fehler?

Habe mich dazu entschlossen hier zu protokollieren, wann es funktioniert und wann nicht.

Funktioniert=ja; funktioniert nicht=nein

01.02.2025 15:00 nein

02.02.2025 3x Shelly 3Em hinzugefügt, keine Änderung der Szenen

02.02.2025 14:30 ja

Nun, was soll ich sagen, das Murmeltier ist noch immer da.

Kurze Zusammenfassung:
Das Abfragen des 2. Ausgangs eines Shelly Plus 2PM ergab immer nur ein "AUS", selbst wenn er "EIN" war.
Dadurch wurden die Szenen natürlich nicht wie erwartet abgearbeitet.

Wann das genau passiert ist kann ich nicht sagen, da der Ausgang anwendungsbedingt (wetterbedingt) in den letzten Wochen nicht benötigt wurde. Allerdings habe ich in der Zeit auch nichts an den Szenen verändert.

Kurz und gut, es funktioniert mal wieder nicht.
Bevor einer frägt: NEIN, den Shelly habe ich noch nicht getauscht.
Warum? Ich hatte gefühlt heftige Zweifel, daß das helfen wird.
Von daher sollte man die Testvorrichtung nicht ändern, bevor man eine Idee hat, was zum Fehler führen könnte.

ABER, ich habe einen zweiten Shelly Plus 2PM angeschlossen und virtuell parallel geschaltet.
Das heißt: wo der erste Shelly eingeschaltet wird (nur eine Szene) wird auch der zweite Shelly geschaltet.
Und beim Ausschalten genauso.
Weitere Verwendung des zweiten Kontroll-Shelly in anderen Szenen gibt es nicht.
Ausser in den Überwachungs-Szenen.
Dazu habe ich einen Shelly S genommen und den dann auch noch parallel zu den beiden 2PM angesteuert.
Somit hatte ich eine Instanz, gegen die ich die Schaltzustände der 2PM prüfen konnte.

Soviel, so kryptisch. Nun zur Praxis:
Einschalten der Ausgänge:
der Shelly S wird 5 Sekunden verzögert eingeschaltet,
der Problem-2PM und der Kontroll-2PM werden direkt eingeschaltet.

Ausschalten der Ausgänge:
der Shelly S wird direkt ausgeschaltet,
der Problem-2PM und der Kontroll-2PM werden 5 Sekunden verzögert ausgeschaltet.

Kontrollszene für den alten 2PM.
Wenn der Shelly S ein ist und der alte 2PM aus meldet, dann alarmieren.

Kontrollszene für den neuen 2PM.
Wenn der Shelly S ein ist und der neue 2PM aus meldet, dann alarmieren.

Wenn nun der Shelly S ein ist und die beiden 2PM angesteuert werden und durchschalten (was sie auch tatsächlich tun),
aber dies in der Abfrage nicht melden, dann bekomme ich einen Alarm.

Und genau das passiert.
Und zwar genau gleich für den alten 2PM wie auch für den neuen 2PM.
Deshalb scheint mir ein Austausch nicht gerade vielversprechend zu sein.

Kann mir das jemand erklären?

Und nun noch ein Zitat aus meinem letzten Eintrag. Vielleicht kann mir auch jemand was dazu sagen:
Wenn nun die Abfrage des Ausgangsstatus in der App immer korrekt und direkt ist, so scheint die Abfrage der Shellys über die Cloud auch korrekt zu funktionieren.
Wenn nun eine Abweichung zwischen der Anzeige in der App und der Abfrage in der Szene auftritt, so scheint dies mit der Abarbeitung der Szene zusammenzuhängen.
Nach meinem bisherigen Verständnis werden die Szenen in der Cloud verarbeitet.
Heißt das nun, daß der Fehler in der Abarbeitung in der Cloud liegt?
Oder habe ich ein prinzipiell falsches Verständnis der Verarbeitung der Szenen?

Erleuchtet mich bitte.

Und noch ein Nachtrag:
Wäre es besser ich würde meine Fragen in den Fred zum Shelly Plus 2PM stellen?
Mittlerweile scheint sich ja die Richtung zu verdichten, so daß "Verschiedenes" nicht mehr die richtige Heimat ist.

Nochmal zum Murmeltier.

Nein, ich habe den Shelly Plus 2PM noch nicht getauscht.
Der Ersatz ist zwar schon gerichtet, aber ich wollte der Sache vorher doch noch genauer auf den Grund gehen.

Zustand:
Die Schaltzustandsabfrage des 2. Ausgangs des Shelly Plus 2PM ist nach Reset des Shelly korrekt und funktioniert wie gedacht.
Shelly "aus" = "aus"; Shelly "ein" = "ein".
Nach einiger Zeit (ohne Änderungen) stimmt ist die Abfrage nicht mehr korrekt.
Shelly "aus" = "aus"; Shelly "ein" = "aus".

Um dem auf den Zahn zu fühlen habe ich 2 Shelly Plug S eingebunden:

Der erste Plug wird parallel zum 2. Ausgang des 2PM geschaltet.
Durch eine verzögerte Abfrage ob der Plug "ein" und der 2PM "aus" ist (was nie der Fall sein dürfte), bekomme ich eine Meldung aufs Phone, so daß ich weiß, daß da was faul ist.

Der zweite Plug wird eingeschaltet wenn der 2. Ausgang des 2PM "ein" meldet.
Für diese Verknüpfung gibt es keine automatische Ausschaltung. Ich muß den Plug von Hand auschalten.
Dadurch kann ich prüfen, ob der Ausgangsstatus des 2PM korrekt gemeldet wird. (Fangschaltung)

So, nach der langen Vorrede:
Seltsam ist, daß in der App der Ausgangsstatus des 2PM immer korrekt dargestellt wird.
Auch der Ausgangsstatus der Plugs ist immer korrekt. Auch wenn ich diese von Hand ausschalte, wird dies korrekt in der App angezeigt.
Wenn nun die Abfrage des Ausgangsstatus in der App immer korrekt und direkt ist, so scheint die Abfrage der Shellys über die Cloud auch korrekt zu funktionieren.
Wenn nun eine Abweichung zwischen der Anzeige in der App und der Abfrage in der Szene auftritt, so scheint dies mit der Abarbeitung der Szene zusammenzuhängen.
Nach meinem bisherigen Verständnis werden die Szenen in der Cloud verarbeitet.
Heißt das nun, daß der Fehler in der Abarbeitung in der Cloud liegt?
Oder habe ich ein prinzipiell falsches Verständnis der Verarbeitung der Szenen?

Erleuchtet mich bitte.

Nachtrag um 17:15:
Das geschilderte Problem ist heute mittag (11.01.2024) aufgetreten.
Heute abend funktioniert die Abfrage des Ausgangszustands wieder wie es soll. Vorgenommene Änderungen: KEINE.

Nachtrag zur Erläuterung:

Das Murmeltier kam zurück:

Das Abfragen des 2. Ausgangs eines Shelly Plus 2PM ergab immer nur ein "AUS", selbst wenn er "EIN" war.
Dadurch wurden die Szenen natürlich nicht wie erwartet abgearbeitet.

Wann das genau passiert ist kann ich nicht sagen, da der Ausgang anwendungsbedingt (wetterbedingt) in den letzten Wochen nicht benötigt wurde. Allerdings habe ich in der Zeit auch nichts an den Szenen verändert.

Auch diesmal konnte der Fehler durch einen Reset auf Werkseinstellung und anschließendes Neueinbinden des Shelly behoben werden.
(Löschen des Shelly in der Geräteliste und Neuerfassen hat nicht geholfen)

Die Ursache scheint seltsam zu sein.
Anscheinend wird der Ausgangszustand nicht mehr korrekt in der Abfrage reflektiert. (IsOn falsch?)
Dies ist ja eigentlich keine physikalische Rückmeldung, sondern nur eine logische. Also durch Software produziert.
Also scheint im Innern des Shelly was aus dem Ruder zu laufen.
Die Firmware ist aktuell: 20241011-1144448/1.4.4-g6d2a586

Nun ist die Frage: hat der Shelly einen Schuß oder ist da was faul in der Firmware?

Wenn der Aufwand nicht so hoch wäre, würde ich den Shelly tauschen. Ich habe noch einen als Reserve.
Was wäre denn die einfachste Möglichkeit den Shelly durch einen anderen zu ersetzen?
Sind viele Verknüpfungen mit verbunden.

Ich habe nun eine Fangschaltung installiert. Ein Shelly Plug S wird gemeinsam mit dem 2. Ausgang des 2PM geschaltet.
Wenn nun der Pug auf "EIN" geschaltet wurde und der 2PM noch "AUS" meldet, dann bekomme ich das als Meldung auf´s Handy.

Wäre es sinnvoll dieses Problem unter der Rubrik des 2PM zu schildern?
Hier ist es nicht ganz richtig am Platz. Hat sich halt durch den Ablauf der Fehlersuche so ergeben.

Die Lösung:

Es war kein Problem der Szenen, sondern ein "Hardware"-Problem.
In den Szenen sind die Ausgangszustände von Shellys abgefragt und in den Verknüpfungen verwendet worden.
Dabei wurden auch die Ausgangszustände eines Shelly Plus 2PM verknüpft.
Der 1. Ausgang hat dabei einwandfrei funktioniert. Wenn er "Ein" war, wurde auch "Ein" gemeldet.
Beim 2. Ausgang ergab die Abfrage aber grundsätzlich nur ein "Aus". Auch wenn der Schalter "Ein" war.

Die Prüfung der Einstellungen des Shelly ergab keinen Grund für dieses Fehlverhalten.

Der Shelly wurde dann zurückgesetzt und neu eingebunden.
Danach funktionierte er wieder einwandfrei.
Sowohl Ausgang 1 als auch Ausgang 2 meldeten den Ausgangszustand wieder korrekt.

Seither funktionieren alle Verknüpfungen wie geplant.

Als Trigger für die Sequenzen wurde übrigens "wiederholt" gewählt.

Die Ursache für das Fehlverhalten konnte nicht gefunden werden.
Zeitlich passt es im Nachhinein aber in die Phase als ein Firmware-Update durchgeführt wurde.

Der Thread kann jetzt geschlossen werden.

Hab ihn schon zurückgesetzt.
Ging problemlos.
Musste nur den Namen neu vergeben.
Dann war der Switch direkt wieder in allen Szenen eingebunden.

Und seither funktioniert die Szene auch.
Mal sehen. Wenn die Sonne scheint, dann kann ich auch den Rest der Szenen probieren.

Werde bei Gelegenheit den verbauten Shelly zurücksetzen und dann wieder einbinden.
Mal sehen, ob er danach wieder funktioniert.

Zumindest ist das mal eine konkrete Ursache.
Hat mich schon gewundert. War mir sicher, daß die Szenen korrekt sind und hätten funktionieren müssen.

Habe jetzt einen 2. Shelly Plus 2PM auf Werkseinstellung zurückgesetzt und auf aktuelle Firmware geupdated.
Dann habe ich den statt Freigabe1 und Freigabe2 eingebunden -> FUNKTIONIERT

Da scheint was am 2. Kanal des "alten" Shelly schräg zu sein.
Ich habe die Parameter des 1. und 2. Kanals verglichen. Sind identisch. Da ist mir nichts aufgefallen.

Wie kann ich den zurücksetzen und wieder einbinden ohne alle Szenen neu schreiben zu müssen?

Habe alle Bedingungen ausser Trigger und Freigabe2 gelöscht. Geht auch nicht.

Test: "Leistung ist Trigger" und "Freigabe2 aus Bedingung" -> "Lampe Aus" > FUNKTIONIERT NICHT

Gut, nachdem das geklärt ist, wollte ich der Magie des Nichtfunktionierens doch noch näher auf den Grund gehen.

Dazu habe ich die komplette Szene gelöscht und von Grund auf neu aufgebaut (nur die erste Sequenz) und schrittweise getestet.
Dazu die Lampe "händisch" eingeschalten und dann die Ausschalt-Szene wirken lassen.

Stufe 1: "Leistung ist Trigger" -> "Lampe Aus" > FUNKTIONIERT
Stufe 2: "Leistung ist Trigger" und "Grundladung aus Bedingung" -> "Lampe Aus" > FUNKTIONIERT
Stufe 3: "Leistung ist Trigger" und "Grundladung aus Bedingung" und "Freigabe1 aus Bedingung" -> "Lampe Aus" > FUNKTIONIERT
Stufe 4: "Leistung ist Trigger" und "Grundladung aus Bedingung" und "Freigabe1 aus Bedingung" und "Freigabe2 aus Bedingung" -> "Lampe Aus" > FUNKTIONIERT NICHT

Freigabe1 und Freigabe2 sind 2 Kanäle eines Shelly Plus 2PM

Nun stellt sich die Frage, weshalb die Szene nicht mehr funktioniert, wenn ich Freigabe2 einbinde.
Freigabe 2 ist der 2. Kanal (1) eines 2PM.
Hat das damit zu tun? Wird dieser nicht korrekt abgefragt?

Hier sind die aktuellen Schaltzustände und Leistungen beim Test:
Grundladung, Freigabe1 und Freigabe2 sind aus. Die Leistung ist über 0W.

Und nun die Szene in ihren Iterationen:

Stufe 1 (funktioniert)

Stufe 2 (funktioniert)

Stufe 3 (funktioniert)

Stufe 4 (funktioniert nicht)

Ah, ok.

Das habe ich bisher falsch verstanden. Ich bin davon ausgegangen, daß die Szene direkt aufgerufen und durchgespielt wird.

So wie es jetzt aussieht, wird aber nur die "DANN"-Anweisung bedingungslos ausgeführt.

Hm, aber warum funktioniert die Szene, wenn ich sie händisch starte?

Wenn was fehlen würde, dann ging sie ja auch dann nicht.

Hm, die Szene funktioniert aber, wenn ich sie von Hand starte.
Was hindert sie daran automatisch ausgeführt zu werden?

Jede Sequenz hat einen Trigger. Ist das nicht ok?
Die Alternative wäre daraus 4 separate Szenen zu machen.
Nur, warum braucht es dann "oder"-Verknüpfungen?

Na ja, der Vollständigkeit halber füge ich mal alle Sequenzen der Szene bei.

Nun habe ich doch noch ein Problem.
Nachdem viele Tage schlechtes Wetter war, kam zu wenig vom Himmel um die Batterie zu laden.
Nun hat aber mal wieder zwischendurch die Sonne geschienen und dadurch wurde die Lampe eingeschalten.

Allerdings wird sie nicht mehr ausgeschaltet.
Die Szene sollte in Ordnung sein.
Wenn ich sie von Hand auslöse, dann wird die Lampe ausgeschaltet, nur automatisch scheint sie nicht ausgeführt zu werden.

Ich füge einen Auszug der Szene als Screenshot an.
Allerdings sollte das Problem nicht die Szene selbst sein.
Die Frage ist eher: warum wird die, eigentlich funktionierende, Szene nicht ausgeführt sondern muß händisch gestartet werden.

So, heute war´s mal endlich wieder sonnig und ich hatte etwas Zeit.
Also habe ich mal beide oben angesprochenen Varianten ausprobiert:
a) Trigger eines digitalen Zustands: wiederholt
b) Trigger eines analogen Werts: bei jeder Änderung
Für die Variante b) habe ich die Sequenzen so umgeschrieben, daß der Trigger am Anfang der Sequenz stand.

Variante a) hat im Prinzip funktioniert.
Allerdings war sie sehr träge und die Anzeige (Farbe Blau/Gelb/Grün/Rot/aus) manchmal nicht ganz nachvollziehbar.

Variante b) brachte dann den Erfolg.
Die Farbwechsel erfolgen sehr schnell (fast zu schnell) und sind nachvollziehbar.

Ja, das ist einsichtig.
Ich habe auch nicht mit mehreren Triggern innerhalb einer Sequenz gearbeitet.
Am sinnvollsten erscheint mir ein Triggern auf wiederholter Basis auf die erste Bedingung.

Im Beispiel des Screenshots:
"Freigabe Ladegerät 1 = an"; wiederholt.
Das müsste dazu führen, daß diese Sequenz wiederkehrend ausgeführt wird und wenn das Ergebnis "True" ist, die Lampe entsprechend befeuert.

Ich war mir nur nicht klar darüber wie ein Trigger zu sehen ist:
- Muß er am Anfang stehen, damit die Sequenz überhaupt bearbeitet wird
oder
- ist er eine besondere Art von Verknüpfung, die nur unter speziellen Bedingungen "True" oder "False" ist.

Im Falle von "wiederholt": wie ist die Frequenz der Wiederholung?
Alternativ könnte ich auch die Leistungsmessung an den Anfang stellen und dann "bei Änderung" triggern.

Nun ja, ich wollte eigentlich nicht so sehr ins Detail gehen, was die Gesamtfunktion anbelangt.
Um alle Szenen mit ihren Sequenzen offenzulegen hätte ich etwa 30 Bildschirmkopien anlegen müssen.
Und das hätte auch nicht geholfen.
Das Gestückel hat sich nur aus den Nachfragen nach weiteren Details ergeben, die gestellt wurden.

Gehen wir doch nochmal auf die Ausgangsfrage zurück:
Welchen Trigger würdet ihr empfehlen um so eine Sequenz zu aktivieren?
Beispiel:
"Freigabe Ladegerät 1" auf "Wiederholt"?
oder "Leistungsmessung Shelly" auf "Wiederholt"?
oder "Leistungsmessung Shelly" auf "Einmal"?

Muß der Trigger immer am Anfang der Sequenz stehen oder darf der auch mittendrin sein?

Krauskopp
Auf deine Fragen:
Die Ansteuerung der Ladegeräte erfolgt bedämpft über die Leistungsmessung mit verzögerten Triggern.
(z.B. Leistungsmessung, Trigger: mehr als 100W einmal, 2 Minuten gültig)
So passen sie sich (gemächlich) an die Leistungssprünge der Waschmaschine etc. an.

Die Anzeige braucht keine Bedämpfung. Sie orientiert sich rein an der Leistungsmessung und den Schaltzuständen.
Dementsprechend wird je nachdem eine andere Farbe angezeigt.
Sie hat im übrigen schon mal in einer einfacheren Variante (1 Ladegerät) funktioniert.
Erst mit dem Aufbohren auf 3 Ladegeräte und der Zunahme an Verknüpfungen ist da was kollabiert.
Deshalb dachte ich: back to the roots und abklären welche Trigger hier am Besten einzusetzen sind und ob sie überall in der Sequenz stehen können oder an den Anfang gehören.

Ja, richtig.
"Freigabe ein" bedeutet, daß die Ladegeräte aktiviert sind.
Die Ansteuerung der Ladegeräte erfolgt in anderen Szenen.
Die damit versorgte Batterie funktioniert bereits über ein Jahr problemlos.
Sie wird geladen, wenn mehr Leistung von der PV zur Verfügung gestellt wird, als im Haus verbraucht wird.
Dabei orientiert sie sich an der Messung des 3EM.
Entsprechend der Messung werden 3 separate Ladegeräte zu- oder abgeschaltet.
Wenn jetzt z.B. die Waschmaschine oder der Kühlschrank oder... mehr Strom verbraucht und deshalb nichts oder
weniger übrig ist, dann schalten sich die Lader auch wieder sequentiell ab.

Dem Nutzer soll aber angezeigt werden, welche Leistung ihm zur Verfügung stünde, wenn die Batterie nicht laden würde.

Der 3EM misst die Leistung der Hauseinspeisung.
Der Wert 100 bedeutet, daß 100W aus dem Netz bezogen werden.
Der Wert - 100 bedeutet, daß 100W ins Netz eingespeist werden.
Größer als - 100 und kleiner als 100 ist durchaus legitim.
Das ist der Bereich des Bezugs zwischen 0 und 100W, sowie der Einspeisung zwischen 0 und 100W.

Die anderen Sequenzen decken dann weitere Bereiche ab. Hier im Beispiel sind zufällig alle "Bezug", also positiv.

Bitte beachtet, daß sich die Meßbereiche zwar scheinbar überschneiden, der Sequenz allerdings andere Schaltzustände zu Grunde liegen.
Von daher passen die 220W (siehe oben) nur bei einem entsprechenden Schaltzustand.
Die Abstufung zwischen den einzelnen Sequenzen bzw. Schaltzuständen ergeben sich durch die Leistungsaufnahme der Ladegeräte.
Lader1 = 150W
Lader2= 150W
Lader3 = 100W

Zur Verdeutlichung versuche ich mal die dazu gehörende Grafik zu digitalisieren.
Ich dachte nur, daß das nicht notwendig sei.
Ich wollte eigentlich nur fragen, was für einen Trigger ich sinnvoller Weise verwenden soll um so eine Sequenz zu aktivieren.

Nun, das ist nur eine Sequenz.
Insgesamt sind es 5 dieser Sequenzen pro Szene.
Die 5 Sequenzen sind per "ODER" miteinander verknupft.

Diese Sequenz soll aussagen:
Wenn
"Freigabe1=aus" UND "Freigabe2=aus" UND "Freigabe3=ein"
UND "die vom Netz bezogene Leistung<100W"
UND "die ins Netz eingespeiste Leistung>100W"
Dann "Lampe - > Blau"

Sie soll also aktiviert werden wenn der 3EM zwischen 100W Einspeisung und 100W Verbrauch misst.
Das entspricht dem 3EM-Meßwert von "Größer -100" UND "Kleiner 100".

Die nächste Sequenz ist mit der obigen mit ODER verknüpft und lautet dann in etwa wie folgt:
Wenn
"Freigabe1=an" UND "Freigabe2=aus" UND "Freigabe3=an"
UND "Leistung<250"
UND "Leistung>50"
Dann "Lampe -> Blau"

Die dritte Sequenz lautet dann:
Wenn
"Freigabe1=an" UND "Freigabe2=an" UND "Freigabe3=an"
UND "Leistung<400"
UND "Leistung>200"
Dann "Lampe -> Blau"

Und so weiter...

Es ist also immer ein Schaltzustand mit einem Leistungsbereich verknüpft und dann einer Lampenfarbe zugeordnet.