Shelly RGB Bulb Farbsteuerung

[wireless-dj]

Bitte airStudio erneut runterladen, installieren, ein Firmware Update durchführen und die Konfiguration übertragen. Dann sollte die Szene als auch das Logging korrekt funktionieren.

Hallo,

leider nein.
Im Log sind beim Request Fehler - da fehlen die "&" Zeichen, oder nicht?:

Bildschirmfoto 2023-05-17 um 17.28.20.png (325.98 KiB) 5084 mal betrachtet

[jbmedia]

Die &-Zeichen werden im Logging aktuell durch Leerzeichen ersetzt, da sich das &-Zeichen nicht mit der dahinterliegenden Datenbank verträgt. Dies war die Ursache, warum das Logging vorher merkwüridg aussah. Wir arbeiten an einer Lösung dafür. Die Befehle sollten nun aber sauber abgearbeitet werden.

[wireless-dj]

Hallo,

Also, mit der Version aus dem Posting von 17:07 Uhr heute, wird nur eine Bulb rot eingeschaltet.
Mehr passiert nicht. Der Farbwechsel und auch das Ausschalten geschehen nicht.
Das „Failed“ im Log macht mich auch stutzig.

Aber, ich warte natürlich auf das, was da noch kommt.
Vielen Dank und ein schönes Wochenende!

[jbmedia]

Failed darf dort natürlich nicht auftauchen, das hatten wir gar nicht gesehen. Failed bedeutet, dass keine Verbindung zum Ziel aufgebaut werden kann. Manche Verbindungen funktionieren jedoch, dort steht kein Failed. Bitte prüfen, ob die Lampen wirklich online sind.

[wireless-dj]

Bitte prüfen, ob die Lampen wirklich online sind.

Ja, sind online - definitiv. Sie sind auch direkt und ohne Repeater mit der Fritz! Box verbunden.
Wenn ich sie hier manuell mit dem "TEST" schalte, dann passiert auch sofort was:

Bildschirmfoto 2023-05-18 um 07.51.56.png (93.81 KiB) 5039 mal betrachtet

Allerdings trifft die Farbauswahl im Ergebnis meist nicht zu - vielleicht ist auch das ein Problem
für die Abarbeitung der Szene?

Auch wenn ich die Bulbs aus dem Shelly Webinterface schalte - dann reagieren sie schnell und sofort.
Es scheint so, als würde eine Szene die notwendigen Befehle nicht richtig abgeben.

Manchmal taucht diese Test-Szene im Log auch teilweise gar nicht auf.

Und, mit den Pausen sollte die Szene eigentlich in 4-5 Sekunden abgearbeitet sein, das dauert irgendwie auch immer 15-20 Sekunden
Hierbei scheint es, als wäre der LMAir beschäftigt, oder nicht in der Lage, die Befehle in der Zeit hintereinander abzuarbeiten.

Und was mir noch aufgefallen ist, ist dass die Einbindung der Aktoren in der Verwaltung beim Aktualisieren manchmal
von RGBW Controller auf Schalter springt, wenn vorher nicht per "ok" betätigt wurde.

Alles in Allem ist die Einbindung der RGB Bulbs und das Abarbeiten einer Szene leider noch sehr unzuverlässig.

[jbmedia]

Wir haben die Szene nun unter Real-Bedingungen getestet, Ergebnis anbei. Wie man sieht, läuft diese sauber durch und benötigt knapp 5 s.

Auf die Farbe haben wir keinen Einfluss. Es werden die korrekten RGB Werte übermittelt. Es obliegt dem Leuchtmittel, das Beste daraus zu machen. Bei dem Shelly RGB Controller für LED Streifen stimmen die Farben recht gut überein.

1.jpg (105.86 KiB) 4973 mal betrachtet

[wireless-dj]

Moin,

Tja, was soll ich sagen... Bei mir läuft sie nicht durch.
Bei Ihnen in der Szene ist es nur 1 Leuchtmittel - bei mir sind es 4. Macht das einen Unterschied?

Wenn der LMAir mit anderen Dingen beschäftigt ist, vielleicht hat er dann gerade nicht die
Möglichkeit, einen Befehl abzusetzen? Ich kann Ihnen ja nur sagen, was geht, und was nicht.

Wir hatten ein ähnliches Problem schon mal. Da gingen auch http-Requests verloren.
https://www.jbmedia.de/forum/viewtopic.php?f=12&t=5470

Für mein Verständnis kann es eigentlich nur ein Problem in AirStudio oder dem LMAir selbst sein.
Vielleicht ist die Leistung begrenzt, oder Zwangspausen zwischen dem Absetzen von Befehlen, oder, oder, oder.

