[Aufruf] ZigBee CC253x Adapter

[ltsalvatore]

@arteck:

mal zu Klärung (klugscheiss Modus an)

das was du unter state verstehst ist eigentlich der link_quality Objekt..da setht eine Zahl diese besagt ..eigentlich die Qualität der Verbindung.

der eigentliche state ist der schaltzustand der Dose bzw. des Devices da eine Lampe auch ei state hat an/aus - true/false

(klugscheiss Modus aus)

und ja das ist mir auch schon aufgefallen dass die Werte nicht korrespondieren.. hab mich aber noch nicht drum gekümmert warum das so ist.. `

stimmt.. hab beides vermischt

meinte natürlich link_quality.

ah super danke.. dann weis ich bescheid, dass es scheinbar ein allgemeines problem zu sein scheint.

[hmanfred]

Meine Installation hat nun einen Umfang angenommen, der weitergehende Tests hinsichtlich Zuverlässigkeit und Reichweite zulässt:

Die Sensoren sind alle Xiaomi Aqara und waren zuerst angelernt. Die drei Steckdosen sind Osram Smart+ und sind nachträglich dazu gekommen.

Meine Tests haben nun einige Fragen aufgeworfen. Ich numeriere sie nachfolgend mal durch - sie betreffen verschiedene Themen und so spart ihr euch evtl. das Zitieren, wenn ihr auf einen bestimmten Punkt antwortet:

1. Den Fühler Temp_Terrasse habe ich nach dem Anlernen an Ort und Stelle gebracht. Dort hatte er drei Tage lang keine Verbindung. Die Plugs mit ihrer Repeaterfunktion waren noch nicht da.

Jetzt gibt es aber die Plugs, eine davon ca. 1 m entfernt vom Fühler. Der Fühler weigert sich aber, seine Daten über die Plug zu senden - er bleibt tot. Bringe ich ihn in Reichweite des Stick, geht er aber.

Auch ein Neuanlernen des Sensors nach Installation der Plugs hat daran nichts geändert.

Sieht so aus, als ob der Sensor die Plugs nicht mag - oder umgekehrt.

2. Die Stabilität / Qualität (???) der Verbiudungen erscheint mir mangelhaft. Möglicherweise habe ich aber irgednwas falsch gemacht oder nicht gemacht…:

Ohne erkennbares Muster weigert sich manchmal eine Plug, Schaltbefehle anzunehmen (bei oben gezeigter Netzwerkstruktur und -qualität). Manchmal ist es sporadisch, dass Befehle gar nicht oder mit bis zu 15 Sekunden Verzögerung ankommen. Manchmal verweigert eine Plug auch kategorisch ihren Dienst, bis ich sie einmal so örtlich verändere, dass sie sich eine andere Route sucht.

Logauszug:

! 2018-11-28 14:18:22.529 - error: zigbee.0 Zigbee publish to '0x84182600000fa3fa', genOnOff - read - [{"attrId":0}] - 3 failed with error Error: AF data request fails, status code: 205\. No network route. Please confirm that the device has (re)joined the network. 2018-11-28 14:18:41.410 - error: zigbee.0 Zigbee publish to '0x84182600000fb1c7', genOnOff - on - {} - 3 failed with error Error: AF data request fails, status code: 233\. MAC no ack. 2018-11-28 14:18:42.078 - error: zigbee.0 Zigbee publish to '0x84182600000fb1c7', genOnOff - read - [{"attrId":0}] - 3 failed with error Error: AF data request fails, status code: 233\. MAC no ack. 2018-11-28 14:20:07.516 - error: zigbee.0 Zigbee publish to '0x84182600000fa3fa', genOnOff - read - [{"attrId":0}] - 3 failed with error Error: AF data request fails, status code: 205\. No network route. Please confirm that the device has (re)joined the network. 2018-11-28 14:20:29.491 - error: zigbee.0 Zigbee publish to '0x84182600000fa3fa', genOnOff - on - {} - 3 failed with error Error: AF data request fails, status code: 205\. No network route. Please confirm that the device has (re)joined the network. 2018-11-28 14:20:30.196 - error: zigbee.0 Zigbee publish to '0x84182600000fa3fa', genOnOff - read - [{"attrId":0}] - 3 failed with error Error: AF data request fails, status code: 205\. No network route. Please confirm that the device has (re)joined the network. 2018-11-28 14:20:55.040 - error: zigbee.0 Zigbee publish to '0x84182600000fb1c7', genOnOff - on - {} - 3 failed with error Error: AF data request fails, status code: 233\. MAC no ack. 2018-11-28 14:20:55.735 - error: zigbee.0 Zigbee publish to '0x84182600000fb1c7', genOnOff - read - [{"attrId":0}] - 3 failed with error Error: AF data request fails, status code: 233\. MAC no ack. !

3. Die Reichweite ist klar geringer als bei Homematic. Dennoch scheint mir das bei mir (im Vergleich zu anderen Schilderungen hier) ziemlich schlecht.

Könnte es sein, dass WLAN da stört. Wo ich die meisten Probleme habe, ist ein UBIQUITY AccessPoint nur 3 m entfernt.

Kann man da was mit Kanaländerung erreichen? Sind die Kanäle analog zum WLAN 2,4 GHz?

4. Lokales Schalten der Plugs (scheinbar insbesondere das Ausschalten) wird erst nach Minuten in den Objekten angezeigt. Ist das normal?

5. Erfolgloses Schalten (also ein "true" ins State-Objekt schreiben) wird nicht erkannt. Das "true" bleibt im Objekt stehen.

Ist die Kommunikation nicht bidirektional?

Erfährt der Stick / Adapter nicht, dass ein Schaltbefehl angekommen und verarbeitet ist?

Falls er es erfährt, warum bleibt dann der State auf "true"?

Vielleicht könnte man (wo es sinnvoll ist) ein Objekt hinzufügen "LastActionResponse", so das man erkennen kann, ob der letzte Befehl vom Aktor bestätigt wurde.

Zuletzt: Liebe Entwickler, bitte versteht meine Ergüsse nicht als Nörgeln. Ich habe höchsten Respekt vor eurer Arbeit. Zudem ist der Adapter ja noch in Entwicklung und Beta. Ich möchte konstruktiv an der Weiterentwicklung mitarbeiten - soweit mir das als "nur" Anwender mögluich ist.

Gruß

Manfred

[Arnulf]

Also alle deine Beobachtungen hören sich nach einem Netzwerk mit zu vielen Abbrüchen oder Störungen an.

Da ich wahrscheinlich bald einen ähnlichen Aufbau habe, werde ich auch mal testen

[oetti]

@hmanfred:

4. Lokales Schalten der Plugs (scheinbar insbesondere das Ausschalten) wird erst nach Minuten in den Objekten angezeigt. Ist das normal? `

