Neues Modul: 30_MilightBridge / 31_MilightDevice

[speex]

Ola, ich hab heute mal ein Update gemacht und festgestellt das die modifizierte Milight_device.pl bei mir auf einmal Fehler im Log erzeugt wie folgt:

Code Auswählen Erweitern

2015.09.22 22:25:05 1: PERL WARNING: Use of uninitialized value $cv in concatenation (.) or string at ./FHEM/31_MilightDevice.pm line 1076.
2015.09.22 22:25:11 1: PERL WARNING: Use of uninitialized value $devname in hash element at ./FHEM/31_MilightDevice.pm line 2082.

Funktioniert ansonsten aber bisher.

Die queues mit pq muss ich noch testen.

[Jumbo]

Auch mit tcp stürzt FHEM mir ab. Hier ne Fehlermeldung aus der nacht.

Code Auswählen Erweitern

2015.09.23 04:52:33.210 1: 192.168.1.56:1000 reappeared (HMLAN1)
2015.09.23 04:52:33.211 1: HMLAN_Parse: HMLAN1 new condition init
2015.09.23 04:52:36.237 1: HMLAN_Parse: HMLAN1 new condition ok
<h1>Software error:</h1>
<pre>Can't udp protocol by name at ./FHEM/30_MilightBridge.pm line 207.
</pre>
<p>
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.

</p>
[Wed Sep 23 06:28:04 2015] fhem.pl: Can't udp protocol by name at ./FHEM/30_MilightBridge.pm line 207.

ne idee wo ich noch suchen kann ?

[Markus M.]

Ola, ich hab heute mal ein Update gemacht und festgestellt das die modifizierte Milight_device.pl bei mir auf einmal Fehler im Log erzeugt

Wenn du ein Update gemacht hast, hast du keine modifizierte Datei mehr sondern wieder die alte Version.
Ich komme erst am Wochenende dazu, die Dateien zu aktualisieren.

Auch mit tcp stürzt FHEM mir ab.

Das Modul war da leider etwas unglücklich programmiert und hat trotzdem UDP initialisiert.
Probier mal die Dateien im Anhang neue Version aus, damit könnte es mit TCP vielleicht klappen. (Muss aber nicht)
Generell ist das aber kein Problem des Moduls - irgendwas ist an deinem Perl oder OS kaputt.


Die letzten Änderungen sind morgen per Update erhältlich (r9297):
- Keine Log Warnungen mehr (Device)
- previousState verbessert, Ausschalten dabei gesondert behandelt um das bekannte Einschaltblitzen zu verhindern (Device)
- Ping Definition UDP/TCP geändert (Bridge)

[speex]

Hi Danke, wollte gerade noch ergänzen das ich natürlich nach dem Update die modifizierte Version wiederhergestellt habe...

Werde jetzt erstmal die neue Version testen, vielen Dank erstmal bis hierhin!

Update: Begeisterung , läuft in den ersten Tests erste Sahne!

[Markus M.]

Ein bisschen Perfektionismus am Sonntag:
Nachdem ich die Lampen mittlerweile auch für farbige Blinksignale ohne Ramp verwende, ist mir aufgefallen dass immer zuerst Farbe und dann Helligkeit umgeschaltet werden.
Beim Zurücksetzen auf eine niedrigere Helligkeit führt das aber leider zu einem unschönen Farb-Blitzen.

Die Version im Anhang schaltet die Farbe deshalb nun immer bei der geringeren Helligkeit um.
Bitte testen

Markus

[speex]

Hi genau das wollte Ich heute auch ergänzen ich habe die neue Version aus deinem Anhang getestet allerdings bleibt bei mir das Blitzen bestehen.

Wenn ich zb. auf die Farbe Rot wechsel und dann die Lampen ausmache und wieder auf Hell weiss gedimmt anmache blitzt es bei mir Rot auf dann wird auf Weiß gewechselt und gedimmt.

[Markus M.]

Wenn ich zb. auf die Farbe Rot wechsel und dann die Lampen ausmache und wieder auf Hell weiss gedimmt anmache blitzt es bei mir Rot auf dann wird auf Weiß gewechselt und gedimmt.

Das ist normal und lässt sich leider nicht vermeiden.
Die Lampe merkt sich beim Ausschalten den letzten Status und hat beim Einschalten anfangs wieder diesen Zustand.
Das sollte aber eigentlich immer die niedrigste Helligkeitsstufe sein.

Die Änderung von heute wirkt nur beim direkten Umschalten ohne Übergang, z.B. von 100% Rot auf 10% Grün:
Vorher: 100% Rot -> 100% Grün -> 10% Grün
Jetzt:    100% Rot -> 10% Rot     -> 10% Grün

[roman1528]

Moin.

Leider habe ich zu meinem Problem nichts im Forum gefunden und denke, dass es hier am besten aufgehoben ist?!