Ich habe ein Experiment gemacht, und mir eine kleine PHP-Datei geschrieben.
In dieser Datei werden nacheinander viele http-reqests mit Pausen dazwischen an meine 4 Bulbs gesendet.
Ähnlich der Szene, die wir hier im Beispiel haben.
Wenn ich diese Datei aufrufe, werden die 4 Bulbs präzise angesteuert, und diese "Szene" läuft komplett
und fehlerfrei ab. Daraus schliesse ich, dass es kein Problem im Netzwerk gibt, und somit lässt es
- so leid es mir auch tut - nur den Rückschluss zu, dass die Ursache dafür in AirStudio oder im LMAir zu finden sein kann.

Mir ist durchaus klar, dass dies ein blödes Problem ist, und es schwierig ist, da einen Ansatz zu finden,
aber irgendwo flutscht da was durch. Möglicherweise liegt das auch ganz tief im Kern für die LAN-Einbindung,
denn der o.g. Thread liegt ja nun auch schon ein ganzes Jahr zurück.

Ich bin ratlos.

[jbmedia]

Bei Ihnen in der Szene ist es nur 1 Leuchtmittel - bei mir sind es 4. Macht das einen Unterschied?

Da wir nur ein Shelly Bulb da haben, wurden die IPs der Leuchtmittel angepasst. Für den Light-Manager macht es keinen Unterschied, welche IP angesteuert wird.

Wenn der LMAir mit anderen Dingen beschäftigt ist, vielleicht hat er dann gerade nicht die
Möglichkeit, einen Befehl abzusetzen?

Sobald eine Szene gestartet wurde, ist der Light-Manager für andere Aufgaben blockiert. Die Szene hat Priorität.

In dieser Datei werden nacheinander viele http-reqests mit Pausen dazwischen an meine 4 Bulbs gesendet.

Ist der PC, auf dem das Skript läuft, mit demselben Access Point per WLAN verbunden wie der Light-Manager?

aber irgendwo flutscht da was durch. Möglicherweise liegt das auch ganz tief im Kern für die LAN-Einbindung,
denn der o.g. Thread liegt ja nun auch schon ein ganzes Jahr zurück.

Wir auch. Wir können die Szene beliebig oft ausführen, sie wird stest fehlerfrei verarbeitet. Die Shelly Integration ist nun auch schon recht lange drin, ohne dass ein derartiger Fehler schonmal gemeldet worden wäre.

[wireless-dj]

Ist der PC, auf dem das Skript läuft, mit demselben Access Point per WLAN verbunden wie der Light-Manager?

Das Script läuft auf einem NAS Server, der im gleichen Netzwerk per LAN angebunden ist.

Die Shelly Integration ist nun auch schon recht lange drin, ohne dass ein derartiger Fehler schonmal gemeldet worden wäre.

Es gibt immer mal wieder das Problem, dass ein Befehl durch rutscht und nicht beim Aktor ankommt.
Sowohl Funk, als auch LAN. Oder auch, dass Aktoren geschaltet werden, die in einer Szene gar nicht enthalten sind.
Es passiert immer wieder mal, dass ein Trust-Aktor auslöst, der in einer Szene gar nicht enthalten ist, oder
plötzlich ein Shelly Plug-S irgendwo in einer Szene ein Licht einschaltet, obwohl er darin gar nicht enthalten ist.
Ich habe das für mich aber immer mit "es ist halt Funk" begründet. Ein Funksignal kann ja immer mal gestört sein.
Vielleicht ist meine Aktoren-Liste auch schon zu voll, oder meine Konfiguration zu umfangreich - oder mein
Netzwerk enthält zu viele Geräte - keine Ahnung.

OK sei es, wie es ist.
Ich habe jetzt dieses PHP-Script als LAN-Aktor angelegt, und kann das dann mit dem LMAir aufrufen.
Das funktioniert tatsächlich sehr gut.
Ich werde dann die Requests im Script hinterlegen - ist sowieso nur eine Spielerei.
Ist zwar nicht so komfortabel, und so auch nicht gedacht, aber es ist zumindest ein Weg.

[jbmedia]

Das Script läuft auf einem NAS Server, der im gleichen Netzwerk per LAN angebunden ist.

Das hatten wir vermutet und damit ist der Test nicht aussagekräftig. Der Sender müsste im selben WLAN, also am selben Access Point hängen wie der Light-Manager, um eine relevante Prüfung zu machen. Unsere Vermutung ist ja, dass das Problem auf dieser Verbindung auftritt.