Hast du noch irgendetwas anderes zum Testen (Hue-Lampen, Tradfri o.ä.)?

Ich habe meinen kompletten Osram-Teile (Gateway, Plugs, Lampen) mittlerweile alle verkauft. Warum?

Der "normale" Osram-Aufbau (Gateway + Plug (5m Entfernung)) hat schon nicht berauschend funktioniert. Teilweise lange Schaltzeiten, Disconnects o.ä.

Im Anschluss habe ich die Plugs und Lampen mal testweise an der HUE-Bridge angelernt. Damit wurde es etwas besser, jedoch waren die HUE deutlich schneller beim Umschalten, Dimmen oder was auch immer - egal über welchen Weg (HUE-App, FHEM, …).

Kurzum, ich war von den Osram-Teilen nicht wirklich begeistert. Vllt waren es alles Montagsgeräte - vllt musste das auch so sein.

Wer weiß. Wenn du hast, teste mal was anderes.

Gruß

oetti

[hmanfred]

@oetti: nein, habe leider nur die Aqara Teile und die drei Osram Plugs.

Zu den anderen Themen bin ich jedoch ein Stück weiter gekommen. Der AccessPoint hat tatsächlich im gleichen Frequenzband gesendet, wie das ZigBee.

Hier mal zwei Links, die mir da immens weiter geholfen haben:

https://www.digitalzimmer.de/artikel/wi … alwechsel/

https://www.elektronik-kompendium.de/si … 712061.htm

Zusammenfassend kann man folgendes sagen (betrifft das 2,4 GHz Band):