Bei einem Neustart meines RPi bzw. von FHEM werden alle meine MiLightDevices auf Blau 100% eingeschaltet.
Blau ist zwar mein Favorit aber nicht in meinem Sinne, da es nunmal vorkommen kann, dass ich einen Reboot machen muss.

Gibt es dafür eine Lösung oder ein Workaround um das Einschalten der Lampen zu verhindern? Ich vermute, dass das passiert wenn sich FHEM bzw. das MilightBridge-Modul mit dem WiFi-Controller verbindet.

Vielen Dank im Vorraus
Grüße

[mattwire]

@roman1528: Ich auch...

Konntest du bitte Dieses Aenderung prufen?

(CHANGED: MilightDevice_Init moved from Define to Notify to prevent execution before init_done)

[roman1528]

@roman1528: Ich auch...

Konntest du bitte Dieses Aenderung prufen?

(CHANGED: MilightDevice_Init moved from Define to Notify to prevent execution before init_done)

Das hat leider nur geändert das meine Stehlampe im tatsächlichen savedState (nämlich gelb statt blau) angegangen ist.

Ein Workaround (zumindest für mich, da ich savedState nicht nutze) ist: Die Lampe/n über FHEM auszuschalten, und dann "set slotX saveState" auszuführen. Das Reading savedState müsste dann so aussehen:
XXX,XXX,0 <- wobei X für eine beliebige Zahl von 0-9 steht... hsv-Wert halt.

Für weitere Test stehe ich gern zur Verfügung

EDIT:

Vergestt den Workaround ... jetzt gehen sie natürlich aus, wenn sie an sind.... doof xD

[Niko1987]

Hallo,

ich habe seit kurzem eine LIGHTEU Milight Wlan/WIFI 2.4G RG LED Lampe E14.
Integration in FHEM über MilightBridge- und MilightDevice-Modul.

Leider kann ich die lampe nicht über FHEM ausschalten. Das ausschalten funktioniert zwar aber die Lampe geht nach ein paar minuten wieder an. Leider weis ich auch nicht wie ich es schaffe einen Filelog zu erstellen. Bei mir ist zu den Milights kein FileLog vorhanden.

Kennt jemand das Problem und kann mir vielleicht helfen?

Danke & Gruß Flo

[thsm]

Hallo zusammen,

Vielleicht kann mir wer hier weiterhelfen. Ich habe eine v4 Bridge  mit mehreren LED Milight Birnen am laufen.
Über die IOS läuft alles einwandfrei. Vor Fhem habe ich alles auf Openhab betrieben, da lief auch die Steuerung reibungslos.
Mit dem Milight Modul unter Fhem bekomme ich aber bei Status unreachable angezeigt.
IP Adresse habe ich überprüft, Port ist 8899.
Der einzige Grund der mir noch einfällt, ist dass ich Fhem auf eine, Windowsrechner betreibe mit Strawberry Perl. Sonst hab ich sowas wie Firewall etc. alles schon ausschliessen können.
Kann jemand das bestätigen, sprich Problem mit Fhem unter Windows und MilightModul ?
Danke
Gruss
Thorsten

[mart]

Ist euch aufgefallen dass Saturation keine Zwischenstufen kennt, es gibt nur 0 (weiß) oder 100 (volle Sättigung). Damit kann man eben nicht beliebig RGB mischen, zum Beispiel für "warmes weiß mit etwas weniger Blauanteil"=RGB #FFFFAA = HSV 60,23,100. Setze ich das bekomme ich HSV 60,100,100 = kräftiges gelb.

Das MilightDevice Modul kann dafür nichts. Die offizielle Milight App deutet das Problem ja schon an: dort kann man die Farbe auf dem Ring wählen (=Hue), und die Helligkeit (=Value). Saturation fehlt.

Siehe dazu auch meine Kommentare zu "Saturation" auf http://www.meintechblog.de/2014/12/die-naechste-hue-alternative-warmweisse-led-stripes-im-smart-home-steuern/

Meine Geräte:
Bridge http://www.amazon.de/gp/product/B00OH2ES9Q
GU10 RGBW http://www.amazon.de/gp/product/B016YGYPNQ

[yogiflop]

Hallo und guten Abend,

gibt es eine Möglichkeit, einen der DiscoModi direkt anzusprechen ?
Ich würde gerne für eine Alarmanlage den 6ten DiscoMode direkt ansprechen und nutzen.

gruß Marc

[speex]

Hallöchen hätte mal ne Feature-Frage gäbe es die Möglichkeit wenn man einen RGBW Controller als RGB Controller nutzt eine art Funktion zu kreieren sodass die Lampe praktisch als RGB behandelt wird oder eine art anderen Workaround vielleicht eine einfachere Lösung?

Das Problem ist zb. wenn ich über den Master die restlichen (RGBW-Lampen) auf weiss stelle geht der "RGBW-aliasRGB-Stripe" aus ist ja logisch weil kein weiss nun würd ich halt gerne eine Lösung basteln die dann zumindest beispielsweise Gelb für weiss bei dem RGB Stripe setzt, Ideen?