Die WLAN Kanäle 1 bis 13 liegen fast deckungsgleich auf den ZigBee Kanälen 11 bis 24. Kanalabstand jeweils 5 MHz.

Die ZigBee Kanäle haben eine Bandbreite von 5 MHz. Das heißt, dass die Sende-/Empfangsfrequenz dort aufhört, wo der Nachbarkanal anfängt.

Die WLAN Kanäle haben eine Bandbreite von 20 oder 40 MHz. Damit funken sie also über 4 oder gar 8 Kanäle. Sie belegen also jeweils nach oben und unten 2 bzw. 4 Nachbarkanäle.

Ich habe den ZigBee Kanal auf 11 gelassen. Der kann von den WLAN Kanälen 4 und kleiner gestört werden. Ich habe also das WLAN fest auf Kanal 11 (das ist bei ZigBee der Kanal 22) eingestellt - also möglichst weit weg. Dass es schwache Netze aus der Nachbarschaft gibt, die auch Kanal 11 benutzen halte ich für unkritisch.

Das Ergebnis war eine massive Verbesserung der beschriebenen Symptome. Allerdings gibt es immer noch manchmal erhebliche Lags bzgl. Schaltbefehlen oder Statusmeldungen.

Was nun noch offen ist, packe ich jetzt mal in einzelne Beiträge.

Gruß

Manfred

[hmanfred]

Hier noch mal mein momentan drängendstes Problem:

Der Aqara Temperatursensor (das quadratische Teil von XIAOMI) weigert sich beharrlich, einen Osram smart+ Plug als Router anzuerkennen. Sobald er außer Reichweite des Sticks und in sichere Reichweite eines (oder gar mehrerer) Plugs gebracht wird, bleibt er aus Sicht des Adapters stumm. Auch nachdem er gelöscht und neu (in Reichweite des Sticks) angelernt wurde.

Ist es denn so, dass das Anlernen in Reichweite des zu benutzenden Routers geschehen muss?

Gibt es hier jemanden, der diesen Sensor erfolgreich über einen Osram Plug (oder wenigstens über ein anderes Gerät) geroutet bekommt?

[Kueppert]

Hi, bei mir sieht die Karte anders aus, aber ja, ich habe es über ein Osram Plug schon geschafft, die Aquara Sensoren anzulernen. Braucht halt Mal Post mehr Versuche, ab und zu beim Sensor 1x das Köpfchen drücken…

Gesendet von meinem HUAWEI RIO-L01 mit Tapatalk

[Homer.J.]

Hallo Arteck,

Hab heut auf Node.js v8.14.0 ein update gemacht seitdem bleibt der Adapter rot.

Hab den Adapter nochmal vollständig gelöscht und wollte Ihn neu Installieren geht aber nicht mehr.

Grüße Steffen

[arteck]

@Homer1976:

Hallo Arteck,

Hab heut auf Node.js v8.14.0 ein update gemacht seitdem bleibt der Adapter rot.

Hab den Adapter nochmal vollständig gelöscht und wollte Ihn neu Installieren geht aber nicht mehr.

Grüße Steffen `

hast du ein reinstall des iobroker gemacht nach dem update. ?? es werden alle Adapter neu installiert.. das dauert muss aber sein

[dimaiv]

Hi Arteck,

ich habe neue Fehler entdeckt:

No state available for '4052899926110' with key 'transition_time'

Vor paar Tagen hat noch funktioniert.

Danke.

[Homer.J.]

@arteck:

@Homer1976:

Hallo Arteck,

Hab heut auf Node.js v8.14.0 ein update gemacht seitdem bleibt der Adapter rot.

Hab den Adapter nochmal vollständig gelöscht und wollte Ihn neu Installieren geht aber nicht mehr.

Grüße Steffen `

hast du ein reinstall des iobroker gemacht nach dem update. ?? es werden alle Adapter neu installiert.. das dauert muss aber sein `

Hab ich gemacht kann natürlich sein das er noch nicht ganz durch gelaufen ist warte mal noch.

[arteck]

@dimaiv:

Hi Arteck,

ich habe neue Fehler entdeckt:

No state available for '4052899926110' with key 'transition_time'

Vor paar Tagen hat noch funktioniert.

Danke. `

bissel mehr infos muss du mir schon geben.. was ist das für ein Device ?? Adapter Version ??

[dimaiv]

@arteck:

@dimaiv:

Hi Arteck,

ich habe neue Fehler entdeckt:

No state available for '4052899926110' with key 'transition_time'

Vor paar Tagen hat noch funktioniert.

Danke. `

bissel mehr infos muss du mir schon geben.. was ist das für ein Device ?? Adapter Version ?? `

Device: LIGHTIFY Indoor Flex RGBW

7cb03eaa00adea74

Adapter: 0.8.0b, aktuelste aus deinem repo.

P.S.: habe gerade über dein repo aktualisiert, und ist ganz kaputt gegangen:

! 018-11-28 21:25:08.084 info Restart adapter system.adapter.zigbee.0 because enabled
! host.raspberrypi 2018-11-28 21:25:08.084 error instance system.adapter.zigbee.0 terminated with code 6 (uncaught exception)
! Caught 2018-11-28 21:25:08.084 error by controller[7]: 2018-11-28T20:25:07.084Z zigbee:controller info zigbee-shepherd stopped undefined
! Caught 2018-11-28 21:25:08.084 error by controller[6]: Wed, 28 Nov 2018 20:25:07 GMT zigbee-shepherd zigbee-shepherd is stopped.
! Caught 2018-11-28 21:25:08.084 error by controller[5]: Wed, 28 Nov 2018 20:25:07 GMT cc-znp The serialport /dev/serial/by-id/usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B000E896DEE-if00 is closed.
! Caught 2018-11-28 21:25:08.083 error by controller[4]: Wed, 28 Nov 2018 20:25:07 GMT cc-znp:SREQ –> ZDO:mgmtPermitJoinReq, { addrmode: 15, dstaddr: 65532, duration: 0, tcsignificance: 0 }
! Caught 2018-11-28 21:25:08.083 error by controller[3]: Wed, 28 Nov 2018 20:25:07 GMT zigbee-shepherd:request REQ –> ZDO:mgmtPermitJoinReq
! Caught 2018-11-28 21:25:08.083 error by controller[2]: Wed, 28 Nov 2018 20:25:07 GMT zigbee-shepherd zigbee-shepherd is stopping.
! Caught 2018-11-28 21:25:08.083 error by controller[1]: at Manager.Emitter.emit (/opt/iobroker/node_modules/socket.io-client/node_modules/component-emitter/index.js:133:20)
! Caught 2018-11-28 21:25:08.083 error by controller[1]: at Manager. <anonymous>(/opt/iobroker/node_modules/component-bind/index.js:21:15)
! Caught 2018-11-28 21:25:08.083 error by controller[1]: at Socket.onpacket (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:236:12)
! Caught 2018-11-28 21:25:08.082 error by controller[1]: at Socket.onack (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:312:9)
! Caught 2018-11-28 21:25:08.082 error by controller[1]: at Socket.adapter.getState (/opt/iobroker/node_modules/iobroker.zigbee/main.js:727:17)
! Caught 2018-11-28 21:25:08.082 error by controller[1]: at options (/opt/iobroker/node_modules/iobroker.zigbee/main.js:87:21)
! Caught 2018-11-28 21:25:08.082 error by controller[1]: at publishFromState (/opt/iobroker/node_modules/iobroker.zigbee/main.js:576:15)
! Caught 2018-11-28 21:25:08.082 error by controller[1]: at Array.forEach (<anonymous>)
! Caught 2018-11-28 21:25:08.082 error by controller[1]: at stateList.forEach (/opt/iobroker/node_modules/iobroker.zigbee/main.js:593:35)
! Caught 2018-11-28 21:25:08.081 error by controller[1]: at Object.convert (/opt/iobroker/node_modules/zigbee-shepherd-converters/converters/toZigbee.js:65:27)
! Caught 2018-11-28 21:25:08.081 error by controller[1]: TypeError: value.includes is not a function
! zigbee.0 2018-11-28 21:25:07.085 info zigbee-shepherd stopped
! zigbee.0 2018-11-28 21:25:07.050 error at Manager.Emitter.emit (/opt/iobroker/node_modules/socket.io-client/node_modules/component-emitter/index.js:133:20)
! zigbee.0 2018-11-28 21:25:07.050 error at Manager. <anonymous>(/opt/iobroker/node_modules/component-bind/index.js:21:15)
! zigbee.0 2018-11-28 21:25:07.050 error at Socket.onpacket (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:236:12)
! zigbee.0 2018-11-28 21:25:07.050 error at Socket.onack (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:312:9)
! zigbee.0 2018-11-28 21:25:07.050 error at Socket.adapter.getState (/opt/iobroker/node_modules/iobroker.zigbee/main.js:727:17)
! zigbee.0 2018-11-28 21:25:07.050 error at options (/opt/iobroker/node_modules/iobroker.zigbee/main.js:87:21)
! zigbee.0 2018-11-28 21:25:07.050 error at publishFromState (/opt/iobroker/node_modules/iobroker.zigbee/main.js:576:15)
! zigbee.0 2018-11-28 21:25:07.050 error at Array.forEach (<anonymous>)
! zigbee.0 2018-11-28 21:25:07.050 error at stateList.forEach (/opt/iobroker/node_modules/iobroker.zigbee/main.js:593:35)
! zigbee.0 2018-11-28 21:25:07.050 error at Object.convert (/opt/iobroker/node_modules/zigbee-shepherd-converters/converters/toZigbee.js:65:27)
! zigbee.0 2018-11-28 21:25:07.050 error TypeError: value.includes is not a function
! zigbee.0 2018-11-28 21:25:07.048 error uncaught exception: value.includes is not a function</anonymous></anonymous></anonymous></anonymous>

[Arnulf]

Ich habe auch eine Merkwürdigkeit entdeckt.

Ich weiß allerdings nicht, ob es am Zigbee Adapter oder am USB-Stick CC2531 liegt.

Ich habe mehere Xiaomi Aqara Fenstersensoren eingesetzt.

Alle zur gleichen Zeit eingebaut. Batterie sollte also einigermaßen gleich stark sein.

Mit meinem bisherigen Xiaomi MiHome-Adapter und einem Original Gateway haben alle Adapter so +/- ähnliche Batteriewerte gehabt.

Nun schwanken die Werte zwischen 55% und 100%. Meist 99%. Das kann ja nicht stimmen. Zumindest Werte über 95% sind merkwürdig.

Vor dem Umstieg auf Zigbee Stick und Adapter waren noch Werte um die 79% zu lesen.

Ich setze den Zigbee-Adapter 0.8.0b ein.

[hmanfred]

@hmanfred:

Der Aqara Temperatursensor (das quadratische Teil von XIAOMI) weigert sich beharrlich, einen Osram smart+ Plug als Router anzuerkennen… `

@Kueppert:

…ja, ich habe es über ein Osram Plug schon geschafft, die Aquara Sensoren anzulernen. Braucht halt Mal Post mehr Versuche, ab und zu beim Sensor 1x das Köpfchen drücken... `

Du glaubst gar nicht, wie oft ich schon das Knöpfchen gedrückt habe. Und wie oft ich den Sensor schon neu angelernt habe…

Das kanns nicht sein. Mein Verständnis der ZigBee Spezifikationen sagt, dass sich Sensoren in einem bestehenden Netzwerk selbsttätig ihre Routen wählen und diese auch mal spontan wechseln können.

Mein Fazit ist und bleibt: irgendeiner hält sich nicht an die Spezifikationen...

• der Sensor?

• der Osram Plug?

• der Stick?

• der Adapter?

Um diese Frage zu beantworten fehlt mir nun aber leider das tiefere Wissen.

[arteck]

ich verstehe deine Frustration aber… mach dir das leben nicht so schwer.. es ist egal wo das einzelne Geräte anlernst ..

ob an dem Plug oder einer Lampe oder direkt am Stick.. der sucht sich ehh den Weg selber und dieser ist nicht immer der direkte/kürzeste

das ist halt so mit den Netzen.. also nimm den Sensor geh zum Stick und leren den da direkt an..

aber bevor du das machst .. aktualisier den Adapter zuerst über die Katze : https://github.com/ioBroker/ioBroker.zigbee

Ilya hat gestern abend noch Änderungen gemacht... deshalb

[hmanfred]

@arteck:

ich verstehe deine Frustration aber… `

Naja, Frustration kann man nicht sagen. Das sind halt flüchtige Emotionen, die im Zuge solcher Tests auftreten.

Ich wiederhole mich: das ändert nichts an dem Respekt, den ich euch zolle. Wenn man bedenkt, dass das alles als Hobby läuft.

Auch wenn es sich manchmal wie Frust anhört - ich sehe das als konstruktive Mitarbeit, um den Adapter voran zu bringen.

Um zum Problem zurück zu kommen:

Ich habe den Sensor gelöscht (schau dir bitte die Dialogbox mal an - Wortdreher :lol: ) und versucht neu zu pairen.

Das Pairing über den grünen Button am Plug zu starten hat nichts gebracht. Es kam immer "cannot get node descriptor".

Anlernen am Stick war dann erfolgreich. Und jetzt - nach einer Stunde - oh Wunder… der Sensor zeigt in der Netzwerkkarte, dass er über die Osram Plug kommt.

Habe ihn jetzt mal wieder an Ort und Stelle gebracht, nahe anderer Plug. Dort bleibt er erst mal stumm, auch mit Druck auf den Sendebutton. Ich warte aber jetzt mal ab.

[gently]

Ich habe das gleiche Problem wie „hmanfred“. Habe mittlerweile 15 Geräte in meinem Netzwerk.

Habe beide Kinderzimmer mit LED Stripes ausgestattet. Diese kann ich über die Visu steuern. Wenn ich die Helligkeit über Visu ändere, werden die ersten 2-3 Befehle umgesetzt und dann hängt alles. Nach einiger Zeit gehen dann ein paar Befehle wieder durch. Das ganz ist reproduzierbar, wenn ich die Stufen direkt über Iobroker –> Objekte von „Hand“ ändere.

Habe am Anfang gedacht, dass mein Raspi zu schwach ist. Alles neu aufgesetzt und wirklich nur das nötigste laufen lassen. Leider kein Erfolg. Wenn ich den Raspi direkt in den Raum bringe und somit direkt eine Verbindung zwischen USB Stick und Zigbee Trafo habe, geht das wesentlich besser aber irgendwann hängen auch dann die Befehle.

Im Log kommen Fehlermeldungen: „No network route. Please confirm that the device has (re)joined the network.“

Ich habe keine Idee mehr, wie die Sache optimieren kann.

Trotzdem „Hut ab“ für das tolle Projekt. Bin begeistert!

[arteck]

@hmanfred:

@arteck:

ich verstehe deine Frustration aber… `

Naja, Frustration kann man nicht sagen. Das sind halt flüchtige Emotionen, die im Zuge solcher Tests auftreten.

Ich wiederhole mich: das ändert nichts an dem Respekt, den ich euch zolle. Wenn man bedenkt, dass das alles als Hobby läuft.

Auch wenn es sich manchmal wie Frust anhört - ich sehe das als konstruktive Mitarbeit, um den Adapter voran zu bringen.

Um zum Problem zurück zu kommen:

Ich habe den Sensor gelöscht (schau dir bitte die Dialogbox mal an - Wortdreher :lol: ) und versucht neu zu pairen.

Das Pairing über den grünen Button am Plug zu starten hat nichts gebracht. Es kam immer "cannot get node descriptor".

Anlernen am Stick war dann erfolgreich. Und jetzt - nach einer Stunde - oh Wunder… der Sensor zeigt in der Netzwerkkarte, dass er über die Osram Plug kommt.

Habe ihn jetzt mal wieder an Ort und Stelle gebracht, nahe anderer Plug. Dort bleibt er erst mal stumm, auch mit Druck auf den Sendebutton. Ich warte aber jetzt mal ab. `

na schau das klingt doch mal gut..jetzt nimm den plug mal raus der an dem Sensor in der nähe ist aus der Steckdose.. zähl bis 10 und dann steck den wieder rein.. der müsste sich reconnecten und den Sensor finden…

probier mal

[arteck]

@gently:

Im Log kommen Fehlermeldungen: „No network route. Please confirm that the device has (re)joined the network.“

Ich habe keine Idee mehr, wie die Sache optimieren kann.

Trotzdem „Hut ab“ für das tolle Projekt. Bin begeistert! `

das heisst das die Geräte sich nicht finden können.. warum auch immer.. welche sind es den du sprichst von 15 Geräten..